Re: [PATCH] D11743: [CMake] First pass at adding support for clang bootstrap builds to CMake
chandlerc accepted this revision.
chandlerc added a comment.
This revision is now accepted and ready to land.
Totally awesome man, ship it. I've left a nit-pick below, but this is
definitely the right starting place.
Comment at: CMakeLists.txt:615
@@ +614,3 @@
+
+ set(ADDITIONAL_TARGETS_TO_ADD check check-all)
+ foreach(target ${ADDITIONAL_TARGETS_TO_ADD})
nit pick: I'd call it 'check-llvm', 'check-clang', and 'check-all'. I'm OK if
we have to hard code the list though, that seems a minor inconvenience.
http://reviews.llvm.org/D11743
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r244065 - Fix a tiny bug in -no-canonical-prefixes that somehow we have never
Author: chandlerc
Date: Wed Aug 5 12:07:33 2015
New Revision: 244065
URL: http://llvm.org/viewvc/llvm-project?rev=244065&view=rev
Log:
Fix a tiny bug in -no-canonical-prefixes that somehow we have never
noticed until now.
The code for setting up the driver's InstalledDir didn't respect
-no-canonical-prefixes. Because of this, there are a few places in the
driver where we would unexpectedly form absolute paths, notably when
searching for and finding GCC installations to use, etc. The fix is
straightforward, and I've added this path to '-v' both so we can test it
sanely and so that it will be substantially more obvious the next time
someone has to debug something here.
Note that there is another bug that we don't actually *canonicalize* the
installed directory! I don't really want to fix that because I don't
have a realistic way to test the usage of this mode. I suspect that
folks using the shared module cache would care about getting this right
though, and so they might want to address it. I've left the appropriate
FIXMEs so that it is clear what to change, and I've updated the test
code to make it clear what is happening here.
Modified:
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/test/Driver/no-canonical-prefixes.c
cfe/trunk/tools/driver/driver.cpp
Modified: cfe/trunk/lib/Driver/Driver.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=244065&r1=244064&r2=244065&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed Aug 5 12:07:33 2015
@@ -762,6 +762,9 @@ void Driver::PrintVersion(const Compilat
} else
OS << "Thread model: " << TC.getThreadModel();
OS << '\n';
+
+ // Print out the install directory.
+ OS << "InstalledDir: " << InstalledDir << '\n';
}
/// PrintDiagnosticCategories - Implement the --print-diagnostic-categories
Modified: cfe/trunk/test/Driver/no-canonical-prefixes.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/no-canonical-prefixes.c?rev=244065&r1=244064&r2=244065&view=diff
==
--- cfe/trunk/test/Driver/no-canonical-prefixes.c (original)
+++ cfe/trunk/test/Driver/no-canonical-prefixes.c Wed Aug 5 12:07:33 2015
@@ -1,11 +1,17 @@
// Due to ln -sf:
// REQUIRES: shell
-// RUN: mkdir -p %t
-// RUN: cd %t
+// RUN: mkdir -p %t.real
+// RUN: cd %t.real
// RUN: ln -sf %clang test-clang
-// RUN: ./test-clang -v -S %s 2>&1 | FileCheck %s
-// RUN: ./test-clang -v -S %s -no-canonical-prefixes 2>&1 | FileCheck
--check-prefix=NCP %s
-
-
-// CHECK: /clang{{.*}}" -cc1
-// NCP: test-clang" -cc1
+// RUN: cd ..
+// RUN: ln -sf %t.real %t.fake
+// RUN: cd %t.fake
+// RUN: ./test-clang -v -S %s 2>&1 | FileCheck --check-prefix=CANONICAL %s
+// RUN: ./test-clang -v -S %s -no-canonical-prefixes 2>&1 | FileCheck
--check-prefix=NON-CANONICAL %s
+//
+// FIXME: This should really be '.real'.
+// CANONICAL: InstalledDir: {{.*}}.fake
+// CANONICAL: {{[/|\\]*}}clang{{.*}}" -cc1
+//
+// NON-CANONICAL: InstalledDir: .{{$}}
+// NON-CANONICAL: test-clang" -cc1
Modified: cfe/trunk/tools/driver/driver.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/driver.cpp?rev=244065&r1=244064&r2=244065&view=diff
==
--- cfe/trunk/tools/driver/driver.cpp (original)
+++ cfe/trunk/tools/driver/driver.cpp Wed Aug 5 12:07:33 2015
@@ -344,7 +344,7 @@ CreateAndPopulateDiagOpts(ArrayRef &argv,
- Driver &TheDriver) {
+ Driver &TheDriver, bool CanonicalPrefixes) {
// Attempt to find the original path used to invoke the driver, to determine
// the installed path. We do this manually, because we want to support that
// path being a symlink.
@@ -355,7 +355,11 @@ static void SetInstallDir(SmallVectorImp
if (llvm::ErrorOr Tmp = llvm::sys::findProgramByName(
llvm::sys::path::filename(InstalledPath.str(
InstalledPath = *Tmp;
- llvm::sys::fs::make_absolute(InstalledPath);
+
+ // FIXME: We don't actually canonicalize this, we just make it absolute.
+ if (CanonicalPrefixes)
+llvm::sys::fs::make_absolute(InstalledPath);
+
InstalledPath = llvm::sys::path::parent_path(InstalledPath);
if (llvm::sys::fs::exists(InstalledPath.c_str()))
TheDriver.setInstalledDir(InstalledPath);
@@ -473,7 +477,7 @@ int main(int argc_, const char **argv_)
ProcessWarningOptions(Diags, *DiagOpts, /*ReportDiags=*/false);
Driver TheDriver(Path, llvm::sys::getDefaultTargetTriple(), Diags);
- SetInstallDir(argv, TheDriver);
+ SetInstallDir(argv, TheDriver, CanonicalPrefixes);
llvm::InitializeAllTargets();
insertArgsFromProgramName(ProgName, DS, argv, SavedStrings);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin
r340515 - [x86/retpoline] Split the LLVM concept of retpolines into separate
Author: chandlerc
Date: Wed Aug 22 23:06:38 2018
New Revision: 340515
URL: http://llvm.org/viewvc/llvm-project?rev=340515&view=rev
Log:
[x86/retpoline] Split the LLVM concept of retpolines into separate
subtarget features for indirect calls and indirect branches.
This is in preparation for enabling *only* the call retpolines when
using speculative load hardening.
I've continued to use subtarget features for now as they continue to
seem the best fit given the lack of other retpoline like constructs so
far.
The LLVM side is pretty simple. I'd like to eventually get rid of the
old feature, but not sure what backwards compatibility issues that will
cause.
This does remove the "implies" from requesting an external thunk. This
always seemed somewhat questionable and is now clearly not desirable --
you specify a thunk the same way no matter which set of things are
getting retpolines.
I really want to keep this nicely isolated from end users and just an
LLVM implementation detail, so I've moved the `-mretpoline` flag in
Clang to no longer rely on a specific subtarget feature by that name and
instead to be directly handled. In some ways this is simpler, but in
order to preserve existing behavior I've had to add some fallback code
so that users who relied on merely passing -mretpoline-external-thunk
continue to get the same behavior. We should eventually remove this
I suspect (we have never tested that it works!) but I've not done that
in this patch.
Differential Revision: https://reviews.llvm.org/D51150
Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Basic/Targets/X86.cpp
cfe/trunk/lib/Basic/Targets/X86.h
cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
cfe/trunk/test/Driver/x86-target-features.c
Modified: cfe/trunk/include/clang/Driver/Options.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=340515&r1=340514&r2=340515&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed Aug 22 23:06:38 2018
@@ -1999,6 +1999,9 @@ def mno_rtd: Flag<["-"], "mno-rtd">, Gro
def mno_soft_float : Flag<["-"], "mno-soft-float">, Group;
def mno_stackrealign : Flag<["-"], "mno-stackrealign">, Group;
+def mretpoline : Flag<["-"], "mretpoline">, Group,
Flags<[CoreOption,DriverOption]>;
+def mno_retpoline : Flag<["-"], "mno-retpoline">, Group,
Flags<[CoreOption,DriverOption]>;
+
def mrelax : Flag<["-"], "mrelax">, Group,
HelpText<"Enable linker relaxation">;
def mno_relax : Flag<["-"], "mno-relax">, Group,
@@ -2824,8 +2827,6 @@ def mxsaves : Flag<["-"], "mxsaves">, Gr
def mno_xsaves : Flag<["-"], "mno-xsaves">, Group;
def mshstk : Flag<["-"], "mshstk">, Group;
def mno_shstk : Flag<["-"], "mno-shstk">, Group;
-def mretpoline : Flag<["-"], "mretpoline">, Group;
-def mno_retpoline : Flag<["-"], "mno-retpoline">, Group;
def mretpoline_external_thunk : Flag<["-"], "mretpoline-external-thunk">,
Group;
def mno_retpoline_external_thunk : Flag<["-"],
"mno-retpoline-external-thunk">, Group;
Modified: cfe/trunk/lib/Basic/Targets/X86.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.cpp?rev=340515&r1=340514&r2=340515&view=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/X86.cpp Wed Aug 22 23:06:38 2018
@@ -796,8 +796,6 @@ bool X86TargetInfo::handleTargetFeatures
HasCLDEMOTE = true;
} else if (Feature == "+rdpid") {
HasRDPID = true;
-} else if (Feature == "+retpoline") {
- HasRetpoline = true;
} else if (Feature == "+retpoline-external-thunk") {
HasRetpolineExternalThunk = true;
} else if (Feature == "+sahf") {
@@ -1397,7 +1395,6 @@ bool X86TargetInfo::hasFeature(StringRef
.Case("rdpid", HasRDPID)
.Case("rdrnd", HasRDRND)
.Case("rdseed", HasRDSEED)
- .Case("retpoline", HasRetpoline)
.Case("retpoline-external-thunk", HasRetpolineExternalThunk)
.Case("rtm", HasRTM)
.Case("sahf", HasLAHFSAHF)
Modified: cfe/trunk/lib/Basic/Targets/X86.h
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/X86.h?rev=340515&r1=340514&r2=340515&view=diff
==
--- cfe/trunk/lib/Basic/Targets/X86.h (original)
+++ cfe/trunk/lib/Basic/Targets/X86.h Wed Aug 22 23:06:38 2018
@@ -98,7 +98,6 @@ class LLVM_LIBRARY_VISIBILITY X86TargetI
bool HasMOVBE = false;
bool HasPREFETCHWT1 = false;
bool HasRDPID = false;
- bool HasRetpoline = false;
bool HasRetpolineExternalThunk = false;
bool HasLAHFSAHF = false;
bool HasWBNOINVD = false;
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp?rev=340515&r1=340514&r2=340515&view
Re: r294176 - [AVR] Add support for the full set of inline asm constraints
Sorry for ancient thread revival, but...
On Mon, Feb 6, 2017 at 2:10 AM Dylan McKay via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: dylanmckay
> Date: Mon Feb 6 03:01:59 2017
> New Revision: 294176
>
> URL: http://llvm.org/viewvc/llvm-project?rev=294176&view=rev
> Log:
> [AVR] Add support for the full set of inline asm constraints
>
> Summary:
> Previously the method would simply return false, causing every single
> inline assembly constraint to trigger a compile error.
>
> This adds inline assembly constraint support for the AVR target.
>
> This patch is derived from the code in
> AVRISelLowering::getConstraintType.
>
> More details can be found on the AVR-GCC reference wiki
> http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
>
> Reviewers: jroelofs, asl
>
> Reviewed By: asl
>
> Subscribers: asl, ahatanak, saaadhu, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D28344
>
> Added:
> cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
>
This test is currently failing. Can you look at fixing it?
> cfe/trunk/test/CodeGen/avr-unsupported-inline-asm-constraints.c
> Modified:
> cfe/trunk/lib/Basic/Targets.cpp
>
> Modified: cfe/trunk/lib/Basic/Targets.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=294176&r1=294175&r2=294176&view=diff
>
> ==
> --- cfe/trunk/lib/Basic/Targets.cpp (original)
> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Feb 6 03:01:59 2017
> @@ -8517,6 +8517,57 @@ public:
>
>bool validateAsmConstraint(const char *&Name,
> TargetInfo::ConstraintInfo &Info) const
> override {
> +// There aren't any multi-character AVR specific constraints.
> +if (StringRef(Name).size() > 1) return false;
> +
> +switch (*Name) {
> + default: return false;
> + case 'a': // Simple upper registers
> + case 'b': // Base pointer registers pairs
> + case 'd': // Upper register
> + case 'l': // Lower registers
> + case 'e': // Pointer register pairs
> + case 'q': // Stack pointer register
> + case 'r': // Any register
> + case 'w': // Special upper register pairs
> + case 't': // Temporary register
> + case 'x': case 'X': // Pointer register pair X
> + case 'y': case 'Y': // Pointer register pair Y
> + case 'z': case 'Z': // Pointer register pair Z
> +Info.setAllowsRegister();
> +return true;
> + case 'I': // 6-bit positive integer constant
> +Info.setRequiresImmediate(0, 63);
> +return true;
> + case 'J': // 6-bit negative integer constant
> +Info.setRequiresImmediate(-63, 0);
> +return true;
> + case 'K': // Integer constant (Range: 2)
> +Info.setRequiresImmediate(2);
> +return true;
> + case 'L': // Integer constant (Range: 0)
> +Info.setRequiresImmediate(0);
> +return true;
> + case 'M': // 8-bit integer constant
> +Info.setRequiresImmediate(0, 0xff);
> +return true;
> + case 'N': // Integer constant (Range: -1)
> +Info.setRequiresImmediate(-1);
> +return true;
> + case 'O': // Integer constant (Range: 8, 16, 24)
> +Info.setRequiresImmediate({8, 16, 24});
> +return true;
> + case 'P': // Integer constant (Range: 1)
> +Info.setRequiresImmediate(1);
> +return true;
> + case 'R': // Integer constant (Range: -6 to 5)
> +Info.setRequiresImmediate(-6, 5);
> +return true;
> + case 'G': // Floating point constant
> + case 'Q': // A memory address based on Y or Z pointer with
> displacement.
> +return true;
> +}
> +
> return false;
>}
>
>
> Added: cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c?rev=294176&view=auto
>
> ==
> --- cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c (added)
> +++ cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c Mon Feb 6
> 03:01:59 2017
> @@ -0,0 +1,124 @@
> +// REQUIRES: avr-registered-target
> +// RUN: %clang_cc1 -triple avr-unknown-unknown -emit-llvm -o - %s |
> FileCheck %s
> +
> +int data;
> +
> +void a() {
> + // CHECK: call void asm sideeffect "add r5, $0", "a"(i16 %0)
> + asm("add r5, %0" :: "a"(data));
> +}
> +
> +void b() {
> + // CHECK: call void asm sideeffect "add r5, $0", "b"(i16 %0)
> + asm("add r5, %0" :: "b"(data));
> +}
> +
> +void d() {
> + // CHECK: call void asm sideeffect "add r5, $0", "d"(i16 %0)
> + asm("add r5, %0" :: "d"(data));
> +}
> +
> +void l() {
> + // CHECK: call void asm sideeffect "add r5, $0", "l"(i16 %0)
> + asm("add r5, %0" :: "l"(data));
> +}
> +
> +void e() {
> + // CHECK: call void asm sideeffect "add r5, $0", "e"(i16 %0)
> + asm("add r5, %0" :: "e"(data));
> +}
> +
Re: r294176 - [AVR] Add support for the full set of inline asm constraints
Trying new address again...
On Thu, Aug 23, 2018 at 8:17 PM Chandler Carruth
wrote:
> Sorry for ancient thread revival, but...
>
> On Mon, Feb 6, 2017 at 2:10 AM Dylan McKay via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: dylanmckay
>> Date: Mon Feb 6 03:01:59 2017
>> New Revision: 294176
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=294176&view=rev
>> Log:
>> [AVR] Add support for the full set of inline asm constraints
>>
>> Summary:
>> Previously the method would simply return false, causing every single
>> inline assembly constraint to trigger a compile error.
>>
>> This adds inline assembly constraint support for the AVR target.
>>
>> This patch is derived from the code in
>> AVRISelLowering::getConstraintType.
>>
>> More details can be found on the AVR-GCC reference wiki
>> http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
>>
>> Reviewers: jroelofs, asl
>>
>> Reviewed By: asl
>>
>> Subscribers: asl, ahatanak, saaadhu, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D28344
>>
>> Added:
>> cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
>>
>
> This test is currently failing. Can you look at fixing it?
>
>
>
>> cfe/trunk/test/CodeGen/avr-unsupported-inline-asm-constraints.c
>> Modified:
>> cfe/trunk/lib/Basic/Targets.cpp
>>
>> Modified: cfe/trunk/lib/Basic/Targets.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=294176&r1=294175&r2=294176&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Basic/Targets.cpp (original)
>> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Feb 6 03:01:59 2017
>> @@ -8517,6 +8517,57 @@ public:
>>
>>bool validateAsmConstraint(const char *&Name,
>> TargetInfo::ConstraintInfo &Info) const
>> override {
>> +// There aren't any multi-character AVR specific constraints.
>> +if (StringRef(Name).size() > 1) return false;
>> +
>> +switch (*Name) {
>> + default: return false;
>> + case 'a': // Simple upper registers
>> + case 'b': // Base pointer registers pairs
>> + case 'd': // Upper register
>> + case 'l': // Lower registers
>> + case 'e': // Pointer register pairs
>> + case 'q': // Stack pointer register
>> + case 'r': // Any register
>> + case 'w': // Special upper register pairs
>> + case 't': // Temporary register
>> + case 'x': case 'X': // Pointer register pair X
>> + case 'y': case 'Y': // Pointer register pair Y
>> + case 'z': case 'Z': // Pointer register pair Z
>> +Info.setAllowsRegister();
>> +return true;
>> + case 'I': // 6-bit positive integer constant
>> +Info.setRequiresImmediate(0, 63);
>> +return true;
>> + case 'J': // 6-bit negative integer constant
>> +Info.setRequiresImmediate(-63, 0);
>> +return true;
>> + case 'K': // Integer constant (Range: 2)
>> +Info.setRequiresImmediate(2);
>> +return true;
>> + case 'L': // Integer constant (Range: 0)
>> +Info.setRequiresImmediate(0);
>> +return true;
>> + case 'M': // 8-bit integer constant
>> +Info.setRequiresImmediate(0, 0xff);
>> +return true;
>> + case 'N': // Integer constant (Range: -1)
>> +Info.setRequiresImmediate(-1);
>> +return true;
>> + case 'O': // Integer constant (Range: 8, 16, 24)
>> +Info.setRequiresImmediate({8, 16, 24});
>> +return true;
>> + case 'P': // Integer constant (Range: 1)
>> +Info.setRequiresImmediate(1);
>> +return true;
>> + case 'R': // Integer constant (Range: -6 to 5)
>> +Info.setRequiresImmediate(-6, 5);
>> +return true;
>> + case 'G': // Floating point constant
>> + case 'Q': // A memory address based on Y or Z pointer with
>> displacement.
>> +return true;
>> +}
>> +
>> return false;
>>}
>>
>>
>> Added: cfe/trunk/test/CodeGen/avr-inline-
r340596 - [AVR] Fix inline asm calls now that the addrspace(0) there is explicit.
Author: chandlerc
Date: Thu Aug 23 21:45:04 2018
New Revision: 340596
URL: http://llvm.org/viewvc/llvm-project?rev=340596&view=rev
Log:
[AVR] Fix inline asm calls now that the addrspace(0) there is explicit.
This updates the test case for r340519 so it should pass again. r340522
only got some of the AVR tests that needed an update.
Modified:
cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
Modified: cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c?rev=340596&r1=340595&r2=340596&view=diff
==
--- cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c (original)
+++ cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c Thu Aug 23 21:45:04 2018
@@ -4,121 +4,121 @@
int data;
void a() {
- // CHECK: call void asm sideeffect "add r5, $0", "a"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "a"(i16 %0)
asm("add r5, %0" :: "a"(data));
}
void b() {
- // CHECK: call void asm sideeffect "add r5, $0", "b"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "b"(i16 %0)
asm("add r5, %0" :: "b"(data));
}
void d() {
- // CHECK: call void asm sideeffect "add r5, $0", "d"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "d"(i16 %0)
asm("add r5, %0" :: "d"(data));
}
void l() {
- // CHECK: call void asm sideeffect "add r5, $0", "l"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "l"(i16 %0)
asm("add r5, %0" :: "l"(data));
}
void e() {
- // CHECK: call void asm sideeffect "add r5, $0", "e"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "e"(i16 %0)
asm("add r5, %0" :: "e"(data));
}
void q() {
- // CHECK: call void asm sideeffect "add r5, $0", "q"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "q"(i16 %0)
asm("add r5, %0" :: "q"(data));
}
void r() {
- // CHECK: call void asm sideeffect "add r5, $0", "r"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "r"(i16 %0)
asm("add r5, %0" :: "r"(data));
}
void w() {
- // CHECK: call void asm sideeffect "add r5, $0", "w"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "w"(i16 %0)
asm("add r5, %0" :: "w"(data));
}
void t() {
- // CHECK: call void asm sideeffect "add r5, $0", "t"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "t"(i16 %0)
asm("add r5, %0" :: "t"(data));
}
void x() {
- // CHECK: call void asm sideeffect "add r5, $0", "x"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "x"(i16 %0)
asm("add r5, %0" :: "x"(data));
}
void y() {
- // CHECK: call void asm sideeffect "add r5, $0", "y"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "y"(i16 %0)
asm("add r5, %0" :: "y"(data));
}
void z() {
- // CHECK: call void asm sideeffect "add r5, $0", "z"(i16 %0)
+ // CHECK: call addrspace(0) void asm sideeffect "add r5, $0", "z"(i16 %0)
asm("add r5, %0" :: "z"(data));
}
void I() {
- // CHECK: call void asm sideeffect "subi r30, $0", "I"(i16 50)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "I"(i16 50)
asm("subi r30, %0" :: "I"(50));
}
void J() {
- // CHECK: call void asm sideeffect "subi r30, $0", "J"(i16 -50)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "J"(i16 -50)
asm("subi r30, %0" :: "J"(-50));
}
void K() {
- // CHECK: call void asm sideeffect "subi r30, $0", "K"(i16 2)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "K"(i16 2)
asm("subi r30, %0" :: "K"(2));
}
void L() {
- // CHECK: call void asm sideeffect "subi r30, $0", "L"(i16 0)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "L"(i16 0)
asm("subi r30, %0" :: "L"(0));
}
void M() {
- // CHECK: call void asm sideeffect "subi r30, $0", "M"(i16 255)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "M"(i16 255)
asm("subi r30, %0" :: "M"(255));
}
void O() {
- // CHECK: call void asm sideeffect "subi r30, $0", "O"(i16 16)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "O"(i16 16)
asm("subi r30, %0" :: "O"(16));
}
void P() {
- // CHECK: call void asm sideeffect "subi r30, $0", "P"(i16 1)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "P"(i16 1)
asm("subi r30, %0" :: "P"(1));
}
void R() {
- // CHECK: call void asm sideeffect "subi r30, $0", "R"(i16 -3)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "R"(i16 -3)
asm("subi r30, %0" :: "R"(-3));
}
void G() {
- // CHECK: call void asm sideeffect "subi r30, $0", "G"(i16 50)
+ // CHECK: call addrspace(0) void asm sideeffect "subi r30, $0", "G"(i16 50)
asm("subi r30, %0" :: "G"(50));
}
void Q() {
- // CHECK: call void asm sideeffect "s
Re: r294176 - [AVR] Add support for the full set of inline asm constraints
This was due to r340519. I've fixed it in r340596 to clean things up.
On Thu, Aug 23, 2018 at 8:20 PM Chandler Carruth
wrote:
> Trying new address again...
>
>
> On Thu, Aug 23, 2018 at 8:17 PM Chandler Carruth
> wrote:
>
>> Sorry for ancient thread revival, but...
>>
>> On Mon, Feb 6, 2017 at 2:10 AM Dylan McKay via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: dylanmckay
>>> Date: Mon Feb 6 03:01:59 2017
>>> New Revision: 294176
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=294176&view=rev
>>> Log:
>>> [AVR] Add support for the full set of inline asm constraints
>>>
>>> Summary:
>>> Previously the method would simply return false, causing every single
>>> inline assembly constraint to trigger a compile error.
>>>
>>> This adds inline assembly constraint support for the AVR target.
>>>
>>> This patch is derived from the code in
>>> AVRISelLowering::getConstraintType.
>>>
>>> More details can be found on the AVR-GCC reference wiki
>>> http://www.nongnu.org/avr-libc/user-manual/inline_asm.html
>>>
>>> Reviewers: jroelofs, asl
>>>
>>> Reviewed By: asl
>>>
>>> Subscribers: asl, ahatanak, saaadhu, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D28344
>>>
>>> Added:
>>> cfe/trunk/test/CodeGen/avr-inline-asm-constraints.c
>>>
>>
>> This test is currently failing. Can you look at fixing it?
>>
>>
>>
>>> cfe/trunk/test/CodeGen/avr-unsupported-inline-asm-constraints.c
>>> Modified:
>>> cfe/trunk/lib/Basic/Targets.cpp
>>>
>>> Modified: cfe/trunk/lib/Basic/Targets.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=294176&r1=294175&r2=294176&view=diff
>>>
>>> ==
>>> --- cfe/trunk/lib/Basic/Targets.cpp (original)
>>> +++ cfe/trunk/lib/Basic/Targets.cpp Mon Feb 6 03:01:59 2017
>>> @@ -8517,6 +8517,57 @@ public:
>>>
>>>bool validateAsmConstraint(const char *&Name,
>>> TargetInfo::ConstraintInfo &Info) const
>>> override {
>>> +// There aren't any multi-character AVR specific constraints.
>>> +if (StringRef(Name).size() > 1) return false;
>>> +
>>> +switch (*Name) {
>>> + default: return false;
>>> + case 'a': // Simple upper registers
>>> + case 'b': // Base pointer registers pairs
>>> + case 'd': // Upper register
>>> + case 'l': // Lower registers
>>> + case 'e': // Pointer register pairs
>>> + case 'q': // Stack pointer register
>>> + case 'r': // Any register
>>> + case 'w': // Special upper register pairs
>>> + case 't': // Temporary register
>>> + case 'x': case 'X': // Pointer register pair X
>>> + case 'y': case 'Y': // Pointer register pair Y
>>> + case 'z': case 'Z': // Pointer register pair Z
>>> +Info.setAllowsRegister();
>>> +return true;
>>> + case 'I': // 6-bit positive integer constant
>>> +Info.setRequiresImmediate(0, 63);
>>> +return true;
>>> + case 'J': // 6-bit negative integer constant
>>> +Info.setRequiresImmediate(-63, 0);
>>> +return true;
>>> + case 'K': // Integer constant (Range: 2)
>>> +Info.setRequiresImmediate(2);
>>> +return true;
>>> + case 'L': // Integer constant (Range: 0)
>>> +Info.setRequiresImmediate(0);
>>> +return true;
>>> + case 'M': // 8-bit integer constant
>>> +Info.setRequiresImmediate(0, 0xff);
>>> +return true;
>>> + case 'N': // Integer constant (Range: -1)
>>> +Info.setRequiresImmediate(-1);
>>> +return true;
>>> + case 'O': // Integer constant (Range: 8, 16, 24)
>>> +Info.setRequiresImmediate({8, 16, 24});
>>> +return true;
>>> + case 'P': // Integer constant (Range: 1)
>
Re: r340709 - [Driver] Change MipsLinux default linker from "lld" to "ld.lld"
FYI, test cases also seem to need updating:
http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/19575/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Amips-mti-linux.c
On Sun, Aug 26, 2018 at 12:48 PM Fangrui Song via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: maskray
> Date: Sun Aug 26 12:47:23 2018
> New Revision: 340709
>
> URL: http://llvm.org/viewvc/llvm-project?rev=340709&view=rev
> Log:
> [Driver] Change MipsLinux default linker from "lld" to "ld.lld"
>
> Reviewers: kzhuravl, atanasyan
>
> Reviewed By: atanasyan
>
> Subscribers: sdardis, arichardson, jrtc27, atanasyan, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D51234
>
> Modified:
> cfe/trunk/lib/Driver/ToolChains/MipsLinux.h
>
> Modified: cfe/trunk/lib/Driver/ToolChains/MipsLinux.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MipsLinux.h?rev=340709&r1=340708&r2=340709&view=diff
>
> ==
> --- cfe/trunk/lib/Driver/ToolChains/MipsLinux.h (original)
> +++ cfe/trunk/lib/Driver/ToolChains/MipsLinux.h Sun Aug 26 12:47:23 2018
> @@ -49,7 +49,7 @@ public:
>}
>
>const char *getDefaultLinker() const override {
> -return "lld";
> +return "ld.lld";
>}
>
> private:
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r340709 - [Driver] Change MipsLinux default linker from "lld" to "ld.lld"
Build bots have been broken all day, so I'm trying a speculative fix in
r340727. If this doesn't work, i'll just revert all of this.
On Sun, Aug 26, 2018 at 3:51 PM Chandler Carruth
wrote:
> FYI, test cases also seem to need updating:
>
> http://lab.llvm.org:8011/builders/clang-ppc64le-linux/builds/19575/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Amips-mti-linux.c
>
> On Sun, Aug 26, 2018 at 12:48 PM Fangrui Song via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: maskray
>> Date: Sun Aug 26 12:47:23 2018
>> New Revision: 340709
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=340709&view=rev
>> Log:
>> [Driver] Change MipsLinux default linker from "lld" to "ld.lld"
>>
>> Reviewers: kzhuravl, atanasyan
>>
>> Reviewed By: atanasyan
>>
>> Subscribers: sdardis, arichardson, jrtc27, atanasyan, cfe-commits
>>
>> Differential Revision: https://reviews.llvm.org/D51234
>>
>> Modified:
>> cfe/trunk/lib/Driver/ToolChains/MipsLinux.h
>>
>> Modified: cfe/trunk/lib/Driver/ToolChains/MipsLinux.h
>> URL:
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/MipsLinux.h?rev=340709&r1=340708&r2=340709&view=diff
>>
>> ==
>> --- cfe/trunk/lib/Driver/ToolChains/MipsLinux.h (original)
>> +++ cfe/trunk/lib/Driver/ToolChains/MipsLinux.h Sun Aug 26 12:47:23 2018
>> @@ -49,7 +49,7 @@ public:
>>}
>>
>>const char *getDefaultLinker() const override {
>> -return "lld";
>> +return "ld.lld";
>>}
>>
>> private:
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r340727 - Try to fix this clang driver test case after r340709.
Author: chandlerc
Date: Mon Aug 27 01:49:20 2018
New Revision: 340727
URL: http://llvm.org/viewvc/llvm-project?rev=340727&view=rev
Log:
Try to fix this clang driver test case after r340709.
If any of the bots complain about this, I'll just revert. This test case
is essentially trying to test the exact change made, but I think this
matches the intent of the patch in question.
Modified:
cfe/trunk/test/Driver/mips-mti-linux.c
Modified: cfe/trunk/test/Driver/mips-mti-linux.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/mips-mti-linux.c?rev=340727&r1=340726&r2=340727&view=diff
==
--- cfe/trunk/test/Driver/mips-mti-linux.c (original)
+++ cfe/trunk/test/Driver/mips-mti-linux.c Mon Aug 27 01:49:20 2018
@@ -15,7 +15,7 @@
// CHECK-BE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple"
"mips-mti-linux"
// CHECK-BE-HF-32R2-SAME: "-fuse-init-array" "-target-cpu" "mips32r2"
// CHECK-BE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
-// CHECK-BE-HF-32R2: "{{[^"]*}}lld{{[^"]*}}" "-flavor" "old-gnu" "-target"
"mips-mti-linux"
+// CHECK-BE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
// CHECK-BE-HF-32R2-SAME: "--sysroot=[[SYSROOT:[^"]+]]" {{.*}}
"-dynamic-linker" "/lib/ld-musl-mips.so.1"
// CHECK-BE-HF-32R2-SAME:
"[[SYSROOT]]/mips-r2-hard-musl/usr/lib{{/|}}crt1.o"
// CHECK-BE-HF-32R2-SAME:
"[[SYSROOT]]/mips-r2-hard-musl/usr/lib{{/|}}crti.o"
@@ -33,7 +33,7 @@
// CHECK-LE-HF-32R2: "{{[^"]*}}clang{{[^"]*}}" {{.*}} "-triple"
"mipsel-mti-linux"
// CHECK-LE-HF-32R2-SAME: "-fuse-init-array" "-target-cpu" "mips32r2"
// CHECK-LE-HF-32R2-SAME: "-isysroot" "{{.*}}mips_mti_linux/sysroot"
-// CHECK-LE-HF-32R2: "{{[^"]*}}lld{{[^"]*}}" "-flavor" "old-gnu" "-target"
"mipsel-mti-linux"
+// CHECK-LE-HF-32R2: "{{[^"]*}}ld.lld{{[^"]*}}"
// CHECK-LE-HF-32R2-SAME: "--sysroot=[[SYSROOT:[^"]+]]" {{.*}}
"-dynamic-linker" "/lib/ld-musl-mipsel.so.1"
// CHECK-LE-HF-32R2-SAME:
"[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib{{/|}}crt1.o"
// CHECK-LE-HF-32R2-SAME:
"[[SYSROOT]]/mipsel-r2-hard-musl/usr/lib{{/|}}crti.o"
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r341363 - [x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative
Author: chandlerc
Date: Tue Sep 4 05:38:00 2018
New Revision: 341363
URL: http://llvm.org/viewvc/llvm-project?rev=341363&view=rev
Log:
[x86/SLH] Add a real Clang flag and LLVM IR attribute for Speculative
Load Hardening.
Wires up the existing pass to work with a proper IR attribute rather
than just a hidden/internal flag. The internal flag continues to work
for now, but I'll likely remove it soon.
Most of the churn here is adding the IR attribute. I talked about this
Kristof Beyls and he seemed at least initially OK with this direction.
The idea of using a full attribute here is that we *do* expect at least
some forms of this for other architectures. There isn't anything
*inherently* x86-specific about this technique, just that we only have
an implementation for x86 at the moment.
While we could potentially expose this as a Clang-level attribute as
well, that seems like a good question to defer for the moment as it
isn't 100% clear whether that or some other programmer interface (or
both?) would be best. We'll defer the programmer interface side of this
for now, but at least get to the point where the feature can be enabled
without relying on implementation details.
This also allows us to do something that was really hard before: we can
enable *just* the indirect call retpolines when using SLH. For x86, we
don't have any other way to mitigate indirect calls. Other architectures
may take a different approach of course, and none of this is surfaced to
user-level flags.
Differential Revision: https://reviews.llvm.org/D51157
Added:
cfe/trunk/test/CodeGen/attr-speculative-load-hardening.c
Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/x86-target-features.c
Modified: cfe/trunk/include/clang/Driver/Options.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=341363&r1=341362&r2=341363&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Tue Sep 4 05:38:00 2018
@@ -2009,6 +2009,10 @@ def mno_stackrealign : Flag<["-"], "mno-
def mretpoline : Flag<["-"], "mretpoline">, Group,
Flags<[CoreOption,DriverOption]>;
def mno_retpoline : Flag<["-"], "mno-retpoline">, Group,
Flags<[CoreOption,DriverOption]>;
+def mspeculative_load_hardening : Flag<["-"], "mspeculative-load-hardening">,
+ Group, Flags<[CoreOption,CC1Option]>;
+def mno_speculative_load_hardening : Flag<["-"],
"mno-speculative-load-hardening">,
+ Group, Flags<[CoreOption]>;
def mrelax : Flag<["-"], "mrelax">, Group,
HelpText<"Enable linker relaxation">;
Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=341363&r1=341362&r2=341363&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Tue Sep 4 05:38:00 2018
@@ -211,6 +211,7 @@ CODEGENOPT(SanitizeCoverageStackDepth, 1
CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
CODEGENOPT(SimplifyLibCalls , 1, 1) ///< Set when -fbuiltin is enabled.
CODEGENOPT(SoftFloat , 1, 0) ///< -soft-float.
+CODEGENOPT(SpeculativeLoadHardening, 1, 0) ///< Enable speculative load
hardening.
CODEGENOPT(FineGrainedBitfieldAccesses, 1, 0) ///< Enable fine-grained
bitfield accesses.
CODEGENOPT(StrictEnums , 1, 0) ///< Optimize based on strict enum
definition.
CODEGENOPT(StrictVTablePointers, 1, 0) ///< Optimize based on the strict
vtable pointers
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=341363&r1=341362&r2=341363&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Tue Sep 4 05:38:00 2018
@@ -1784,6 +1784,9 @@ void CodeGenModule::ConstructDefaultFnAt
FuncAttrs.addAttribute("stackrealign");
if (CodeGenOpts.Backchain)
FuncAttrs.addAttribute("backchain");
+
+if (CodeGenOpts.SpeculativeLoadHardening)
+ FuncAttrs.addAttribute(llvm::Attribute::SpeculativeLoadHardening);
}
if (getLangOpts().assumeFunctionsAreConvergent()) {
Modified: cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp?rev=341363&r1=341362&r2=341363&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Arch/X86.cpp
Re: r337456 - [CodeGen] Disable aggressive structor optimizations at -O0, take 3
On Thu, Jul 19, 2018 at 7:10 AM Pavel Labath via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: labath > Date: Thu Jul 19 07:05:22 2018 > New Revision: 337456 > > URL: http://llvm.org/viewvc/llvm-project?rev=337456&view=rev > Log: > [CodeGen] Disable aggressive structor optimizations at -O0, take 3 > I'm really sorry to do this, but I need to revert this patch Let me try to explain We're seeing at least two issues with it that are causing *serious* issues for our users, and due to numerous other things, we really need to get top-of-tree into usable shape sooner rather than later. As this is improving a long-standing deficiency in Clang, I think it is reasonable to revert temporarily while we sort it out. I'm CC-ing Richard Smith and Eric Christopher directly as I'm going to ask them to make sure we get satisfactory answers to why this patch causes us so many problems and how we can make progress here. I don't have a test case at the moment, and I want to *very clearly* call out that it is on us to find a test case or otherwise clearly explain what problem this patch causes and how it can be addressed, or else this patch should be re-landed. To at least give some idea of what is going wrong here.. First, this patch does increase object code size. This isn't really unexpected based on the nature of the patch, and it does so ostensibly in order to gain material fidelity improvements to debug information. Despite the fact that the increased object size causes us problems (it made a few hundered of our binaries' inputs too large to fit into the quota for the input files to our internal distributed build system) we tried to soldier onward... But it also causes the Gold linker at least to use considerably more memory than it used to. This has resulted in over 400 failures to link executables due to running out of available memory on the system. There are a number of possible causes for both the input size issues and the linker memory issue: - An unexpected side-effect of this change causes lots of redundant sections to be output with -ffunction-sections, all of which merge away into nothing, but this takes huge amounts of object file and linker resources. - The object file size increease is expected and unavoidable, but there is some bug in the linker being triggered? - Something else It is going to take us some time to investigate these issues, and sadly, all of these issues are breaking builds actively for us. So while we will work very hard on getting to a resolution, if you also really need this functionality to land sooner rather than later, what I would request is to add it back under a flag. In fact, if you need that and request it, we can do the actual work of adding it back under a flag. I think that's the least we can do here. Anyways, again, sorry to revert with relatively little warning and with relatively little info. Feel free to reach out to myself or Richard Smith, or Eric Christopher who will all be looking at this first thing next week to understand exactly what is going on here and what the root causes is and whether any of these issues are due to bugs in some tool or another, or whether these are all due to some particular issue with our source code. -Chandler > The previous version of this patch (r332839) was reverted because it was > causing "definition with same mangled name as another definition" errors > in some module builds. This was caused by an unrelated bug in module > importing which it exposed. The importing problem was fixed in r336240, > so this recommits the original patch (r332839). > > Differential Revision: https://reviews.llvm.org/D46685 > > Modified: > cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp > cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp > cfe/trunk/test/CodeGenCXX/float16-declarations.cpp > > Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=337456&r1=337455&r2=337456&view=diff > > == > --- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original) > +++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Thu Jul 19 07:05:22 2018 > @@ -3737,12 +3737,22 @@ static StructorCodegen getCodegenToUse(C >} >llvm::GlobalValue::LinkageTypes Linkage = > CGM.getFunctionLinkage(AliasDecl); > > - if (llvm::GlobalValue::isDiscardableIfUnused(Linkage)) > -return StructorCodegen::RAUW; > + // All discardable structors can be RAUWed, but we don't want to do > that in > + // unoptimized code, as that makes complete structor symbol disappear > + // completely, which degrades debugging experience. > + // Symbols with private linkage can be safely aliased, so we special > case them > + // here. > + if (llvm::GlobalValue::isLocalLinkage(Linkage)) > +return CGM.getCodeGenOpts().OptimizationLevel > 0 ? > StructorCodegen::RAUW > +
Re: r337456 - [CodeGen] Disable aggressive structor optimizations at -O0, take 3
On Sat, Jul 28, 2018 at 2:26 AM Chandler Carruth wrote: > On Thu, Jul 19, 2018 at 7:10 AM Pavel Labath via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Author: labath >> Date: Thu Jul 19 07:05:22 2018 >> New Revision: 337456 >> >> URL: http://llvm.org/viewvc/llvm-project?rev=337456&view=rev >> Log: >> [CodeGen] Disable aggressive structor optimizations at -O0, take 3 >> > > I'm really sorry to do this, but I need to revert this patch Let me > try to explain > > We're seeing at least two issues with it that are causing *serious* issues > for our users, and due to numerous other things, we really need to get > top-of-tree into usable shape sooner rather than later. As this is > improving a long-standing deficiency in Clang, I think it is reasonable to > revert temporarily while we sort it out. I'm CC-ing Richard Smith and Eric > Christopher directly as I'm going to ask them to make sure we get > satisfactory answers to why this patch causes us so many problems and how > we can make progress here. > > I don't have a test case at the moment, and I want to *very clearly* call > out that it is on us to find a test case or otherwise clearly explain what > problem this patch causes and how it can be addressed, or else this patch > should be re-landed. > > To at least give some idea of what is going wrong here.. > > First, this patch does increase object code size. This isn't really > unexpected based on the nature of the patch, and it does so ostensibly in > order to gain material fidelity improvements to debug information. Despite > the fact that the increased object size causes us problems (it made a few > hundered of our binaries' inputs too large to fit into the quota for the > input files to our internal distributed build system) we tried to soldier > onward... > > But it also causes the Gold linker at least to use considerably more > memory than it used to. This has resulted in over 400 failures to link > executables due to running out of available memory on the system. > > There are a number of possible causes for both the input size issues and > the linker memory issue: > - An unexpected side-effect of this change causes lots of redundant > sections to be output with -ffunction-sections, all of which merge away > into nothing, but this takes huge amounts of object file and linker > resources. > - The object file size increease is expected and unavoidable, but there is > some bug in the linker being triggered? > - Something else > I wanted to at least do some initial investigation before reverting and I've done that now. What I'm seeing is a 10% or higher increase in the number of sections and the size spent on ELF headers. This doesn't seem *too* surprising. What is surprising is that this seems to cause an even larger increase in memory usage by gold. Anyways, we'll have to debug this more to truly understand what the issue is and whether there is something we can do with this patch that would improve things (such as maybe using fewer sections?) or whether this all just needs to be guarded under a flag. I'm going to revert for now, but hopefully first thing Monday, Richard and Eric can help out with suggestions on how to make progress here. Again, really sorry about this, especially on the third iteration -Chandler > > It is going to take us some time to investigate these issues, and sadly, > all of these issues are breaking builds actively for us. > > So while we will work very hard on getting to a resolution, if you also > really need this functionality to land sooner rather than later, what I > would request is to add it back under a flag. In fact, if you need that and > request it, we can do the actual work of adding it back under a flag. I > think that's the least we can do here. > > Anyways, again, sorry to revert with relatively little warning and with > relatively little info. > > Feel free to reach out to myself or Richard Smith, or Eric Christopher who > will all be looking at this first thing next week to understand exactly > what is going on here and what the root causes is and whether any of these > issues are due to bugs in some tool or another, or whether these are all > due to some particular issue with our source code. > > -Chandler > > >> The previous version of this patch (r332839) was reverted because it was >> causing "definition with same mangled name as another definition" errors >> in some module builds. This was caused by an unrelated bug in module >> importing which it exposed. The importing problem was fixed in r336240, >> so this recommits the original patch (r332839). >> >
r338209 - Revert r337456: [CodeGen] Disable aggressive structor optimizations at -O0, take 3
Author: chandlerc
Date: Sat Jul 28 20:05:07 2018
New Revision: 338209
URL: http://llvm.org/viewvc/llvm-project?rev=338209&view=rev
Log:
Revert r337456: [CodeGen] Disable aggressive structor optimizations at -O0,
take 3
This commit increases the number of sections and overall output size of
.o files by 10% and sometimes a bit more. This alone is challenging for
some users, but it also appears to trigger an as-yet unexplained
behavior in the Gold linker where the memory usage increases
considerably more than 10% (we think).
The increase is also frustrating because in many (if not all) cases we
end up with almost all of the growth coming from the ELF overhead of
-ffunction-sections and such, not from actual extra code being emitted.
Richard Smith and Eric Christopher are both going to investigate this
and try to get to the bottom of what is triggering this and whether the
kinds of increases here are sustainable or what options we might have to
minimize the impact they have. However, this is currently breaking
a pretty large number of our users' builds so reverting it while we sort
out how to make progress here. I've seen a longer and more detailed
update to the commit thread.
Modified:
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp
cfe/trunk/test/CodeGenCXX/float16-declarations.cpp
Modified: cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp?rev=338209&r1=338208&r2=338209&view=diff
==
--- cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp (original)
+++ cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp Sat Jul 28 20:05:07 2018
@@ -3744,22 +3744,12 @@ static StructorCodegen getCodegenToUse(C
}
llvm::GlobalValue::LinkageTypes Linkage = CGM.getFunctionLinkage(AliasDecl);
- // All discardable structors can be RAUWed, but we don't want to do that in
- // unoptimized code, as that makes complete structor symbol disappear
- // completely, which degrades debugging experience.
- // Symbols with private linkage can be safely aliased, so we special case
them
- // here.
- if (llvm::GlobalValue::isLocalLinkage(Linkage))
-return CGM.getCodeGenOpts().OptimizationLevel > 0 ? StructorCodegen::RAUW
- : StructorCodegen::Alias;
+ if (llvm::GlobalValue::isDiscardableIfUnused(Linkage))
+return StructorCodegen::RAUW;
- // Linkonce structors cannot be aliased nor placed in a comdat, so these need
- // to be emitted separately.
// FIXME: Should we allow available_externally aliases?
- if (llvm::GlobalValue::isDiscardableIfUnused(Linkage) ||
- !llvm::GlobalAlias::isValidLinkage(Linkage))
-return CGM.getCodeGenOpts().OptimizationLevel > 0 ? StructorCodegen::RAUW
- : StructorCodegen::Emit;
+ if (!llvm::GlobalAlias::isValidLinkage(Linkage))
+return StructorCodegen::RAUW;
if (llvm::GlobalValue::isWeakForLinker(Linkage)) {
// Only ELF and wasm support COMDATs with arbitrary names (C5/D5).
Modified: cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp?rev=338209&r1=338208&r2=338209&view=diff
==
--- cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp Sat Jul 28 20:05:07 2018
@@ -1,7 +1,5 @@
-// RUN: %clang_cc1 %s -triple i686-linux -emit-llvm -o - -mconstructor-aliases
> %t
-// RUN: FileCheck --check-prefix=NOOPT1 --input-file=%t %s
-// RUN: FileCheck --check-prefix=NOOPT2 --input-file=%t %s
-// RUN: FileCheck --check-prefix=NOOPT3 --input-file=%t %s
+// RUN: %clang_cc1 %s -triple i686-linux -emit-llvm -o - -mconstructor-aliases
| FileCheck --check-prefix=NOOPT %s
+
// RUN: %clang_cc1 %s -triple i686-linux -emit-llvm -o - -mconstructor-aliases
-O1 -disable-llvm-passes > %t
// RUN: FileCheck --check-prefix=CHECK1 --input-file=%t %s
// RUN: FileCheck --check-prefix=CHECK2 --input-file=%t %s
@@ -23,13 +21,6 @@ namespace test1 {
// CHECK1: define weak_odr void @_ZN5test16foobarIvED0Ev({{.*}}
comdat($_ZN5test16foobarIvED5Ev)
// CHECK1-NOT: comdat
-// This should happen regardless of the opt level.
-// NOOPT1: @_ZN5test16foobarIvEC1Ev = weak_odr unnamed_addr alias void {{.*}}
@_ZN5test16foobarIvEC2Ev
-// NOOPT1: @_ZN5test16foobarIvED1Ev = weak_odr unnamed_addr alias void
(%"struct.test1::foobar"*), void (%"struct.test1::foobar"*)*
@_ZN5test16foobarIvED2Ev
-// NOOPT1: define weak_odr void @_ZN5test16foobarIvEC2Ev({{.*}}
comdat($_ZN5test16foobarIvEC5Ev)
-// NOOPT1: define weak_odr void @_ZN5test16foobarIvED2Ev({{.*}}
comdat($_ZN5test16foobarIvED5Ev)
-// NOOPT1: define weak_odr void @_ZN5test16foobarIvED0Ev({{.*}}
comdat($_ZN5test16foobarIvED5Ev)
-
// COFF doesn't support comdats with
r338979 - [docs] Don't use the `asm` syntax highlighting (which our docs builder
Author: chandlerc
Date: Sun Aug 5 18:28:42 2018
New Revision: 338979
URL: http://llvm.org/viewvc/llvm-project?rev=338979&view=rev
Log:
[docs] Don't use the `asm` syntax highlighting (which our docs builder
errors on) and clean up the formattting.
This isn't actualy assembly anyways, so dropping the highlighting is
probably for the best.
Modified:
cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
Modified: cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst?rev=338979&r1=338978&r2=338979&view=diff
==
--- cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst (original)
+++ cfe/trunk/docs/HardwareAssistedAddressSanitizerDesign.rst Sun Aug 5
18:28:42 2018
@@ -47,21 +47,21 @@ All memory accesses are prefixed with an
verifies the tags. Currently, the following sequence is used:
-.. code-block:: asm
+.. code-block:: none
// int foo(int *a) { return *a; }
// clang -O2 --target=aarch64-linux -fsanitize=hwaddress -c load.c
foo:
0: 08 00 00 90 adrpx8, 0 <__hwasan_shadow>
- 4: 08 01 40 f9 ldr x8, [x8] // shadow base (to be
resolved by the loader)
- 8: 09 dc 44 d3 ubfxx9, x0, #4, #52 // shadow offset
- c: 28 69 68 38 ldrbw8, [x9, x8] // load shadow tag
- 10: 09 fc 78 d3 lsr x9, x0, #56 // extract address tag
- 14: 3f 01 08 6b cmp w9, w8 // compare tags
- 18: 61 00 00 54 b.ne24 // jump on mismatch
- 1c: 00 00 40 b9 ldr w0, [x0] // original load
+ 4: 08 01 40 f9 ldr x8, [x8] // shadow base (to be
resolved by the loader)
+ 8: 09 dc 44 d3 ubfxx9, x0, #4, #52 // shadow offset
+ c: 28 69 68 38 ldrbw8, [x9, x8]// load shadow tag
+ 10: 09 fc 78 d3 lsr x9, x0, #56 // extract address tag
+ 14: 3f 01 08 6b cmp w9, w8// compare tags
+ 18: 61 00 00 54 b.ne24 // jump on mismatch
+ 1c: 00 00 40 b9 ldr w0, [x0] // original load
20: c0 03 5f d6 ret
- 24: 40 20 21 d4 brk #0x902 // trap
+ 24: 40 20 21 d4 brk #0x902// trap
Alternatively, memory accesses are prefixed with a function call.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D33467: Fix LLVM build errors if necent build of GCC 7 is used
I kind of think this may be a GCC bug. It is quite strange that no one else
has reported it, and that you're only seeing it in this context. We have
many std::string flags and they are used in this way pretty commonly.
I'm not seeing this with any other GCC-hosted build bot either, including a
PPC one here: http://lab.llvm.org:8011/builders/clang-ppc64le-linux
On Fri, May 26, 2017 at 1:34 AM David Abdurachmanov via Phabricator <
revi...@reviews.llvm.org> wrote:
> davidlt added a comment.
>
> This happens with recent GCC 7.1.1 (updated yesterday) and if compiled in
> C++1z mode.
>
> FAILED:
> /home/davidlt/root_patch_check/a/slc7_ppc64le_gcc700/external/gcc/7.0.0-njopjo2/bin/g++
> -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
> -Iinterpreter/llvm/src/lib/Transforms/Instrumentation
> -I/home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation
> -Iinterpreter/llvm/src/include
> -I/home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include
> -D__ROOFIT_NOBANNER -Wno-implicit-fallthrough -Wno-noexcept-type -pipe
> -Wshadow -Wall -W -Woverloaded-virtual -fsigned-char -fPIC -pthread
> -std=c++1z -fvisibility=hidden -fPIC -fvisibility-inlines-hidden -w
> -Werror=date-time -std=c++1z -ffunction-sections -fdata-sections -O2
> -DNDEBUG-fno-exceptions -fno-rtti -MD -MT
> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o
> -MF
> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o.d
> -o
> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o
> -c
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
>
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:
> In constructor
> '{anonymous}::PGOInstrumentationUseLegacyPass::PGOInstrumentationUseLegacyPass(std::string)':
>
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:155:25:
> error: 'llvm::cl::opt::opt(const
> llvm::cl::opt&) [with DataType =
> std::basic_string; bool ExternalStorage = false; ParserClass =
> llvm::cl::parser >]' is private within this context
> ProfileFileName = PGOTestProfileFile;
>^~
> In file included from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/Support/Options.h:41:0,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/LLVMContext.h:19,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Metadata.h:26,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/TrackingMDRef.h:17,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/DebugLoc.h:18,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Instruction.h:20,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/BasicBlock.h:19,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Function.h:24,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/PassManager.h:44,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/Transforms/PGOInstrumentation.h:17,
>from
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:51:
>
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/Support/CommandLine.h:1296:3:
> note: declared private here
> opt(const opt &) = delete;
> ^~~
>
> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/ro
Re: [PATCH] D33467: Fix LLVM build errors if necent build of GCC 7 is used
Maybe Richard would be a better one to explain what on earth is going on
here then...
On Fri, May 26, 2017 at 1:51 AM David Abdurachmanov <
david.abdurachma...@gmail.com> wrote:
> Just reminder that this is in C++1z (C++17) mode, which I doubt is being
> widely used at this point.
>
> I was a change a few months ago that caused it, but cannot recall exact
> commit in GCC.
>
> david
>
> On 26 May 2017, at 10:43, Chandler Carruth wrote:
>
> I kind of think this may be a GCC bug. It is quite strange that no one
> else has reported it, and that you're only seeing it in this context. We
> have many std::string flags and they are used in this way pretty commonly.
>
> I'm not seeing this with any other GCC-hosted build bot either, including
> a PPC one here: http://lab.llvm.org:8011/builders/clang-ppc64le-linux
>
> On Fri, May 26, 2017 at 1:34 AM David Abdurachmanov via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> davidlt added a comment.
>>
>> This happens with recent GCC 7.1.1 (updated yesterday) and if compiled in
>> C++1z mode.
>>
>> FAILED:
>> /home/davidlt/root_patch_check/a/slc7_ppc64le_gcc700/external/gcc/7.0.0-njopjo2/bin/g++
>> -DGTEST_HAS_RTTI=0 -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
>> -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> -Iinterpreter/llvm/src/lib/Transforms/Instrumentation
>> -I/home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation
>> -Iinterpreter/llvm/src/include
>> -I/home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include
>> -D__ROOFIT_NOBANNER -Wno-implicit-fallthrough -Wno-noexcept-type -pipe
>> -Wshadow -Wall -W -Woverloaded-virtual -fsigned-char -fPIC -pthread
>> -std=c++1z -fvisibility=hidden -fPIC -fvisibility-inlines-hidden -w
>> -Werror=date-time -std=c++1z -ffunction-sections -fdata-sections -O2
>> -DNDEBUG-fno-exceptions -fno-rtti -MD -MT
>> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o
>> -MF
>> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o.d
>> -o
>> interpreter/llvm/src/lib/Transforms/Instrumentation/CMakeFiles/LLVMInstrumentation.dir/PGOInstrumentation.cpp.o
>> -c
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
>>
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:
>> In constructor
>> '{anonymous}::PGOInstrumentationUseLegacyPass::PGOInstrumentationUseLegacyPass(std::string)':
>>
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/lib/Transforms/Instrumentation/PGOInstrumentation.cpp:155:25:
>> error: 'llvm::cl::opt::opt(const
>> llvm::cl::opt&) [with DataType =
>> std::basic_string; bool ExternalStorage = false; ParserClass =
>> llvm::cl::parser >]' is private within this context
>> ProfileFileName = PGOTestProfileFile;
>>^~
>> In file included from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/Support/Options.h:41:0,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/LLVMContext.h:19,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Metadata.h:26,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/TrackingMDRef.h:17,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/DebugLoc.h:18,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/Instruction.h:20,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le_gcc700/lcg/root/6.09.04/root-6.09.04/interpreter/llvm/src/include/llvm/IR/BasicBlock.h:19,
>>from
>> /home/davidlt/root_patch_check/a/BUILD/slc7_ppc64le
r321392 - Add an explicit `LLVM_FALLTHROUGH` annotation to an intentional
Author: chandlerc Date: Fri Dec 22 15:29:49 2017 New Revision: 321392 URL: http://llvm.org/viewvc/llvm-project?rev=321392&view=rev Log: Add an explicit `LLVM_FALLTHROUGH` annotation to an intentional fallthrough. Fixes GCC and Clang warnings about this. 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=321392&r1=321391&r2=321392&view=diff == --- cfe/trunk/lib/Sema/SemaType.cpp (original) +++ cfe/trunk/lib/Sema/SemaType.cpp Fri Dec 22 15:29:49 2017 @@ -3143,6 +3143,7 @@ static void warnAboutRedundantParens(Sem case DeclaratorChunk::Paren: if (&C == &Paren) continue; + LLVM_FALLTHROUGH; case DeclaratorChunk::Pointer: StartsWithDeclaratorId = false; continue; ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] r321469 - There is no portable format string for printing `uintptr_t` values.
Author: chandlerc
Date: Tue Dec 26 21:46:53 2017
New Revision: 321469
URL: http://llvm.org/viewvc/llvm-project?rev=321469&view=rev
Log:
There is no portable format string for printing `uintptr_t` values.
Instead, cast them to `void *` which has a portable format string syntax
of `%p`.
This fixes a -Wformat error when building libunwind.
Modified:
libunwind/trunk/src/AddressSpace.hpp
Modified: libunwind/trunk/src/AddressSpace.hpp
URL:
http://llvm.org/viewvc/llvm-project/libunwind/trunk/src/AddressSpace.hpp?rev=321469&r1=321468&r2=321469&view=diff
==
--- libunwind/trunk/src/AddressSpace.hpp (original)
+++ libunwind/trunk/src/AddressSpace.hpp Tue Dec 26 21:46:53 2017
@@ -384,13 +384,13 @@ inline bool LocalAddressSpace::findUnwin
// Bare metal is statically linked, so no need to ask the dynamic loader
info.dwarf_section_length = (uintptr_t)(&__eh_frame_end - &__eh_frame_start);
info.dwarf_section =(uintptr_t)(&__eh_frame_start);
- _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %X length %x",
- info.dwarf_section, info.dwarf_section_length);
+ _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %p length %p",
+ (void *)info.dwarf_section, (void
*)info.dwarf_section_length);
#if defined(_LIBUNWIND_SUPPORT_DWARF_INDEX)
info.dwarf_index_section =(uintptr_t)(&__eh_frame_hdr_start);
info.dwarf_index_section_length = (uintptr_t)(&__eh_frame_hdr_end -
&__eh_frame_hdr_start);
- _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: index section %X length %x",
- info.dwarf_index_section,
info.dwarf_index_section_length);
+ _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: index section %p length %p",
+ (void *)info.dwarf_index_section, (void
*)info.dwarf_index_section_length);
#endif
if (info.dwarf_section_length)
return true;
@@ -398,8 +398,8 @@ inline bool LocalAddressSpace::findUnwin
// Bare metal is statically linked, so no need to ask the dynamic loader
info.arm_section =(uintptr_t)(&__exidx_start);
info.arm_section_length = (uintptr_t)(&__exidx_end - &__exidx_start);
- _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %X length %x",
- info.arm_section, info.arm_section_length);
+ _LIBUNWIND_TRACE_UNWINDING("findUnwindSections: section %p length %p",
+ (void *)info.arm_section, (void
*)info.arm_section_length);
if (info.arm_section && info.arm_section_length)
return true;
#elif defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND) && defined(_WIN32)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r335309 - [x86] Teach the builtin argument range check to allow invalid ranges in
Author: chandlerc Date: Thu Jun 21 16:46:09 2018 New Revision: 335309 URL: http://llvm.org/viewvc/llvm-project?rev=335309&view=rev Log: [x86] Teach the builtin argument range check to allow invalid ranges in dead code. This is important for C++ templates that essentially compute the valid input in a way that is constant and will cause all the invalid cases to be dead code that is deleted. Code in the wild actually does this and GCC also accepts these kinds of patterns so it is important to support it. To make this work, we provide a non-error path to diagnose these issues, and use a default-error warning instead. This keeps the relatively strict handling but prevents nastiness like SFINAE on these errors. It also allows us to safely use the system to diagnose this only when it occurs at runtime (in emitted code). Entertainingly, this required fixing the syntax in various other ways for the x86 test because we never bothered to diagnose that the returns were invalid. Since debugging these compile failures was super confusing, I've also improved the diagnostic to actually say what the value was. Most of the checks I've made ignore this to simplify maintenance, but I've checked it in a few places to make sure the diagnsotic is working. Depends on D48462. Without that, we might actually crash some part of the compiler after bypassing the error here. Thanks to Richard, Ben Kramer, and especially Craig Topper for all the help here. Differential Revision: https://reviews.llvm.org/D48464 Added: cfe/trunk/test/Sema/builtins-x86.cpp Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td cfe/trunk/include/clang/Sema/Sema.h cfe/trunk/lib/Sema/SemaChecking.cpp cfe/trunk/test/CodeGen/builtins-mips-args.c cfe/trunk/test/CodeGen/builtins-systemz-vector-error.c cfe/trunk/test/CodeGen/builtins-systemz-vector2-error.c cfe/trunk/test/CodeGen/builtins-systemz-zvector-error.c cfe/trunk/test/CodeGen/builtins-systemz-zvector2-error.c cfe/trunk/test/CodeGen/hexagon-check-builtins.c cfe/trunk/test/Sema/aarch64-neon-fp16-ranges.c cfe/trunk/test/Sema/aarch64-neon-ranges.c cfe/trunk/test/Sema/arm-neon-types.c cfe/trunk/test/Sema/builtin-object-size.c cfe/trunk/test/Sema/builtin-prefetch.c cfe/trunk/test/Sema/builtins-arm.c cfe/trunk/test/Sema/builtins-arm64.c cfe/trunk/test/Sema/builtins-ppc.c cfe/trunk/test/Sema/builtins-x86.c cfe/trunk/test/SemaCXX/neon-vector-types.cpp Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=335309&r1=335308&r2=335309&view=diff == --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original) +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Jun 21 16:46:09 2018 @@ -8132,7 +8132,10 @@ def err_altivec_empty_initializer : Erro def err_invalid_neon_type_code : Error< "incompatible constant for this __builtin_neon function">; def err_argument_invalid_range : Error< - "argument should be a value from %0 to %1">; + "argument value %0 is outside the valid range [%1, %2]">; +def warn_argument_invalid_range : Warning< + "argument value %0 is outside the valid range [%1, %2]">, DefaultError, + InGroup>; def err_argument_not_multiple : Error< "argument should be a multiple of %0">; def warn_neon_vector_initializer_non_portable : Warning< Modified: cfe/trunk/include/clang/Sema/Sema.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=335309&r1=335308&r2=335309&view=diff == --- cfe/trunk/include/clang/Sema/Sema.h (original) +++ cfe/trunk/include/clang/Sema/Sema.h Thu Jun 21 16:46:09 2018 @@ -10431,8 +10431,8 @@ private: bool IsDelete); bool SemaBuiltinConstantArg(CallExpr *TheCall, int ArgNum, llvm::APSInt &Result); - bool SemaBuiltinConstantArgRange(CallExpr *TheCall, int ArgNum, - int Low, int High); + bool SemaBuiltinConstantArgRange(CallExpr *TheCall, int ArgNum, int Low, + int High, bool RangeIsError = true); bool SemaBuiltinConstantArgMultiple(CallExpr *TheCall, int ArgNum, unsigned Multiple); bool SemaBuiltinARMSpecialReg(unsigned BuiltinID, CallExpr *TheCall, Modified: cfe/trunk/lib/Sema/SemaChecking.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaChecking.cpp?rev=335309&r1=335308&r2=335309&view=diff == --- cfe/trunk/lib/Sema/SemaChecking.cpp (original) +++ cfe/trunk/lib/Sema/SemaChecking.cpp Thu Jun 21 16:46:09 2018 @@ -2937,7 +2937,12 @@ bool Sema::CheckX86BuiltinFunctionCall(u i = 4; l = 0;
r335310 - [x86] Fix a tiny bug in my test case in r335309 by marking that we don't
Author: chandlerc Date: Thu Jun 21 16:52:36 2018 New Revision: 335310 URL: http://llvm.org/viewvc/llvm-project?rev=335310&view=rev Log: [x86] Fix a tiny bug in my test case in r335309 by marking that we don't expect any diagnostics. Modified: cfe/trunk/test/Sema/builtins-x86.cpp Modified: cfe/trunk/test/Sema/builtins-x86.cpp URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/builtins-x86.cpp?rev=335310&r1=335309&r2=335310&view=diff == --- cfe/trunk/test/Sema/builtins-x86.cpp (original) +++ cfe/trunk/test/Sema/builtins-x86.cpp Thu Jun 21 16:52:36 2018 @@ -2,6 +2,7 @@ // // Ensure that when we use builtins in C++ code with templates that compute the // valid immediate, the dead code with the invalid immediate doesn't error. +// expected-no-diagnostics typedef short __v8hi __attribute__((__vector_size__(16))); @@ -20,4 +21,4 @@ template __v8hi test<3>(__v8hi); template __v8hi test<4>(__v8hi); template __v8hi test<5>(__v8hi); template __v8hi test<6>(__v8hi); -template __v8hi test<7>(__v8hi); \ No newline at end of file +template __v8hi test<7>(__v8hi); ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] r344225 - Fix the qualification of `IntrusiveRefCntPtr` to use `llvm::`.
Author: chandlerc
Date: Thu Oct 11 01:05:10 2018
New Revision: 344225
URL: http://llvm.org/viewvc/llvm-project?rev=344225&view=rev
Log:
Fix the qualification of `IntrusiveRefCntPtr` to use `llvm::`.
Without this, the code only compiled if the header was included after
something introduced the alias from `clang::` to `llvm::` for this type.
Any modules build would fail here.
Modified:
clang-tools-extra/trunk/clangd/FSProvider.h
Modified: clang-tools-extra/trunk/clangd/FSProvider.h
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clangd/FSProvider.h?rev=344225&r1=344224&r2=344225&view=diff
==
--- clang-tools-extra/trunk/clangd/FSProvider.h (original)
+++ clang-tools-extra/trunk/clangd/FSProvider.h Thu Oct 11 01:05:10 2018
@@ -25,13 +25,15 @@ public:
/// Context::current() will be the context passed to the clang entrypoint,
/// such as addDocument(), and will also be propagated to result callbacks.
/// Embedders may use this to isolate filesystem accesses.
- virtual IntrusiveRefCntPtr getFileSystem() const = 0;
+ virtual llvm::IntrusiveRefCntPtr
+ getFileSystem() const = 0;
};
class RealFileSystemProvider : public FileSystemProvider {
public:
// FIXME: returns the single real FS instance, which is not threadsafe.
- IntrusiveRefCntPtr getFileSystem() const override {
+ llvm::IntrusiveRefCntPtr
+ getFileSystem() const override {
return llvm::vfs::getRealFileSystem();
}
};
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r344504 - [TI removal] Make `getTerminator()` return a generic `Instruction`.
Author: chandlerc
Date: Mon Oct 15 03:42:50 2018
New Revision: 344504
URL: http://llvm.org/viewvc/llvm-project?rev=344504&view=rev
Log:
[TI removal] Make `getTerminator()` return a generic `Instruction`.
This removes the primary remaining API producing `TerminatorInst` which
will reduce the rate at which code is introduced trying to use it and
generally make it much easier to remove the remaining APIs across the
codebase.
Also clean up some of the stragglers that the previous mechanical update
of variables missed.
Users of LLVM and out-of-tree code generally will need to update any
explicit variable types to handle this. Replacing `TerminatorInst` with
`Instruction` (or `auto`) almost always works. Most of these edits were
made in prior commits using the perl one-liner:
```
perl -i -ple 's/TerminatorInst(\b.* = .*getTerminator\(\))/Instruction\1/g'
```
This also my break some rare use cases where people overload for both
`Instruction` and `TerminatorInst`, but these should be easily fixed by
removing the `TerminatorInst` overload.
Modified:
cfe/trunk/lib/CodeGen/CGCleanup.cpp
cfe/trunk/lib/CodeGen/CGException.cpp
Modified: cfe/trunk/lib/CodeGen/CGCleanup.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCleanup.cpp?rev=344504&r1=344503&r2=344504&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCleanup.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCleanup.cpp Mon Oct 15 03:42:50 2018
@@ -366,7 +366,7 @@ static llvm::SwitchInst *TransitionToCle
llvm::BasicBlock *Block) {
// If it's a branch, turn it into a switch whose default
// destination is its original target.
- llvm::TerminatorInst *Term = Block->getTerminator();
+ llvm::Instruction *Term = Block->getTerminator();
assert(Term && "can't transition block without terminator");
if (llvm::BranchInst *Br = dyn_cast(Term)) {
@@ -589,7 +589,7 @@ static void ForwardPrebranchedFallthroug
llvm::BasicBlock *To) {
// Exit is the exit block of a cleanup, so it always terminates in
// an unconditional branch or a switch.
- llvm::TerminatorInst *Term = Exit->getTerminator();
+ llvm::Instruction *Term = Exit->getTerminator();
if (llvm::BranchInst *Br = dyn_cast(Term)) {
assert(Br->isUnconditional() && Br->getSuccessor(0) == From);
Modified: cfe/trunk/lib/CodeGen/CGException.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGException.cpp?rev=344504&r1=344503&r2=344504&view=diff
==
--- cfe/trunk/lib/CodeGen/CGException.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGException.cpp Mon Oct 15 03:42:50 2018
@@ -1248,7 +1248,7 @@ void CodeGenFunction::ExitCXXTryStmt(con
// we follow the false destination for each of the cond branches to reach
// the rethrow block.
llvm::BasicBlock *RethrowBlock = WasmCatchStartBlock;
-while (llvm::TerminatorInst *TI = RethrowBlock->getTerminator()) {
+while (llvm::Instruction *TI = RethrowBlock->getTerminator()) {
auto *BI = cast(TI);
assert(BI->isConditional());
RethrowBlock = BI->getSuccessor(1);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r344730 - [TI removal] Test predicate rather than casting to detect a terminator
Author: chandlerc
Date: Thu Oct 18 01:16:20 2018
New Revision: 344730
URL: http://llvm.org/viewvc/llvm-project?rev=344730&view=rev
Log:
[TI removal] Test predicate rather than casting to detect a terminator
and use the range based successor API.
Modified:
cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
Modified: cfe/trunk/lib/CodeGen/CGLoopInfo.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGLoopInfo.cpp?rev=344730&r1=344729&r2=344730&view=diff
==
--- cfe/trunk/lib/CodeGen/CGLoopInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGLoopInfo.cpp Thu Oct 18 01:16:20 2018
@@ -12,6 +12,7 @@
#include "clang/AST/Attr.h"
#include "clang/Sema/LoopHint.h"
#include "llvm/IR/BasicBlock.h"
+#include "llvm/IR/CFG.h"
#include "llvm/IR/Constants.h"
#include "llvm/IR/InstrTypes.h"
#include "llvm/IR/Instructions.h"
@@ -335,10 +336,10 @@ void LoopInfoStack::InsertHelper(Instruc
if (!L.getLoopID())
return;
- if (TerminatorInst *TI = dyn_cast(I)) {
-for (unsigned i = 0, ie = TI->getNumSuccessors(); i < ie; ++i)
- if (TI->getSuccessor(i) == L.getHeader()) {
-TI->setMetadata(llvm::LLVMContext::MD_loop, L.getLoopID());
+ if (I->isTerminator()) {
+for (BasicBlock *Succ : successors(I))
+ if (Succ == L.getHeader()) {
+I->setMetadata(llvm::LLVMContext::MD_loop, L.getLoopID());
break;
}
return;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] r351631 - Install new LLVM license structure and new developer policy.
Author: chandlerc Date: Fri Jan 18 22:14:24 2019 New Revision: 351631 URL: http://llvm.org/viewvc/llvm-project?rev=351631&view=rev Log: Install new LLVM license structure and new developer policy. This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 Modified: clang-tools-extra/trunk/LICENSE.TXT clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt clang-tools-extra/trunk/clang-tidy/cert/LICENSE.TXT clang-tools-extra/trunk/clang-tidy/hicpp/LICENSE.TXT Modified: clang-tools-extra/trunk/LICENSE.TXT URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/LICENSE.TXT?rev=351631&r1=351630&r2=351631&view=diff == --- clang-tools-extra/trunk/LICENSE.TXT (original) +++ clang-tools-extra/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019 @@ -1,5 +1,240 @@ == -LLVM Release License +The LLVM Project is under the Apache License v2.0 with LLVM Exceptions: +== + + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + +TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + +1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in
[libunwind] r351631 - Install new LLVM license structure and new developer policy.
Author: chandlerc Date: Fri Jan 18 22:14:24 2019 New Revision: 351631 URL: http://llvm.org/viewvc/llvm-project?rev=351631&view=rev Log: Install new LLVM license structure and new developer policy. This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 Modified: libunwind/trunk/LICENSE.TXT Modified: libunwind/trunk/LICENSE.TXT URL: http://llvm.org/viewvc/llvm-project/libunwind/trunk/LICENSE.TXT?rev=351631&r1=351630&r2=351631&view=diff == --- libunwind/trunk/LICENSE.TXT (original) +++ libunwind/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019 @@ -1,5 +1,240 @@ == -libunwind License +The LLVM Project is under the Apache License v2.0 with LLVM Exceptions: +== + + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + +TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + +1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electron
[libclc] r351631 - Install new LLVM license structure and new developer policy.
Author: chandlerc Date: Fri Jan 18 22:14:24 2019 New Revision: 351631 URL: http://llvm.org/viewvc/llvm-project?rev=351631&view=rev Log: Install new LLVM license structure and new developer policy. This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 Modified: libclc/trunk/LICENSE.TXT Modified: libclc/trunk/LICENSE.TXT URL: http://llvm.org/viewvc/llvm-project/libclc/trunk/LICENSE.TXT?rev=351631&r1=351630&r2=351631&view=diff == --- libclc/trunk/LICENSE.TXT (original) +++ libclc/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019 @@ -1,5 +1,240 @@ == -libclc License +The LLVM Project is under the Apache License v2.0 with LLVM Exceptions: +== + + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + +TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + +1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted" + means any form of electronic, verbal, or wri
r351631 - Install new LLVM license structure and new developer policy.
Author: chandlerc Date: Fri Jan 18 22:14:24 2019 New Revision: 351631 URL: http://llvm.org/viewvc/llvm-project?rev=351631&view=rev Log: Install new LLVM license structure and new developer policy. This installs the new developer policy and moves all of the license files across all LLVM projects in the monorepo to the new license structure. The remaining projects will be moved independently. Note that I've left odd formatting and other idiosyncracies of the legacy license structure text alone to make the diff easier to read. Critically, note that we do not in any case *remove* the old license notice or terms, as that remains necessary until we finish the relicensing process. I've updated a few license files that refer to the LLVM license to instead simply refer generically to whatever license the LLVM project is under, basically trying to minimize confusion. This is really the culmination of so many people. Chris led the community discussions, drafted the policy update and organized the multi-year string of meeting between lawyers across the community to figure out the strategy. Numerous lawyers at companies in the community spent their time figuring out initial answers, and then the Foundation's lawyer Heather Meeker has done *so* much to help refine and get us ready here. I could keep going on, but I just want to make sure everyone realizes what a huge community effort this has been from the begining. Differential Revision: https://reviews.llvm.org/D56897 Modified: cfe/trunk/LICENSE.TXT cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt Modified: cfe/trunk/LICENSE.TXT URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/LICENSE.TXT?rev=351631&r1=351630&r2=351631&view=diff == --- cfe/trunk/LICENSE.TXT (original) +++ cfe/trunk/LICENSE.TXT Fri Jan 18 22:14:24 2019 @@ -1,5 +1,240 @@ == -LLVM Release License +The LLVM Project is under the Apache License v2.0 with LLVM Exceptions: +== + + Apache License + Version 2.0, January 2004 +http://www.apache.org/licenses/ + +TERMS AND CONDITIONS FOR USE, REPRODUCTION, AND DISTRIBUTION + +1. Definitions. + + "License" shall mean the terms and conditions for use, reproduction, + and distribution as defined by Sections 1 through 9 of this document. + + "Licensor" shall mean the copyright owner or entity authorized by + the copyright owner that is granting the License. + + "Legal Entity" shall mean the union of the acting entity and all + other entities that control, are controlled by, or are under common + control with that entity. For the purposes of this definition, + "control" means (i) the power, direct or indirect, to cause the + direction or management of such entity, whether by contract or + otherwise, or (ii) ownership of fifty percent (50%) or more of the + outstanding shares, or (iii) beneficial ownership of such entity. + + "You" (or "Your") shall mean an individual or Legal Entity + exercising permissions granted by this License. + + "Source" form shall mean the preferred form for making modifications, + including but not limited to software source code, documentation + source, and configuration files. + + "Object" form shall mean any form resulting from mechanical + transformation or translation of a Source form, including but + not limited to compiled object code, generated documentation, + and conversions to other media types. + + "Work" shall mean the work of authorship, whether in Source or + Object form, made available under the License, as indicated by a + copyright notice that is included in or attached to the work + (an example is provided in the Appendix below). + + "Derivative Works" shall mean any work, whether in Source or Object + form, that is based on (or derived from) the Work and for which the + editorial revisions, annotations, elaborations, or other modifications + represent, as a whole, an original work of authorship. For the purposes + of this License, Derivative Works shall not include works that remain + separable from, or merely link (or bind by name) to the interfaces of, + the Work and Derivative Works thereof. + + "Contribution" shall mean any work of authorship, including + the original version of the Work and any modifications or additions + to that Work or Derivative Works thereof, that is intentionally + submitted to Licensor for inclusion in the Work by the copyright owner + or by an individual or Legal Entity authorized to submit on behalf of + the copyright owner. For the purposes of this definition, "submitted"
r351632 - Update some code used in our visual studio plugins to use linux file
Author: chandlerc
Date: Fri Jan 18 22:29:07 2019
New Revision: 351632
URL: http://llvm.org/viewvc/llvm-project?rev=351632&view=rev
Log:
Update some code used in our visual studio plugins to use linux file
endings. We already used them in some cases, and this makes things
consistent. This will also simplify updating the licenses in these
files.
Modified:
cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
cfe/trunk/tools/clang-format-vs/ClangFormat/Guids.cs
cfe/trunk/tools/clang-format-vs/ClangFormat/PkgCmdID.cs
Modified: cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs?rev=351632&r1=351631&r2=351632&view=diff
==
--- cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs (original)
+++ cfe/trunk/tools/clang-format-vs/ClangFormat/ClangFormatPackage.cs Fri Jan
18 22:29:07 2019
@@ -1,456 +1,456 @@
-//===-- ClangFormatPackages.cs - VSPackage for clang-format --*- C#
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// This class contains a VS extension package that runs clang-format over a
-// selection in a VS text editor.
-//
-//===--===//
-
-using EnvDTE;
-using Microsoft.VisualStudio.Shell;
-using Microsoft.VisualStudio.Shell.Interop;
-using Microsoft.VisualStudio.Text;
-using Microsoft.VisualStudio.Text.Editor;
-using System;
-using System.Collections;
-using System.ComponentModel;
-using System.ComponentModel.Design;
-using System.IO;
-using System.Runtime.InteropServices;
-using System.Xml.Linq;
-using System.Linq;
-
-namespace LLVM.ClangFormat
-{
-[ClassInterface(ClassInterfaceType.AutoDual)]
-[CLSCompliant(false), ComVisible(true)]
-public class OptionPageGrid : DialogPage
-{
-private string assumeFilename = "";
-private string fallbackStyle = "LLVM";
-private bool sortIncludes = false;
-private string style = "file";
-private bool formatOnSave = false;
-private string formatOnSaveFileExtensions =
-".c;.cpp;.cxx;.cc;.tli;.tlh;.h;.hh;.hpp;.hxx;.hh;.inl;" +
-".java;.js;.ts;.m;.mm;.proto;.protodevel;.td";
-
-public OptionPageGrid Clone()
-{
-// Use MemberwiseClone to copy value types.
-var clone = (OptionPageGrid)MemberwiseClone();
-return clone;
-}
-
-public class StyleConverter : TypeConverter
-{
-protected ArrayList values;
-public StyleConverter()
-{
-// Initializes the standard values list with defaults.
-values = new ArrayList(new string[] { "file", "Chromium",
"Google", "LLVM", "Mozilla", "WebKit" });
-}
-
-public override bool
GetStandardValuesSupported(ITypeDescriptorContext context)
-{
-return true;
-}
-
-public override StandardValuesCollection
GetStandardValues(ITypeDescriptorContext context)
-{
-return new StandardValuesCollection(values);
-}
-
-public override bool CanConvertFrom(ITypeDescriptorContext
context, Type sourceType)
-{
-if (sourceType == typeof(string))
-return true;
-
-return base.CanConvertFrom(context, sourceType);
-}
-
-public override object ConvertFrom(ITypeDescriptorContext context,
System.Globalization.CultureInfo culture, object value)
-{
-string s = value as string;
-if (s == null)
-return base.ConvertFrom(context, culture, value);
-
-return value;
-}
-}
-
-[Category("Format Options")]
-[DisplayName("Style")]
-[Description("Coding style, currently supports:\n" +
- " - Predefined styles ('LLVM', 'Google', 'Chromium',
'Mozilla', 'WebKit').\n" +
- " - 'file' to search for a YAML .clang-format or
_clang-format\n" +
- "configuration file.\n" +
- " - A YAML configuration snippet.\n\n" +
- "'File':\n" +
- " Searches for a .clang-format or _clang-format
configuration file\n" +
- " in the source file's directory and its parents.\n\n" +
- "YAML configuration snippet:\n" +
- " The content of a .clang-format configuration file, as
string.\n" +
- " Example: '{BasedOnS
[clang-tools-extra] r351632 - Update some code used in our visual studio plugins to use linux file
Author: chandlerc
Date: Fri Jan 18 22:29:07 2019
New Revision: 351632
URL: http://llvm.org/viewvc/llvm-project?rev=351632&view=rev
Log:
Update some code used in our visual studio plugins to use linux file
endings. We already used them in some cases, and this makes things
consistent. This will also simplify updating the licenses in these
files.
Modified:
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPropertyGrid.cs
clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/PkgCmdID.cs
Modified: clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs?rev=351632&r1=351631&r2=351632&view=diff
==
--- clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs
(original)
+++ clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/ClangTidyPackage.cs Fri Jan
18 22:29:07 2019
@@ -1,56 +1,56 @@
-//===-- ClangTidyPackages.cs - VSPackage for clang-tidy --*- C#
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-//
-// This class contains a VS extension package that runs clang-tidy over a
-// file in a VS text editor.
-//
-//===--===//
-
-using Microsoft.VisualStudio.Editor;
-using Microsoft.VisualStudio.Shell;
-using Microsoft.VisualStudio.Shell.Interop;
-using Microsoft.VisualStudio.TextManager.Interop;
-using System;
-using System.Collections;
-using System.ComponentModel;
-using System.ComponentModel.Design;
-using System.IO;
-using System.Runtime.InteropServices;
-using System.Windows.Forms;
-using System.Xml.Linq;
-
-namespace LLVM.ClangTidy
-{
-[PackageRegistration(UseManagedResourcesOnly = true)]
-[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
-[ProvideMenuResource("Menus.ctmenu", 1)]
-[Guid(GuidList.guidClangTidyPkgString)]
-[ProvideOptionPage(typeof(ClangTidyConfigurationPage), "LLVM/Clang",
"ClangTidy", 0, 0, true)]
-public sealed class ClangTidyPackage : Package
-{
-#region Package Members
-protected override void Initialize()
-{
-base.Initialize();
-
-var commandService = GetService(typeof(IMenuCommandService)) as
OleMenuCommandService;
-if (commandService != null)
-{
-var menuCommandID = new
CommandID(GuidList.guidClangTidyCmdSet, (int)PkgCmdIDList.cmdidClangTidy);
-var menuItem = new MenuCommand(MenuItemCallback,
menuCommandID);
-commandService.AddCommand(menuItem);
-}
-}
-#endregion
-
-private void MenuItemCallback(object sender, EventArgs args)
-{
-}
-}
-}
+//===-- ClangTidyPackages.cs - VSPackage for clang-tidy --*- C#
-*-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+//
+// This class contains a VS extension package that runs clang-tidy over a
+// file in a VS text editor.
+//
+//===--===//
+
+using Microsoft.VisualStudio.Editor;
+using Microsoft.VisualStudio.Shell;
+using Microsoft.VisualStudio.Shell.Interop;
+using Microsoft.VisualStudio.TextManager.Interop;
+using System;
+using System.Collections;
+using System.ComponentModel;
+using System.ComponentModel.Design;
+using System.IO;
+using System.Runtime.InteropServices;
+using System.Windows.Forms;
+using System.Xml.Linq;
+
+namespace LLVM.ClangTidy
+{
+[PackageRegistration(UseManagedResourcesOnly = true)]
+[InstalledProductRegistration("#110", "#112", "1.0", IconResourceID = 400)]
+[ProvideMenuResource("Menus.ctmenu", 1)]
+[Guid(GuidList.guidClangTidyPkgString)]
+[ProvideOptionPage(typeof(ClangTidyConfigurationPage), "LLVM/Clang",
"ClangTidy", 0, 0, true)]
+public sealed class ClangTidyPackage : Package
+{
+#region Package Members
+protected override void Initialize()
+{
+base.Initialize();
+
+var commandService = GetService(typeof(IMenuCommandService)) as
OleMenuCommandService;
+if (commandService != null)
+{
+var menuCommandID = new
CommandID(GuidList.guidClangTidyCmdSet, (int)PkgCmdIDList.cmdidClangTidy);
+var menuItem = new MenuCommand(MenuItemCallback,
menuCommandID);
+commandServi
[clang-tools-extra] r351634 - Convert two more files that were using Windows line endings and remove
Author: chandlerc
Date: Fri Jan 18 22:36:08 2019
New Revision: 351634
URL: http://llvm.org/viewvc/llvm-project?rev=351634&view=rev
Log:
Convert two more files that were using Windows line endings and remove
a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.
Modified:
clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp?rev=351634&r1=351633&r2=351634&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/ElseAfterReturnCheck.cpp Fri
Jan 18 22:36:08 2019
@@ -1,58 +1,58 @@
-//===--- ElseAfterReturnCheck.cpp -
clang-tidy-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#include "ElseAfterReturnCheck.h"
-#include "clang/AST/ASTContext.h"
-#include "clang/ASTMatchers/ASTMatchFinder.h"
-#include "clang/Tooling/FixIt.h"
-
-using namespace clang::ast_matchers;
-
-namespace clang {
-namespace tidy {
-namespace readability {
-
-void ElseAfterReturnCheck::registerMatchers(MatchFinder *Finder) {
- const auto ControlFlowInterruptorMatcher =
- stmt(anyOf(returnStmt().bind("return"), continueStmt().bind("continue"),
- breakStmt().bind("break"),
- expr(ignoringImplicit(cxxThrowExpr().bind("throw");
- Finder->addMatcher(
- compoundStmt(forEach(
- ifStmt(unless(isConstexpr()),
- hasThen(stmt(
- anyOf(ControlFlowInterruptorMatcher,
- compoundStmt(has(ControlFlowInterruptorMatcher),
- hasElse(stmt().bind("else")))
- .bind("if"))),
- this);
-}
-
-void ElseAfterReturnCheck::check(const MatchFinder::MatchResult &Result) {
- const auto *If = Result.Nodes.getNodeAs("if");
- SourceLocation ElseLoc = If->getElseLoc();
- std::string ControlFlowInterruptor;
- for (const auto *BindingName : {"return", "continue", "break", "throw"})
-if (Result.Nodes.getNodeAs(BindingName))
- ControlFlowInterruptor = BindingName;
-
- DiagnosticBuilder Diag = diag(ElseLoc, "do not use 'else' after '%0'")
- << ControlFlowInterruptor;
- Diag << tooling::fixit::createRemoval(ElseLoc);
-
- // FIXME: Removing the braces isn't always safe. Do a more careful analysis.
- // FIXME: Change clang-format to correctly un-indent the code.
- if (const auto *CS = Result.Nodes.getNodeAs("else"))
-Diag << tooling::fixit::createRemoval(CS->getLBracLoc())
- << tooling::fixit::createRemoval(CS->getRBracLoc());
-}
-
-} // namespace readability
-} // namespace tidy
-} // namespace clang
+//===--- ElseAfterReturnCheck.cpp -
clang-tidy-===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is distributed under the University of Illinois Open Source
+// License. See LICENSE.TXT for details.
+//
+//===--===//
+
+#include "ElseAfterReturnCheck.h"
+#include "clang/AST/ASTContext.h"
+#include "clang/ASTMatchers/ASTMatchFinder.h"
+#include "clang/Tooling/FixIt.h"
+
+using namespace clang::ast_matchers;
+
+namespace clang {
+namespace tidy {
+namespace readability {
+
+void ElseAfterReturnCheck::registerMatchers(MatchFinder *Finder) {
+ const auto ControlFlowInterruptorMatcher =
+ stmt(anyOf(returnStmt().bind("return"), continueStmt().bind("continue"),
+ breakStmt().bind("break"),
+ expr(ignoringImplicit(cxxThrowExpr().bind("throw");
+ Finder->addMatcher(
+ compoundStmt(forEach(
+ ifStmt(unless(isConstexpr()),
+ hasThen(stmt(
+ anyOf(ControlFlowInterruptorMatcher,
+ compoundStmt(has(ControlFlowInterruptorMatcher),
+ hasElse(stmt().bind("else")))
+ .bind("if"))),
+ this);
+}
+
+void ElseAfterReturnCheck::check(const MatchFinder::MatchResult &Result) {
+ const auto *If = Result.Nodes.getNodeAs("if");
+ SourceLocation ElseLoc = If->getElseLoc();
+ std::string ControlFlowInterruptor;
+ for (const auto *BindingName : {"return", "continue", "break", "throw"})
+if (Result.Nodes.getNodeAs(BindingName))
+ ControlFlowInterruptor = BindingName;
+
+ DiagnosticBuilder Diag = diag(ElseLoc, "do not use 'else' after '%0'")
+ << ControlFlowInterruptor
r351633 - Remove random windows line endings that snuck into the middle of this
Author: chandlerc
Date: Fri Jan 18 22:36:00 2019
New Revision: 351633
URL: http://llvm.org/viewvc/llvm-project?rev=351633&view=rev
Log:
Remove random windows line endings that snuck into the middle of this
code.
Modified:
cfe/trunk/lib/Lex/PPDirectives.cpp
Modified: cfe/trunk/lib/Lex/PPDirectives.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/PPDirectives.cpp?rev=351633&r1=351632&r2=351633&view=diff
==
--- cfe/trunk/lib/Lex/PPDirectives.cpp (original)
+++ cfe/trunk/lib/Lex/PPDirectives.cpp Fri Jan 18 22:36:00 2019
@@ -76,24 +76,24 @@ Preprocessor::AllocateVisibilityMacroDir
bool isPublic) {
return new (BP) VisibilityMacroDirective(Loc, isPublic);
}
-
-/// Read and discard all tokens remaining on the current line until
-/// the tok::eod token is found.
-SourceRange Preprocessor::DiscardUntilEndOfDirective() {
- Token Tmp;
- SourceRange Res;
-
- LexUnexpandedToken(Tmp);
- Res.setBegin(Tmp.getLocation());
- while (Tmp.isNot(tok::eod)) {
-assert(Tmp.isNot(tok::eof) && "EOF seen while discarding directive
tokens");
-LexUnexpandedToken(Tmp);
- }
- Res.setEnd(Tmp.getLocation());
- return Res;
-}
-
-/// Enumerates possible cases of #define/#undef a reserved identifier.
+
+/// Read and discard all tokens remaining on the current line until
+/// the tok::eod token is found.
+SourceRange Preprocessor::DiscardUntilEndOfDirective() {
+ Token Tmp;
+ SourceRange Res;
+
+ LexUnexpandedToken(Tmp);
+ Res.setBegin(Tmp.getLocation());
+ while (Tmp.isNot(tok::eod)) {
+assert(Tmp.isNot(tok::eof) && "EOF seen while discarding directive
tokens");
+LexUnexpandedToken(Tmp);
+ }
+ Res.setEnd(Tmp.getLocation());
+ return Res;
+}
+
+/// Enumerates possible cases of #define/#undef a reserved identifier.
enum MacroDiag {
MD_NoWarn,//> Not a reserved identifier
MD_KeywordDef,//> Macro hides keyword, enabled by default
@@ -541,25 +541,25 @@ void Preprocessor::SkipExcludedCondition
// If this is in a skipping block or if we're already handled this #if
// block, don't bother parsing the condition.
-if (CondInfo.WasSkipping || CondInfo.FoundNonSkip) {
- DiscardUntilEndOfDirective();
-} else {
- // Restore the value of LexingRawMode so that identifiers are
- // looked up, etc, inside the #elif expression.
- assert(CurPPLexer->LexingRawMode && "We have to be skipping here!");
- CurPPLexer->LexingRawMode = false;
- IdentifierInfo *IfNDefMacro = nullptr;
- DirectiveEvalResult DER = EvaluateDirectiveExpression(IfNDefMacro);
- const bool CondValue = DER.Conditional;
- CurPPLexer->LexingRawMode = true;
- if (Callbacks) {
-Callbacks->Elif(
-Tok.getLocation(), DER.ExprRange,
-(CondValue ? PPCallbacks::CVK_True : PPCallbacks::CVK_False),
-CondInfo.IfLoc);
- }
- // If this condition is true, enter it!
- if (CondValue) {
+if (CondInfo.WasSkipping || CondInfo.FoundNonSkip) {
+ DiscardUntilEndOfDirective();
+} else {
+ // Restore the value of LexingRawMode so that identifiers are
+ // looked up, etc, inside the #elif expression.
+ assert(CurPPLexer->LexingRawMode && "We have to be skipping here!");
+ CurPPLexer->LexingRawMode = false;
+ IdentifierInfo *IfNDefMacro = nullptr;
+ DirectiveEvalResult DER = EvaluateDirectiveExpression(IfNDefMacro);
+ const bool CondValue = DER.Conditional;
+ CurPPLexer->LexingRawMode = true;
+ if (Callbacks) {
+Callbacks->Elif(
+Tok.getLocation(), DER.ExprRange,
+(CondValue ? PPCallbacks::CVK_True : PPCallbacks::CVK_False),
+CondInfo.IfLoc);
+ }
+ // If this condition is true, enter it!
+ if (CondValue) {
CondInfo.FoundNonSkip = true;
break;
}
@@ -1119,30 +1119,30 @@ void Preprocessor::HandleLineDirective()
// If the StrTok is "eod", then it wasn't present. Otherwise, it must be a
// string followed by eod.
if (StrTok.is(tok::eod))
-; // ok
- else if (StrTok.isNot(tok::string_literal)) {
-Diag(StrTok, diag::err_pp_line_invalid_filename);
-DiscardUntilEndOfDirective();
-return;
- } else if (StrTok.hasUDSuffix()) {
-Diag(StrTok, diag::err_invalid_string_udl);
-DiscardUntilEndOfDirective();
-return;
- } else {
-// Parse and validate the string, converting it into a unique ID.
-StringLiteralParser Literal(StrTok, *this);
-assert(Literal.isAscii() && "Didn't allow wide strings in");
-if (Literal.hadError) {
- DiscardUntilEndOfDirective();
- return;
-}
-if (Literal.Pascal) {
- Diag(StrTok, diag::err_pp_linemarker_inval
r351634 - Convert two more files that were using Windows line endings and remove
Author: chandlerc
Date: Fri Jan 18 22:36:08 2019
New Revision: 351634
URL: http://llvm.org/viewvc/llvm-project?rev=351634&view=rev
Log:
Convert two more files that were using Windows line endings and remove
a stray single '\r' from one file. These are the last line ending issues
I can find in the files containing parts of LLVM's file headers.
Modified:
cfe/trunk/lib/Basic/Targets/ARC.cpp
Modified: cfe/trunk/lib/Basic/Targets/ARC.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets/ARC.cpp?rev=351634&r1=351633&r2=351634&view=diff
==
--- cfe/trunk/lib/Basic/Targets/ARC.cpp (original)
+++ cfe/trunk/lib/Basic/Targets/ARC.cpp Fri Jan 18 22:36:08 2019
@@ -22,4 +22,4 @@ using namespace clang::targets;
void ARCTargetInfo::getTargetDefines(const LangOptions &Opts,
MacroBuilder &Builder) const {
Builder.defineMacro("__arc__");
-}
+}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] r351636 - Update the file headers across all of the LLVM projects in the monorepo
Author: chandlerc Date: Sat Jan 19 00:50:56 2019 New Revision: 351636 URL: http://llvm.org/viewvc/llvm-project?rev=351636&view=rev Log: Update the file headers across all of the LLVM projects in the monorepo to reflect the new license. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. Modified: libclc/trunk/generic/include/clc/misc/shuffle.h libclc/trunk/generic/include/clc/misc/shuffle2.h libclc/trunk/generic/lib/misc/shuffle.cl libclc/trunk/generic/lib/misc/shuffle2.cl Modified: libclc/trunk/generic/include/clc/misc/shuffle.h URL: http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/include/clc/misc/shuffle.h?rev=351636&r1=351635&r2=351636&view=diff == --- libclc/trunk/generic/include/clc/misc/shuffle.h (original) +++ libclc/trunk/generic/include/clc/misc/shuffle.h Sat Jan 19 00:50:56 2019 @@ -1,9 +1,8 @@ //===-- generic/include/clc/misc/shuffle.h --===// // -// The LLVM Compiler Infrastructure -// -// This file is dual licensed under both the University of Illinois Open Source -// License and the MIT license. See LICENSE.TXT for details. +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // //===--===// Modified: libclc/trunk/generic/include/clc/misc/shuffle2.h URL: http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/include/clc/misc/shuffle2.h?rev=351636&r1=351635&r2=351636&view=diff == --- libclc/trunk/generic/include/clc/misc/shuffle2.h (original) +++ libclc/trunk/generic/include/clc/misc/shuffle2.h Sat Jan 19 00:50:56 2019 @@ -1,9 +1,8 @@ //===-- generic/include/clc/misc/shuffle2.h --===// // -// The LLVM Compiler Infrastructure -// -// This file is dual licensed under both the University of Illinois Open Source -// License and the MIT license. See LICENSE.TXT for details. +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // //===--===// Modified: libclc/trunk/generic/lib/misc/shuffle.cl URL: http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/misc/shuffle.cl?rev=351636&r1=351635&r2=351636&view=diff == --- libclc/trunk/generic/lib/misc/shuffle.cl (original) +++ libclc/trunk/generic/lib/misc/shuffle.cl Sat Jan 19 00:50:56 2019 @@ -1,9 +1,8 @@ //===-- generic/lib/misc/shuffle.cl --===// // -// The LLVM Compiler Infrastructure -// -// This file is dual licensed under both the University of Illinois Open Source -// License and the MIT license. See LICENSE.TXT for details. +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // //===--===// Modified: libclc/trunk/generic/lib/misc/shuffle2.cl URL: http://llvm.org/viewvc/llvm-project/libclc/trunk/generic/lib/misc/shuffle2.cl?rev=351636&r1=351635&r2=351636&view=diff == --- libclc/trunk/generic/lib/misc/shuffle2.cl (original) +++ libclc/trunk/generic/lib/misc/shuffle2.cl Sat Jan 19 00:50:56 2019 @@ -1,9 +1,8 @@ //===-- generic/lib/misc/shuffle2.cl --===// // -// The LLVM Compiler Infrastructure -// -// This file is dual licensed under both the University of Illinois Open Source -// License and the MIT license. See LICENSE.TXT for details. +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // //===--===//
r351640 - Update the license header in this man-page file.
Author: chandlerc Date: Sat Jan 19 01:24:38 2019 New Revision: 351640 URL: http://llvm.org/viewvc/llvm-project?rev=351640&view=rev Log: Update the license header in this man-page file. It contains an `$Id$` expansion and so can only be updated from a true Subversion client. See the details of this update in r351636. Modified: cfe/trunk/tools/scan-build/man/scan-build.1 Modified: cfe/trunk/tools/scan-build/man/scan-build.1 URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build/man/scan-build.1?rev=351640&r1=351639&r2=351640&view=diff == --- cfe/trunk/tools/scan-build/man/scan-build.1 (original) +++ cfe/trunk/tools/scan-build/man/scan-build.1 Sat Jan 19 01:24:38 2019 @@ -1,5 +1,6 @@ -.\" This file is distributed under the University of Illinois Open Source -.\" License. See LICENSE.TXT for details. +.\" Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +.\" See https://llvm.org/LICENSE.txt for license information. +.\" SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception .\" $Id$ .Dd May 25, 2012 .Dt SCAN-BUILD 1 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] r351648 - Update more file headers across all of the LLVM projects in the monorepo
Author: chandlerc Date: Sat Jan 19 02:56:40 2019 New Revision: 351648 URL: http://llvm.org/viewvc/llvm-project?rev=351648&view=rev Log: Update more file headers across all of the LLVM projects in the monorepo to reflect the new license. These used slightly different spellings that defeated my regular expressions. We understand that people may be surprised that we're moving the header entirely to discuss the new license. We checked this carefully with the Foundation's lawyer and we believe this is the correct approach. Essentially, all code in the project is now made available by the LLVM project under our new license, so you will see that the license headers include that license only. Some of our contributors have contributed code under our old license, and accordingly, we have retained a copy of our old license notice in the top-level files in each project and repository. Modified: libunwind/trunk/include/__libunwind_config.h libunwind/trunk/include/libunwind.h libunwind/trunk/include/mach-o/compact_unwind_encoding.h libunwind/trunk/include/unwind.h libunwind/trunk/src/AddressSpace.hpp libunwind/trunk/src/CompactUnwinder.hpp libunwind/trunk/src/DwarfInstructions.hpp libunwind/trunk/src/DwarfParser.hpp libunwind/trunk/src/EHHeaderParser.hpp libunwind/trunk/src/RWMutex.hpp libunwind/trunk/src/Registers.hpp libunwind/trunk/src/Unwind-EHABI.cpp libunwind/trunk/src/Unwind-EHABI.h libunwind/trunk/src/Unwind-seh.cpp libunwind/trunk/src/Unwind-sjlj.c libunwind/trunk/src/UnwindCursor.hpp libunwind/trunk/src/UnwindLevel1-gcc-ext.c libunwind/trunk/src/UnwindLevel1.c libunwind/trunk/src/UnwindRegistersRestore.S libunwind/trunk/src/UnwindRegistersSave.S libunwind/trunk/src/Unwind_AppleExtras.cpp libunwind/trunk/src/assembly.h libunwind/trunk/src/config.h libunwind/trunk/src/dwarf2.h libunwind/trunk/src/libunwind.cpp libunwind/trunk/src/libunwind_ext.h libunwind/trunk/test/alignment.pass.cpp libunwind/trunk/test/libunwind/test/config.py Modified: libunwind/trunk/include/__libunwind_config.h URL: http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/__libunwind_config.h?rev=351648&r1=351647&r2=351648&view=diff == --- libunwind/trunk/include/__libunwind_config.h (original) +++ libunwind/trunk/include/__libunwind_config.h Sat Jan 19 02:56:40 2019 @@ -1,9 +1,8 @@ //===- __libunwind_config.h ---===// // -// The LLVM Compiler Infrastructure -// -// This file is dual licensed under the MIT and the University of Illinois Open -// Source Licenses. See LICENSE.TXT for details. +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // //===--===// Modified: libunwind/trunk/include/libunwind.h URL: http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/libunwind.h?rev=351648&r1=351647&r2=351648&view=diff == --- libunwind/trunk/include/libunwind.h (original) +++ libunwind/trunk/include/libunwind.h Sat Jan 19 02:56:40 2019 @@ -1,9 +1,8 @@ //=== libunwind.h -===// // -// The LLVM Compiler Infrastructure -// -// This file is dual licensed under the MIT and the University of Illinois Open -// Source Licenses. See LICENSE.TXT for details. +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // // // Compatible with libunwind API documented at: Modified: libunwind/trunk/include/mach-o/compact_unwind_encoding.h URL: http://llvm.org/viewvc/llvm-project/libunwind/trunk/include/mach-o/compact_unwind_encoding.h?rev=351648&r1=351647&r2=351648&view=diff == --- libunwind/trunk/include/mach-o/compact_unwind_encoding.h (original) +++ libunwind/trunk/include/mach-o/compact_unwind_encoding.h Sat Jan 19 02:56:40 2019 @@ -1,9 +1,8 @@ //===-- mach-o/compact_unwind_encoding.h --===// // -// The LLVM Compiler Infrastructure -// -// This file is dual licensed under the MIT and the University of Illinois Open -// Source Licenses. See LICENSE.TXT for details. +// Part of the LLVM Project, under the Apache License v2.0 with LLVM Exceptions. +// See https://llvm.org/LICENSE.txt for license information. +// SPDX-License-Identifier: Apache-2.0 WITH LLVM-exception // // // Darwin's alternative to DWARF based unwind encodings. Modified
r351651 - Update the license mentioned in this documentation.
Author: chandlerc Date: Sat Jan 19 03:48:15 2019 New Revision: 351651 URL: http://llvm.org/viewvc/llvm-project?rev=351651&view=rev Log: Update the license mentioned in this documentation. Modified: cfe/trunk/tools/scan-build-py/README.md Modified: cfe/trunk/tools/scan-build-py/README.md URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/scan-build-py/README.md?rev=351651&r1=351650&r2=351651&view=diff == --- cfe/trunk/tools/scan-build-py/README.md (original) +++ cfe/trunk/tools/scan-build-py/README.md Sat Jan 19 03:48:15 2019 @@ -138,7 +138,7 @@ how to fix it, include that as well. Pat License --- -The project is licensed under University of Illinois/NCSA Open Source License. +The project is licensed under Apache-2.0 with LLVM exceptions. See LICENSE.TXT for details. [1]: http://clang.llvm.org/docs/JSONCompilationDatabase.html ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r351731 - Fix typos throughout the license files that somehow I and my reviewers
Author: chandlerc Date: Mon Jan 21 01:52:34 2019 New Revision: 351731 URL: http://llvm.org/viewvc/llvm-project?rev=351731&view=rev Log: Fix typos throughout the license files that somehow I and my reviewers all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. Modified: cfe/trunk/LICENSE.TXT cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt Modified: cfe/trunk/LICENSE.TXT URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/LICENSE.TXT?rev=351731&r1=351730&r2=351731&view=diff == --- cfe/trunk/LICENSE.TXT (original) +++ cfe/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019 @@ -234,7 +234,7 @@ mechanisms: file. == -Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy): +Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy): == University of Illinois/NCSA Open Source License Modified: cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt?rev=351731&r1=351730&r2=351731&view=diff == --- cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt (original) +++ cfe/trunk/tools/clang-format-vs/ClangFormat/license.txt Mon Jan 21 01:52:34 2019 @@ -234,7 +234,7 @@ mechanisms: file. == -Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy): +Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy): == University of Illinois/NCSA Open Source License ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libclc] r351731 - Fix typos throughout the license files that somehow I and my reviewers
Author: chandlerc Date: Mon Jan 21 01:52:34 2019 New Revision: 351731 URL: http://llvm.org/viewvc/llvm-project?rev=351731&view=rev Log: Fix typos throughout the license files that somehow I and my reviewers all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. Modified: libclc/trunk/LICENSE.TXT Modified: libclc/trunk/LICENSE.TXT URL: http://llvm.org/viewvc/llvm-project/libclc/trunk/LICENSE.TXT?rev=351731&r1=351730&r2=351731&view=diff == --- libclc/trunk/LICENSE.TXT (original) +++ libclc/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019 @@ -234,7 +234,7 @@ mechanisms: file. == -Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy): +Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy): == The libclc library is dual licensed under both the University of Illinois ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[libunwind] r351731 - Fix typos throughout the license files that somehow I and my reviewers
Author: chandlerc Date: Mon Jan 21 01:52:34 2019 New Revision: 351731 URL: http://llvm.org/viewvc/llvm-project?rev=351731&view=rev Log: Fix typos throughout the license files that somehow I and my reviewers all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. Modified: libunwind/trunk/LICENSE.TXT Modified: libunwind/trunk/LICENSE.TXT URL: http://llvm.org/viewvc/llvm-project/libunwind/trunk/LICENSE.TXT?rev=351731&r1=351730&r2=351731&view=diff == --- libunwind/trunk/LICENSE.TXT (original) +++ libunwind/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019 @@ -234,7 +234,7 @@ mechanisms: file. == -Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy): +Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy): == The libunwind library is dual licensed under both the University of Illinois ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] r351731 - Fix typos throughout the license files that somehow I and my reviewers
Author: chandlerc Date: Mon Jan 21 01:52:34 2019 New Revision: 351731 URL: http://llvm.org/viewvc/llvm-project?rev=351731&view=rev Log: Fix typos throughout the license files that somehow I and my reviewers all missed! Thanks to Alex Bradbury for pointing this out, and the fact that I never added the intended `legacy` anchor to the developer policy. Add that anchor too. With hope, this will cause the links to all resolve successfully. Modified: clang-tools-extra/trunk/LICENSE.TXT clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt Modified: clang-tools-extra/trunk/LICENSE.TXT URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/LICENSE.TXT?rev=351731&r1=351730&r2=351731&view=diff == --- clang-tools-extra/trunk/LICENSE.TXT (original) +++ clang-tools-extra/trunk/LICENSE.TXT Mon Jan 21 01:52:34 2019 @@ -234,7 +234,7 @@ mechanisms: file. == -Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy): +Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy): == University of Illinois/NCSA Open Source License Modified: clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt?rev=351731&r1=351730&r2=351731&view=diff == --- clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt (original) +++ clang-tools-extra/trunk/clang-tidy-vs/ClangTidy/license.txt Mon Jan 21 01:52:34 2019 @@ -234,7 +234,7 @@ mechanisms: file. == -Legacy LLVM License (ttps://llvm.org/docs/DeveloperPolicy.html#legacy): +Legacy LLVM License (https://llvm.org/docs/DeveloperPolicy.html#legacy): == University of Illinois/NCSA Open Source License ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r351629 - Emit !callback metadata and introduce the callback attribute
On Sat, Jan 19, 2019 at 2:18 AM Johannes Doerfert via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: jdoerfert
> Date: Fri Jan 18 21:36:54 2019
> New Revision: 351629
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351629&view=rev
> Log:
> Emit !callback metadata and introduce the callback attribute
>
> With commit r351627, LLVM gained the ability to apply (existing) IPO
> optimizations on indirections through callbacks, or transitive calls.
> The general idea is that we use an abstraction to hide the middle man
> and represent the callback call in the context of the initial caller.
> It is described in more detail in the commit message of the LLVM patch
> r351627, the llvm::AbstractCallSite class description, and the
> language reference section on callback-metadata.
>
> This commit enables clang to emit !callback metadata that is
> understood by LLVM. It does so in three different cases:
> 1) For known broker functions declarations that are directly
>generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
> 2) For known broker functions that are identified by their name and
>source location through the builtin detection, e.g.,
>pthread_create from the POSIX thread API.
> 3) For user annotated functions that carry the "callback(callee, ...)"
>attribute. The attribute has to include the name, or index, of
>the callback callee and how the passed arguments can be
>identified (as many as the callback callee has). See the callback
>attribute documentation for detailed information.
>
> Differential Revision: https://reviews.llvm.org/D55483
>
> Added:
> cfe/trunk/test/CodeGen/attr-callback.c
> cfe/trunk/test/CodeGen/callback_annotated.c
> cfe/trunk/test/CodeGen/callback_openmp.c
> cfe/trunk/test/CodeGen/callback_pthread_create.c
> cfe/trunk/test/CodeGenCXX/attr-callback.cpp
> cfe/trunk/test/Sema/attr-callback-broken.c
> cfe/trunk/test/Sema/attr-callback.c
> cfe/trunk/test/SemaCXX/attr-callback-broken.cpp
> cfe/trunk/test/SemaCXX/attr-callback.cpp
> Modified:
> cfe/trunk/include/clang/AST/ASTContext.h
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/include/clang/Basic/Builtins.def
> cfe/trunk/include/clang/Basic/Builtins.h
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/AST/ASTContext.cpp
> cfe/trunk/lib/Basic/Builtins.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/Analysis/retain-release.m
> cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
> cfe/trunk/test/OpenMP/parallel_codegen.cpp
> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
>
> Modified: cfe/trunk/include/clang/AST/ASTContext.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=351629&r1=351628&r2=351629&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTContext.h (original)
> +++ cfe/trunk/include/clang/AST/ASTContext.h Fri Jan 18 21:36:54 2019
> @@ -2003,6 +2003,9 @@ public:
> /// No error
> GE_None,
>
> +/// Missing a type
> +GE_Missing_type,
> +
> /// Missing a type from
> GE_Missing_stdio,
>
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=351629&r1=351628&r2=351629&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Fri Jan 18 21:36:54 2019
> @@ -190,6 +190,9 @@ class VariadicIdentifierArgument // Like VariadicUnsignedArgument except values are ParamIdx.
> class VariadicParamIdxArgument : Argument;
>
> +// A list of identifiers matching parameters or ParamIdx indices.
> +class VariadicParamOrParamIdxArgument : Argument;
> +
> // Like VariadicParamIdxArgument but for a single function parameter
> index.
> class ParamIdxArgument : Argument;
>
> @@ -1210,6 +1213,13 @@ def FormatArg : InheritableAttr {
>let Documentation = [Undocumented];
> }
>
> +def Callback : InheritableAttr {
> + let Spellings = [Clang<"callback">];
> + let Args = [VariadicParamOrParamIdxArgument<"Encoding">];
> + let Subjects = SubjectList<[Function]>;
> + let Documentation = [CallbackDocs];
> +}
> +
> def GNUInline : InheritableAttr {
>let Spellings = [GCC<"gnu_inline">];
>let Subjects = SubjectList<[Function]>;
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=351629&r1=351628&r2=351629&view=diff
>
> ==
Re: r351629 - Emit !callback metadata and introduce the callback attribute
On Sat, Jan 19, 2019 at 2:18 AM Johannes Doerfert via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: jdoerfert
> Date: Fri Jan 18 21:36:54 2019
> New Revision: 351629
>
> URL: http://llvm.org/viewvc/llvm-project?rev=351629&view=rev
> Log:
> Emit !callback metadata and introduce the callback attribute
>
> With commit r351627, LLVM gained the ability to apply (existing) IPO
> optimizations on indirections through callbacks, or transitive calls.
> The general idea is that we use an abstraction to hide the middle man
> and represent the callback call in the context of the initial caller.
> It is described in more detail in the commit message of the LLVM patch
> r351627, the llvm::AbstractCallSite class description, and the
> language reference section on callback-metadata.
>
> This commit enables clang to emit !callback metadata that is
> understood by LLVM. It does so in three different cases:
> 1) For known broker functions declarations that are directly
>generated, e.g., __kmpc_fork_call for the OpenMP pragma parallel.
> 2) For known broker functions that are identified by their name and
>source location through the builtin detection, e.g.,
>pthread_create from the POSIX thread API.
> 3) For user annotated functions that carry the "callback(callee, ...)"
>attribute. The attribute has to include the name, or index, of
>the callback callee and how the passed arguments can be
>identified (as many as the callback callee has). See the callback
>attribute documentation for detailed information.
>
> Differential Revision: https://reviews.llvm.org/D55483
>
> Added:
> cfe/trunk/test/CodeGen/attr-callback.c
> cfe/trunk/test/CodeGen/callback_annotated.c
> cfe/trunk/test/CodeGen/callback_openmp.c
> cfe/trunk/test/CodeGen/callback_pthread_create.c
> cfe/trunk/test/CodeGenCXX/attr-callback.cpp
> cfe/trunk/test/Sema/attr-callback-broken.c
> cfe/trunk/test/Sema/attr-callback.c
> cfe/trunk/test/SemaCXX/attr-callback-broken.cpp
> cfe/trunk/test/SemaCXX/attr-callback.cpp
> Modified:
> cfe/trunk/include/clang/AST/ASTContext.h
> cfe/trunk/include/clang/Basic/Attr.td
> cfe/trunk/include/clang/Basic/AttrDocs.td
> cfe/trunk/include/clang/Basic/Builtins.def
> cfe/trunk/include/clang/Basic/Builtins.h
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/lib/AST/ASTContext.cpp
> cfe/trunk/lib/Basic/Builtins.cpp
> cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp
> cfe/trunk/lib/CodeGen/CodeGenModule.cpp
> cfe/trunk/lib/Parse/ParseDecl.cpp
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaDeclAttr.cpp
> cfe/trunk/test/Analysis/retain-release.m
> cfe/trunk/test/Misc/pragma-attribute-supported-attributes-list.test
> cfe/trunk/test/OpenMP/parallel_codegen.cpp
> cfe/trunk/utils/TableGen/ClangAttrEmitter.cpp
>
> Modified: cfe/trunk/include/clang/AST/ASTContext.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=351629&r1=351628&r2=351629&view=diff
>
> ==
> --- cfe/trunk/include/clang/AST/ASTContext.h (original)
> +++ cfe/trunk/include/clang/AST/ASTContext.h Fri Jan 18 21:36:54 2019
> @@ -2003,6 +2003,9 @@ public:
> /// No error
> GE_None,
>
> +/// Missing a type
> +GE_Missing_type,
> +
> /// Missing a type from
> GE_Missing_stdio,
>
>
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=351629&r1=351628&r2=351629&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Fri Jan 18 21:36:54 2019
> @@ -190,6 +190,9 @@ class VariadicIdentifierArgument // Like VariadicUnsignedArgument except values are ParamIdx.
> class VariadicParamIdxArgument : Argument;
>
> +// A list of identifiers matching parameters or ParamIdx indices.
> +class VariadicParamOrParamIdxArgument : Argument;
> +
> // Like VariadicParamIdxArgument but for a single function parameter
> index.
> class ParamIdxArgument : Argument;
>
> @@ -1210,6 +1213,13 @@ def FormatArg : InheritableAttr {
>let Documentation = [Undocumented];
> }
>
> +def Callback : InheritableAttr {
> + let Spellings = [Clang<"callback">];
> + let Args = [VariadicParamOrParamIdxArgument<"Encoding">];
> + let Subjects = SubjectList<[Function]>;
> + let Documentation = [CallbackDocs];
> +}
> +
> def GNUInline : InheritableAttr {
>let Spellings = [GCC<"gnu_inline">];
>let Subjects = SubjectList<[Function]>;
>
> Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=351629&r1=351628&r2=351629&view=diff
>
> ==
Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type
On Sun, Sep 3, 2017 at 10:41 PM Hal Finkel via llvm-commits < llvm-comm...@lists.llvm.org> wrote: > Nevertheless, I think that you've convinced me that this is a least-bad > solution. I'll want a flag preserving the old behavior. Something like > -fwiden-bitfield-accesses (modulo bikeshedding). > Several different approaches have been discussed in this thread, I'm not sure what you mean about "least-bad solution"... I remain completely unconvinced that we should change the default behavior. At most, I'm not strongly opposed to adding an attribute that indicates "please try to use narrow loads for this bitfield member" and is an error if applied to a misaligned or non-byte-sized bitfield member. But I remain strongly opposed to changing the default behavior. We have one or two cases that regress and are easily addressed by source changes (either to not use bitfields or to use an attribute). I don't think that is cause to change the lowering Clang has used for years and potentially regress many other use cases. ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r330184 - Add some infuriatingly necessary comments to this test case.
Author: chandlerc Date: Tue Apr 17 04:08:05 2018 New Revision: 330184 URL: http://llvm.org/viewvc/llvm-project?rev=330184&view=rev Log: Add some infuriatingly necessary comments to this test case. Without these comments, by "luck" the contents of SomeKit's SKWidget.h are precisely the same as SomeKitCore's SomeKitCore.h. This can create havoc if anything canonicalizes on the inode and your filesystem assigns a common inode to files with identical file content. Alternatively, if your build system uses symlinks into a content-addressed-storage (as Google's does), you end up with these files being symlinks to the same file. The end result is that Clang deduplicates them internally, and then believes that the SomeKit framework includes the SomeKitCore.h header, and does not include the SKWidget.h in SomeKit. This in turn results in warnings in this test and eventually errors as Clang becomes confused because the umbrella header for SomeKitCore has already been included into another framework's module (SomeKit). Yay. If anyone has a better idea about how to avoid this, I'm all ears. Nothing other than causing the file content to change worked for me. Modified: cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h Modified: cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h?rev=330184&r1=330183&r2=330184&view=diff == --- cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h (original) +++ cfe/trunk/test/Modules/Inputs/exportas-link/OtherKit.framework/Headers/OtherKit.h Tue Apr 17 04:08:05 2018 @@ -1,3 +1,4 @@ +// Umbrella header for OtherKit. #import #ifdef F Modified: cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h?rev=330184&r1=330183&r2=330184&view=diff == --- cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h (original) +++ cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SKWidget.h Tue Apr 17 04:08:05 2018 @@ -1 +1,2 @@ +// Delegate to SomeKitCore. #import Modified: cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h?rev=330184&r1=330183&r2=330184&view=diff == --- cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h (original) +++ cfe/trunk/test/Modules/Inputs/exportas-link/SomeKit.framework/Headers/SomeKit.h Tue Apr 17 04:08:05 2018 @@ -1 +1,6 @@ +// Umbrella header for SomeKit. +// +// Note that this file's content must not end up to coincidentally be identical +// to any other file in the test which can easily happen given the reduced +// test. #import Modified: cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h?rev=330184&r1=330183&r2=330184&view=diff == --- cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h (original) +++ cfe/trunk/test/Modules/Inputs/exportas-link/SomeKitCore.framework/Headers/SomeKitCore.h Tue Apr 17 04:08:05 2018 @@ -1 +1,6 @@ +// Umbrella header for SomeKitCore. +// +// Note that this file's content must not end up to coincidentally be identical +// to any other file in the test which can easily happen given the reduced +// test. #import ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r330492 - [clang-tidy] add new check to find out objc ivars which do not have prefix '_'
This has broken most of the build bots. Are you working on a fix or revert?
Might be useful to get on the IRC channel to help coordinate this kind of
thing.
On Fri, Apr 20, 2018 at 4:45 PM Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: wizard
> Date: Fri Apr 20 16:18:09 2018
> New Revision: 330492
>
> URL: http://llvm.org/viewvc/llvm-project?rev=330492&view=rev
> Log:
> [clang-tidy] add new check to find out objc ivars which do not have prefix
> '_'
>
> Summary:
> For code of ivar declaration:
>
>int barWithoutPrefix;
>
> The fix will be:
>
>int _barWithoutPrefix;
>
> Reviewers: benhamilton, hokein, alexfh, aaron.ballman, ilya-biryukov
>
> Reviewed By: alexfh
>
> Subscribers: Eugene.Zelenko, xazax.hun, klimek, mgorny, cfe-commits
>
> Tags: #clang-tools-extra
>
> Differential Revision: https://reviews.llvm.org/D45392
>
> Added:
>
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> Modified:
>
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330492&r1=330491&r2=330492&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> Fri Apr 20 16:18:09 2018
> @@ -109,6 +109,7 @@ namespace readability {
> m(TemplateParameter) \
> m(TypeAlias) \
> m(MacroDefinition) \
> +m(ObjcIvar) \
>
> enum StyleKind {
> #define ENUMERATE(v) SK_ ## v,
> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
> const NamedDecl *D,
> const std::vector>
> &NamingStyles) {
> + if (isa(D) && NamingStyles[SK_ObjcIvar])
> +return SK_ObjcIvar;
> +
>if (isa(D) && NamingStyles[SK_Typedef])
> return SK_Typedef;
>
>
> Added:
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330492&view=auto
>
> ==
> ---
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> (added)
> +++
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> Fri Apr 20 16:18:09 2018
> @@ -0,0 +1,15 @@
> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
> +// RUN: -config='{CheckOptions: \
> +// RUN: [{key: readability-identifier-naming.ObjcIvarPrefix, value:
> '_'}]}' \
> +// RUN: --
> +
> +@interface Foo
> +@end
> +
> +@interface Foo () {
> +int _bar;
> +int barWithoutPrefix;
> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
> +// CHECK-FIXES: int _barWithoutPrefix;
> +}
> +@end
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r330492 - [clang-tidy] add new check to find out objc ivars which do not have prefix '_'
I see Alex already got it, but in the future, that kind of trivial test fix
for a failing test is fine to just land, and it is more important to get
the bots healthy. =]
On Fri, Apr 20, 2018, 22:14 Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> https://reviews.llvm.org/D45912 need someone to accept
>
> Best regards
> Yan Zhang
>
> On Apr 20, 2018, at 19:08, Chandler Carruth wrote:
>
> This has broken most of the build bots. Are you working on a fix or revert?
>
> Might be useful to get on the IRC channel to help coordinate this kind of
> thing.
>
> On Fri, Apr 20, 2018 at 4:45 PM Yan Zhang via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: wizard
>> Date: Fri Apr 20 16:18:09 2018
>> New Revision: 330492
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=330492&view=rev
>> Log:
>> [clang-tidy] add new check to find out objc ivars which do not have
>> prefix '_'
>>
>> Summary:
>> For code of ivar declaration:
>>
>>int barWithoutPrefix;
>>
>> The fix will be:
>>
>>int _barWithoutPrefix;
>>
>> Reviewers: benhamilton, hokein, alexfh, aaron.ballman, ilya-biryukov
>>
>> Reviewed By: alexfh
>>
>> Subscribers: Eugene.Zelenko, xazax.hun, klimek, mgorny, cfe-commits
>>
>> Tags: #clang-tools-extra
>>
>> Differential Revision: https://reviews.llvm.org/D45392
>>
>> Added:
>>
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> Modified:
>>
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330492&r1=330491&r2=330492&view=diff
>>
>> ==
>> ---
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> (original)
>> +++
>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>> Fri Apr 20 16:18:09 2018
>> @@ -109,6 +109,7 @@ namespace readability {
>> m(TemplateParameter) \
>> m(TypeAlias) \
>> m(MacroDefinition) \
>> +m(ObjcIvar) \
>>
>> enum StyleKind {
>> #define ENUMERATE(v) SK_ ## v,
>> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>> const NamedDecl *D,
>> const std::vector>
>> &NamingStyles) {
>> + if (isa(D) && NamingStyles[SK_ObjcIvar])
>> +return SK_ObjcIvar;
>> +
>>if (isa(D) && NamingStyles[SK_Typedef])
>> return SK_Typedef;
>>
>>
>> Added:
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330492&view=auto
>>
>> ==
>> ---
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> (added)
>> +++
>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>> Fri Apr 20 16:18:09 2018
>> @@ -0,0 +1,15 @@
>> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
>> +// RUN: -config='{CheckOptions: \
>> +// RUN: [{key: readability-identifier-naming.ObjcIvarPrefix, value:
>> '_'}]}' \
>> +// RUN: --
>> +
>> +@interface Foo
>> +@end
>> +
>> +@interface Foo () {
>> +int _bar;
>> +int barWithoutPrefix;
>> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
>> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
>> +// CHECK-FIXES: int _barWithoutPrefix;
>> +}
>> +@end
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] r330528 - Revert r330492: [clang-tidy] add new check to find out objc ivars which do not have prefix '_'
Author: chandlerc
Date: Sat Apr 21 16:27:34 2018
New Revision: 330528
URL: http://llvm.org/viewvc/llvm-project?rev=330528&view=rev
Log:
Revert r330492: [clang-tidy] add new check to find out objc ivars which do not
have prefix '_'
This commit has been breaking most bots for a day now. There is a fix
proposed in https://reviews.llvm.org/D45912 but when I applied that
I just got different errors. Reverting to get our bots back to green.
Removed:
clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
Modified:
clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
Modified:
clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330528&r1=330527&r2=330528&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
(original)
+++ clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
Sat Apr 21 16:27:34 2018
@@ -109,7 +109,6 @@ namespace readability {
m(TemplateParameter) \
m(TypeAlias) \
m(MacroDefinition) \
-m(ObjcIvar) \
enum StyleKind {
#define ENUMERATE(v) SK_ ## v,
@@ -385,9 +384,6 @@ static StyleKind findStyleKind(
const NamedDecl *D,
const std::vector>
&NamingStyles) {
- if (isa(D) && NamingStyles[SK_ObjcIvar])
-return SK_ObjcIvar;
-
if (isa(D) && NamingStyles[SK_Typedef])
return SK_Typedef;
Removed:
clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330527&view=auto
==
---
clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
(original)
+++
clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
(removed)
@@ -1,15 +0,0 @@
-// RUN: %check_clang_tidy %s readability-identifier-naming %t \
-// RUN: -config='{CheckOptions: \
-// RUN: [{key: readability-identifier-naming.ObjcIvarPrefix, value: '_'}]}' \
-// RUN: --
-
-@interface Foo
-@end
-
-@interface Foo () {
-int _bar;
-int barWithoutPrefix;
-// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for objc
ivar 'barWithoutPrefix' [readability-identifier-naming]
-// CHECK-FIXES: int _barWithoutPrefix;
-}
-@end
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r330492 - [clang-tidy] add new check to find out objc ivars which do not have prefix '_'
Ok, this still isn't fixed a day later and over half our build bots are red
because of it. =/ I tried just applying the patch, and it doesn't seem to
fully fix the test as it results in a different error...
I've reverted in r330528 for now so that our bots are green. =] Feel free
to re-land once you've confirmed the tests are passing, and keep an eye on
the bots after it goes in. =D
On Fri, Apr 20, 2018 at 11:33 PM Chandler Carruth
wrote:
> I see Alex already got it, but in the future, that kind of trivial test
> fix for a failing test is fine to just land, and it is more important to
> get the bots healthy. =]
>
> On Fri, Apr 20, 2018, 22:14 Yan Zhang via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> https://reviews.llvm.org/D45912 need someone to accept
>>
>> Best regards
>> Yan Zhang
>>
>> On Apr 20, 2018, at 19:08, Chandler Carruth wrote:
>>
>> This has broken most of the build bots. Are you working on a fix or
>> revert?
>>
>> Might be useful to get on the IRC channel to help coordinate this kind of
>> thing.
>>
>> On Fri, Apr 20, 2018 at 4:45 PM Yan Zhang via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: wizard
>>> Date: Fri Apr 20 16:18:09 2018
>>> New Revision: 330492
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=330492&view=rev
>>> Log:
>>> [clang-tidy] add new check to find out objc ivars which do not have
>>> prefix '_'
>>>
>>> Summary:
>>> For code of ivar declaration:
>>>
>>>int barWithoutPrefix;
>>>
>>> The fix will be:
>>>
>>>int _barWithoutPrefix;
>>>
>>> Reviewers: benhamilton, hokein, alexfh, aaron.ballman, ilya-biryukov
>>>
>>> Reviewed By: alexfh
>>>
>>> Subscribers: Eugene.Zelenko, xazax.hun, klimek, mgorny, cfe-commits
>>>
>>> Tags: #clang-tools-extra
>>>
>>> Differential Revision: https://reviews.llvm.org/D45392
>>>
>>> Added:
>>>
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> Modified:
>>>
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>
>>> Modified:
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330492&r1=330491&r2=330492&view=diff
>>>
>>> ==
>>> ---
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> (original)
>>> +++
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> Fri Apr 20 16:18:09 2018
>>> @@ -109,6 +109,7 @@ namespace readability {
>>> m(TemplateParameter) \
>>> m(TypeAlias) \
>>> m(MacroDefinition) \
>>> +m(ObjcIvar) \
>>>
>>> enum StyleKind {
>>> #define ENUMERATE(v) SK_ ## v,
>>> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>>> const NamedDecl *D,
>>> const
>>> std::vector>
>>> &NamingStyles) {
>>> + if (isa(D) && NamingStyles[SK_ObjcIvar])
>>> +return SK_ObjcIvar;
>>> +
>>>if (isa(D) && NamingStyles[SK_Typedef])
>>> return SK_Typedef;
>>>
>>>
>>> Added:
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330492&view=auto
>>>
>>> ==
>>> ---
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> (added)
>>> +++
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> Fri Apr 20 16:18:09 2018
>>> @@ -0,0 +1,15 @@
>>> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
>>> +// RUN: -config='{CheckOptions: \
>>> +// RUN: [{key: readability-identifier-naming.ObjcIvarPrefix, value:
>>> '_'}]}' \
>>> +// RUN: --
>>> +
>>> +@interface Foo
>>> +@end
>>> +
>>> +@interface Foo () {
>>> +int _bar;
>>> +int barWithoutPrefix;
>>> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
>>> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
>>> +// CHECK-FIXES: int _barWithoutPrefix;
>>> +}
>>> +@end
>>>
>>>
>>> ___
>>> cfe-commits mailing list
>>> cfe-commits@lists.llvm.org
>>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r330492 - [clang-tidy] add new check to find out objc ivars which do not have prefix '_'
Should be able to reproduce it by patching it in and running the tests
yourself? Nothing configuration specific here. Still, no hurry.
On Sat, Apr 21, 2018 at 6:02 PM Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Sorry I was out today. What is the new error? Can u send it to me?
>
> Best regards
> Yan Zhang
>
> On Apr 21, 2018, at 16:32, Chandler Carruth wrote:
>
> Ok, this still isn't fixed a day later and over half our build bots are
> red because of it. =/ I tried just applying the patch, and it doesn't seem
> to fully fix the test as it results in a different error...
>
> I've reverted in r330528 for now so that our bots are green. =] Feel free
> to re-land once you've confirmed the tests are passing, and keep an eye on
> the bots after it goes in. =D
>
> On Fri, Apr 20, 2018 at 11:33 PM Chandler Carruth
> wrote:
>
>> I see Alex already got it, but in the future, that kind of trivial test
>> fix for a failing test is fine to just land, and it is more important to
>> get the bots healthy. =]
>>
>> On Fri, Apr 20, 2018, 22:14 Yan Zhang via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> https://reviews.llvm.org/D45912 need someone to accept
>>>
>>> Best regards
>>> Yan Zhang
>>>
>>> On Apr 20, 2018, at 19:08, Chandler Carruth wrote:
>>>
>>> This has broken most of the build bots. Are you working on a fix or
>>> revert?
>>>
>>> Might be useful to get on the IRC channel to help coordinate this kind
>>> of thing.
>>>
>>> On Fri, Apr 20, 2018 at 4:45 PM Yan Zhang via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>> Author: wizard
>>>> Date: Fri Apr 20 16:18:09 2018
>>>> New Revision: 330492
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=330492&view=rev
>>>> Log:
>>>> [clang-tidy] add new check to find out objc ivars which do not have
>>>> prefix '_'
>>>>
>>>> Summary:
>>>> For code of ivar declaration:
>>>>
>>>>int barWithoutPrefix;
>>>>
>>>> The fix will be:
>>>>
>>>>int _barWithoutPrefix;
>>>>
>>>> Reviewers: benhamilton, hokein, alexfh, aaron.ballman, ilya-biryukov
>>>>
>>>> Reviewed By: alexfh
>>>>
>>>> Subscribers: Eugene.Zelenko, xazax.hun, klimek, mgorny, cfe-commits
>>>>
>>>> Tags: #clang-tools-extra
>>>>
>>>> Differential Revision: https://reviews.llvm.org/D45392
>>>>
>>>> Added:
>>>>
>>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>>> Modified:
>>>>
>>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>>
>>>> Modified:
>>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>> URL:
>>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330492&r1=330491&r2=330492&view=diff
>>>>
>>>> ==
>>>> ---
>>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>> (original)
>>>> +++
>>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>> Fri Apr 20 16:18:09 2018
>>>> @@ -109,6 +109,7 @@ namespace readability {
>>>> m(TemplateParameter) \
>>>> m(TypeAlias) \
>>>> m(MacroDefinition) \
>>>> +m(ObjcIvar) \
>>>>
>>>> enum StyleKind {
>>>> #define ENUMERATE(v) SK_ ## v,
>>>> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>>>> const NamedDecl *D,
>>>> const
>>>> std::vector>
>>>> &NamingStyles) {
>>>> + if (isa(D) && NamingStyles[SK_ObjcIvar])
>>>> +return SK_ObjcIvar;
>>>> +
>>>>if (isa(D) && NamingStyles[SK_Typedef])
>>>> return SK_Typedef;
>>>>
>>>>
>>>> Added:
>>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>>> URL:
>>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-namin
Re: [clang-tools-extra] r330559 - update test to use ivar in implementation instead of class extension
The commit log here no longer reflects the commit. This is not just
updating the test, this is a complete re-application of the original patch
in r330492. =[
Also, the bots are still complaining:
http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17830
http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/1979
http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11659
I'm not sure how you're running your tests that you don't see these issues,
but they seem to reproduce on many build bots and the error message doesn't
seem to be architecture specific at all...
I suspect something about how you are trying to run tests isn't actually
running this test if you aren't able to locally reproduce.
On Sun, Apr 22, 2018 at 5:19 PM Yan Zhang via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: wizard
> Date: Sun Apr 22 17:15:15 2018
> New Revision: 330559
>
> URL: http://llvm.org/viewvc/llvm-project?rev=330559&view=rev
> Log:
> update test to use ivar in implementation instead of class extension
>
> Summary: using ivar in class extension is not supported in 32-bit
> architecture of MacOS.
>
> Reviewers: alexfh, hokein
>
> Reviewed By: alexfh
>
> Subscribers: klimek, cfe-commits
>
> Differential Revision: https://reviews.llvm.org/D45912
>
> Added:
>
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> Modified:
>
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>
> Modified:
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330559&r1=330558&r2=330559&view=diff
>
> ==
> ---
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> (original)
> +++
> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
> Sun Apr 22 17:15:15 2018
> @@ -109,6 +109,7 @@ namespace readability {
> m(TemplateParameter) \
> m(TypeAlias) \
> m(MacroDefinition) \
> +m(ObjcIvar) \
>
> enum StyleKind {
> #define ENUMERATE(v) SK_ ## v,
> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
> const NamedDecl *D,
> const std::vector>
> &NamingStyles) {
> + if (isa(D) && NamingStyles[SK_ObjcIvar])
> +return SK_ObjcIvar;
> +
>if (isa(D) && NamingStyles[SK_Typedef])
> return SK_Typedef;
>
>
> Added:
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> URL:
> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330559&view=auto
>
> ==
> ---
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> (added)
> +++
> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
> Sun Apr 22 17:15:15 2018
> @@ -0,0 +1,15 @@
> +// RUN: %check_clang_tidy %s readability-identifier-naming %t \
> +// RUN: -config='{CheckOptions: \
> +// RUN: [{key: readability-identifier-naming.ObjcIvarPrefix, value:
> '_'}]}' \
> +// RUN: --
> +
> +@interface Foo
> +@end
> +
> +@implementation Foo {
> +int _bar;
> +int barWithoutPrefix;
> +// CHECK-MESSAGES: :[[@LINE-1]]:9: warning: invalid case style for
> objc ivar 'barWithoutPrefix' [readability-identifier-naming]
> +// CHECK-FIXES: int _barWithoutPrefix;
> +}
> +@end
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r330559 - update test to use ivar in implementation instead of class extension
I don't know anything about objective-c, or anything about OSX.
However, I guarantee these bots aren't using 32-bit OSX. ;] Look at the bot
names. They're running Linux in various flavors: ppc64be, ppc64le, armv8,
etc.
My suspicion is that this is a linux-specific issue.
But you can reproduce this yourself. Just run clang (or clang-tidy) over
this test file with --target= for various linux triples. It doesn't
include any headers or anything else, so you should be able to see all
these failures.
Anyways, please land that revision or revert until you have a reviewer for
it (many maybe not around this weekend). But please don't leave the bots
broken.
On Sun, Apr 22, 2018 at 5:55 PM Yan Zhang wrote:
> I am running tests locally with "ninja check-clang-tools" and I am sure
> it is running this test because I could get error message when I debug it.
>
> The problem (according to the error message) is all caused by different
> architecture. It seems a lot of ObjC features are not supported in old
> 32-bit OSX (which I believe the test bots are using). I have another
> revision sent out to see if it can help. Can you take a quick look?
> https://reviews.llvm.org/D45936
>
> On Sun, Apr 22, 2018 at 5:51 PM Chandler Carruth
> wrote:
>
>> The commit log here no longer reflects the commit. This is not just
>> updating the test, this is a complete re-application of the original patch
>> in r330492. =[
>>
>> Also, the bots are still complaining:
>> http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17830
>> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/1979
>> http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11659
>>
>> I'm not sure how you're running your tests that you don't see these
>> issues, but they seem to reproduce on many build bots and the error message
>> doesn't seem to be architecture specific at all...
>>
>> I suspect something about how you are trying to run tests isn't actually
>> running this test if you aren't able to locally reproduce.
>>
>> On Sun, Apr 22, 2018 at 5:19 PM Yan Zhang via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: wizard
>>> Date: Sun Apr 22 17:15:15 2018
>>> New Revision: 330559
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=330559&view=rev
>>> Log:
>>> update test to use ivar in implementation instead of class extension
>>>
>>> Summary: using ivar in class extension is not supported in 32-bit
>>> architecture of MacOS.
>>>
>>> Reviewers: alexfh, hokein
>>>
>>> Reviewed By: alexfh
>>>
>>> Subscribers: klimek, cfe-commits
>>>
>>> Differential Revision: https://reviews.llvm.org/D45912
>>>
>>> Added:
>>>
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> Modified:
>>>
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>
>>> Modified:
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330559&r1=330558&r2=330559&view=diff
>>>
>>> ==
>>> ---
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> (original)
>>> +++
>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>> Sun Apr 22 17:15:15 2018
>>> @@ -109,6 +109,7 @@ namespace readability {
>>> m(TemplateParameter) \
>>> m(TypeAlias) \
>>> m(MacroDefinition) \
>>> +m(ObjcIvar) \
>>>
>>> enum StyleKind {
>>> #define ENUMERATE(v) SK_ ## v,
>>> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>>> const NamedDecl *D,
>>> const
>>> std::vector>
>>> &NamingStyles) {
>>> + if (isa(D) && NamingStyles[SK_ObjcIvar])
>>> +return SK_ObjcIvar;
>>> +
>>>if (isa(D) && NamingStyles[SK_Typedef])
>>> return SK_Typedef;
>>>
>>>
>>> Added:
>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m?rev=330559&view=auto
>&
Re: [clang-tools-extra] r330559 - update test to use ivar in implementation instead of class extension
See my other email -- you can compile code targeting other platforms
regardless of the platform you develop on. Not exactly as good as
reproducing it with a bot, but about the best you have.
On Sun, Apr 22, 2018 at 6:01 PM Chandler Carruth
wrote:
> I don't know anything about objective-c, or anything about OSX.
>
> However, I guarantee these bots aren't using 32-bit OSX. ;] Look at the
> bot names. They're running Linux in various flavors: ppc64be, ppc64le,
> armv8, etc.
>
> My suspicion is that this is a linux-specific issue.
>
> But you can reproduce this yourself. Just run clang (or clang-tidy) over
> this test file with --target= for various linux triples. It doesn't
> include any headers or anything else, so you should be able to see all
> these failures.
>
> Anyways, please land that revision or revert until you have a reviewer for
> it (many maybe not around this weekend). But please don't leave the bots
> broken.
>
> On Sun, Apr 22, 2018 at 5:55 PM Yan Zhang wrote:
>
>> I am running tests locally with "ninja check-clang-tools" and I am sure
>> it is running this test because I could get error message when I debug it.
>>
>> The problem (according to the error message) is all caused by different
>> architecture. It seems a lot of ObjC features are not supported in old
>> 32-bit OSX (which I believe the test bots are using). I have another
>> revision sent out to see if it can help. Can you take a quick look?
>> https://reviews.llvm.org/D45936
>>
>> On Sun, Apr 22, 2018 at 5:51 PM Chandler Carruth
>> wrote:
>>
>>> The commit log here no longer reflects the commit. This is not just
>>> updating the test, this is a complete re-application of the original patch
>>> in r330492. =[
>>>
>>> Also, the bots are still complaining:
>>> http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17830
>>> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/1979
>>> http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11659
>>>
>>> I'm not sure how you're running your tests that you don't see these
>>> issues, but they seem to reproduce on many build bots and the error message
>>> doesn't seem to be architecture specific at all...
>>>
>>> I suspect something about how you are trying to run tests isn't actually
>>> running this test if you aren't able to locally reproduce.
>>>
>>> On Sun, Apr 22, 2018 at 5:19 PM Yan Zhang via cfe-commits <
>>> cfe-commits@lists.llvm.org> wrote:
>>>
>>>> Author: wizard
>>>> Date: Sun Apr 22 17:15:15 2018
>>>> New Revision: 330559
>>>>
>>>> URL: http://llvm.org/viewvc/llvm-project?rev=330559&view=rev
>>>> Log:
>>>> update test to use ivar in implementation instead of class extension
>>>>
>>>> Summary: using ivar in class extension is not supported in 32-bit
>>>> architecture of MacOS.
>>>>
>>>> Reviewers: alexfh, hokein
>>>>
>>>> Reviewed By: alexfh
>>>>
>>>> Subscribers: klimek, cfe-commits
>>>>
>>>> Differential Revision: https://reviews.llvm.org/D45912
>>>>
>>>> Added:
>>>>
>>>> clang-tools-extra/trunk/test/clang-tidy/readability-identifier-naming-objc.m
>>>> Modified:
>>>>
>>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>>
>>>> Modified:
>>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>> URL:
>>>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp?rev=330559&r1=330558&r2=330559&view=diff
>>>>
>>>> ==
>>>> ---
>>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>> (original)
>>>> +++
>>>> clang-tools-extra/trunk/clang-tidy/readability/IdentifierNamingCheck.cpp
>>>> Sun Apr 22 17:15:15 2018
>>>> @@ -109,6 +109,7 @@ namespace readability {
>>>> m(TemplateParameter) \
>>>> m(TypeAlias) \
>>>> m(MacroDefinition) \
>>>> +m(ObjcIvar) \
>>>>
>>>> enum StyleKind {
>>>> #define ENUMERATE(v) SK_ ## v,
>>>> @@ -384,6 +385,9 @@ static StyleKind findStyleKind(
>>>> cons
Re: [clang-tools-extra] r330559 - update test to use ivar in implementation instead of class extension
I won't be back at a computer for a while and I really don't know anything about objective-c... But if you don't feel confident submitting fixes with post commit review, you should probably just revert If the fix is trivial and/or you can find ways to test it a similar suggested in my earlier email, then I'd suggest landing it and watching the build bots to ensure they are happy. But if you can't figure out how to restore the bots you'll end up needing to revert the whole series and get some help from someone with access to another platform. On Sun, Apr 22, 2018, 18:03 Yan Zhang via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Need a accept for that revision. Can you accept it? > > On Sun, Apr 22, 2018 at 6:02 PM Chandler Carruth > wrote: > >> See my other email -- you can compile code targeting other platforms >> regardless of the platform you develop on. Not exactly as good as >> reproducing it with a bot, but about the best you have. >> >> On Sun, Apr 22, 2018 at 6:01 PM Chandler Carruth >> wrote: >> >>> I don't know anything about objective-c, or anything about OSX. >>> >>> However, I guarantee these bots aren't using 32-bit OSX. ;] Look at the >>> bot names. They're running Linux in various flavors: ppc64be, ppc64le, >>> armv8, etc. >>> >>> My suspicion is that this is a linux-specific issue. >>> >>> But you can reproduce this yourself. Just run clang (or clang-tidy) over >>> this test file with --target= for various linux triples. It doesn't >>> include any headers or anything else, so you should be able to see all >>> these failures. >>> >>> Anyways, please land that revision or revert until you have a reviewer >>> for it (many maybe not around this weekend). But please don't leave the >>> bots broken. >>> >>> On Sun, Apr 22, 2018 at 5:55 PM Yan Zhang wrote: >>> >>>> I am running tests locally with "ninja check-clang-tools" and I am >>>> sure it is running this test because I could get error message when I debug >>>> it. >>>> >>>> The problem (according to the error message) is all caused by different >>>> architecture. It seems a lot of ObjC features are not supported in old >>>> 32-bit OSX (which I believe the test bots are using). I have another >>>> revision sent out to see if it can help. Can you take a quick look? >>>> https://reviews.llvm.org/D45936 >>>> >>>> On Sun, Apr 22, 2018 at 5:51 PM Chandler Carruth >>>> wrote: >>>> >>>>> The commit log here no longer reflects the commit. This is not just >>>>> updating the test, this is a complete re-application of the original patch >>>>> in r330492. =[ >>>>> >>>>> Also, the bots are still complaining: >>>>> http://lab.llvm.org:8011/builders/clang-ppc64be-linux/builds/17830 >>>>> http://lab.llvm.org:8011/builders/clang-cmake-armv8-quick/builds/1979 >>>>> http://lab.llvm.org:8011/builders/clang-ppc64le-linux-lnt/builds/11659 >>>>> >>>>> I'm not sure how you're running your tests that you don't see these >>>>> issues, but they seem to reproduce on many build bots and the error >>>>> message >>>>> doesn't seem to be architecture specific at all... >>>>> >>>>> I suspect something about how you are trying to run tests isn't >>>>> actually running this test if you aren't able to locally reproduce. >>>>> >>>>> On Sun, Apr 22, 2018 at 5:19 PM Yan Zhang via cfe-commits < >>>>> cfe-commits@lists.llvm.org> wrote: >>>>> >>>>>> Author: wizard >>>>>> Date: Sun Apr 22 17:15:15 2018 >>>>>> New Revision: 330559 >>>>>> >>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=330559&view=rev >>>>>> Log: >>>>>> update test to use ivar in implementation instead of class extension >>>>>> >>>>>> Summary: using ivar in class extension is not supported in 32-bit >>>>>> architecture of MacOS. >>>>>> >>>>>> Reviewers: alexfh, hokein >>>>>> >>>>>> Reviewed By: alexfh >>>>>> >>>>>> Subscribers: klimek, cfe-commits >>>>>> >>>>>> Differential Revision: https://revie
r330997 - [x86] Revert r330322 (& r330323): Lowering x86 adds/addus/subs/subus intrinsics
Author: chandlerc
Date: Thu Apr 26 14:46:01 2018
New Revision: 330997
URL: http://llvm.org/viewvc/llvm-project?rev=330997&view=rev
Log:
[x86] Revert r330322 (& r330323): Lowering x86 adds/addus/subs/subus intrinsics
The LLVM commit introduces a crash in LLVM's instruction selection.
I filed http://llvm.org/PR37260 with the test case.
Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp
cfe/trunk/test/CodeGen/avx2-builtins.c
cfe/trunk/test/CodeGen/avx512bw-builtins.c
cfe/trunk/test/CodeGen/avx512vlbw-builtins.c
cfe/trunk/test/CodeGen/sse2-builtins.c
Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=330997&r1=330996&r2=330997&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Thu Apr 26 14:46:01 2018
@@ -8449,76 +8449,6 @@ static Value *EmitX86SExtMask(CodeGenFun
return CGF.Builder.CreateSExt(Mask, DstTy, "vpmovm2");
}
-// Emit addition or subtraction with saturation.
-// Handles both signed and unsigned intrinsics.
-static Value *EmitX86AddSubSatExpr(CodeGenFunction &CGF, const CallExpr *E,
- SmallVectorImpl &Ops,
- bool IsAddition, bool Signed) {
-
- // Collect vector elements and type data.
- llvm::Type *ResultType = CGF.ConvertType(E->getType());
- int NumElements = ResultType->getVectorNumElements();
- Value *Res;
- if (!IsAddition && !Signed) {
-Value *ICmp = CGF.Builder.CreateICmp(ICmpInst::ICMP_UGT, Ops[0], Ops[1]);
-Value *Select = CGF.Builder.CreateSelect(ICmp, Ops[0], Ops[1]);
-Res = CGF.Builder.CreateSub(Select, Ops[1]);
- } else {
-unsigned EltSizeInBits = ResultType->getScalarSizeInBits();
-llvm::Type *ExtElementType = EltSizeInBits == 8 ?
- CGF.Builder.getInt16Ty() :
- CGF.Builder.getInt32Ty();
-
-// Extending vectors to next possible width to make space for possible
-// overflow.
-llvm::Type *ExtType = llvm::VectorType::get(ExtElementType, NumElements);
-Value *VecA = Signed ? CGF.Builder.CreateSExt(Ops[0], ExtType)
- : CGF.Builder.CreateZExt(Ops[0], ExtType);
-Value *VecB = Signed ? CGF.Builder.CreateSExt(Ops[1], ExtType)
- : CGF.Builder.CreateZExt(Ops[1], ExtType);
-
-llvm::Value *ExtProduct = IsAddition ? CGF.Builder.CreateAdd(VecA, VecB)
- : CGF.Builder.CreateSub(VecA, VecB);
-
-// Create vector of the same type as expected result with max possible
-// values and extend it to the same type as the product of the addition.
-APInt SignedMaxValue =
-llvm::APInt::getSignedMaxValue(EltSizeInBits);
-Value *Max = Signed ? llvm::ConstantInt::get(ResultType, SignedMaxValue)
-: llvm::Constant::getAllOnesValue(ResultType);
-Value *ExtMaxVec = Signed ? CGF.Builder.CreateSExt(Max, ExtType)
- : CGF.Builder.CreateZExt(Max, ExtType);
-// In Product, replace all overflowed values with max values of
non-extended
-// type.
-ICmpInst::Predicate Pred = Signed ? ICmpInst::ICMP_SLE :
ICmpInst::ICMP_ULE;
-Value *Cmp = CGF.Builder.CreateICmp(Pred, ExtProduct,
-ExtMaxVec); // 1 if no overflow.
-Value *SaturatedProduct = CGF.Builder.CreateSelect(
-Cmp, ExtProduct, ExtMaxVec); // If overflowed, copy from max values.
-
-if (Signed) {
- APInt SignedMinValue =
- llvm::APInt::getSignedMinValue(EltSizeInBits);
- Value *Min = llvm::ConstantInt::get(ResultType, SignedMinValue);
- Value *ExtMinVec = CGF.Builder.CreateSExt(Min, ExtType);
- Value *IsNegative =
-CGF.Builder.CreateICmp(ICmpInst::ICMP_SLT, SaturatedProduct,
ExtMinVec);
- SaturatedProduct =
-CGF.Builder.CreateSelect(IsNegative, ExtMinVec, SaturatedProduct);
-}
-
-Res = CGF.Builder.CreateTrunc(SaturatedProduct,
- ResultType); // Trunc to ResultType.
- }
- if (E->getNumArgs() == 4) { // For masked intrinsics.
-Value *VecSRC = Ops[2];
-Value *Mask = Ops[3];
-return EmitX86Select(CGF, Mask, Res, VecSRC);
- }
-
- return Res;
-}
-
Value *CodeGenFunction::EmitX86CpuIs(const CallExpr *E) {
const Expr *CPUExpr = E->getArg(0)->IgnoreParenCasts();
StringRef CPUStr = cast(CPUExpr)->getString();
@@ -9586,37 +9516,10 @@ Value *CodeGenFunction::EmitX86BuiltinEx
Load->setVolatile(true);
return Load;
}
- case X86::BI__builtin_ia32_paddusb512_mask:
- case X86::BI__builtin_ia32_paddusw512_mask:
- case X86::BI__builtin_ia32_paddusb256:
- case X86::BI__builtin_ia32_paddusw256:
- case X86::BI__builtin_ia32_paddusb128:
- case X86::BI__builtin_ia32_paddusw128:
-return EmitX86AddSubSatExpr(*this, E, Ops, true,
Re: r331056 - [docs] add -ffp-cast-overflow-workaround to the release notes
On Fri, Apr 27, 2018 at 4:36 PM Richard Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On 27 April 2018 at 16:07, Sanjay Patel via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> Missing dash corrected at r331057. I can improve the doc wording, but >> let's settle on the flag name first, and I'll try to get it all fixed up in >> one shot. >> >> So far we have these candidates: >> 1. -ffp-cast-overflow-workaround >> 2. -fstrict-fp-trunc-semantics >> 3. -fstrict-fp-cast-overflow >> >> I don't have a strong opinion here, but on 2nd reading, it does seem like >> a 'strict' flag fits better with existing options. >> > > The corresponding UBSan check is called -fsanitize=float-cast-overflow, so > maybe -fno-strict-float-cast-overflow would be the most consistent name? > On this topic: we were hit by this on a *lot* of code. All of that code builds and passes tests with -fsanitize=float-cast-overflow. So I think we've been mistaken in assuming that this sanitizer catches all of the failure modes of the optimization. That at least impacts the sanitizer suggestion in the release notes. And probably impacts the flag name / attribuet name. > > >> On Fri, Apr 27, 2018 at 4:41 PM, Richard Smith >> wrote: >> >>> On 27 April 2018 at 09:21, Sanjay Patel via cfe-commits < >>> cfe-commits@lists.llvm.org> wrote: >>> Author: spatel Date: Fri Apr 27 09:21:22 2018 New Revision: 331056 URL: http://llvm.org/viewvc/llvm-project?rev=331056&view=rev Log: [docs] add -ffp-cast-overflow-workaround to the release notes This option was added with: D46135 rL331041 ...copying the text from UsersManual.rst for more exposure. Modified: cfe/trunk/docs/ReleaseNotes.rst Modified: cfe/trunk/docs/ReleaseNotes.rst URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=331056&r1=331055&r2=331056&view=diff == --- cfe/trunk/docs/ReleaseNotes.rst (original) +++ cfe/trunk/docs/ReleaseNotes.rst Fri Apr 27 09:21:22 2018 @@ -83,6 +83,15 @@ Non-comprehensive list of changes in thi New Compiler Flags -- +- :option:`-ffp-cast-overflow-workaround` and + :option:`-fnofp-cast-overflow-workaround` >>> >>> Shouldn't this be -fno-fp-cast-overflow-workaround? >>> >>> Also, our convention for flags that define undefined behavior is >>> `-fno-strict-*`, so perhaps this should be `-fno-strict-fp-cast-overflow`? >>> >>> + enable (disable) a workaround for code that casts floating-point values to + integers and back to floating-point. If the floating-point value is not + representable in the intermediate integer type, the code is incorrect + according to the language standard. >>> >>> >>> I find this hard to read: I initially misread "the code is incorrect >>> according to the language standard" as meaning "Clang will generate code >>> that is incorrect according to the language standard". I think what you >>> mean here is "the code has undefined behavior according to the language >>> standard, and Clang will not guarantee any particular result. This flag >>> causes the behavior to be defined to match the overflowing behavior of the >>> target's native float-to-int conversion instructions." >>> >>> This flag will attempt to generate code + as if the result of an overflowing conversion matches the overflowing behavior + of a target's native float-to-int conversion instructions. + - ... Deprecated Compiler Flags ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >>> >>> >> >> ___ >> cfe-commits mailing list >> cfe-commits@lists.llvm.org >> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits >> >> ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r331056 - [docs] add -ffp-cast-overflow-workaround to the release notes
On Fri, Apr 27, 2018 at 5:13 PM Richard Smith wrote: > On 27 April 2018 at 17:09, Chandler Carruth via cfe-commits < > cfe-commits@lists.llvm.org> wrote: > >> On Fri, Apr 27, 2018 at 4:36 PM Richard Smith via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> On 27 April 2018 at 16:07, Sanjay Patel via cfe-commits < >>> cfe-commits@lists.llvm.org> wrote: >>> >>>> Missing dash corrected at r331057. I can improve the doc wording, but >>>> let's settle on the flag name first, and I'll try to get it all fixed up in >>>> one shot. >>>> >>>> So far we have these candidates: >>>> 1. -ffp-cast-overflow-workaround >>>> 2. -fstrict-fp-trunc-semantics >>>> 3. -fstrict-fp-cast-overflow >>>> >>>> I don't have a strong opinion here, but on 2nd reading, it does seem >>>> like a 'strict' flag fits better with existing options. >>>> >>> >>> The corresponding UBSan check is called -fsanitize=float-cast-overflow, >>> so maybe -fno-strict-float-cast-overflow would be the most consistent name? >>> >> >> On this topic: we were hit by this on a *lot* of code. All of that code >> builds and passes tests with -fsanitize=float-cast-overflow. So I think >> we've been mistaken in assuming that this sanitizer catches all of the >> failure modes of the optimization. That at least impacts the sanitizer >> suggestion in the release notes. And probably impacts the flag name / >> attribuet name. >> > > That's interesting, and definitely sounds like a bug (either the sanitizer > or LLVM is presumably getting the range check wrong). Can you point me at > an example? > It appears that the code that hit this has cleverly dodged *EVERY* build configuration we have deployed this sanitizer in... despite our best efforts. Sorry for the noise. > > >> On Fri, Apr 27, 2018 at 4:41 PM, Richard Smith >>>> wrote: >>>> >>>>> On 27 April 2018 at 09:21, Sanjay Patel via cfe-commits < >>>>> cfe-commits@lists.llvm.org> wrote: >>>>> >>>>>> Author: spatel >>>>>> Date: Fri Apr 27 09:21:22 2018 >>>>>> New Revision: 331056 >>>>>> >>>>>> URL: http://llvm.org/viewvc/llvm-project?rev=331056&view=rev >>>>>> Log: >>>>>> [docs] add -ffp-cast-overflow-workaround to the release notes >>>>>> >>>>>> This option was added with: >>>>>> D46135 >>>>>> rL331041 >>>>>> ...copying the text from UsersManual.rst for more exposure. >>>>>> >>>>>> >>>>>> Modified: >>>>>> cfe/trunk/docs/ReleaseNotes.rst >>>>>> >>>>>> Modified: cfe/trunk/docs/ReleaseNotes.rst >>>>>> URL: >>>>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/ReleaseNotes.rst?rev=331056&r1=331055&r2=331056&view=diff >>>>>> >>>>>> == >>>>>> --- cfe/trunk/docs/ReleaseNotes.rst (original) >>>>>> +++ cfe/trunk/docs/ReleaseNotes.rst Fri Apr 27 09:21:22 2018 >>>>>> @@ -83,6 +83,15 @@ Non-comprehensive list of changes in thi >>>>>> New Compiler Flags >>>>>> -- >>>>>> >>>>>> +- :option:`-ffp-cast-overflow-workaround` and >>>>>> + :option:`-fnofp-cast-overflow-workaround` >>>>>> >>>>> >>>>> Shouldn't this be -fno-fp-cast-overflow-workaround? >>>>> >>>>> Also, our convention for flags that define undefined behavior is >>>>> `-fno-strict-*`, so perhaps this should be `-fno-strict-fp-cast-overflow`? >>>>> >>>>> >>>>>> + enable (disable) a workaround for code that casts floating-point >>>>>> values to >>>>>> + integers and back to floating-point. If the floating-point value >>>>>> is not >>>>>> + representable in the intermediate integer type, the code is >>>>>> incorrect >>>>>> + according to the language standard. >>>>> >>>>> >>>>> I find this hard to read: I initially misread "the code is incorrect >>>>> according
Re: r331244 - Implement P0482R2, support for char8_t type.
I adjusted the test case in r331245 - it was failing for me and most of the build bots. Please check that I didn't miss anything. On Mon, Apr 30, 2018 at 10:06 PM Richard Smith via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: rsmith > Date: Mon Apr 30 22:02:45 2018 > New Revision: 331244 > > URL: http://llvm.org/viewvc/llvm-project?rev=331244&view=rev > Log: > Implement P0482R2, support for char8_t type. > > This is not yet part of any C++ working draft, and so is controlled by the > flag > -fchar8_t rather than a -std= flag. (The GCC implementation is controlled > by a > flag with the same name.) > > This implementation is experimental, and will be removed or revised > substantially to match the proposal as it makes its way through the C++ > committee. > > Added: > cfe/trunk/test/CodeGenCXX/char8_t.cpp > cfe/trunk/test/Lexer/char8_t.cpp > cfe/trunk/test/SemaCXX/char8_t.cpp > Modified: > cfe/trunk/include/clang/AST/ASTContext.h > cfe/trunk/include/clang/AST/BuiltinTypes.def > cfe/trunk/include/clang/AST/Type.h > cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td > cfe/trunk/include/clang/Basic/LangOptions.def > cfe/trunk/include/clang/Basic/Specifiers.h > cfe/trunk/include/clang/Basic/TokenKinds.def > cfe/trunk/include/clang/Driver/Options.td > cfe/trunk/include/clang/Sema/DeclSpec.h > cfe/trunk/include/clang/Sema/Initialization.h > cfe/trunk/include/clang/Serialization/ASTBitCodes.h > cfe/trunk/lib/AST/ASTContext.cpp > cfe/trunk/lib/AST/ExprConstant.cpp > cfe/trunk/lib/AST/ItaniumMangle.cpp > cfe/trunk/lib/AST/MicrosoftMangle.cpp > cfe/trunk/lib/AST/NSAPI.cpp > cfe/trunk/lib/AST/Type.cpp > cfe/trunk/lib/AST/TypeLoc.cpp > cfe/trunk/lib/Analysis/PrintfFormatString.cpp > cfe/trunk/lib/Basic/IdentifierTable.cpp > cfe/trunk/lib/CodeGen/CGDebugInfo.cpp > cfe/trunk/lib/CodeGen/CodeGenTypes.cpp > cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp > cfe/trunk/lib/Driver/ToolChains/Clang.cpp > cfe/trunk/lib/Format/FormatToken.cpp > cfe/trunk/lib/Frontend/CompilerInvocation.cpp > cfe/trunk/lib/Frontend/InitPreprocessor.cpp > cfe/trunk/lib/Index/USRGeneration.cpp > cfe/trunk/lib/Lex/PPExpressions.cpp > cfe/trunk/lib/Parse/ParseDecl.cpp > cfe/trunk/lib/Parse/ParseExpr.cpp > cfe/trunk/lib/Parse/ParseExprCXX.cpp > cfe/trunk/lib/Parse/ParseTentative.cpp > cfe/trunk/lib/Sema/DeclSpec.cpp > cfe/trunk/lib/Sema/SemaDecl.cpp > cfe/trunk/lib/Sema/SemaDeclCXX.cpp > cfe/trunk/lib/Sema/SemaExpr.cpp > cfe/trunk/lib/Sema/SemaInit.cpp > cfe/trunk/lib/Sema/SemaOverload.cpp > cfe/trunk/lib/Sema/SemaTemplate.cpp > cfe/trunk/lib/Sema/SemaTemplateVariadic.cpp > cfe/trunk/lib/Sema/SemaType.cpp > cfe/trunk/lib/Serialization/ASTCommon.cpp > cfe/trunk/lib/Serialization/ASTReader.cpp > cfe/trunk/test/Lexer/cxx-features.cpp > > Modified: cfe/trunk/include/clang/AST/ASTContext.h > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=331244&r1=331243&r2=331244&view=diff > > == > --- cfe/trunk/include/clang/AST/ASTContext.h (original) > +++ cfe/trunk/include/clang/AST/ASTContext.h Mon Apr 30 22:02:45 2018 > @@ -999,6 +999,7 @@ public: >CanQualType WCharTy; // [C++ 3.9.1p5]. >CanQualType WideCharTy; // Same as WCharTy in C++, integer type in C99. >CanQualType WIntTy; // [C99 7.24.1], integer type unchanged by > default promotions. > + CanQualType Char8Ty; // [C++20 proposal] >CanQualType Char16Ty; // [C++0x 3.9.1p5], integer type in C99. >CanQualType Char32Ty; // [C++0x 3.9.1p5], integer type in C99. >CanQualType SignedCharTy, ShortTy, IntTy, LongTy, LongLongTy, Int128Ty; > > Modified: cfe/trunk/include/clang/AST/BuiltinTypes.def > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/BuiltinTypes.def?rev=331244&r1=331243&r2=331244&view=diff > > == > --- cfe/trunk/include/clang/AST/BuiltinTypes.def (original) > +++ cfe/trunk/include/clang/AST/BuiltinTypes.def Mon Apr 30 22:02:45 2018 > @@ -72,6 +72,9 @@ UNSIGNED_TYPE(UChar, UnsignedCharTy) > // 'wchar_t' for targets where it's unsigned > SHARED_SINGLETON_TYPE(UNSIGNED_TYPE(WChar_U, WCharTy)) > > +// 'char8_t' in C++20 (proposed) > +UNSIGNED_TYPE(Char8, Char8Ty) > + > // 'char16_t' in C++ > UNSIGNED_TYPE(Char16, Char16Ty) > > > Modified: cfe/trunk/include/clang/AST/Type.h > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=331244&r1=331243&r2=331244&view=diff > > == > --- cfe/trunk/include/clang/AST/Type.h (original) > +++ cfe/trunk/include/clang/AST/Type.h Mon Apr 30 22:02:45 2018 > @@ -1777,6 +1777,7 @@ public: >bool isBooleanType() const; >bool isCharTyp
r331245 - Fix up r331244 - the emitted definition is weak_odr linkage. Should get
Author: chandlerc
Date: Mon Apr 30 23:48:30 2018
New Revision: 331245
URL: http://llvm.org/viewvc/llvm-project?rev=331245&view=rev
Log:
Fix up r331244 - the emitted definition is weak_odr linkage. Should get
the build bots to healthy again without a full revert. As the
functionality added has nothing to do with linkage this seems unlikely
to represent a deep or interesting bug in the patch.
Modified:
cfe/trunk/test/CodeGenCXX/char8_t.cpp
Modified: cfe/trunk/test/CodeGenCXX/char8_t.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/char8_t.cpp?rev=331245&r1=331244&r2=331245&view=diff
==
--- cfe/trunk/test/CodeGenCXX/char8_t.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/char8_t.cpp Mon Apr 30 23:48:30 2018
@@ -3,6 +3,6 @@
// CHECK: define void @_Z1fDu(
void f(char8_t c) {}
-// CHECK: define void @_Z1gIiEvDTplplcvT__ELA4_KDuELDu114EE
+// CHECK: define weak_odr void @_Z1gIiEvDTplplcvT__ELA4_KDuELDu114EE
template void g(decltype(T() + u8"foo" + u8'r')) {}
template void g(const char8_t*);
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r331411 - [gcov] Make the CLang side coverage test work with the new
Author: chandlerc
Date: Wed May 2 15:57:20 2018
New Revision: 331411
URL: http://llvm.org/viewvc/llvm-project?rev=331411&view=rev
Log:
[gcov] Make the CLang side coverage test work with the new
instrumentation codegeneration strategy of using a data structure and
a loop. Required some finesse to get the critical things being tested to
surface in a nice way for FileCheck but I think this preserves the
original intent of the test.
Modified:
cfe/trunk/test/CodeGen/code-coverage.c
Modified: cfe/trunk/test/CodeGen/code-coverage.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/code-coverage.c?rev=331411&r1=331410&r2=331411&view=diff
==
--- cfe/trunk/test/CodeGen/code-coverage.c (original)
+++ cfe/trunk/test/CodeGen/code-coverage.c Wed May 2 15:57:20 2018
@@ -23,17 +23,25 @@ int test1(int a) {
return a;
}
+int test2(int b) {
+ return b * 2;
+}
+
+// Inside function emission data structure, check that
+// -coverage-no-function-names-in-data uses null as the function name.
+// CHECK: @__llvm_internal_gcov_emit_function_args.0 = internal unnamed_addr
constant
+// CHECK-SAME: { i32 {{[0-9]+}}, i8* getelementptr inbounds ({{[^,]*}},
{{[^,]*}}* @
+// CHECK-SAME: { i32 {{[0-9]+}}, i8* getelementptr inbounds ({{[^,]*}},
{{[^,]*}}* @
+// WITHOUTNAMES: @__llvm_internal_gcov_emit_function_args.0 = internal
unnamed_addr constant
+// WITHOUTNAMES-NOT: getelementptr inbounds ({{.*}}@
+// WITHOUTNAMES-SAME: zeroinitializer,
+// WITHOUTNAMES-NOT: getelementptr inbounds ({{.*}}@
+// WITHOUTNAMES-SAME: { i32 {{[0-9]+}}, i8* null,
+
// Check that the noredzone flag is set on the generated functions.
// CHECK: void @__llvm_gcov_indirect_counter_increment(i32* %{{.*}}, i64**
%{{.*}}) unnamed_addr [[NRZ:#[0-9]+]]
-
-// Inside llvm_gcov_writeout, check that -coverage-no-function-names-in-data
-// passes null as the function name.
// CHECK: void @__llvm_gcov_writeout() unnamed_addr [[NRZ]]
-// CHECK: call void @llvm_gcda_emit_function({{.*}}, i8* getelementptr {{.*}},
{{.*}})
-// WITHOUTNAMES: void @__llvm_gcov_writeout() unnamed_addr
-// WITHOUTNAMES: call void @llvm_gcda_emit_function({{.*}}, i8* null, {{.*}})
-
// CHECK: void @__llvm_gcov_flush() unnamed_addr [[NRZ]]
// CHECK: void @__llvm_gcov_init() unnamed_addr [[NRZ]]
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang] dc1499b - Improve Clang's getting involved document and make it more inclusive in wording.
Author: Chandler Carruth Date: 2019-10-23T16:11:24-07:00 New Revision: dc1499b90dc41838e1ee8c7052bbe9535b3609bb URL: https://github.com/llvm/llvm-project/commit/dc1499b90dc41838e1ee8c7052bbe9535b3609bb DIFF: https://github.com/llvm/llvm-project/commit/dc1499b90dc41838e1ee8c7052bbe9535b3609bb.diff LOG: Improve Clang's getting involved document and make it more inclusive in wording. Summary: Working with Meike and others to improve the wording in this document. Reviewers: klimek Subscribers: mcrosier, cfe-commits Tags: #clang Differential Revision: https://reviews.llvm.org/D69351 Added: Modified: clang/www/get_involved.html Removed: diff --git a/clang/www/get_involved.html b/clang/www/get_involved.html index ed961ca0b61c..fabaec46bda3 100755 --- a/clang/www/get_involved.html +++ b/clang/www/get_involved.html @@ -50,8 +50,8 @@ Follow what's going on as well. -The best way to talk with other developers on the project is through the http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev mailing +The most common way to talk with other developers on the project is through +the http://lists.llvm.org/mailman/listinfo/cfe-dev";>cfe-dev mailing list. The clang mailing list is a very friendly place and we welcome newcomers. In addition to the cfe-dev list, a significant amount of design discussion takes place on the Follow what's going on Contributing Extensions to Clang -Clang has always been designed as a platform for experimentation, +Clang is designed to support experimentation, allowing programmers to easily extend the compiler to support great new language features and tools. At some point, the authors of these extensions may propose that the extensions become a part of Clang -itself, to benefit the whole Clang community. But not every idea--not -even every great idea--should become part of Clang. Extensions -(particularly language extensions) pose a long-term maintenance burden -on Clang, and therefore the benefits of the extension must outweigh -those costs. Hence, these are the seven criteria used to evaluate the -merits of a proposed extension: +itself, to benefit the whole Clang community. However, extensions +(particularly language extensions) have long-term maintenance costs +for Clang. The benefits of the extension need to be evaluated against +these costs. The Clang project uses the following criteria for this +evaluation: - Evidence of a significant user community: This is based on a number of factors, including an actual, existing user community, the perceived likelihood that users would adopt such a feature if it were available, and any "trickle-down" effects that come from, e.g., a library adopting the feature and providing benefits to its users. - - A specific need to reside within the Clang tree: There are some extensions that would be better expressed as a separate tool, and should remain as separate tools even if they end up being hosted as part of the LLVM umbrella project. - - A complete specification: The specification must be sufficient to understand the design of the feature as well as interpret the meaning of specific examples. The specification should be detailed enough that another compiler vendor could conceivably implement the feature. - - Representation within the appropriate governing organization: For extensions to a language governed by a standards committee (C, C++, OpenCL), the extension itself must have an active proposal and proponent within that committee and have a reasonable chance of acceptance. Clang should drive the standard, not diverge from it. This criterion does not apply to all extensions, since some extensions fall outside of the realm of the standards bodies. - - A long-term support plan: Contributing a non-trivial extension to Clang implies a commitment to supporting that extension, improving the implementation and specification as Clang evolves. The capacity of the contributor to make that commitment is as important as the commitment itself. - - A high-quality implementation: The implementation must fit well into Clang's architecture, follow LLVM's coding conventions, and meet Clang's quality standards, including high-quality diagnostics and rich AST representations. This is particularly important for language extensions, because users will learn how those extensions work through the behavior of the compiler. - - A proper test suite: Extensive testing is crucial to ensure that the language extension is not broken by ongoing maintenance in Clang. The test suite should be complete enough that another compiler vendor could conceivably validate their implementation of the feature against it. + Evidence of a significant user community: This is based on a number of + factors, including an existing user community, the perceived likeli
Re: [clang-tools-extra] r281453 - [clang-tidy] Add check 'misc-use-after-move'
(Somehow I missed this, sorry for silence...) On Wed, Sep 14, 2016 at 6:13 AM Martin Böhme wrote: > While I'm excited to see this go in anywhere, I have to say I'm a bit sad > it isn't going in as a warning and instead inside clang-tidy. This has been > a much requested warning from Clang for many years. > > Is there a concise description of why this design was chosen? Are there > specific problems that make it infeasible to be a warnings? Is there maybe > a plan to move it to a warning after some set of issues are addressed? > > > Yes, my hope is that this can be moved to a warning, and others have > expressed the same thought to me. > > There are two main issues that need to be addressed before this can be > made a warning: > >- I suspect (though I haven't measured) that the implementation isn't >currently efficient enough to be made a Clang warning. >- There are a number of scenarios in which the check warns when >arguably it should not. These are: > - User-defined types that make guarantees about the state of a > moved-from object (in the way that std::unique_ptr and std::shared_ptr > do). > Some form of annotation could be used to indicate that this is the case. > - User-defined types that provide a member function to reinitialize > the entire object (the way that clear() does on the standard container > classes). These could either again be annotated in some way, or we could > simply assume that any non-const member function reinitializes the > object. > > I think it would be good to have a general design discussion about what the semantic model should be here. I have a somewhat specific and precise idea of what C++ is going for here based on several previous (extensive) conversations about this with Richard Smith, David Blaikie, and DeLesley Hutchins. Notably, DeLesley worked on this and closely related warnings in Clang for quite some time. >- Tests for move constructors / move assignment operators. Often, > these tests check that a moved-from object is left in a certain state, > even > if the class in question does not provide such a guarantee to clients > (the > intent being to check that the move constructor / move assignment > operator > do not simply perform a copy). > > All of these scenarios are probably somewhat controversial, but I don't > think there's a broad consensus that any of them should be prohibited, so > there needs to be a way to silence the warning in these cases. > > The first two are actually pretty critical features of some types, so yea, this will end up needing to be directly supported. > > I do hope to resolve these issues and make this check into a warning, but > in the meantime, having it available as a clang-tidy check seems like a > good way to gather feedback and gain experience with it. > > Since you say this is a much-requested warning: Any pointers to previous > discussions that I should be aware of? > Searching the interwebs finds at least: http://lists.llvm.org/pipermail/cfe-dev/2014-October/039468.html I know internally our users have asked for this repeatedly, I'll send you info there. > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r283963 - [CUDA] Make touching a kernel from a __host__ __device__ function a deferred error.
On Tue, Oct 11, 2016 at 6:39 PM Justin Lebar via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: jlebar
>
> Date: Tue Oct 11 20:30:08 2016
>
> New Revision: 283963
>
>
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283963&view=rev
>
> Log:
>
> [CUDA] Make touching a kernel from a __host__ __device__ function a
> deferred error.
>
>
>
> Previously, this was an immediate, don't pass go, don't collect $200
>
> error. But this precludes us from writing code like
>
>
>
> __host__ __device__ void launch_kernel() {
>
> kernel<<<...>>>();
>
> }
>
>
>
> Such code isn't wrong, following our notions of right and wrong in CUDA,
>
> unless it's codegen'ed.
>
>
>
> Added:
>
> cfe/trunk/test/SemaCUDA/function-overload-hd.cu
This test fails for buildbots that don't configure the NVPTX backend:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/15830/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Afunction-overload-hd.cu
> Modified:
>
> cfe/trunk/lib/Sema/SemaCUDA.cpp
>
> cfe/trunk/test/SemaCUDA/function-overload.cu
>
> cfe/trunk/test/SemaCUDA/reference-to-kernel-fn.cu
>
>
>
> Modified: cfe/trunk/lib/Sema/SemaCUDA.cpp
>
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaCUDA.cpp?rev=283963&r1=283962&r2=283963&view=diff
>
>
> ==
>
> --- cfe/trunk/lib/Sema/SemaCUDA.cpp (original)
>
> +++ cfe/trunk/lib/Sema/SemaCUDA.cpp Tue Oct 11 20:30:08 2016
>
> @@ -120,8 +120,7 @@ Sema::IdentifyCUDAPreference(const Funct
>
>// (a) Can't call global from some contexts until we support CUDA's
>
>// dynamic parallelism.
>
>if (CalleeTarget == CFT_Global &&
>
> - (CallerTarget == CFT_Global || CallerTarget == CFT_Device ||
>
> - (CallerTarget == CFT_HostDevice && getLangOpts().CUDAIsDevice)))
>
> + (CallerTarget == CFT_Global || CallerTarget == CFT_Device))
>
> return CFP_Never;
>
>
>
>// (b) Calling HostDevice is OK for everyone.
>
>
>
> Added: cfe/trunk/test/SemaCUDA/function-overload-hd.cu
>
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCUDA/function-overload-hd.cu?rev=283963&view=auto
>
>
> ==
>
> --- cfe/trunk/test/SemaCUDA/function-overload-hd.cu (added)
>
> +++ cfe/trunk/test/SemaCUDA/function-overload-hd.cu Tue Oct 11 20:30:08
> 2016
>
> @@ -0,0 +1,28 @@
>
> +// RUN: %clang_cc1 -triple x86_64-unknown-linux-gnu -S -o /dev/null
> -verify \
>
> +// RUN: -verify-ignore-unexpected=note %s
>
> +// RUN: %clang_cc1 -triple nvptx64-nvidia-cuda -S -o /dev/null
> -fcuda-is-device \
>
> +// RUN: -verify -verify-ignore-unexpected=note %s
>
> +
>
> +#include "Inputs/cuda.h"
>
> +
>
> +// FIXME: Merge into function-overload.cu once deferred errors can be
> emitted
>
> +// when non-deferred errors are present.
>
> +
>
> +#if !defined(__CUDA_ARCH__)
>
> +//expected-no-diagnostics
>
> +#endif
>
> +
>
> +typedef void (*GlobalFnPtr)(); // __global__ functions must return void.
>
> +
>
> +__global__ void g() {}
>
> +
>
> +__host__ __device__ void hd() {
>
> + GlobalFnPtr fp_g = g;
>
> +#if defined(__CUDA_ARCH__)
>
> + // expected-error@-2 {{reference to __global__ function 'g' in
> __host__ __device__ function}}
>
> +#endif
>
> + g<<<0,0>>>();
>
> +#if defined(__CUDA_ARCH__)
>
> + // expected-error@-2 {{reference to __global__ function 'g' in
> __host__ __device__ function}}
>
> +#endif // __CUDA_ARCH__
>
> +}
>
>
>
> Modified: cfe/trunk/test/SemaCUDA/function-overload.cu
>
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCUDA/function-overload.cu?rev=283963&r1=283962&r2=283963&view=diff
>
>
> ==
>
> --- cfe/trunk/test/SemaCUDA/function-overload.cu (original)
>
> +++ cfe/trunk/test/SemaCUDA/function-overload.cu Tue Oct 11 20:30:08 2016
>
> @@ -181,18 +181,7 @@ __host__ __device__ void hostdevicef() {
>
>CurrentFnPtr fp_cdh = cdh;
>
>CurrentReturnTy ret_cdh = cdh();
>
>
>
> - GlobalFnPtr fp_g = g;
>
> -#if defined(__CUDA_ARCH__)
>
> - // expected-error@-2 {{reference to __global__ function 'g' in
> __host__ __device__ function}}
>
> -#endif
>
> - g();
>
> - g<<<0,0>>>();
>
> -#if !defined(__CUDA_ARCH__)
>
> - // expected-error@-3 {{call to global function g not configured}}
>
> -#else
>
> - // expected-error@-5 {{no matching function for call to 'g'}}
>
> - // expected-error@-5 {{reference to __global__ function 'g' in
> __host__ __device__ function}}
>
> -#endif // __CUDA_ARCH__
>
> + g(); // expected-error {{call to global function g not configured}}
>
> }
>
>
>
> // Test for address of overloaded function resolution in the global
> context.
>
>
>
> Modified: cfe/trunk/test/SemaCUDA/reference-to-kernel-fn.cu
>
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCUDA/reference-to-kernel-fn.cu?rev=283963&r1=283962&r2=283963&view=diff
>
>
> ==
r310994 - Fix a UBSan failure where this boolean was copied when uninitialized.
Author: chandlerc
Date: Wed Aug 16 00:22:49 2017
New Revision: 310994
URL: http://llvm.org/viewvc/llvm-project?rev=310994&view=rev
Log:
Fix a UBSan failure where this boolean was copied when uninitialized.
When r310905 moved the pointer and bool out of a PointerIntPair, it made
them end up uninitialized and caused UBSan failures when copying the
uninitialized boolean. However, making the pointer be null should avoid
the reference to the boolean entirely.
Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=310994&r1=310993&r2=310994&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Wed Aug 16 00:22:49 2017
@@ -977,7 +977,7 @@ namespace {
/// RAII object used to optionally suppress diagnostics and side-effects from
/// a speculative evaluation.
class SpeculativeEvaluationRAII {
-EvalInfo *Info;
+EvalInfo *Info = nullptr;
Expr::EvalStatus OldStatus;
bool OldIsSpeculativelyEvaluating;
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type
On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator < > revi...@reviews.llvm.org> wrote: > >> chandlerc added a comment. >> >> I'm really not a fan of the degree of complexity and subtlety that this >> introduces into the frontend, all to allow particular backend optimizations. >> >> I feel like this is Clang working around a fundamental deficiency in LLVM >> and we should instead find a way to fix this in LLVM itself. >> >> As has been pointed out before, user code can synthesize large integers >> that small bit sequences are extracted from, and Clang and LLVM should >> handle those just as well as actual bitfields. >> >> Can we see how far we can push the LLVM side before we add complexity to >> Clang here? I understand that there remain challenges to LLVM's stuff, but >> I don't think those challenges make *all* of the LLVM improvements off the >> table, I don't think we've exhausted all ways of improving the LLVM changes >> being proposed, and I think we should still land all of those and >> re-evaluate how important these issues are when all of that is in place. >> > > The main challenge of doing this in LLVM is that inter-procedural > analysis (and possibly cross module) is needed (for store forwarding > issues). > > Wei, perhaps you can provide concrete test case to illustrate the issue so > that reviewers have a good understanding. > It doesn't seem like all options for addressing that have been exhausted. And even then, I feel like trying to fix this with non-obvious (to the programmer) frontend heuristics isn't a good solution. I actually *prefer* the source work around of "don't use a bitfield if you *must* have narrow width access across modules where the optimizer cannot see enough to narrow them and you happen to know that there is a legal narrow access that works". Because that way the programmer has *control* over this rather than being at the whim of whichever side of the heuristic they end up on. > > David > >> >> >> Repository: >> rL LLVM >> >> https://reviews.llvm.org/D36562 >> >> >> >> ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [PATCH] D36562: [Bitfield] Make the bitfield a separate location if it has width of legal integer type and its bit offset is naturally aligned for the type
On Tue, Aug 22, 2017 at 7:18 PM Xinliang David Li via llvm-commits < llvm-comm...@lists.llvm.org> wrote: > On Tue, Aug 22, 2017 at 7:10 PM, Chandler Carruth via llvm-commits < > llvm-comm...@lists.llvm.org> wrote: > >> On Tue, Aug 22, 2017 at 7:03 PM Xinliang David Li via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> On Tue, Aug 22, 2017 at 6:37 PM, Chandler Carruth via Phabricator < >>> revi...@reviews.llvm.org> wrote: >>> >>>> chandlerc added a comment. >>>> >>>> I'm really not a fan of the degree of complexity and subtlety that this >>>> introduces into the frontend, all to allow particular backend >>>> optimizations. >>>> >>>> I feel like this is Clang working around a fundamental deficiency in >>>> LLVM and we should instead find a way to fix this in LLVM itself. >>>> >>>> As has been pointed out before, user code can synthesize large integers >>>> that small bit sequences are extracted from, and Clang and LLVM should >>>> handle those just as well as actual bitfields. >>>> >>>> Can we see how far we can push the LLVM side before we add complexity >>>> to Clang here? I understand that there remain challenges to LLVM's stuff, >>>> but I don't think those challenges make *all* of the LLVM improvements off >>>> the table, I don't think we've exhausted all ways of improving the LLVM >>>> changes being proposed, and I think we should still land all of those and >>>> re-evaluate how important these issues are when all of that is in place. >>>> >>> >>> The main challenge of doing this in LLVM is that inter-procedural >>> analysis (and possibly cross module) is needed (for store forwarding >>> issues). >>> >>> Wei, perhaps you can provide concrete test case to illustrate the issue >>> so that reviewers have a good understanding. >>> >> >> It doesn't seem like all options for addressing that have been exhausted. >> And even then, I feel like trying to fix this with non-obvious (to the >> programmer) frontend heuristics isn't a good solution. I actually *prefer* >> the source work around of "don't use a bitfield if you *must* have narrow >> width access across modules where the optimizer cannot see enough to narrow >> them and you happen to know that there is a legal narrow access that >> works". Because that way the programmer has *control* over this rather than >> being at the whim of whichever side of the heuristic they end up on. >> > > > The source workaround solution *does not* scale. Most importantly, user > may not even be aware of the problem (and performance loss) unless > compiling the code with another compiler and notice the performance > difference. > I don't really understand this argument... I don't think we can realistically chase all performance problems that users aren't aware of or can't measure. And our users *do* care and seem very good at benchmarking and noticing problems. =] I also think it is OK if in rare cases programmers have to adapt their source code to optimize well. We can and should make this as rare as reasonable from an engineering tradeoff perspective, but at a certain point we need to work with programmers to find a way to solve the problem. There exist coding patterns that Clang and LLVM will never be particularly effective at optimizing, and that seems OK. We just need to have reasonable engineering requirements for those cases: 1) They need to be quite rare. So far, this issue has come up fairly infrequently. Not never, but there are many issues that seem to come up much more often such as inlining issues. 2) We need an effective way to explain how programmers should write code to optimize well, and this explanation needs to be as simple as possible. 3) We likely need to give programmers *choices* about which direction their code gets optimized for. And this is (IMO) the biggest practical issue with the approach in this change (beyond race detection and other semantic issues). I'm suggesting that we teach programmers to choose between a bitfield to get combining-friendly access to tightly packed data, and integer types of an appropriate size to get inexpensive and predictable loads and stores. For sub-byte-width and non-byte-aligned bitfields this is already a necessary property and so it seems like a consistent and easily explained and taught model. While there are times where there is a single "right" answer and we only have to provide that, I don't think this is one of them. I've seen
[clang] aaf7ffd - Teach `-fsanitize=fuzzer` to respect `-static` and `-static-libstdc++` when adding C++ standard libraries.
Author: Chandler Carruth
Date: 2020-10-27T01:36:54Z
New Revision: aaf7ffd4e1aa81c7f4cc8da4f943982ca2e131f4
URL:
https://github.com/llvm/llvm-project/commit/aaf7ffd4e1aa81c7f4cc8da4f943982ca2e131f4
DIFF:
https://github.com/llvm/llvm-project/commit/aaf7ffd4e1aa81c7f4cc8da4f943982ca2e131f4.diff
LOG: Teach `-fsanitize=fuzzer` to respect `-static` and `-static-libstdc++`
when adding C++ standard libraries.
Summary:
Makes linking the sanitizers follow the same logic as the rest of the
driver with respect to the static linking strategy for the C++ standard
library.
Subscribers: mcrosier, cfe-commits
Tags: #clang
Differential Revision: https://reviews.llvm.org/D80488
Added:
Modified:
clang/lib/Driver/ToolChains/CommonArgs.cpp
clang/test/Driver/fuzzer.c
Removed:
diff --git a/clang/lib/Driver/ToolChains/CommonArgs.cpp
b/clang/lib/Driver/ToolChains/CommonArgs.cpp
index 692d0600bad3..23522e0886ff 100644
--- a/clang/lib/Driver/ToolChains/CommonArgs.cpp
+++ b/clang/lib/Driver/ToolChains/CommonArgs.cpp
@@ -833,8 +833,15 @@ bool tools::addSanitizerRuntimes(const ToolChain &TC,
const ArgList &Args,
if (SanArgs.needsFuzzerInterceptors())
addSanitizerRuntime(TC, Args, CmdArgs, "fuzzer_interceptors", false,
true);
-if (!Args.hasArg(clang::driver::options::OPT_nostdlibxx))
+if (!Args.hasArg(clang::driver::options::OPT_nostdlibxx)) {
+ bool OnlyLibstdcxxStatic = Args.hasArg(options::OPT_static_libstdcxx) &&
+ !Args.hasArg(options::OPT_static);
+ if (OnlyLibstdcxxStatic)
+CmdArgs.push_back("-Bstatic");
TC.AddCXXStdlibLibArgs(Args, CmdArgs);
+ if (OnlyLibstdcxxStatic)
+CmdArgs.push_back("-Bdynamic");
+}
}
for (auto RT : SharedRuntimes)
diff --git a/clang/test/Driver/fuzzer.c b/clang/test/Driver/fuzzer.c
index 3fdf5ab9c9b9..d91dd573dec3 100644
--- a/clang/test/Driver/fuzzer.c
+++ b/clang/test/Driver/fuzzer.c
@@ -29,6 +29,23 @@
// RUN: %clang -fsanitize=fuzzer -fsanitize-coverage=trace-pc %s -### 2>&1 |
FileCheck --check-prefixes=CHECK-MSG %s
// CHECK-MSG-NOT: argument unused during compilation
+// Check that we respect whether thes tandard library should be linked
+// statically.
+//
+// RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=libstdc++
%s -### 2>&1 | FileCheck --check-prefixes=CHECK-LIBSTDCXX-DYNAMIC %s
+// CHECK-LIBSTDCXX-DYNAMIC-NOT: -Bstatic
+// CHECK-LIBSTDCXX-DYNAMIC: -lstdc++
+//
+// RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=libstdc++
-static-libstdc++ %s -### 2>&1 | FileCheck
--check-prefixes=CHECK-LIBSTDCXX-STATIC %s
+// CHECK-LIBSTDCXX-STATIC: "-Bstatic" "-lstdc++"
+//
+// RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=libc++ %s
-### 2>&1 | FileCheck --check-prefixes=CHECK-LIBCXX-DYNAMIC %s
+// CHECK-LIBCXX-DYNAMIC-NOT: -Bstatic
+// CHECK-LIBCXX-DYNAMIC: -lc++
+//
+// RUN: %clang -fsanitize=fuzzer -target i386-unknown-linux -stdlib=libc++
-static-libstdc++ %s -### 2>&1 | FileCheck --check-prefixes=CHECK-LIBCXX-STATIC
%s
+// CHECK-LIBCXX-STATIC: "-Bstatic" "-lc++"
+
int LLVMFuzzerTestOneInput(const char *Data, long Size) {
return 0;
}
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r329113 - Add REQUIRES: darwin-system to test/Driver/darwin-sdkroot.c
See my reply to the original commit, but I think this is the wrong fix. On Tue, Apr 3, 2018 at 2:13 PM Alex Lorenz via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: arphaman > Date: Tue Apr 3 14:10:26 2018 > New Revision: 329113 > > URL: http://llvm.org/viewvc/llvm-project?rev=329113&view=rev > Log: > Add REQUIRES: darwin-system to test/Driver/darwin-sdkroot.c > > The test from r329110 is for Darwin only > > Modified: > cfe/trunk/test/Driver/darwin-sdkroot.c > > Modified: cfe/trunk/test/Driver/darwin-sdkroot.c > URL: > http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-sdkroot.c?rev=329113&r1=329112&r2=329113&view=diff > > == > --- cfe/trunk/test/Driver/darwin-sdkroot.c (original) > +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr 3 14:10:26 2018 > @@ -1,4 +1,5 @@ > // Check that SDKROOT is used to define the default for -isysroot on > Darwin. > +// REQUIRES: system-darwin > // > // RUN: rm -rf %t.tmpdir > // RUN: mkdir -p %t.tmpdir > > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs
On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: arphaman > Date: Tue Apr 3 13:50:05 2018 > New Revision: 329110 > > URL: http://llvm.org/viewvc/llvm-project?rev=329110&view=rev > Log: > [driver][darwin] Do not infer -simulator environment for non-simulator SDKs > I know you added a REQUIRES line to these tests, but I think there is a much better way: > --- cfe/trunk/test/Driver/darwin-sdkroot.c (original) > +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr 3 13:50:05 2018 > @@ -51,12 +51,21 @@ > // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0" > // CHECK-IPHONE: ld > // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0" > +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \ > Instead of just running %clang, actually pass the `-target` you want to it like we do in the below invocation and the other invocations in this file. We shouldn't lose driver testing on other systems as long as you can specify the desired target. > +// RUN: | FileCheck --check-prefix=CHECK-IPHONE-X86 %s > +// CHECK-IPHONE-X86: clang > +// CHECK-IPHONE-X86: "-cc1" > +// CHECK-IPHONE-X86: -apple-ios8.0.0" > +// CHECK-IPHONE-X86: ld > +// CHECK-IPHONE-X86: "-iphoneos_version_min" "8.0.0" > // > // > // RUN: rm -rf %t/SDKs/iPhoneSimulator8.0.sdk > // RUN: mkdir -p %t/SDKs/iPhoneSimulator8.0.sdk > // RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -target > x86_64-apple-darwin %s -### 2>&1 \ > // RUN: | FileCheck --check-prefix=CHECK-SIMULATOR %s > +// RUN: env SDKROOT=%t/SDKs/iPhoneSimulator8.0.sdk %clang -arch x86_64 %s > -### 2>&1 \ > +// RUN: | FileCheck --check-prefix=CHECK-SIMULATOR %s > // > // CHECK-SIMULATOR: clang > // CHECK-SIMULATOR: "-cc1" > @@ -74,3 +83,49 @@ > // CHECK-MACOSX: "-triple" "x86_64-apple-macosx10.10.0" > // CHECK-MACOSX: ld > // CHECK-MACOSX: "-macosx_version_min" "10.10.0" > + > +// RUN: rm -rf %t/SDKs/WatchOS3.0.sdk > +// RUN: mkdir -p %t/SDKs/WatchOS3.0.sdk > +// RUN: env SDKROOT=%t/SDKs/WatchOS3.0.sdk %clang %s -### 2>&1 \ > +// RUN: | FileCheck --check-prefix=CHECK-WATCH %s > +// > +// CHECK-WATCH: clang > +// CHECK-WATCH: "-cc1" > +// CHECK-WATCH: -apple-watchos3.0.0" > +// CHECK-WATCH: ld > +// CHECK-WATCH: "-watchos_version_min" "3.0.0" > +// > +// > +// RUN: rm -rf %t/SDKs/WatchSimulator3.0.sdk > +// RUN: mkdir -p %t/SDKs/WatchSimulator3.0.sdk > +// RUN: env SDKROOT=%t/SDKs/WatchSimulator3.0.sdk %clang %s -### 2>&1 \ > +// RUN: | FileCheck --check-prefix=CHECK-WATCH-SIMULATOR %s > +// > +// CHECK-WATCH-SIMULATOR: clang > +// CHECK-WATCH-SIMULATOR: "-cc1" > +// CHECK-WATCH-SIMULATOR: -apple-watchos3.0.0-simulator" > +// CHECK-WATCH-SIMULATOR: ld > +// CHECK-WATCH-SIMULATOR: "-watchos_simulator_version_min" "3.0.0" > + > +// RUN: rm -rf %t/SDKs/AppleTVOS10.0.sdk > +// RUN: mkdir -p %t/SDKs/AppleTVOS10.0.sdk > +// RUN: env SDKROOT=%t/SDKs/AppleTVOS10.0.sdk %clang %s -### 2>&1 \ > +// RUN: | FileCheck --check-prefix=CHECK-TV %s > +// > +// CHECK-TV: clang > +// CHECK-TV: "-cc1" > +// CHECK-TV: -apple-tvos10.0.0" > +// CHECK-TV: ld > +// CHECK-TV: "-tvos_version_min" "10.0.0" > +// > +// > +// RUN: rm -rf %t/SDKs/AppleTVSimulator10.0.sdk > +// RUN: mkdir -p %t/SDKs/AppleTVSimulator10.0.sdk > +// RUN: env SDKROOT=%t/SDKs/AppleTVSimulator10.0.sdk %clang %s -### 2>&1 \ > +// RUN: | FileCheck --check-prefix=CHECK-TV-SIMULATOR %s > +// > +// CHECK-TV-SIMULATOR: clang > +// CHECK-TV-SIMULATOR: "-cc1" > +// CHECK-TV-SIMULATOR: -apple-tvos10.0.0-simulator" > +// CHECK-TV-SIMULATOR: ld > +// CHECK-TV-SIMULATOR: "-tvos_simulator_version_min" "10.0.0" > > > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r329110 - [driver][darwin] Do not infer -simulator environment for non-simulator SDKs
On Tue, Apr 3, 2018 at 4:01 PM Alex L via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On 3 April 2018 at 14:30, Chandler Carruth wrote: > >> On Tue, Apr 3, 2018 at 1:52 PM Alex Lorenz via cfe-commits < >> cfe-commits@lists.llvm.org> wrote: >> >>> Author: arphaman >>> Date: Tue Apr 3 13:50:05 2018 >>> New Revision: 329110 >>> >>> URL: http://llvm.org/viewvc/llvm-project?rev=329110&view=rev >>> Log: >>> [driver][darwin] Do not infer -simulator environment for non-simulator >>> SDKs >>> >> >> I know you added a REQUIRES line to these tests, but I think there is a >> much better way: >> >> >>> --- cfe/trunk/test/Driver/darwin-sdkroot.c (original) >>> +++ cfe/trunk/test/Driver/darwin-sdkroot.c Tue Apr 3 13:50:05 2018 >>> @@ -51,12 +51,21 @@ >>> // CHECK-IPHONE: "-triple" "arm64-apple-ios8.0.0" >>> // CHECK-IPHONE: ld >>> // CHECK-IPHONE: "-iphoneos_version_min" "8.0.0" >>> +// RUN: env SDKROOT=%t/SDKs/iPhoneOS8.0.0.sdk %clang %s -### 2>&1 \ >>> >> >> Instead of just running %clang, actually pass the `-target` you want to >> it like we do in the below invocation and the other invocations in this >> file. >> >> We shouldn't lose driver testing on other systems as long as you can >> specify the desired target. >> > > > Hi Chandler! > > Thanks for pointing this out! We actually can't use -target here because > when -target is specified, Darwin's driver won't infer the triple's > environment from the SDKROOT. So this test covers the path in the driver > that won't be taken when -target is specified. > Ah, I see, that's where the inference is triggered. Sure. > > You've made a good point about losing testing though. I can split out this > test into the original file (with -target use) and the new tests which > can't use -target and are Darwin specific to ensure we won't loose the > existing coverage. I will commit a follow-up commit that does this. > Sure, makes sense to factor out inference-based tests where possible and cover as much as you can w/o inference. Thanks for explaining! ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] r329550 - Fix unused variable warning.
Author: chandlerc
Date: Mon Apr 9 00:26:42 2018
New Revision: 329550
URL: http://llvm.org/viewvc/llvm-project?rev=329550&view=rev
Log:
Fix unused variable warning.
Modified:
clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
Modified: clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
URL:
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp?rev=329550&r1=329549&r2=329550&view=diff
==
--- clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
(original)
+++ clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp Mon
Apr 9 00:26:42 2018
@@ -99,6 +99,7 @@ void ParentVirtualCallCheck::registerMat
void ParentVirtualCallCheck::check(const MatchFinder::MatchResult &Result) {
const auto *MatchedDecl = Result.Nodes.getNodeAs("call");
+ (void)MatchedDecl;
assert(MatchedDecl);
const auto *Member = Result.Nodes.getNodeAs("member");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: [clang-tools-extra] r329550 - Fix unused variable warning.
I have no opinion other than removing the warning. =D This seemed to be the
idiomatic pattern in the rest of LLVM and Clang. If someone wants to adjust
this locally, by all means.
On Mon, Apr 9, 2018 at 12:47 AM Zinovy Nis via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Thanks, Chandler.
>
>assert(Result.Nodes.getNodeAs("call"));
>
> would also be fine.
>
> пн, 9 апр. 2018 г. в 10:29, Chandler Carruth via cfe-commits <
> cfe-commits@lists.llvm.org>:
>
>> Author: chandlerc
>> Date: Mon Apr 9 00:26:42 2018
>> New Revision: 329550
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=329550&view=rev
>> Log:
>> Fix unused variable warning.
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
>>
>> Modified:
>> clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
>> URL:
>> http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp?rev=329550&r1=329549&r2=329550&view=diff
>>
>> ==
>> ---
>> clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp
>> (original)
>> +++
>> clang-tools-extra/trunk/clang-tidy/bugprone/ParentVirtualCallCheck.cpp Mon
>> Apr 9 00:26:42 2018
>> @@ -99,6 +99,7 @@ void ParentVirtualCallCheck::registerMat
>>
>> void ParentVirtualCallCheck::check(const MatchFinder::MatchResult
>> &Result) {
>>const auto *MatchedDecl =
>> Result.Nodes.getNodeAs("call");
>> + (void)MatchedDecl;
>>assert(MatchedDecl);
>>
>>const auto *Member = Result.Nodes.getNodeAs("member");
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r318128 - [PM] Port BoundsChecking to the new PM.
Author: chandlerc
Date: Mon Nov 13 17:30:04 2017
New Revision: 318128
URL: http://llvm.org/viewvc/llvm-project?rev=318128&view=rev
Log:
[PM] Port BoundsChecking to the new PM.
Registers it and everything, updates all the references, etc.
Next patch will add support to Clang's `-fexperimental-new-pass-manager`
path to actually enable BoundsChecking correctly.
Differential Revision: https://reviews.llvm.org/D39084
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=318128&r1=318127&r2=318128&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Nov 13 17:30:04 2017
@@ -168,7 +168,7 @@ static void addAddDiscriminatorsPass(con
static void addBoundsCheckingPass(const PassManagerBuilder &Builder,
legacy::PassManagerBase &PM) {
- PM.add(createBoundsCheckingPass());
+ PM.add(createBoundsCheckingLegacyPass());
}
static void addSanitizerCoveragePass(const PassManagerBuilder &Builder,
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r318130 - [PM] Add a missing header that I had in the next commit but was needed
Author: chandlerc Date: Mon Nov 13 17:47:24 2017 New Revision: 318130 URL: http://llvm.org/viewvc/llvm-project?rev=318130&view=rev Log: [PM] Add a missing header that I had in the next commit but was needed in r318128. Should fix the build. 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=318130&r1=318129&r2=318130&view=diff == --- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original) +++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Nov 13 17:47:24 2017 @@ -51,6 +51,7 @@ #include "llvm/Transforms/IPO/PassManagerBuilder.h" #include "llvm/Transforms/IPO/ThinLTOBitcodeWriter.h" #include "llvm/Transforms/Instrumentation.h" +#include "llvm/Transforms/Instrumentation/BoundsChecking.h" #include "llvm/Transforms/ObjCARC.h" #include "llvm/Transforms/Scalar.h" #include "llvm/Transforms/Scalar/GVN.h" ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r318131 - [PM] Wire up support for the bounds checking sanitizer with the new PM.
Author: chandlerc
Date: Mon Nov 13 17:59:18 2017
New Revision: 318131
URL: http://llvm.org/viewvc/llvm-project?rev=318131&view=rev
Log:
[PM] Wire up support for the bounds checking sanitizer with the new PM.
Not much interesting here. Mostly wiring things together.
One thing worth noting is that the approach is substantially different
from the old PM. Here, the -O0 case works fundamentally differently in
that we just directly build the pipeline without any callbacks or other
cruft. In some ways, this is nice and clean. However, I don't like that
it causes the sanitizers to be enabled with different changes at
different times. =/ Suggestions for a better way to do this are welcome.
Differential Revision: https://reviews.llvm.org/D39085
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/CodeGen/bounds-checking.c
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=318131&r1=318130&r2=318131&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Nov 13 17:59:18 2017
@@ -900,6 +900,12 @@ void EmitAssemblyHelper::EmitAssemblyWit
// Build a minimal pipeline based on the semantics required by Clang,
// which is just that always inlining occurs.
MPM.addPass(AlwaysInlinerPass());
+
+ // At -O0 we directly run necessary sanitizer passes.
+ if (LangOpts.Sanitize.has(SanitizerKind::LocalBounds))
+MPM.addPass(createModuleToFunctionPassAdaptor(BoundsCheckingPass()));
+
+ // Lastly, add a semantically necessary pass for ThinLTO.
if (IsThinLTO)
MPM.addPass(NameAnonGlobalPass());
} else {
@@ -907,6 +913,14 @@ void EmitAssemblyHelper::EmitAssemblyWit
// configure the pipeline.
PassBuilder::OptimizationLevel Level = mapToLevel(CodeGenOpts);
+ // Register callbacks to schedule sanitizer passes at the appropriate
part of
+ // the pipeline.
+ if (LangOpts.Sanitize.has(SanitizerKind::LocalBounds))
+PB.registerScalarOptimizerLateEPCallback(
+[](FunctionPassManager &FPM, PassBuilder::OptimizationLevel Level)
{
+ FPM.addPass(BoundsCheckingPass());
+});
+
if (IsThinLTO) {
MPM = PB.buildThinLTOPreLinkDefaultPipeline(
Level, CodeGenOpts.DebugPassManager);
Modified: cfe/trunk/test/CodeGen/bounds-checking.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/bounds-checking.c?rev=318131&r1=318130&r2=318131&view=diff
==
--- cfe/trunk/test/CodeGen/bounds-checking.c (original)
+++ cfe/trunk/test/CodeGen/bounds-checking.c Mon Nov 13 17:59:18 2017
@@ -1,5 +1,7 @@
// RUN: %clang_cc1 -fsanitize=local-bounds -emit-llvm -triple
x86_64-apple-darwin10 %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fsanitize=local-bounds -fexperimental-new-pass-manager
-emit-llvm -triple x86_64-apple-darwin10 %s -o - | FileCheck %s
// RUN: %clang_cc1 -fsanitize=array-bounds -O -fsanitize-trap=array-bounds
-emit-llvm -triple x86_64-apple-darwin10 -DNO_DYNAMIC %s -o - | FileCheck %s
+// RUN: %clang_cc1 -fsanitize=array-bounds -O -fsanitize-trap=array-bounds
-fexperimental-new-pass-manager -emit-llvm -triple x86_64-apple-darwin10
-DNO_DYNAMIC %s -o - | FileCheck %s
// CHECK-LABEL: @f
double f(int b, int i) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r318137 - [PM] Require a registered x86 target for this test which uses the x86
Author: chandlerc
Date: Mon Nov 13 21:20:03 2017
New Revision: 318137
URL: http://llvm.org/viewvc/llvm-project?rev=318137&view=rev
Log:
[PM] Require a registered x86 target for this test which uses the x86
triple.
Modified:
cfe/trunk/test/CodeGen/bounds-checking.c
Modified: cfe/trunk/test/CodeGen/bounds-checking.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/bounds-checking.c?rev=318137&r1=318136&r2=318137&view=diff
==
--- cfe/trunk/test/CodeGen/bounds-checking.c (original)
+++ cfe/trunk/test/CodeGen/bounds-checking.c Mon Nov 13 21:20:03 2017
@@ -2,6 +2,8 @@
// RUN: %clang_cc1 -fsanitize=local-bounds -fexperimental-new-pass-manager
-emit-llvm -triple x86_64-apple-darwin10 %s -o - | FileCheck %s
// RUN: %clang_cc1 -fsanitize=array-bounds -O -fsanitize-trap=array-bounds
-emit-llvm -triple x86_64-apple-darwin10 -DNO_DYNAMIC %s -o - | FileCheck %s
// RUN: %clang_cc1 -fsanitize=array-bounds -O -fsanitize-trap=array-bounds
-fexperimental-new-pass-manager -emit-llvm -triple x86_64-apple-darwin10
-DNO_DYNAMIC %s -o - | FileCheck %s
+//
+// REQUIRES: x86-registered-target
// CHECK-LABEL: @f
double f(int b, int i) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r290159 - Fix the spelling of 'bitfield' in diagnostics to be consistently 'bit-field'.
Author: chandlerc
Date: Mon Dec 19 20:43:58 2016
New Revision: 290159
URL: http://llvm.org/viewvc/llvm-project?rev=290159&view=rev
Log:
Fix the spelling of 'bitfield' in diagnostics to be consistently 'bit-field'.
The latter agrees with most existing diagnostics and the C and C++ standards.
Differential Revision: https://reviews.llvm.org/D26530
Modified:
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/test/Parser/objc-property-syntax.m
cfe/trunk/test/Sema/constant-conversion.c
cfe/trunk/test/SemaCXX/conversion.cpp
cfe/trunk/test/SemaCXX/member-init.cpp
cfe/trunk/test/SemaOpenCL/unsupported.cl
Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=290159&r1=290158&r2=290159&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Mon Dec 19 20:43:58
2016
@@ -398,7 +398,7 @@ def err_objc_expected_selector_for_gette
"expected selector for Objective-C %select{setter|getter}0">;
def err_objc_property_requires_field_name : Error<
"property requires fields to be named">;
-def err_objc_property_bitfield : Error<"property name cannot be a bitfield">;
+def err_objc_property_bitfield : Error<"property name cannot be a bit-field">;
def err_objc_expected_property_attr : Error<"unknown property attribute %0">;
def err_objc_properties_require_objc2 : Error<
"properties are an Objective-C 2 feature">;
@@ -726,7 +726,7 @@ def warn_cxx98_compat_nonstatic_member_i
"in-class initialization of non-static data members is incompatible with
C++98">,
InGroup, DefaultIgnore;
def err_bitfield_member_init: Error<
- "bitfield member cannot have an in-class initializer">;
+ "bit-field member cannot have an in-class initializer">;
def err_incomplete_array_member_init: Error<
"array bound cannot be deduced from an in-class initializer">;
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=290159&r1=290158&r2=290159&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Dec 19 20:43:58
2016
@@ -2930,7 +2930,7 @@ def warn_impcast_integer_precision_const
"implicit conversion from %2 to %3 changes value from %0 to %1">,
InGroup;
def warn_impcast_bitfield_precision_constant : Warning<
- "implicit truncation from %2 to bitfield changes value from %0 to %1">,
+ "implicit truncation from %2 to bit-field changes value from %0 to %1">,
InGroup;
def warn_impcast_literal_float_to_integer : Warning<
@@ -8088,7 +8088,7 @@ def err_opencl_function_variable : Error
def err_static_function_scope : Error<
"variables in function scope cannot be declared static">;
def err_opencl_bitfields : Error<
- "bitfields are not supported in OpenCL">;
+ "bit-fields are not supported in OpenCL">;
def err_opencl_vla : Error<
"variable length arrays are not supported in OpenCL">;
def err_bad_kernel_param_type : Error<
Modified: cfe/trunk/test/Parser/objc-property-syntax.m
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Parser/objc-property-syntax.m?rev=290159&r1=290158&r2=290159&view=diff
==
--- cfe/trunk/test/Parser/objc-property-syntax.m (original)
+++ cfe/trunk/test/Parser/objc-property-syntax.m Mon Dec 19 20:43:58 2016
@@ -4,7 +4,7 @@
int prop;
};
@property unsigned char bufferedUTF8Bytes[4]; // expected-error {{property
cannot have array or function type}}
-@property unsigned char bufferedUTFBytes:1;// expected-error {{property
name cannot be a bitfield}}
+@property unsigned char bufferedUTFBytes:1;// expected-error {{property
name cannot be a bit-field}}
@property(nonatomic, retain, setter=ab_setDefaultToolbarItems) MyClass
*ab_defaultToolbarItems; // expected-error {{method name referenced in property
setter attribute must end with ':'}}
@property int prop;
Modified: cfe/trunk/test/Sema/constant-conversion.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/constant-conversion.c?rev=290159&r1=290158&r2=290159&view=diff
==
--- cfe/trunk/test/Sema/constant-conversion.c (original)
+++ cfe/trunk/test/Sema/constant-conversion.c Mon Dec 19 20:43:58 2016
@@ -11,7 +11,7 @@ void test_6792488(void) {
void test_7809123(void) {
struct { int i5 : 5; } a;
- a.i5 = 36; // expected-warning {{implicit truncation from 'int' to bitfield
changes value from 36 to 4}}
+ a.i5 = 36; // expected-war
r290169 - Revert r290149: Add the alloc_size attribute to clang.
Author: chandlerc
Date: Tue Dec 20 02:28:19 2016
New Revision: 290169
URL: http://llvm.org/viewvc/llvm-project?rev=290169&view=rev
Log:
Revert r290149: Add the alloc_size attribute to clang.
This commit fails MSan when running test/CodeGen/object-size.c in
a confusing way. After some discussion with George, it isn't really
clear what is going on here. We can make the MSan failure go away by
testing for the invalid bit, but *why* things are invalid isn't clear.
And yet, other code in the surrounding area is doing precisely this and
testing for invalid.
George is going to take a closer look at this to better understand the
nature of the failure and recommit it, for now backing it out to clean
up MSan builds.
Removed:
cfe/trunk/test/CodeGen/alloc-size.c
cfe/trunk/test/CodeGenCXX/alloc-size.cpp
cfe/trunk/test/Sema/alloc-size.c
Modified:
cfe/trunk/include/clang/Basic/Attr.td
cfe/trunk/include/clang/Basic/AttrDocs.td
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/lib/CodeGen/CGBlocks.cpp
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/CodeGenModule.h
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/test/CodeGenCXX/block-in-ctor-dtor.cpp
cfe/trunk/test/CodeGenCXX/global-init.cpp
cfe/trunk/test/CodeGenOpenCL/cl20-device-side-enqueue.cl
cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp
Modified: cfe/trunk/include/clang/Basic/Attr.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=290169&r1=290168&r2=290169&view=diff
==
--- cfe/trunk/include/clang/Basic/Attr.td (original)
+++ cfe/trunk/include/clang/Basic/Attr.td Tue Dec 20 02:28:19 2016
@@ -780,15 +780,6 @@ def EmptyBases : InheritableAttr, Target
let Documentation = [EmptyBasesDocs];
}
-def AllocSize : InheritableAttr {
- let Spellings = [GCC<"alloc_size">];
- let Subjects = SubjectList<[HasFunctionProto], WarnDiag,
- "ExpectedFunctionWithProtoType">;
- let Args = [IntArgument<"ElemSizeParam">, IntArgument<"NumElemsParam", 1>];
- let TemplateDependent = 1;
- let Documentation = [AllocSizeDocs];
-}
-
def EnableIf : InheritableAttr {
let Spellings = [GNU<"enable_if">];
let Subjects = SubjectList<[Function]>;
Modified: cfe/trunk/include/clang/Basic/AttrDocs.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/AttrDocs.td?rev=290169&r1=290168&r2=290169&view=diff
==
--- cfe/trunk/include/clang/Basic/AttrDocs.td (original)
+++ cfe/trunk/include/clang/Basic/AttrDocs.td Tue Dec 20 02:28:19 2016
@@ -206,44 +206,6 @@ to enforce the provided alignment assump
}];
}
-def AllocSizeDocs : Documentation {
- let Category = DocCatFunction;
- let Content = [{
-The ``alloc_size`` attribute can be placed on functions that return pointers in
-order to hint to the compiler how many bytes of memory will be available at the
-returned poiner. ``alloc_size`` takes one or two arguments.
-
-- ``alloc_size(N)`` implies that argument number N equals the number of
- available bytes at the returned pointer.
-- ``alloc_size(N, M)`` implies that the product of argument number N and
- argument number M equals the number of available bytes at the returned
- pointer.
-
-Argument numbers are 1-based.
-
-An example of how to use ``alloc_size``
-
-.. code-block:: c
-
- void *my_malloc(int a) __attribute__((alloc_size(1)));
- void *my_calloc(int a, int b) __attribute__((alloc_size(1, 2)));
-
- int main() {
-void *const p = my_malloc(100);
-assert(__builtin_object_size(p, 0) == 100);
-void *const a = my_calloc(20, 5);
-assert(__builtin_object_size(a, 0) == 100);
- }
-
-.. Note:: This attribute works differently in clang than it does in GCC.
- Specifically, clang will only trace ``const`` pointers (as above); we give up
- on pointers that are not marked as ``const``. In the vast majority of cases,
- this is unimportant, because LLVM has support for the ``alloc_size``
- attribute. However, this may cause mildly unintuitive behavior when used with
- other attributes, such as ``enable_if``.
- }];
-}
-
def EnableIfDocs : Documentation {
let Category = DocCatFunction;
let Content = [{
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=290169&r1=290168&r2=290169&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Dec 20 02:28:19
2016
@@ -2297,9 +2297,6 @@ def warn_attribute_pointers_only : Warni
"%0 attribute only applies to%select{| constant}1 pointer arguments">,
InGroup;
r290392 - Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'.
Author: chandlerc Date: Thu Dec 22 18:23:01 2016 New Revision: 290392 URL: http://llvm.org/viewvc/llvm-project?rev=290392&view=rev Log: Make '-disable-llvm-optzns' an alias for '-disable-llvm-passes'. Much to my surprise, '-disable-llvm-optzns' which I thought was the magical flag I wanted to get at the raw LLVM IR coming out of Clang deosn't do that. It still runs some passes over the IR. I don't want that, I really want the *raw* IR coming out of Clang and I strongly suspect everyone else using it is in the same camp. There is actually a flag that does what I want that I didn't know about called '-disable-llvm-passes'. I suspect many others don't know about it either. It both does what I want and is much simpler. This removes the confusing version and makes that spelling of the flag an alias for '-disable-llvm-passes'. I've also moved everything in Clang to use the 'passes' spelling as it seems both more accurate (*all* LLVM passes are disabled, not just optimizations) and much easier to remember and spell correctly. This is part of simplifying how Clang drives LLVM to make it cleaner to wire up to the new pass manager. Differential Revision: https://reviews.llvm.org/D28047 Modified: cfe/trunk/include/clang/Driver/CC1Options.td cfe/trunk/include/clang/Frontend/CodeGenOptions.def cfe/trunk/lib/CodeGen/BackendUtil.cpp cfe/trunk/lib/Driver/Tools.cpp cfe/trunk/lib/Frontend/CompilerInvocation.cpp cfe/trunk/test/CXX/drs/dr158.cpp cfe/trunk/test/CXX/temp/temp.spec/temp.explicit/p9-linkage.cpp cfe/trunk/test/CodeGen/always_inline.c cfe/trunk/test/CodeGen/attr-minsize.cpp cfe/trunk/test/CodeGen/bool_test.c cfe/trunk/test/CodeGen/builtin-expect.c cfe/trunk/test/CodeGen/builtin-unpredictable.c cfe/trunk/test/CodeGen/fixup-depth-overflow.c cfe/trunk/test/CodeGen/function-attributes.c cfe/trunk/test/CodeGen/inline.c cfe/trunk/test/CodeGen/may-alias.c cfe/trunk/test/CodeGen/tbaa-class.cpp cfe/trunk/test/CodeGen/tbaa-ms-abi.cpp cfe/trunk/test/CodeGen/tbaa.cpp cfe/trunk/test/CodeGenCXX/PR26569.cpp cfe/trunk/test/CodeGenCXX/ctor-dtor-alias.cpp cfe/trunk/test/CodeGenCXX/cxx1y-variable-template-linkage.cpp cfe/trunk/test/CodeGenCXX/destructors.cpp cfe/trunk/test/CodeGenCXX/dllexport.cpp cfe/trunk/test/CodeGenCXX/dllimport-rtti.cpp cfe/trunk/test/CodeGenCXX/dllimport.cpp cfe/trunk/test/CodeGenCXX/exceptions-seh.cpp cfe/trunk/test/CodeGenCXX/explicit-instantiation.cpp cfe/trunk/test/CodeGenCXX/inline-hint.cpp cfe/trunk/test/CodeGenCXX/invariant.group-for-vptrs.cpp cfe/trunk/test/CodeGenCXX/linkage.cpp cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-catch.cpp cfe/trunk/test/CodeGenCXX/microsoft-abi-eh-cleanups.cpp cfe/trunk/test/CodeGenCXX/microsoft-abi-extern-template.cpp cfe/trunk/test/CodeGenCXX/microsoft-abi-structors-alias.cpp cfe/trunk/test/CodeGenCXX/microsoft-abi-vftables.cpp cfe/trunk/test/CodeGenCXX/pr24097.cpp cfe/trunk/test/CodeGenCXX/sanitize-dtor-bit-field.cpp cfe/trunk/test/CodeGenCXX/sanitize-dtor-derived-class.cpp cfe/trunk/test/CodeGenCXX/sanitize-dtor-tail-call.cpp cfe/trunk/test/CodeGenCXX/sanitize-dtor-trivial.cpp cfe/trunk/test/CodeGenCXX/sanitize-dtor-vtable.cpp cfe/trunk/test/CodeGenCXX/stack-reuse-miscompile.cpp cfe/trunk/test/CodeGenCXX/strict-vtable-pointers.cpp cfe/trunk/test/CodeGenCXX/template-instantiation.cpp cfe/trunk/test/CodeGenCXX/thunks.cpp cfe/trunk/test/CodeGenCXX/virtual-destructor-calls.cpp cfe/trunk/test/CodeGenCXX/visibility-inlines-hidden.cpp cfe/trunk/test/CodeGenCXX/vtable-assume-load.cpp cfe/trunk/test/CodeGenCXX/vtable-available-externally.cpp cfe/trunk/test/CodeGenCXX/vtable-linkage.cpp cfe/trunk/test/CodeGenObjC/arc-blocks.m cfe/trunk/test/CodeGenObjC/arc-bridged-cast.m cfe/trunk/test/CodeGenObjC/arc-literals.m cfe/trunk/test/CodeGenObjC/arc-no-arc-exceptions.m cfe/trunk/test/CodeGenObjC/arc-precise-lifetime.m cfe/trunk/test/CodeGenObjC/arc-ternary-op.m cfe/trunk/test/CodeGenObjC/arc-unsafeclaim.m cfe/trunk/test/CodeGenObjC/arc.m cfe/trunk/test/CodeGenObjC/nsvalue-objc-boxable-ios-arc.m cfe/trunk/test/CodeGenObjC/nsvalue-objc-boxable-ios.m cfe/trunk/test/CodeGenObjC/nsvalue-objc-boxable-mac-arc.m cfe/trunk/test/CodeGenObjC/nsvalue-objc-boxable-mac.m cfe/trunk/test/CodeGenObjCXX/arc-globals.mm cfe/trunk/test/CodeGenObjCXX/arc-move.mm cfe/trunk/test/CodeGenObjCXX/arc-new-delete.mm cfe/trunk/test/CodeGenObjCXX/arc-references.mm cfe/trunk/test/CodeGenObjCXX/arc.mm cfe/trunk/test/CodeGenObjCXX/destroy.mm cfe/trunk/test/CodeGenObjCXX/literals.mm cfe/trunk/test/Driver/cc1-response-files.c cfe/trunk/test/Driver/cl-options.c cfe/trunk/test/Modules/cxx-irgen.cpp cfe/trunk/test/OpenMP/declare_reduction_codegen.c cfe/trunk/test/OpenMP/declare_reduction_codegen.cpp cfe/trunk/test/Profile/f
r290398 - Cleanup the handling of noinline function attributes, -fno-inline,
Author: chandlerc Date: Thu Dec 22 19:24:49 2016 New Revision: 290398 URL: http://llvm.org/viewvc/llvm-project?rev=290398&view=rev Log: Cleanup the handling of noinline function attributes, -fno-inline, -fno-inline-functions, -O0, and optnone. These were really, really tangled together: - We used the noinline LLVM attribute for -fno-inline - But not for -fno-inline-functions (breaking LTO) - But we did use it for -finline-hint-functions (yay, LTO is happy!) - But we didn't for -O0 (LTO is sad yet again...) - We had weird structuring of CodeGenOpts with both an inlining enumeration and a boolean. They interacted in weird ways and needlessly. - A *lot* of set smashing went on with setting these, and then got worse when we considered optnone and other inlining-effecting attributes. - A bunch of inline affecting attributes were managed in a completely different place from -fno-inline. - Even with -fno-inline we failed to put the LLVM noinline attribute onto many generated function definitions because they didn't show up as AST-level functions. - If you passed -O0 but -finline-functions we would run the normal inliner pass in LLVM despite it being in the O0 pipeline, which really doesn't make much sense. - Lastly, we used things like '-fno-inline' to manipulate the pass pipeline which forced the pass pipeline to be much more parameterizable than it really needs to be. Instead we can *just* use the optimization level to select a pipeline and control the rest via attributes. Sadly, this causes a bunch of churn in tests because we don't run the optimizer in the tests and check the contents of attribute sets. It would be awesome if attribute sets were a bit more FileCheck friendly, but oh well. I think this is a significant improvement and should remove the semantic need to change what inliner pass we run in order to comply with the requested inlining semantics by relying completely on attributes. It also cleans up tho optnone and related handling a bit. One unfortunate aspect of this is that for generating alwaysinline routines like those in OpenMP we end up removing noinline and then adding alwaysinline. I tried a bunch of other approaches, but because we recompute function attributes from scratch and don't have a declaration here I couldn't find anything substantially cleaner than this. Differential Revision: https://reviews.llvm.org/D28053 Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def cfe/trunk/include/clang/Frontend/CodeGenOptions.h cfe/trunk/lib/CodeGen/BackendUtil.cpp cfe/trunk/lib/CodeGen/CGOpenMPRuntime.cpp cfe/trunk/lib/CodeGen/CGOpenMPRuntimeNVPTX.cpp cfe/trunk/lib/CodeGen/CodeGenFunction.cpp cfe/trunk/lib/CodeGen/CodeGenModule.cpp cfe/trunk/lib/Frontend/CompilerInvocation.cpp cfe/trunk/test/CXX/special/class.dtor/p3-0x.cpp cfe/trunk/test/CodeGen/2008-04-08-NoExceptions.c cfe/trunk/test/CodeGen/address-safety-attr-kasan.cpp cfe/trunk/test/CodeGen/address-safety-attr.cpp cfe/trunk/test/CodeGen/address-space-field1.c cfe/trunk/test/CodeGen/alias.c cfe/trunk/test/CodeGen/attr-minsize.cpp cfe/trunk/test/CodeGen/attributes.c cfe/trunk/test/CodeGen/incomplete-function-type-2.c cfe/trunk/test/CodeGen/inline-optim.c cfe/trunk/test/CodeGen/mips16-attr.c cfe/trunk/test/CodeGen/mrtd.c cfe/trunk/test/CodeGen/ms-declspecs.c cfe/trunk/test/CodeGen/ppc64-complex-parms.c cfe/trunk/test/CodeGen/ppc64-complex-return.c cfe/trunk/test/CodeGen/ppc64-extend.c cfe/trunk/test/CodeGen/sanitize-thread-attr.cpp cfe/trunk/test/CodeGen/sanitize-thread-no-checking-at-run-time.m cfe/trunk/test/CodeGen/unwind-attr.c cfe/trunk/test/CodeGenCXX/attr.cpp cfe/trunk/test/CodeGenCXX/cxx11-exception-spec.cpp cfe/trunk/test/CodeGenCXX/cxx11-noreturn.cpp cfe/trunk/test/CodeGenCXX/derived-to-base.cpp cfe/trunk/test/CodeGenCXX/global-dtor-no-atexit.cpp cfe/trunk/test/CodeGenCXX/global-init.cpp cfe/trunk/test/CodeGenCXX/inline-hint.cpp cfe/trunk/test/CodeGenCXX/main-norecurse.cpp cfe/trunk/test/CodeGenCXX/microsoft-abi-array-cookies.cpp cfe/trunk/test/CodeGenCXX/no-exceptions.cpp cfe/trunk/test/CodeGenCXX/optnone-class-members.cpp cfe/trunk/test/CodeGenCXX/optnone-def-decl.cpp cfe/trunk/test/CodeGenCXX/reference-cast.cpp cfe/trunk/test/CodeGenCXX/threadsafe-statics.cpp cfe/trunk/test/CodeGenCXX/thunks.cpp cfe/trunk/test/CodeGenCXX/virtual-base-cast.cpp cfe/trunk/test/CodeGenObjC/gnu-exceptions.m cfe/trunk/test/CodeGenObjC/objc-literal-tests.m cfe/trunk/test/CodeGenObjCXX/lambda-expressions.mm cfe/trunk/test/CodeGenOpenCL/amdgpu-attrs.cl cfe/trunk/test/Driver/darwin-iphone-defaults.m cfe/trunk/test/PCH/objc_container.m Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=290398&r1=290397&r2=290398&v
r290417 - Add an assert to catch improperly constructed %diff sequences in
Author: chandlerc
Date: Thu Dec 22 23:19:47 2016
New Revision: 290417
URL: http://llvm.org/viewvc/llvm-project?rev=290417&view=rev
Log:
Add an assert to catch improperly constructed %diff sequences in
diagnostics and fix one such diagnostic.
Sadly, this assert doesn't catch this bug because we have no tests that
emit this diagnostic! Doh! I'm following up on the commit that
introduces it to get that fixed. Then this assert will help in a more
direct way.
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Basic/Diagnostic.cpp
Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=290417&r1=290416&r2=290417&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Dec 22 23:19:47
2016
@@ -3346,7 +3346,7 @@ def note_ovl_candidate_inconsistent_dedu
def note_ovl_candidate_inconsistent_deduction_types : Note<
"candidate template ignored: deduced values %diff{"
"of conflicting types for parameter %0 (%1 of type $ vs. %3 of type $)|"
-"%1 and %3 of conflicting types for parameter %0|}2,4">;
+"%1 and %3 of conflicting types for parameter %0}2,4">;
def note_ovl_candidate_explicit_arg_mismatch_named : Note<
"candidate template ignored: invalid explicitly-specified argument "
"for template parameter %0">;
Modified: cfe/trunk/lib/Basic/Diagnostic.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Diagnostic.cpp?rev=290417&r1=290416&r2=290417&view=diff
==
--- cfe/trunk/lib/Basic/Diagnostic.cpp (original)
+++ cfe/trunk/lib/Basic/Diagnostic.cpp Thu Dec 22 23:19:47 2016
@@ -742,7 +742,10 @@ FormatDiagnostic(const char *DiagStr, co
// "%diff{compare $ to $|other text}1,2"
// treat it as:
// "compare %1 to %2"
-const char *Pipe = ScanFormat(Argument, Argument + ArgumentLen, '|');
+const char *ArgumentEnd = Argument + ArgumentLen;
+const char *Pipe = ScanFormat(Argument, ArgumentEnd, '|');
+assert(ScanFormat(Pipe + 1, ArgumentEnd, '|') == ArgumentEnd &&
+ "Found too many '|'s in a %diff modifier!");
const char *FirstDollar = ScanFormat(Argument, Pipe, '$');
const char *SecondDollar = ScanFormat(FirstDollar + 1, Pipe, '$');
const char ArgStr1[] = { '%', static_cast('0' + ArgNo) };
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r290399 - When merging two deduced non-type template arguments for the same parameter,
On Thu, Dec 22, 2016 at 5:41 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Dec 22
> 19:30:39 2016
> @@ -3343,6 +3343,10 @@ def note_ovl_candidate_incomplete_deduct
> def note_ovl_candidate_inconsistent_deduction : Note<
> "candidate template ignored: deduced conflicting
> %select{types|values|"
> "templates}0 for parameter %1%diff{ ($ vs. $)|}2,3">;
> +def note_ovl_candidate_inconsistent_deduction_types : Note<
> +"candidate template ignored: deduced values %diff{"
> +"of conflicting types for parameter %0 (%1 of type $ vs. %3 of type
> $)|"
> +"%1 and %3 of conflicting types for parameter %0|}2,4">;
>
So, this new diagnostic isn't actually covered by any test. Not just is the
wording not covered, literally it isn't emitted. There is a bug in the
format that we didn't defend against -- having too many '|'s in the %diff
alternatives. I added an assert to try to catch this in r290417 and it
didn't trigger here because we never process this format.
Could you add a test covering this?
I went ahead and fixed the %diff format syntax by inspection in r290417.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r290399 - When merging two deduced non-type template arguments for the same parameter,
On Fri, Dec 23, 2016 at 12:32 AM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> On 22 Dec 2016 9:32 pm, "Chandler Carruth via cfe-commits" <
> cfe-commits@lists.llvm.org> wrote:
>
> On Thu, Dec 22, 2016 at 5:41 PM Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Thu Dec 22
> 19:30:39 2016
> @@ -3343,6 +3343,10 @@ def note_ovl_candidate_incomplete_deduct
> def note_ovl_candidate_inconsistent_deduction : Note<
> "candidate template ignored: deduced conflicting
> %select{types|values|"
> "templates}0 for parameter %1%diff{ ($ vs. $)|}2,3">;
> +def note_ovl_candidate_inconsistent_deduction_types : Note<
> +"candidate template ignored: deduced values %diff{"
> +"of conflicting types for parameter %0 (%1 of type $ vs. %3 of type
> $)|"
> +"%1 and %3 of conflicting types for parameter %0|}2,4">;
>
>
> So, this new diagnostic isn't actually covered by any test. Not just is
> the wording not covered, literally it isn't emitted. There is a bug in the
> format that we didn't defend against -- having too many '|'s in the %diff
> alternatives. I added an assert to try to catch this in r290417 and it
> didn't trigger here because we never process this format.
>
> Could you add a test covering this?
>
>
> Both tests changed in this commit produce this diagnostic. We don't have
> coverage for the tree-format diagnostic here, though; is that what you're
> referring to?
>
I mean, it is possible I messed something up, but i put a bunch of garbage
text into the message and all tests passed.
And I put an extra '|' into other messages with %diff and tests assert
failed. I don't think they were doing tree-format anything.
But the diagnostic I changed here passed even with my added assert
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r290450 - [PM] Introduce options to enable the (still experimental) new pass
Author: chandlerc Date: Fri Dec 23 14:44:01 2016 New Revision: 290450 URL: http://llvm.org/viewvc/llvm-project?rev=290450&view=rev Log: [PM] Introduce options to enable the (still experimental) new pass manager, and a code path to use it. The option is actually a top-level option but does contain 'experimental' in the name. This is the compromise suggested by Richard in discussions. We expect this option will be around long enough and have enough users towards the end that it merits not being relegated to CC1, but it still needs to be clear that this option will go away at some point. The backend code is a fresh codepath dedicated to handling the flow with the new pass manager. This was also Richard's suggested code structuring to essentially leave a clean path for development rather than carrying complexity or idiosyncracies of how we do things just to share code with the parts of this in common with the legacy pass manager. And it turns out, not much is really in common even though we use the legacy pass manager for codegen at this point. I've switched a couple of tests to run with the new pass manager, and they appear to work. There are still plenty of bugs that need squashing (just with basic experiments I've found two already!) but they aren't in this code, and the whole point is to expose the necessary hooks to start experimenting with the pass manager in more realistic scenarios. That said, I want to *strongly caution* anyone itching to play with this: it is still *very shaky*. Several large components have not yet been shaken down. For example I have bugs in both the always inliner and inliner that I have already spotted and will be fixing independently. Still, this is a fun milestone. =D One thing not in this patch (but that might be very reasonable to add) is some level of support for raw textual pass pipelines such as what Sean had a patch for some time ago. I'm mostly interested in the more traditional flow of getting the IR out of Clang and then running it through opt, but I can see other use cases so someone may want to add it. And of course, *many* features are not yet supported! - O1 is currently more like O2 - None of the sanitizers are wired up - ObjC ARC optimizer isn't wired up - ... So plenty of stuff still lef to do! Differential Revision: https://reviews.llvm.org/D28077 Modified: cfe/trunk/include/clang/Driver/Options.td cfe/trunk/include/clang/Frontend/CodeGenOptions.def cfe/trunk/lib/CodeGen/BackendUtil.cpp cfe/trunk/lib/Driver/Tools.cpp cfe/trunk/lib/Frontend/CompilerInvocation.cpp cfe/trunk/test/CodeGen/arm64_crypto.c cfe/trunk/test/CodeGen/inline-optim.c cfe/trunk/test/Driver/clang_f_opts.c Modified: cfe/trunk/include/clang/Driver/Options.td URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=290450&r1=290449&r2=290450&view=diff == --- cfe/trunk/include/clang/Driver/Options.td (original) +++ cfe/trunk/include/clang/Driver/Options.td Fri Dec 23 14:44:01 2016 @@ -823,6 +823,9 @@ def finline_functions : Flag<["-"], "fin def finline_hint_functions: Flag<["-"], "finline-hint-functions">, Group, Flags<[CC1Option]>, HelpText<"Inline functions wich are (explicitly or implicitly) marked inline">; def finline : Flag<["-"], "finline">, Group; +def fexperimental_new_pass_manager : Flag<["-"], "fexperimental-new-pass-manager">, + Group, Flags<[CC1Option]>, + HelpText<"Enables an experimental new pass manager in LLVM.">; def finput_charset_EQ : Joined<["-"], "finput-charset=">, Group; def fexec_charset_EQ : Joined<["-"], "fexec-charset=">, Group; def finstrument_functions : Flag<["-"], "finstrument-functions">, Group, Flags<[CC1Option]>, @@ -1000,6 +1003,9 @@ def fno_exceptions : Flag<["-"], "fno-ex def fno_gnu_keywords : Flag<["-"], "fno-gnu-keywords">, Group, Flags<[CC1Option]>; def fno_inline_functions : Flag<["-"], "fno-inline-functions">, Group, Flags<[CC1Option]>; def fno_inline : Flag<["-"], "fno-inline">, Group, Flags<[CC1Option]>; +def fno_experimental_new_pass_manager : Flag<["-"], "fno-experimental-new-pass-manager">, + Group, Flags<[CC1Option]>, + HelpText<"Disables an experimental new pass manager in LLVM.">; def fveclib : Joined<["-"], "fveclib=">, Group, Flags<[CC1Option]>, HelpText<"Use the given vector functions library">; def fno_lax_vector_conversions : Flag<["-"], "fno-lax-vector-conversions">, Group, Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=290450&r1=290449&r2=290450&view=diff == --- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original) +++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Fri Dec 23 14:44:01 2016 @@ -52,6 +52,8 @@ CODEGENOPT(DisableGCov , 1, 0) /// CODEGENOPT(D
r290451 - [PM] Fix up from r290449 to start requiring the x86 target to be
Author: chandlerc Date: Fri Dec 23 15:19:16 2016 New Revision: 290451 URL: http://llvm.org/viewvc/llvm-project?rev=290451&view=rev Log: [PM] Fix up from r290449 to start requiring the x86 target to be available. It doesn't seem terribly important to test this with a specific target triple but without that target available. Modified: cfe/trunk/test/CodeGen/inline-optim.c Modified: cfe/trunk/test/CodeGen/inline-optim.c URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/inline-optim.c?rev=290451&r1=290450&r2=290451&view=diff == --- cfe/trunk/test/CodeGen/inline-optim.c (original) +++ cfe/trunk/test/CodeGen/inline-optim.c Fri Dec 23 15:19:16 2016 @@ -1,5 +1,7 @@ // Make sure -finline-functions family flags are behaving correctly. - +// +// REQUIRES: x86-registered-target +// // RUN: %clang_cc1 -triple i686-pc-win32 -emit-llvm %s -o - | FileCheck -check-prefix=NOINLINE %s // RUN: %clang_cc1 -triple i686-pc-win32 -fexperimental-new-pass-manager -emit-llvm %s -o - | FileCheck -check-prefix=NOINLINE %s // RUN: %clang_cc1 -triple i686-pc-win32 -O3 -fno-inline-functions -emit-llvm %s -o - | FileCheck -check-prefix=NOINLINE %s ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r290558 - [PH] Teach the new PM code path to support -disable-llvm-passes.
Author: chandlerc
Date: Mon Dec 26 18:13:09 2016
New Revision: 290558
URL: http://llvm.org/viewvc/llvm-project?rev=290558&view=rev
Log:
[PH] Teach the new PM code path to support -disable-llvm-passes.
This is kind of funny because I specifically did work to make this easy
and then it didn't actually get implemented.
I've also ported a set of tests that rely on this functionality to run
with the new PM as well as the old PM so that we don't mess this up in
the future.
Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/CodeGen/inline.c
Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=290558&r1=290557&r2=290558&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Dec 26 18:13:09 2016
@@ -780,17 +780,20 @@ void EmitAssemblyHelper::EmitAssemblyWit
PB.crossRegisterProxies(LAM, FAM, CGAM, MAM);
ModulePassManager MPM;
- if (CodeGenOpts.OptimizationLevel == 0) {
-// Build a minimal pipeline based on the semantics required by Clang, which
-// is just that always inlining occurs.
-MPM.addPass(AlwaysInlinerPass());
- } else {
-// Otherwise, use the default pass pipeline. We also have to map our
-// optimization levels into one of the distinct levels used to configure
-// the pipeline.
-PassBuilder::OptimizationLevel Level = mapToLevel(CodeGenOpts);
-MPM = PB.buildPerModuleDefaultPipeline(Level);
+ if (!CodeGenOpts.DisableLLVMPasses) {
+if (CodeGenOpts.OptimizationLevel == 0) {
+ // Build a minimal pipeline based on the semantics required by Clang,
+ // which is just that always inlining occurs.
+ MPM.addPass(AlwaysInlinerPass());
+} else {
+ // Otherwise, use the default pass pipeline. We also have to map our
+ // optimization levels into one of the distinct levels used to configure
+ // the pipeline.
+ PassBuilder::OptimizationLevel Level = mapToLevel(CodeGenOpts);
+
+ MPM = PB.buildPerModuleDefaultPipeline(Level);
+}
}
// FIXME: We still use the legacy pass manager to do code generation. We
Modified: cfe/trunk/test/CodeGen/inline.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/inline.c?rev=290558&r1=290557&r2=290558&view=diff
==
--- cfe/trunk/test/CodeGen/inline.c (original)
+++ cfe/trunk/test/CodeGen/inline.c Mon Dec 26 18:13:09 2016
@@ -1,5 +1,6 @@
// RUN: echo "GNU89 tests:"
// RUN: %clang_cc1 %s -triple i386-unknown-unknown -O1 -disable-llvm-passes
-emit-llvm -o - -std=gnu89 | FileCheck %s --check-prefix=CHECK1
+// RUN: %clang_cc1 %s -triple i386-unknown-unknown
-fexperimental-new-pass-manager -O1 -disable-llvm-passes -emit-llvm -o -
-std=gnu89 | FileCheck %s --check-prefix=CHECK1
// CHECK1-LABEL: define i32 @foo()
// CHECK1-LABEL: define i32 @bar()
// CHECK1-LABEL: define void @unreferenced1()
@@ -22,6 +23,7 @@
// RUN: echo "C99 tests:"
// RUN: %clang_cc1 %s -triple i386-unknown-unknown -O1 -disable-llvm-passes
-emit-llvm -o - -std=gnu99 | FileCheck %s --check-prefix=CHECK2
+// RUN: %clang_cc1 %s -triple i386-unknown-unknown
-fexperimental-new-pass-manager -O1 -disable-llvm-passes -emit-llvm -o -
-std=gnu99 | FileCheck %s --check-prefix=CHECK2
// CHECK2-LABEL: define i32 @ei()
// CHECK2-LABEL: define i32 @bar()
// CHECK2-NOT: unreferenced1
@@ -44,6 +46,7 @@
// RUN: echo "C++ tests:"
// RUN: %clang_cc1 -x c++ %s -triple i386-unknown-unknown -O1
-disable-llvm-passes -emit-llvm -o - -std=c++98 | FileCheck %s
--check-prefix=CHECK3
+// RUN: %clang_cc1 -x c++ %s -triple i386-unknown-unknown
-fexperimental-new-pass-manager -O1 -disable-llvm-passes -emit-llvm -o -
-std=c++98 | FileCheck %s --check-prefix=CHECK3
// CHECK3-LABEL: define i32 @_Z3barv()
// CHECK3-LABEL: define linkonce_odr i32 @_Z3foov()
// CHECK3-NOT: unreferenced
@@ -54,6 +57,7 @@
// RUN: echo "MS C Mode tests:"
// RUN: %clang_cc1 %s -triple i386-pc-win32 -O1 -disable-llvm-passes
-emit-llvm -o - -std=c99 | FileCheck %s --check-prefix=CHECK4
+// RUN: %clang_cc1 %s -triple i386-pc-win32 -fexperimental-new-pass-manager
-O1 -disable-llvm-passes -emit-llvm -o - -std=c99 | FileCheck %s
--check-prefix=CHECK4
// CHECK4-NOT: define weak_odr void @_Exit(
// CHECK4-LABEL: define weak_odr i32 @ei()
// CHECK4-LABEL: define i32 @bar()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r290560 - [PM] The new pass manager requires a registered target for these, and
Author: chandlerc Date: Mon Dec 26 18:31:34 2016 New Revision: 290560 URL: http://llvm.org/viewvc/llvm-project?rev=290560&view=rev Log: [PM] The new pass manager requires a registered target for these, and given that they hard code specific triples that seems reasonable so add the REQUIRES. Modified: cfe/trunk/test/CodeGen/inline.c Modified: cfe/trunk/test/CodeGen/inline.c URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/inline.c?rev=290560&r1=290559&r2=290560&view=diff == --- cfe/trunk/test/CodeGen/inline.c (original) +++ cfe/trunk/test/CodeGen/inline.c Mon Dec 26 18:31:34 2016 @@ -1,3 +1,5 @@ +// REQUIRES: x86-registered-target +// // RUN: echo "GNU89 tests:" // RUN: %clang_cc1 %s -triple i386-unknown-unknown -O1 -disable-llvm-passes -emit-llvm -o - -std=gnu89 | FileCheck %s --check-prefix=CHECK1 // RUN: %clang_cc1 %s -triple i386-unknown-unknown -fexperimental-new-pass-manager -O1 -disable-llvm-passes -emit-llvm -o - -std=gnu89 | FileCheck %s --check-prefix=CHECK1 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r290593 - DR1495: A partial specialization is ill-formed if it is not (strictly) more
I suspect that this commit is responsible for a regression parsing widely
used open source packages like Eigen.
See the code in Eigen here:
https://bitbucket.org/eigen/eigen/src/e46c8246b284dea1690ac260dfe50851906138f0/unsupported/Eigen/CXX11/src/Tensor/TensorStorage.h?at=default&fileviewer=file-view-default#TensorStorage.h-38
I'm not claiming this code is correct, but I'm worried about how much code
out there looks like this... Thoughts? Could we at least temporarily put
this DR fix behind a flag or make it a warning?
On Tue, Dec 27, 2016 at 12:07 AM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Tue Dec 27 01:56:27 2016
> New Revision: 290593
>
> URL: http://llvm.org/viewvc/llvm-project?rev=290593&view=rev
> Log:
> DR1495: A partial specialization is ill-formed if it is not (strictly) more
> specialized than the primary template. (Put another way, if we imagine
> there
> were a partial specialization matching the primary template, we should
> never
> select it if some other partial specialization also matches.)
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Sema/Sema.h
> cfe/trunk/include/clang/Sema/TemplateDeduction.h
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiate.cpp
> cfe/trunk/test/CXX/drs/dr14xx.cpp
> cfe/trunk/test/CXX/temp/temp.decls/temp.variadic/fixed-expansion.cpp
> cfe/trunk/test/SemaTemplate/class-template-spec.cpp
> cfe/trunk/test/SemaTemplate/temp_arg_nontype.cpp
> cfe/trunk/www/cxx_dr_status.html
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=290593&r1=290592&r2=290593&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Tue Dec 27
> 01:56:27 2016
> @@ -4043,6 +4043,10 @@ def err_partial_spec_args_match_primary_
> "%select{class|variable}0 template partial specialization does not "
> "specialize any template argument; to %select{declare|define}1 the "
> "primary template, remove the template argument list">;
> +def err_partial_spec_not_more_specialized_than_primary : Error<
> +"%select{class|variable}0 template partial specialization is not "
> +"more specialized than the primary template">;
> +def note_partial_spec_not_more_specialized_than_primary : Note<"%0">;
> def warn_partial_specs_not_deducible : Warning<
> "%select{class|variable}0 template partial specialization contains "
> "%select{a template parameter|template parameters}1 that cannot be "
> @@ -4147,7 +4151,7 @@ def note_function_template_deduction_ins
>"%1">;
> def note_deduced_template_arg_substitution_here : Note<
>"during template argument deduction for %select{class|variable}0
> template "
> - "partial specialization %1 %2">;
> + "%select{partial specialization |}1%2 %3">;
> def note_prior_template_arg_substitution : Note<
>"while substituting prior template arguments into
> %select{non-type|template}0"
>" template parameter%1 %2">;
>
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=290593&r1=290592&r2=290593&view=diff
>
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Tue Dec 27 01:56:27 2016
> @@ -6697,10 +6697,16 @@ public:
>ClassTemplatePartialSpecializationDecl
> *PS2,
>SourceLocation Loc);
>
> + bool
> isMoreSpecializedThanPrimary(ClassTemplatePartialSpecializationDecl *T,
> +sema::TemplateDeductionInfo &Info);
> +
>VarTemplatePartialSpecializationDecl
> *getMoreSpecializedPartialSpecialization(
>VarTemplatePartialSpecializationDecl *PS1,
>VarTemplatePartialSpecializationDecl *PS2, SourceLocation Loc);
>
> + bool isMoreSpecializedThanPrimary(VarTemplatePartialSpecializationDecl
> *T,
> +sema::TemplateDeductionInfo &Info);
> +
>void MarkUsedTemplateParameters(const TemplateArgumentList
> &TemplateArgs,
>bool OnlyDeduced,
>unsigned Depth,
> @@ -6752,7 +6758,7 @@ public:
>/// template argument deduction for either a class template
>/// partial specialization or a function template. The
>/// Entity is either a {Class|Var}TemplatePartialSpecializationDecl
> or
> - /// a FunctionTemplateDecl.
> + /// a TemplateDecl.
>DeducedTemplateArgumentSubstitution,
>
>/// We are sub
Re: r290539 - [inline-asm]No error for conflict between inputs\outputs and clobber list
On Mon, Dec 26, 2016 at 4:34 AM Marina Yatsina via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: myatsina
> Date: Mon Dec 26 06:23:42 2016
> New Revision: 290539
>
> URL: http://llvm.org/viewvc/llvm-project?rev=290539&view=rev
> Log:
> [inline-asm]No error for conflict between inputs\outputs and clobber list
>
> According to extended asm syntax, a case where the clobber list includes a
> variable from the inputs or outputs should be an error - conflict.
> for example:
>
> const long double a = 0.0;
> int main()
> {
>
> char b;
> double t1 = a;
> __asm__ ("fucompp": "=a" (b) : "u" (t1), "t" (t1) : "cc", "st", "st(1)");
>
> return 0;
> }
>
> This should conflict with the output - t1 which is st, and st which is st
> aswell.
> The patch fixes it.
> Commit on behald of Ziv Izhar.
>
> Differential Revision: https://reviews.llvm.org/D15075
>
>
> Modified:
> cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> cfe/trunk/include/clang/Basic/TargetInfo.h
> cfe/trunk/lib/Basic/TargetInfo.cpp
> cfe/trunk/lib/Basic/Targets.cpp
> cfe/trunk/lib/Headers/intrin.h
> cfe/trunk/lib/Sema/SemaStmtAsm.cpp
> cfe/trunk/test/Sema/asm.c
>
> Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=290539&r1=290538&r2=290539&view=diff
>
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Dec 26
> 06:23:42 2016
> @@ -7069,6 +7069,10 @@ let CategoryName = "Inline Assembly Issu
> "constraint '%0' is already present here">;
> }
>
> + def error_inoutput_conflict_with_clobber : Error<
> +"asm-specifier for input or output variable conflicts with asm"
> +" clobber list">;
>
Clang generally works to avoid this kind of error message. All this does is
say "there was a problem of this kind" without identifying any of the
specifics. And for this error in particular I think this is of the utmost
importance. Developers are not going to understand what went wrong here.
I would suggest at a minimum to enhance this to explain:
1) What operands and clobbers conflict, preferably with source ranges
underlining them.
2) Why they conflict (for example the fact that "D" means the di register
group, of which "%rdi" is a member)
Beyond that, I wonder if you could add a note suggesting to remove the
clobber if the input (or output) operand is sufficient.
You can make this note explain carefully the case where something would
need to be added to the inputs or outputs instead, but I think it at least
makes sense to clarify that this will be a common fix and what to look out
for that might make it an incorrect fix.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r291036 - [gtest] The way EXPECT_TEST now works after upgrading gtest triggers an
Author: chandlerc
Date: Wed Jan 4 17:57:25 2017
New Revision: 291036
URL: http://llvm.org/viewvc/llvm-project?rev=291036&view=rev
Log:
[gtest] The way EXPECT_TEST now works after upgrading gtest triggers an
ODR use. These traits don't have a definition as they're intended to be
used strictly at compile time. Change the tests to use static_assert to
move the entire thing into compile-time.
Modified:
cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
Modified: cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp?rev=291036&r1=291035&r2=291036&view=diff
==
--- cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp (original)
+++ cfe/trunk/unittests/ASTMatchers/ASTMatchersTraversalTest.cpp Wed Jan 4
17:57:25 2017
@@ -222,9 +222,12 @@ TEST(HasDeclaration, HasDeclarationOfEnu
}
TEST(HasDeclaration, HasGetDeclTraitTest) {
- EXPECT_TRUE(internal::has_getDecl::value);
- EXPECT_TRUE(internal::has_getDecl::value);
- EXPECT_FALSE(internal::has_getDecl::value);
+ static_assert(internal::has_getDecl::value,
+"Expected TypedefType to have a getDecl.");
+ static_assert(internal::has_getDecl::value,
+"Expected RecordType to have a getDecl.");
+ static_assert(!internal::has_getDecl::value,
+"Expected TemplateSpecializationType to *not* have a
getDecl.");
}
TEST(HasDeclaration, HasDeclarationOfTypeWithDecl) {
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r290450 - [PM] Introduce options to enable the (still experimental) new pass
(explicitly adding Richard so he sees this discussion as some of this involves a discussion between myself and him) On Tue, Jan 10, 2017 at 4:36 PM Justin Bogner via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Chandler Carruth via cfe-commits writes: > > Author: chandlerc > > Date: Fri Dec 23 14:44:01 2016 > > New Revision: 290450 > > > > URL: http://llvm.org/viewvc/llvm-project?rev=290450&view=rev > > Log: > > [PM] Introduce options to enable the (still experimental) new pass > > manager, and a code path to use it. > > > > The option is actually a top-level option but does contain > > 'experimental' in the name. This is the compromise suggested by Richard > > in discussions. We expect this option will be around long enough and > > have enough users towards the end that it merits not being relegated to > > CC1, but it still needs to be clear that this option will go away at > > some point. > > I don't really understand why this is a driver option and not just a CC1 > option. Using a driver flag makes me think we expect people to be using > this in production before we make the new PM the default, which seems > kind of questionable to me, I tried to explain the thinking here, but sorry if it wasn't clear. And maybe its just the wrong tradeoff. My thought process is this: until we get users of Clang and LLVM using the new PM in production, I think it's going to be between hard and impossible to make it the default. So I've been trying to make sure we have a healthy state for asking users to enable this including in production. Speaking just for myself as a user, I will need to enable this in production prior to it being the default. > and I don't see how adding a new > "-fexperimental" is any better than just using the "-Xclang" that people > are already familiar with the implications of. > The "experimental" thing was not really intended to be anything like the CC1 interface. It communicates two things IMO: that the functionality is less mature at this point, and that there will (eventually) be changes. I would still expect us to go through a very slow process to remove this flag, the same as I would expect for any other driver-level flag. To give an idea of the kind of timeframe I'm trying to prepare for (although it being faster would of course be a pleasant surprise): I suspect we will need there to be an open source release with the functionality finished and reasonably well tested but still not the default. And in that release we'll want to in the release notes advertise that this is coming and that the next release will flip the default. And then I think we'll need to do *another* release where the old pass manager is still around, but is not the default. Maybe things will go substantially better/faster than I've described, but I'm trying to have a plan that is viable even if things move that slowly. Anyways, if the decision is to go back to a CC1 flag, we can do that. I just really want to avoid that if possible as I'd like to avoid deploying a CC1 flag to my users (we work actively to avoid doing this where possible). -Chandler ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r278897 - [PM] Update Clang for LLVM's r278896 which re-organized a header.
Author: chandlerc Date: Tue Aug 16 22:09:11 2016 New Revision: 278897 URL: http://llvm.org/viewvc/llvm-project?rev=278897&view=rev Log: [PM] Update Clang for LLVM's r278896 which re-organized a header. (sorry this didn't get landed closer in time...) 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=278897&r1=278896&r2=278897&view=diff == --- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original) +++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Tue Aug 16 22:09:11 2016 @@ -42,6 +42,7 @@ #include "llvm/Target/TargetOptions.h" #include "llvm/Target/TargetSubtargetInfo.h" #include "llvm/Transforms/IPO.h" +#include "llvm/Transforms/IPO/AlwaysInliner.h" #include "llvm/Transforms/IPO/PassManagerBuilder.h" #include "llvm/Transforms/Instrumentation.h" #include "llvm/Transforms/ObjCARC.h" @@ -318,9 +319,9 @@ void EmitAssemblyHelper::CreatePasses(le // Respect always_inline. if (OptLevel == 0) // Do not insert lifetime intrinsics at -O0. - PMBuilder.Inliner = createAlwaysInlinerPass(false); + PMBuilder.Inliner = createAlwaysInlinerLegacyPass(false); else - PMBuilder.Inliner = createAlwaysInlinerPass(); + PMBuilder.Inliner = createAlwaysInlinerLegacyPass(); break; } ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
Re: r278882 - If possible, set the stack rlimit to at least 8MiB on cc1 startup, and work
I feel like this thread has two very unrelated concerns and it might be useful to separate them. 1) Should an application be changing the stack limit, or should the system be able to enforce this? Fortunately, there are two limits. One an application is allowed to change, one it isn't. It seems like the mechanism has been provided for system administrators to impose firm limits and neither Clang nor another application will perturb them. I don't see any reason to preclude an application from changing the one it is explicitly permitted to change. That seems to be WAI from a permissions and ACL model. 2) Should Clang be using the stack to allocate significant portions of its memory, or should it be assiduously keeping allocations on the heap and removing recursive algorithms? I actually think this is the crux of the issue, and #1 is largely coming up as a proxy for "Clang should use less stack space". However, I'll point out that this commit does not change how much stack space Clang uses. It just changes the nature of errors that occur to make the experience of today's Clang more friendly for users. So this commit seems like a fine thing even if we decide that Clang should work to lower this number over time and reduce what it sets it to. In fact, if you want to reduce Clang's stack usage, you almost certainly want it to explicitly set a limit so that we consistently hit errors when bugs creep into Clang. Past that, while I think Clang's current allocation and recursion pattern is fine, I don't actually have a terribly strong opinion. But it seems odd to suddenly want to make a dramatic change in the design of Clang now... It doesn't seem like this was an accidental or unconsidered design decision. On Fri, Aug 19, 2016 at 4:33 PM Joerg Sonnenberger via cfe-commits < cfe-commits@lists.llvm.org> wrote: > On Fri, Aug 19, 2016 at 03:30:42PM -0700, Richard Smith wrote: > > It typically does; the default stack ulimit is likely tuned for "normal" > > applications that are not expected (by an ISO standard) to cope with > > recursing a thousand levels deep. If the system administrator really > wants > > to control the stack space for some stupid reason, they can set a hard > > ulimit. If people actually do that, and then file bugs on clang crashing > > (which they do today), we may want to resort to spawning a separate > thread > > with a higher ulimit if we detect the problem. > > Thread stacks by default are even smaller and for good reason. > Especially on 32bit platforms, it would be unusable otherwise. To put > this into perspective: if you need to support a recursion level of 1000 > and can't do that with a 4MB stack, it means you are using more than 4KB > per recursion level. That's a very high stack use and certainly > something that qualifies as the kind of abusive behavior the process > limit is designed for in first place. > > > It *is* unreasonable to expect them to fiddle with stack ulimits to get > the > > compiler to accept programs that, say, use certain components of boost > (and > > fit within the standard's recommended limits). > > I fundamentally disagree with this statement. Effectively, this seems to > me to be papering over excessive stack use and nothing else. > > Joerg > ___ > cfe-commits mailing list > cfe-commits@lists.llvm.org > http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits > ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r279500 - Revert r279486 "Fix regression introduced by r279164"
Author: chandlerc
Date: Mon Aug 22 21:00:51 2016
New Revision: 279500
URL: http://llvm.org/viewvc/llvm-project?rev=279500&view=rev
Log:
Revert r279486 "Fix regression introduced by r279164"
Build bots seem unhappy and as Richard was leaving he asked me to revert
this for him. Doing so.
Modified:
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaTemplate.cpp
cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
cfe/trunk/lib/Sema/SemaType.cpp
cfe/trunk/test/Modules/Inputs/merge-template-pattern-visibility/a.h
cfe/trunk/test/Modules/Inputs/merge-template-pattern-visibility/b.h
cfe/trunk/test/Modules/merge-template-pattern-visibility.cpp
Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=279500&r1=279499&r2=279500&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Mon Aug 22 21:00:51 2016
@@ -11274,8 +11274,9 @@ Sema::CheckForFunctionRedefinition(Funct
SkipBody->ShouldSkip = true;
if (auto *TD = Definition->getDescribedFunctionTemplate())
makeMergedDefinitionVisible(TD, FD->getLocation());
-makeMergedDefinitionVisible(const_cast(Definition),
-FD->getLocation());
+else
+ makeMergedDefinitionVisible(const_cast(Definition),
+ FD->getLocation());
return;
}
Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=279500&r1=279499&r2=279500&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplate.cpp Mon Aug 22 21:00:51 2016
@@ -487,6 +487,8 @@ bool Sema::DiagnoseUninstantiableTemplat
QualType InstantiationTy;
if (TagDecl *TD = dyn_cast(Instantiation))
InstantiationTy = Context.getTypeDeclType(TD);
+ else
+InstantiationTy = cast(Instantiation)->getType();
if (!Complain || (PatternDef && PatternDef->isInvalidDecl())) {
// Say nothing
} else if (PatternDef) {
@@ -498,30 +500,15 @@ bool Sema::DiagnoseUninstantiableTemplat
// we're lexically inside it.
Instantiation->setInvalidDecl();
} else if (InstantiatedFromMember) {
-if (isa(Instantiation)) {
- Diag(PointOfInstantiation,
- diag::err_explicit_instantiation_undefined_member)
-<< 1 << Instantiation->getDeclName() <<
Instantiation->getDeclContext();
-} else {
- Diag(PointOfInstantiation,
- diag::err_implicit_instantiate_member_undefined)
-<< InstantiationTy;
-}
-Diag(Pattern->getLocation(), isa(Instantiation)
- ? diag::note_explicit_instantiation_here
- : diag::note_member_declared_at);
+Diag(PointOfInstantiation,
+ diag::err_implicit_instantiate_member_undefined)
+ << InstantiationTy;
+Diag(Pattern->getLocation(), diag::note_member_declared_at);
} else {
-if (isa(Instantiation))
- Diag(PointOfInstantiation,
- diag::err_explicit_instantiation_undefined_func_template)
-<< Pattern;
-else
- Diag(PointOfInstantiation, diag::err_template_instantiate_undefined)
-<< (TSK != TSK_ImplicitInstantiation)
-<< InstantiationTy;
-Diag(Pattern->getLocation(), isa(Instantiation)
- ? diag::note_explicit_instantiation_here
- : diag::note_template_decl_here);
+Diag(PointOfInstantiation, diag::err_template_instantiate_undefined)
+ << (TSK != TSK_ImplicitInstantiation)
+ << InstantiationTy;
+Diag(Pattern->getLocation(), diag::note_template_decl_here);
}
// In general, Instantiation isn't marked invalid to get more than one
Modified: cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp?rev=279500&r1=279499&r2=279500&view=diff
==
--- cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp Mon Aug 22 21:00:51 2016
@@ -3554,38 +3554,23 @@ void Sema::InstantiateFunctionDefinition
const FunctionDecl *PatternDecl =
Function->getTemplateInstantiationPattern();
assert(PatternDecl && "instantiating a non-template");
- const FunctionDecl *PatternDef = PatternDecl->getDefinition();
- Stmt *Pattern = PatternDef->getBody(PatternDef);
- if (PatternDef)
-PatternDecl = PatternDef;
+ Stmt *Pattern = PatternDecl->getBody(PatternDecl);
+ assert(PatternDecl && "template definition is not a template");
+ if (!Pattern) {
+// Try to find a defaulted definition
+PatternDecl->isDefined(PatternDecl);
+ }
+
Re: r279486 - Fix regression introduced by r279164: only pass definitions as the PatternDef
Reverted this per Richard's request in r279500.
On Mon, Aug 22, 2016 at 3:33 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:
> Author: rsmith
> Date: Mon Aug 22 17:25:03 2016
> New Revision: 279486
>
> URL: http://llvm.org/viewvc/llvm-project?rev=279486&view=rev
> Log:
> Fix regression introduced by r279164: only pass definitions as the
> PatternDef
> to DiagnoseUninstantiableTemplate, teach hasVisibleDefinition to correctly
> determine whether a function definition is visible, and mark both the
> function
> and the template as visible when merging function template definitions to
> provide hasVisibleDefinition with the relevant information.
>
> The change to always pass the right declaration as the PatternDef to
> DiagnoseUninstantiableTemplate also caused those checks to happen before
> other
> diagnostics in InstantiateFunctionDefinition, giving worse diagnostics for
> the
> same situations, so I sunk the relevant diagnostics into
> DiagnoseUninstantiableTemplate. Those parts of this patch are based on
> changes
> in reviews.llvm.org/D23492 by Vassil Vassilev.
>
> Modified:
> cfe/trunk/lib/Sema/SemaDecl.cpp
> cfe/trunk/lib/Sema/SemaTemplate.cpp
> cfe/trunk/lib/Sema/SemaTemplateInstantiateDecl.cpp
> cfe/trunk/lib/Sema/SemaType.cpp
> cfe/trunk/test/Modules/Inputs/merge-template-pattern-visibility/a.h
> cfe/trunk/test/Modules/Inputs/merge-template-pattern-visibility/b.h
> cfe/trunk/test/Modules/merge-template-pattern-visibility.cpp
>
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=279486&r1=279485&r2=279486&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Mon Aug 22 17:25:03 2016
> @@ -11274,9 +11274,8 @@ Sema::CheckForFunctionRedefinition(Funct
> SkipBody->ShouldSkip = true;
> if (auto *TD = Definition->getDescribedFunctionTemplate())
>makeMergedDefinitionVisible(TD, FD->getLocation());
> -else
> - makeMergedDefinitionVisible(const_cast(Definition),
> - FD->getLocation());
> +makeMergedDefinitionVisible(const_cast(Definition),
> +FD->getLocation());
> return;
>}
>
>
> Modified: cfe/trunk/lib/Sema/SemaTemplate.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaTemplate.cpp?rev=279486&r1=279485&r2=279486&view=diff
>
> ==
> --- cfe/trunk/lib/Sema/SemaTemplate.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaTemplate.cpp Mon Aug 22 17:25:03 2016
> @@ -487,8 +487,6 @@ bool Sema::DiagnoseUninstantiableTemplat
>QualType InstantiationTy;
>if (TagDecl *TD = dyn_cast(Instantiation))
> InstantiationTy = Context.getTypeDeclType(TD);
> - else
> -InstantiationTy = cast(Instantiation)->getType();
>if (!Complain || (PatternDef && PatternDef->isInvalidDecl())) {
> // Say nothing
>} else if (PatternDef) {
> @@ -500,15 +498,30 @@ bool Sema::DiagnoseUninstantiableTemplat
> // we're lexically inside it.
> Instantiation->setInvalidDecl();
>} else if (InstantiatedFromMember) {
> -Diag(PointOfInstantiation,
> - diag::err_implicit_instantiate_member_undefined)
> - << InstantiationTy;
> -Diag(Pattern->getLocation(), diag::note_member_declared_at);
> +if (isa(Instantiation)) {
> + Diag(PointOfInstantiation,
> + diag::err_explicit_instantiation_undefined_member)
> +<< 1 << Instantiation->getDeclName() <<
> Instantiation->getDeclContext();
> +} else {
> + Diag(PointOfInstantiation,
> + diag::err_implicit_instantiate_member_undefined)
> +<< InstantiationTy;
> +}
> +Diag(Pattern->getLocation(), isa(Instantiation)
> + ?
> diag::note_explicit_instantiation_here
> + : diag::note_member_declared_at);
>} else {
> -Diag(PointOfInstantiation, diag::err_template_instantiate_undefined)
> - << (TSK != TSK_ImplicitInstantiation)
> - << InstantiationTy;
> -Diag(Pattern->getLocation(), diag::note_template_decl_here);
> +if (isa(Instantiation))
> + Diag(PointOfInstantiation,
> + diag::err_explicit_instantiation_undefined_func_template)
> +<< Pattern;
> +else
> + Diag(PointOfInstantiation, diag::err_template_instantiate_undefined)
> +<< (TSK != TSK_ImplicitInstantiation)
> +<< InstantiationTy;
> +Diag(Pattern->getLocation(), isa(Instantiation)
> + ?
> diag::note_explicit_instantiation_here
> + : diag::note_template_decl_here);
>}
>
>// In general, Instantiation isn't marked invalid to get more than one
>
> Modified: cfe/trunk/lib/Sema/SemaTemplateInst
Re: [clang-tools-extra] r281453 - [clang-tidy] Add check 'misc-use-after-move'
On Wed, Sep 14, 2016 at 3:38 AM Martin Bohme via cfe-commits < cfe-commits@lists.llvm.org> wrote: > Author: mboehme > Date: Wed Sep 14 05:29:32 2016 > New Revision: 281453 > > URL: http://llvm.org/viewvc/llvm-project?rev=281453&view=rev > Log: > [clang-tidy] Add check 'misc-use-after-move' > > Summary: > The check warns if an object is used after it has been moved, without an > intervening reinitialization. > While I'm excited to see this go in anywhere, I have to say I'm a bit sad it isn't going in as a warning and instead inside clang-tidy. This has been a much requested warning from Clang for many years. Is there a concise description of why this design was chosen? Are there specific problems that make it infeasible to be a warnings? Is there maybe a plan to move it to a warning after some set of issues are addressed? > > See user-facing documentation for details. > In general, I suspect at least some more context should be provided in change descriptions. =] ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
[clang-tools-extra] r298434 - Don't make unqualified calls to functions that could well be found via
Author: chandlerc Date: Tue Mar 21 15:15:42 2017 New Revision: 298434 URL: http://llvm.org/viewvc/llvm-project?rev=298434&view=rev Log: Don't make unqualified calls to functions that could well be found via ADL as reasonable extension points. All of this would be cleaner if this code followed the more usual LLVM convention of not having deeply nested namespaces inside of .cpp files and instead having a `using namespace ...;` at the top. Then the static function would be in the global namespace and easily referred to as `::join`. Instead we have to write a fairly contrived qualified name. I figure the authors can clean this up with a less ambiguous name, using the newly provided LLVM `join` function, or any other solution, but this at least fixes the build. Modified: clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp Modified: clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp URL: http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp?rev=298434&r1=298433&r2=298434&view=diff == --- clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp (original) +++ clang-tools-extra/trunk/clang-tidy/cppcoreguidelines/SpecialMemberFunctionsCheck.cpp Tue Mar 21 15:15:42 2017 @@ -182,8 +182,8 @@ void SpecialMemberFunctionsCheck::checkF if (!MissingMembers.empty()) diag(ID.first, "class '%0' defines %1 but does not define %2") -<< ID.second << join(DefinedMembers, " and ") -<< join(MissingMembers, " or "); +<< ID.second << cppcoreguidelines::join(DefinedMembers, " and ") +<< cppcoreguidelines::join(MissingMembers, " or "); } } // namespace cppcoreguidelines ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r298491 - [nonnull] Teach Clang to attach the nonnull LLVM attribute to
Author: chandlerc Date: Wed Mar 22 04:09:13 2017 New Revision: 298491 URL: http://llvm.org/viewvc/llvm-project?rev=298491&view=rev Log: [nonnull] Teach Clang to attach the nonnull LLVM attribute to declarations and calls instead of just definitions, and then teach it to *not* attach such attributes even if the source code contains them. This follows the design direction discussed on cfe-dev here: http://lists.llvm.org/pipermail/cfe-dev/2017-January/052066.html The idea is that for C standard library builtins, even if the library vendor chooses to annotate their routines with __attribute__((nonnull)), we will ignore those attributes which pertain to pointer arguments that have an associated size. This allows the widespread (and seemingly reasonable) pattern of calling these routines with a null pointer and a zero size. I have only done this for the library builtins currently recognized by Clang, but we can now trivially add to this set. This will be controllable with -fno-builtin if anyone should care to do so. Note that this does *not* change the AST. As a consequence, warnings, static analysis, and source code rewriting are not impacted. This isn't even a regression on any platform as neither Clang nor LLVM have ever put 'nonnull' onto these arguments for declarations. All this patch does is enable it on other declarations while preventing us from ever accidentally enabling it on these libc functions due to a library vendor. It will also allow any other libraries using this annotation to gain optimizations based on the annotation even when only a declaration is visible. Modified: cfe/trunk/include/clang/AST/ASTContext.h cfe/trunk/include/clang/Basic/Builtins.def cfe/trunk/lib/AST/ASTContext.cpp cfe/trunk/lib/CodeGen/CGCall.cpp cfe/trunk/test/CodeGen/nonnull.c Modified: cfe/trunk/include/clang/AST/ASTContext.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=298491&r1=298490&r2=298491&view=diff == --- cfe/trunk/include/clang/AST/ASTContext.h (original) +++ cfe/trunk/include/clang/AST/ASTContext.h Wed Mar 22 04:09:13 2017 @@ -1864,7 +1864,9 @@ public: /// arguments to the builtin that are required to be integer constant /// expressions. QualType GetBuiltinType(unsigned ID, GetBuiltinTypeError &Error, - unsigned *IntegerConstantArgs = nullptr) const; + unsigned *IntegerConstantArgs = nullptr, + bool *OverrideNonnullReturn = nullptr, + unsigned *OverrideNonnullArgs = nullptr) const; private: CanQualType getFromTargetType(unsigned Type) const; Modified: cfe/trunk/include/clang/Basic/Builtins.def URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=298491&r1=298490&r2=298491&view=diff == --- cfe/trunk/include/clang/Basic/Builtins.def (original) +++ cfe/trunk/include/clang/Basic/Builtins.def Wed Mar 22 04:09:13 2017 @@ -55,6 +55,12 @@ // S -> signed // U -> unsigned // I -> Required to constant fold to an integer constant expression. +// N -> Do not assume non-null for optimizations even if attributed nonnull. +// This can be used when a relevant standard requires arguments or +// returns to be non-null and they are attributed accordingly but in +// practice are not used in this way. This typically used when a size +// parameter is also provided and when zero it would be reasonable to +// give an invalid pointer. // // Types may be postfixed with the following modifiers: // * -> pointer (optionally followed by an address space number, if no address @@ -787,27 +793,27 @@ LIBBUILTIN(_Exit, "vi", "fr", LIBBUILTIN(malloc, "v*z", "f", "stdlib.h", ALL_LANGUAGES) LIBBUILTIN(realloc, "v*v*z", "f", "stdlib.h", ALL_LANGUAGES) // C99 string.h -LIBBUILTIN(memcpy, "v*v*vC*z","f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(memcmp, "ivC*vC*z","f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(memmove, "v*v*vC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strcpy, "c*c*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strncpy, "c*c*cC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strcmp, "icC*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strncmp, "icC*cC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strcat, "c*c*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strncat, "c*c*cC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strxfrm, "zc*cC*z","f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(memchr, "v*vC*iz", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strchr, "c*cC*i", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strcspn, "zcC*cC*","f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strpbrk, "
r298494 - Remove an overly aggressive assert in r298491 and leave a comment
Author: chandlerc
Date: Wed Mar 22 05:38:07 2017
New Revision: 298494
URL: http://llvm.org/viewvc/llvm-project?rev=298494&view=rev
Log:
Remove an overly aggressive assert in r298491 and leave a comment
explaining why we have to ignore errors here even though in other parts
of codegen we can be more strict with builtins.
Also add a test case based on the code in a TSan test that found this
issue.
Modified:
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/test/CodeGen/function-attributes.c
Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=298494&r1=298493&r2=298494&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Wed Mar 22 05:38:07 2017
@@ -1813,7 +1813,11 @@ void CodeGenModule::ConstructAttributeLi
ASTContext::GetBuiltinTypeError Error;
getContext().GetBuiltinType(BuiltinID, Error, nullptr,
&OverrideNonnullReturn, &OverrideNonnullArgs);
-assert(Error == ASTContext::GE_None && "Should not codegen an error");
+// Note that we can't check the 'Error' here as there may be errors that
+// have been diagnosed and reported to the programmer as warnings but
+// repaired in the AST such as for implicit declarations of builtin
+// functions. None of those impact our usage of this to analyze attributes
+// for the builtins.
}
bool HasOptnone = false;
Modified: cfe/trunk/test/CodeGen/function-attributes.c
URL:
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/function-attributes.c?rev=298494&r1=298493&r2=298494&view=diff
==
--- cfe/trunk/test/CodeGen/function-attributes.c (original)
+++ cfe/trunk/test/CodeGen/function-attributes.c Wed Mar 22 05:38:07 2017
@@ -108,6 +108,20 @@ void f20(void) {
_setjmp(0);
}
+// Bogus declarations that will end up with bad types when detecting builtins,
+// but that we will still process when considering whether to add attributes.
+struct __jmp_buf_tag;
+extern int __sigsetjmp(struct __jmp_buf_tag *__env, int __savemask);
+
+// CHECK-LABEL: define void @f21()
+// CHECK: {
+// CHECK: call i32 @__sigsetjmp(%{{.*}}* null, i32 0)
+// CHECK: [[RT_CALL]]
+// CHECK: ret void
+void f21(void) {
+ __sigsetjmp(0, 0);
+}
+
// CHECK: attributes [[NUW]] = { nounwind optsize{{.*}} }
// CHECK: attributes [[AI]] = { alwaysinline nounwind optsize{{.*}} }
// CHECK: attributes [[NUW_OS_RN]] = { nounwind optsize readnone{{.*}} }
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
r298695 - Revert r298491 and r298494 which changed Clang's handling of 'nonnull'
Author: chandlerc Date: Fri Mar 24 04:11:57 2017 New Revision: 298695 URL: http://llvm.org/viewvc/llvm-project?rev=298695&view=rev Log: Revert r298491 and r298494 which changed Clang's handling of 'nonnull' attributes. These patches don't work because we can't currently access the parameter information in a reliable way when building attributes. I thought this would be relatively straightforward to fix, but it seems not to be the case. Fixing this will requrie a substantial re-plumbing of machinery to allow attributes to be handled in this location, and several other fixes to the attribute machinery should probably be made at the same time. All of this will make the patch substantially more complicated. Reverting for now as there are active miscompiles caused by the current version. Modified: cfe/trunk/include/clang/AST/ASTContext.h cfe/trunk/include/clang/Basic/Builtins.def cfe/trunk/lib/AST/ASTContext.cpp cfe/trunk/lib/CodeGen/CGCall.cpp cfe/trunk/test/CodeGen/function-attributes.c cfe/trunk/test/CodeGen/nonnull.c Modified: cfe/trunk/include/clang/AST/ASTContext.h URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/ASTContext.h?rev=298695&r1=298694&r2=298695&view=diff == --- cfe/trunk/include/clang/AST/ASTContext.h (original) +++ cfe/trunk/include/clang/AST/ASTContext.h Fri Mar 24 04:11:57 2017 @@ -1864,9 +1864,7 @@ public: /// arguments to the builtin that are required to be integer constant /// expressions. QualType GetBuiltinType(unsigned ID, GetBuiltinTypeError &Error, - unsigned *IntegerConstantArgs = nullptr, - bool *OverrideNonnullReturn = nullptr, - unsigned *OverrideNonnullArgs = nullptr) const; + unsigned *IntegerConstantArgs = nullptr) const; private: CanQualType getFromTargetType(unsigned Type) const; Modified: cfe/trunk/include/clang/Basic/Builtins.def URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Builtins.def?rev=298695&r1=298694&r2=298695&view=diff == --- cfe/trunk/include/clang/Basic/Builtins.def (original) +++ cfe/trunk/include/clang/Basic/Builtins.def Fri Mar 24 04:11:57 2017 @@ -55,12 +55,6 @@ // S -> signed // U -> unsigned // I -> Required to constant fold to an integer constant expression. -// N -> Do not assume non-null for optimizations even if attributed nonnull. -// This can be used when a relevant standard requires arguments or -// returns to be non-null and they are attributed accordingly but in -// practice are not used in this way. This typically used when a size -// parameter is also provided and when zero it would be reasonable to -// give an invalid pointer. // // Types may be postfixed with the following modifiers: // * -> pointer (optionally followed by an address space number, if no address @@ -792,27 +786,27 @@ LIBBUILTIN(_Exit, "vi", "fr", LIBBUILTIN(malloc, "v*z", "f", "stdlib.h", ALL_LANGUAGES) LIBBUILTIN(realloc, "v*v*z", "f", "stdlib.h", ALL_LANGUAGES) // C99 string.h -LIBBUILTIN(memcpy, "Nv*Nv*NvC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(memcmp, "iNvC*NvC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(memmove, "Nv*Nv*NvC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strcpy, "c*c*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strncpy, "Nc*Nc*NcC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strcmp, "icC*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strncmp, "iNcC*NcC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strcat, "c*c*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strncat, "c*c*NcC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strxfrm, "zc*cC*z", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(memchr, "Nv*NvC*iz","f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strchr, "c*cC*i", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strcspn, "zcC*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strpbrk, "c*cC*cC*","f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strrchr, "c*cC*i", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strspn, "zcC*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strstr, "c*cC*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strtok, "c*c*cC*", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(memset, "Nv*Nv*iz", "f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strerror, "c*i","f", "string.h", ALL_LANGUAGES) -LIBBUILTIN(strlen, "zcC*", "f", "string.h", ALL_LANGUAGES) +LIBBUILTIN(memcpy, "v*v*vC*z","f", "string.h", ALL_LANGUAGES) +LIBBUILTIN(memcmp, "ivC*vC*z","f", "string.h", ALL_LANGUAGES) +LIBBUILTIN(memmove, "v*v*vC*z", "f",
