r333148 - [Sema][ObjC] Do not DiagnoseUseOfDecl in LookupMemberExpr

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Wed May 23 18:01:43 2018
New Revision: 333148

URL: http://llvm.org/viewvc/llvm-project?rev=333148&view=rev
Log:
[Sema][ObjC] Do not DiagnoseUseOfDecl in LookupMemberExpr

Summary:
Remove the call to DiagnoseUseOfDecl in LookupMemberExpr because:
1. LookupMemberExpr eagerly lookup both getter and setter, reguardless
if they are used or not. It causes wrong diagnostics if you are only
using getter.
2. LookupMemberExpr only diagnoses getter, but not setter.
3. ObjCPropertyOpBuilder already DiagnoseUseOfDecl when building getter
and setter. Doing it again in LookupMemberExpr causes duplicated
diagnostics.

rdar://problem/38479756

Reviewers: erik.pilkington, arphaman, doug.gregor

Reviewed By: arphaman

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/Sema/SemaExprMember.cpp
cfe/trunk/test/SemaObjC/property-deprecated-warning.m

Modified: cfe/trunk/lib/Sema/SemaExprMember.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExprMember.cpp?rev=333148&r1=333147&r2=333148&view=diff
==
--- cfe/trunk/lib/Sema/SemaExprMember.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExprMember.cpp Wed May 23 18:01:43 2018
@@ -1490,9 +1490,6 @@ static ExprResult LookupMemberExpr(Sema
 }
 
 if (ObjCMethodDecl *OMD = dyn_cast(PMDecl)) {
-  // Check the use of this method.
-  if (S.DiagnoseUseOfDecl(OMD, MemberLoc))
-return ExprError();
   Selector SetterSel =
 SelectorTable::constructSetterSelector(S.PP.getIdentifierTable(),
S.PP.getSelectorTable(),

Modified: cfe/trunk/test/SemaObjC/property-deprecated-warning.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/property-deprecated-warning.m?rev=333148&r1=333147&r2=333148&view=diff
==
--- cfe/trunk/test/SemaObjC/property-deprecated-warning.m (original)
+++ cfe/trunk/test/SemaObjC/property-deprecated-warning.m Wed May 23 18:01:43 
2018
@@ -167,3 +167,14 @@ void testUserAccessorAttributes(Foo *foo
foo.x = foo.x; // expected-error {{property access is using 'x' method 
which is unavailable}} \
   // expected-warning {{property access is using 'setX:' 
method which is deprecated}}
 }
+
+// test implicit property does not emit duplicated warning.
+@protocol Foo
+- (int)size __attribute__((availability(ios,deprecated=3.0))); // 
expected-note {{'size' has been explicitly marked deprecated here}}
+- (void)setSize: (int)x __attribute__((availability(ios,deprecated=2.0))); // 
expected-note {{'setSize:' has been explicitly marked deprecated here}}
+@end
+
+void testImplicitProperty(id object) {
+  object.size = object.size; // expected-warning {{'size' is deprecated: first 
deprecated in iOS 3.0}} \
+ // expected-warning {{'setSize:' is deprecated: 
first deprecated in iOS 2.0}}
+}


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

r321909 - Preserve unknown STDC pragma through preprocessor

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Fri Jan  5 14:45:03 2018
New Revision: 321909

URL: http://llvm.org/viewvc/llvm-project?rev=321909&view=rev
Log:
Preserve unknown STDC pragma through preprocessor

Summary:
#pragma STDC FP_CONTRACT handler is only registered in parser so we
should keep the unknown STDC pragma through preprocessor and we also
should not emit warning for unknown STDC pragma during preprocessor.

rdar://problem/35724351

Reviewers: efriedma, rsmith, arphaman

Reviewed By: efriedma

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
cfe/trunk/include/clang/Parse/Parser.h
cfe/trunk/lib/Lex/Pragma.cpp
cfe/trunk/lib/Parse/ParsePragma.cpp
cfe/trunk/test/Preprocessor/pragma_unknown.c

Modified: cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td?rev=321909&r1=321908&r2=321909&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticLexKinds.td Fri Jan  5 14:45:03 2018
@@ -505,17 +505,12 @@ def warn_pragma_message : Warning<"%0">,
 def err_pragma_message : Error<"%0">;
 def warn_pragma_ignored : Warning<"unknown pragma ignored">,
InGroup, DefaultIgnore;
-def ext_stdc_pragma_ignored : ExtWarn<"unknown pragma in STDC namespace">,
-   InGroup;
 def ext_on_off_switch_syntax :
ExtWarn<"expected 'ON' or 'OFF' or 'DEFAULT' in pragma">,
InGroup;
 def ext_pragma_syntax_eod :
ExtWarn<"expected end of directive in pragma">,
InGroup;
-def warn_stdc_fenv_access_not_supported :
-   Warning<"pragma STDC FENV_ACCESS ON is not supported, ignoring pragma">,
-   InGroup;
 def warn_pragma_diagnostic_invalid :
ExtWarn<"pragma diagnostic expected 'error', 'warning', 'ignored', 'fatal',"
 " 'push', or 'pop'">,

Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=321909&r1=321908&r2=321909&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Fri Jan  5 14:45:03 
2018
@@ -973,6 +973,12 @@ def warn_pragma_init_seg_unsupported_tar
 def err_pragma_fp_contract_scope : Error<
   "'#pragma fp_contract' can only appear at file scope or at the start of a "
   "compound statement">; 
+// - #pragma stdc unknown
+def ext_stdc_pragma_ignored : ExtWarn<"unknown pragma in STDC namespace">,
+   InGroup;
+def warn_stdc_fenv_access_not_supported :
+   Warning<"pragma STDC FENV_ACCESS ON is not supported, ignoring pragma">,
+   InGroup;
 // - #pragma comment
 def err_pragma_comment_malformed : Error<
   "pragma comment requires parenthesized identifier and optional string">;

Modified: cfe/trunk/include/clang/Parse/Parser.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Parse/Parser.h?rev=321909&r1=321908&r2=321909&view=diff
==
--- cfe/trunk/include/clang/Parse/Parser.h (original)
+++ cfe/trunk/include/clang/Parse/Parser.h Fri Jan  5 14:45:03 2018
@@ -185,6 +185,9 @@ class Parser : public CodeCompletionHand
   std::unique_ptr UnrollHintHandler;
   std::unique_ptr NoUnrollHintHandler;
   std::unique_ptr FPHandler;
+  std::unique_ptr STDCFENVHandler;
+  std::unique_ptr STDCCXLIMITHandler;
+  std::unique_ptr STDCUnknownHandler;
   std::unique_ptr AttributePragmaHandler;
 
   std::unique_ptr CommentSemaHandler;

Modified: cfe/trunk/lib/Lex/Pragma.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Lex/Pragma.cpp?rev=321909&r1=321908&r2=321909&view=diff
==
--- cfe/trunk/lib/Lex/Pragma.cpp (original)
+++ cfe/trunk/lib/Lex/Pragma.cpp Fri Jan  5 14:45:03 2018
@@ -1601,44 +1601,6 @@ struct PragmaPopMacroHandler : public Pr
   }
 };
 
-// Pragma STDC implementations.
-
-/// PragmaSTDC_FENV_ACCESSHandler - "\#pragma STDC FENV_ACCESS ...".
-struct PragmaSTDC_FENV_ACCESSHandler : public PragmaHandler {
-  PragmaSTDC_FENV_ACCESSHandler() : PragmaHandler("FENV_ACCESS") {}
-
-  void HandlePragma(Preprocessor &PP, PragmaIntroducerKind Introducer,
-Token &Tok) override {
-tok::OnOffSwitch OOS;
-if (PP.LexOnOffSwitch(OOS))
- return;
-if (OOS == tok::OOS_ON)
-  PP.Diag(Tok, diag::warn_stdc_fenv_access_not_supported);
-  }
-};
-
-/// PragmaSTDC_CX_LIMITED_RANGEHandler - "\#pragma STDC CX_LIMITED_RANGE ...".
-struct PragmaSTDC_CX_LIMITED_RANGEHandler : public PragmaHandler {
-  PragmaSTDC_CX_LIMITED_RANGEHandler() : PragmaHandler("CX_LIMITED_RANGE") {}

r335366 - Add const qualifier on FieldChainInfoComparator::operator()

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Fri Jun 22 09:51:17 2018
New Revision: 335366

URL: http://llvm.org/viewvc/llvm-project?rev=335366&view=rev
Log:
Add const qualifier on FieldChainInfoComparator::operator()

libcxx has user defined warning to check for non const call operator.
Silence the warning by adding the const on operator().

Modified:
cfe/trunk/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp

Modified: cfe/trunk/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp?rev=335366&r1=335365&r2=335366&view=diff
==
--- cfe/trunk/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp 
(original)
+++ cfe/trunk/lib/StaticAnalyzer/Checkers/UninitializedObjectChecker.cpp Fri 
Jun 22 09:51:17 2018
@@ -85,7 +85,7 @@ private:
 };
 
 struct FieldChainInfoComparator {
-  bool operator()(const FieldChainInfo &lhs, const FieldChainInfo &rhs) {
+  bool operator()(const FieldChainInfo &lhs, const FieldChainInfo &rhs) const {
 assert(!lhs.Chain.isEmpty() && !rhs.Chain.isEmpty() &&
"Attempted to store an empty fieldchain!");
 return *lhs.Chain.begin() < *rhs.Chain.begin();


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

r350970 - [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Fri Jan 11 13:16:04 2019
New Revision: 350970

URL: http://llvm.org/viewvc/llvm-project?rev=350970&view=rev
Log:
[Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

Summary:
After r327851, Driver::GetTemporaryPath will create the file rather than
just create a potientially unqine filename. If clang driver pass the
file as parameter as -object_path_lto, ld64 will pass it back to libLTO
as GeneratedObjectsDirectory, which is going to cause a LLVM ERROR if it
is not a directory.
Now during thinLTO, pass a temp directory path to linker instread.

rdar://problem/47194182

Reviewers: arphaman, dexonsmith

Reviewed By: arphaman

Subscribers: mehdi_amini, inglorion, jkorous, cfe-commits

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

Modified:
cfe/trunk/include/clang/Driver/Driver.h
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
cfe/trunk/test/Driver/darwin-ld-lto.c

Modified: cfe/trunk/include/clang/Driver/Driver.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Driver.h?rev=350970&r1=350969&r2=350970&view=diff
==
--- cfe/trunk/include/clang/Driver/Driver.h (original)
+++ cfe/trunk/include/clang/Driver/Driver.h Fri Jan 11 13:16:04 2019
@@ -505,6 +505,10 @@ public:
   /// GCC goes to extra lengths here to be a bit more robust.
   std::string GetTemporaryPath(StringRef Prefix, StringRef Suffix) const;
 
+  /// GetTemporaryDirectory - Return the pathname of a temporary directory to
+  /// use as part of compilation; the directory will have the given prefix.
+  std::string GetTemporaryDirectory(StringRef Prefix) const;
+
   /// Return the pathname of the pch file in clang-cl mode.
   std::string GetClPchPath(Compilation &C, StringRef BaseName) const;
 

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=350970&r1=350969&r2=350970&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Fri Jan 11 13:16:04 2019
@@ -4478,6 +4478,17 @@ std::string Driver::GetTemporaryPath(Str
   return Path.str();
 }
 
+std::string Driver::GetTemporaryDirectory(StringRef Prefix) const {
+  SmallString<128> Path;
+  std::error_code EC = llvm::sys::fs::createUniqueDirectory(Prefix, Path);
+  if (EC) {
+Diag(clang::diag::err_unable_to_make_temp) << EC.message();
+return "";
+  }
+
+  return Path.str();
+}
+
 std::string Driver::GetClPchPath(Compilation &C, StringRef BaseName) const {
   SmallString<128> Output;
   if (Arg *FpArg = C.getArgs().getLastArg(options::OPT__SLASH_Fp)) {

Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=350970&r1=350969&r2=350970&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Fri Jan 11 13:16:04 2019
@@ -224,13 +224,20 @@ void darwin::Linker::AddLinkArgs(Compila
options::OPT_fno_application_extension, false))
 CmdArgs.push_back("-application_extension");
 
-  if (D.isUsingLTO()) {
-// If we are using LTO, then automatically create a temporary file path for
-// the linker to use, so that it's lifetime will extend past a possible
-// dsymutil step.
-if (Version[0] >= 116 && NeedsTempPath(Inputs)) {
-  const char *TmpPath = C.getArgs().MakeArgString(
-  D.GetTemporaryPath("cc", 
types::getTypeTempSuffix(types::TY_Object)));
+  if (D.isUsingLTO() && Version[0] >= 116 && NeedsTempPath(Inputs)) {
+std::string TmpPathName;
+if (D.getLTOMode() == LTOK_Full) {
+  // If we are using full LTO, then automatically create a temporary file
+  // path for the linker to use, so that it's lifetime will extend past a
+  // possible dsymutil step.
+  TmpPathName =
+  D.GetTemporaryPath("cc", types::getTypeTempSuffix(types::TY_Object));
+} else if (D.getLTOMode() == LTOK_Thin)
+  // If we are using thin LTO, then create a directory instead.
+  TmpPathName = D.GetTemporaryDirectory("thinlto");
+
+if (!TmpPathName.empty()) {
+  auto *TmpPath = C.getArgs().MakeArgString(TmpPathName);
   C.addTempFile(TmpPath);
   CmdArgs.push_back("-object_path_lto");
   CmdArgs.push_back(TmpPath);

Modified: cfe/trunk/test/Driver/darwin-ld-lto.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-ld-lto.c?rev=350970&r1=350969&r2=350970&view=diff
==
--- cfe/trunk/test/Driver/darwin-ld-lto.c (original)
+++ cfe/trunk/test/Driver/darwin-ld-lto.c Fri Jan 11 13:16:04 2019
@@ -17,3 +17,14 @@
 // RUN: %clang -target x86_64-apple-darwin10 

r352537 - Fix the tests from r350970

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Tue Jan 29 12:13:02 2019
New Revision: 352537

URL: http://llvm.org/viewvc/llvm-project?rev=352537&view=rev
Log:
Fix the tests from r350970

Relax the tests from r350970 to allow non-standard path for ld.

Modified:
cfe/trunk/test/Driver/darwin-ld-lto.c

Modified: cfe/trunk/test/Driver/darwin-ld-lto.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-ld-lto.c?rev=352537&r1=352536&r2=352537&view=diff
==
--- cfe/trunk/test/Driver/darwin-ld-lto.c (original)
+++ cfe/trunk/test/Driver/darwin-ld-lto.c Tue Jan 29 12:13:02 2019
@@ -22,9 +22,9 @@
 // Check that -object_lto_path is passed correctly to ld64
 // RUN: %clang -target x86_64-apple-darwin10 %s -flto=full -### 2>&1 | \
 // RUN:   FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
-// FULL_LTO_OBJECT_PATH: /usr/bin/ld
+// FULL_LTO_OBJECT_PATH: {{ld(.exe)?"}}
 // FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto" 
"{{[a-zA-Z0-9_\/]+\/cc\-[a-zA-Z0-9_]+.o}}"
 // RUN: %clang -target x86_64-apple-darwin10 %s -flto=thin -### 2>&1 | \
 // RUN:   FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
-// THIN_LTO_OBJECT_PATH: /usr/bin/ld
+// THIN_LTO_OBJECT_PATH: {{ld(.exe)?"}}
 // THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto" 
"{{[a-zA-Z0-9_\/]+\/thinlto\-[a-zA-Z0-9_]+}}"


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

Re: r350970 - [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO

[Steven Wu via cfe-commits]

r352537 should fix it.

Steven

> On Jan 29, 2019, at 11:36 AM, Matt Arsenault  wrote:
> 
> 
> 
>> On Jan 11, 2019, at 4:16 PM, Steven Wu via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> 
>> Author: steven_wu
>> Date: Fri Jan 11 13:16:04 2019
>> New Revision: 350970
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=350970&view=rev 
>> <http://llvm.org/viewvc/llvm-project?rev=350970&view=rev>
>> Log:
>> [Darwin][Driver] Don't pass a file as object_path_lto during ThinLTO
>> 
>> Summary:
>> After r327851, Driver::GetTemporaryPath will create the file rather than
>> just create a potientially unqine filename. If clang driver pass the
>> file as parameter as -object_path_lto, ld64 will pass it back to libLTO
>> as GeneratedObjectsDirectory, which is going to cause a LLVM ERROR if it
>> is not a directory.
>> Now during thinLTO, pass a temp directory path to linker instread.
>> 
>> rdar://problem/47194182 
>> 
>> Reviewers: arphaman, dexonsmith
>> 
>> Reviewed By: arphaman
>> 
>> Subscribers: mehdi_amini, inglorion, jkorous, cfe-commits
>> 
>> Differential Revision: https://reviews.llvm.org/D56608
>> 
>> Modified:
>>cfe/trunk/include/clang/Driver/Driver.h
>>cfe/trunk/lib/Driver/Driver.cpp
>>cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>>cfe/trunk/test/Driver/darwin-ld-lto.c
>> 
>> Modified: cfe/trunk/include/clang/Driver/Driver.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Driver.h?rev=350970&r1=350969&r2=350970&view=diff
>> ==
>> --- cfe/trunk/include/clang/Driver/Driver.h (original)
>> +++ cfe/trunk/include/clang/Driver/Driver.h Fri Jan 11 13:16:04 2019
>> @@ -505,6 +505,10 @@ public:
>>   /// GCC goes to extra lengths here to be a bit more robust.
>>   std::string GetTemporaryPath(StringRef Prefix, StringRef Suffix) const;
>> 
>> +  /// GetTemporaryDirectory - Return the pathname of a temporary directory 
>> to
>> +  /// use as part of compilation; the directory will have the given prefix.
>> +  std::string GetTemporaryDirectory(StringRef Prefix) const;
>> +
>>   /// Return the pathname of the pch file in clang-cl mode.
>>   std::string GetClPchPath(Compilation &C, StringRef BaseName) const;
>> 
>> 
>> Modified: cfe/trunk/lib/Driver/Driver.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=350970&r1=350969&r2=350970&view=diff
>> ==
>> --- cfe/trunk/lib/Driver/Driver.cpp (original)
>> +++ cfe/trunk/lib/Driver/Driver.cpp Fri Jan 11 13:16:04 2019
>> @@ -4478,6 +4478,17 @@ std::string Driver::GetTemporaryPath(Str
>>   return Path.str();
>> }
>> 
>> +std::string Driver::GetTemporaryDirectory(StringRef Prefix) const {
>> +  SmallString<128> Path;
>> +  std::error_code EC = llvm::sys::fs::createUniqueDirectory(Prefix, Path);
>> +  if (EC) {
>> +Diag(clang::diag::err_unable_to_make_temp) << EC.message();
>> +return "";
>> +  }
>> +
>> +  return Path.str();
>> +}
>> +
>> std::string Driver::GetClPchPath(Compilation &C, StringRef BaseName) const {
>>   SmallString<128> Output;
>>   if (Arg *FpArg = C.getArgs().getLastArg(options::OPT__SLASH_Fp)) {
>> 
>> Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=350970&r1=350969&r2=350970&view=diff
>> ==
>> --- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
>> +++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Fri Jan 11 13:16:04 2019
>> @@ -224,13 +224,20 @@ void darwin::Linker::AddLinkArgs(Compila
>>options::OPT_fno_application_extension, false))
>> CmdArgs.push_back("-application_extension");
>> 
>> -  if (D.isUsingLTO()) {
>> -// If we are using LTO, then automatically create a temporary file path 
>> for
>> -// the linker to use, so that it's lifetime will extend past a possible
>> -// dsymutil step.
>> -if (Version[0] >= 116 && NeedsTempPath(Inputs)) {
>> -  const char *TmpPath = C.getArgs().MakeArgString(
>> -  D.GetTemporaryPath("cc", 
>> types::getTyp

Re: r328173 - Improve -Winfinite-recursion

[Steven Wu via cfe-commits]

Hi Robert

I ping'ed this commit on Phabricator with an example of false positive 
introduced by this patch. Can you take a look?

Thanks

Steven

> On Mar 21, 2018, at 8:16 PM, Robert Widmann via cfe-commits 
>  wrote:
> 
> Author: codafi
> Date: Wed Mar 21 20:16:23 2018
> New Revision: 328173
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=328173&view=rev
> Log:
> Improve -Winfinite-recursion
> 
> Summary: Rewrites -Winfinite-recursion to remove the state dictionary and 
> explore paths in loops - especially infinite loops.  The new check now 
> detects recursion in loop bodies dominated by a recursive call.
> 
> Reviewers: rsmith, rtrieu
> 
> Reviewed By: rtrieu
> 
> Subscribers: lebedev.ri, cfe-commits
> 
> Differential Revision: https://reviews.llvm.org/D43737
> 
> Modified:
>cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
>cfe/trunk/test/SemaCXX/warn-infinite-recursion.cpp
> 
> Modified: cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp?rev=328173&r1=328172&r2=328173&view=diff
> ==
> --- cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp (original)
> +++ cfe/trunk/lib/Sema/AnalysisBasedWarnings.cpp Wed Mar 21 20:16:23 2018
> @@ -200,60 +200,41 @@ static bool hasRecursiveCallInPath(const
>   return false;
> }
> 
> -// All blocks are in one of three states.  States are ordered so that blocks
> -// can only move to higher states.
> -enum RecursiveState {
> -  FoundNoPath,
> -  FoundPath,
> -  FoundPathWithNoRecursiveCall
> -};
> -
> -// Returns true if there exists a path to the exit block and every path
> -// to the exit block passes through a call to FD.
> +// Returns true if every path from the entry block passes through a call to 
> FD.
> static bool checkForRecursiveFunctionCall(const FunctionDecl *FD, CFG *cfg) {
> +  llvm::SmallPtrSet Visited;
> +  llvm::SmallVector WorkList;
> +  // Keep track of whether we found at least one recursive path.
> +  bool foundRecursion = false;
> 
>   const unsigned ExitID = cfg->getExit().getBlockID();
> 
> -  // Mark all nodes as FoundNoPath, then set the status of the entry block.
> -  SmallVector States(cfg->getNumBlockIDs(), FoundNoPath);
> -  States[cfg->getEntry().getBlockID()] = FoundPathWithNoRecursiveCall;
> -
> -  // Make the processing stack and seed it with the entry block.
> -  SmallVector Stack;
> -  Stack.push_back(&cfg->getEntry());
> -
> -  while (!Stack.empty()) {
> -CFGBlock *CurBlock = Stack.back();
> -Stack.pop_back();
> -
> -unsigned ID = CurBlock->getBlockID();
> -RecursiveState CurState = States[ID];
> -
> -if (CurState == FoundPathWithNoRecursiveCall) {
> -  // Found a path to the exit node without a recursive call.
> -  if (ExitID == ID)
> -return false;
> -
> -  // Only change state if the block has a recursive call.
> -  if (hasRecursiveCallInPath(FD, *CurBlock))
> -CurState = FoundPath;
> -}
> +  // Seed the work list with the entry block.
> +  WorkList.push_back(&cfg->getEntry());
> 
> -// Loop over successor blocks and add them to the Stack if their state
> -// changes.
> -for (auto I = CurBlock->succ_begin(), E = CurBlock->succ_end(); I != E; 
> ++I)
> -  if (*I) {
> -unsigned next_ID = (*I)->getBlockID();
> -if (States[next_ID] < CurState) {
> -  States[next_ID] = CurState;
> -  Stack.push_back(*I);
> +  while (!WorkList.empty()) {
> +CFGBlock *Block = WorkList.pop_back_val();
> +
> +for (auto I = Block->succ_begin(), E = Block->succ_end(); I != E; ++I) {
> +  if (CFGBlock *SuccBlock = *I) {
> +if (!Visited.insert(SuccBlock).second)
> +  continue;
> +
> +// Found a path to the exit node without a recursive call.
> +if (ExitID == SuccBlock->getBlockID())
> +  return false;
> +
> +// If the successor block contains a recursive call, end analysis 
> there.
> +if (hasRecursiveCallInPath(FD, *SuccBlock)) {
> +  foundRecursion = true;
> +  continue;
> }
> +
> +WorkList.push_back(SuccBlock);
>   }
> +}
>   }
> -
> -  // Return true if the exit node is reachable, and only reachable through
> -  // a recursive call.
> -  return States[ExitID] == FoundPath;
> +  return foundRecursion;
> }
> 
> static void checkRecursiveFunction(Sema &S, const FunctionDecl *FD,
> @@ -269,10 +250,6 @@ static void checkRecursiveFunction(Sema
>   CFG *cfg = AC.getCFG();
>   if (!cfg) return;
> 
> -  // If the exit block is unreachable, skip processing the function.
> -  if (cfg->getExit().pred_empty())
> -return;
> -
>   // Emit diagnostic if a recursive function call is detected for all paths.
>   if (checkForRecursiveFunctionCall(FD, cfg))
> S.Diag(Body->getLocStart(), diag::warn_infinite_recursive_function);
> 
> Modified: cfe/trunk/test/SemaCXX/warn-infinite-recursion.cpp
> URL: 
> 

Re: r304661 - CodeGen: fix section names for different file formats

[Steven Wu via cfe-commits]

Hi Saleem

I just realize there can be an issue with this commit. This breaks the bitcode 
compatibility when LTO linking bitcode file produced by llvm-5.0 vs the older 
versions. Because the objc related module flag has the behavior Module::Error, 
simple whitespace changes will cause libLTO to error upon seeing different 
values.

I wish I caught this earlier so we can fix the issue before 5.0 released. Maybe 
we need another bitcode upgrade path to strip away all the whitespaces in 
"Objective-C Image Info Section" module flag?

Steven


> On Jun 3, 2017, at 9:18 AM, Saleem Abdulrasool via cfe-commits 
>  wrote:
> 
> Author: compnerd
> Date: Sat Jun  3 11:18:09 2017
> New Revision: 304661
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=304661&view=rev
> Log:
> CodeGen: fix section names for different file formats
> 
> This changes the codegen to match the section names according to the
> ObjC rewriter as well as the runtime.  The changes to the test are
> simply whitespace changes to the section attributes and names and are
> functionally equivalent (the whitespace is ignored by the linker).
> 
> Added:
>cfe/trunk/test/CodeGenObjC/sections.m
> Modified:
>cfe/trunk/lib/CodeGen/CGObjCMac.cpp
>cfe/trunk/test/CodeGenObjC/exceptions-asm-attribute.m
>cfe/trunk/test/CodeGenObjC/image-info.m
>cfe/trunk/test/CodeGenObjC/metadata-symbols-64.m
>cfe/trunk/test/CodeGenObjC/metadata_symbols.m
>cfe/trunk/test/CodeGenObjC/non-lazy-classes.m
> 
> Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=304661&r1=304660&r2=304661&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Sat Jun  3 11:18:09 2017
> @@ -1004,6 +1004,8 @@ protected:
>   const ObjCInterfaceDecl *ID,
>   ObjCCommonTypesHelper &ObjCTypes);
> 
> +  std::string GetSectionName(StringRef Section, StringRef MachOAttributes);
> +
> public:
>   /// CreateMetadataVar - Create a global variable with internal
>   /// linkage for use by the Objective-C runtime.
> @@ -4786,6 +4788,27 @@ llvm::Value *CGObjCMac::EmitIvarOffset(C
> 
> /* *** Private Interface *** */
> 
> +std::string CGObjCCommonMac::GetSectionName(StringRef Section,
> +StringRef MachOAttributes) {
> +  switch (CGM.getTriple().getObjectFormat()) {
> +  default:
> +llvm_unreachable("unexpected object file format");
> +  case llvm::Triple::MachO: {
> +if (MachOAttributes.empty())
> +  return ("__DATA," + Section).str();
> +return ("__DATA," + Section + "," + MachOAttributes).str();
> +  }
> +  case llvm::Triple::ELF:
> +assert(Section.substr(0, 2) == "__" &&
> +   "expected the name to begin with __");
> +return Section.substr(2).str();
> +  case llvm::Triple::COFF:
> +assert(Section.substr(0, 2) == "__" &&
> +   "expected the name to begin with __");
> +return ("." + Section.substr(2) + "$B").str();
> +  }
> +}
> +
> /// EmitImageInfo - Emit the image info marker used to encode some module
> /// level information.
> ///
> @@ -4809,9 +4832,10 @@ enum ImageInfoFlags {
> 
> void CGObjCCommonMac::EmitImageInfo() {
>   unsigned version = 0; // Version is unused?
> -  const char *Section = (ObjCABI == 1) ?
> -"__OBJC, __image_info,regular" :
> -"__DATA, __objc_imageinfo, regular, no_dead_strip";
> +  std::string Section =
> +  (ObjCABI == 1)
> +  ? "__OBJC,__image_info,regular"
> +  : GetSectionName("__objc_imageinfo", "regular,no_dead_strip");
> 
>   // Generate module-level named metadata to convey this information to the
>   // linker and code-gen.
> @@ -4822,7 +4846,7 @@ void CGObjCCommonMac::EmitImageInfo() {
>   Mod.addModuleFlag(llvm::Module::Error, "Objective-C Image Info Version",
> version);
>   Mod.addModuleFlag(llvm::Module::Error, "Objective-C Image Info Section",
> -llvm::MDString::get(VMContext,Section));
> +llvm::MDString::get(VMContext, Section));
> 
>   if (CGM.getLangOpts().getGC() == LangOptions::NonGC) {
> // Non-GC overrides those files which specify GC.
> @@ -5930,17 +5954,21 @@ void CGObjCNonFragileABIMac::FinishNonFr
>   }
> 
>   AddModuleClassList(DefinedClasses, "OBJC_LABEL_CLASS_$",
> - "__DATA, __objc_classlist, regular, no_dead_strip");
> + GetSectionName("__objc_classlist",
> +"regular,no_dead_strip"));
> 
>   AddModuleClassList(DefinedNonLazyClasses, "OBJC_LABEL_NONLAZY_CLASS_$",
> - "__DATA, __objc_nlclslist, regular, no_dead_strip");
> + GetSectionName("__objc_nlclslist",
> +"regular,no_dead_strip"));
> 
>   // Build list of all implemen

r348943 - [Driver] Add support for -fembed-bitcode for assembly file

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Wed Dec 12 09:30:16 2018
New Revision: 348943

URL: http://llvm.org/viewvc/llvm-project?rev=348943&view=rev
Log:
[Driver] Add support for -fembed-bitcode for assembly file

Summary:
Handle -fembed-bitcode for assembly inputs. When the input file is
assembly, write a marker as "__LLVM,__asm" section.

Fix llvm.org/pr39659

Reviewers: compnerd, dexonsmith

Reviewed By: compnerd

Subscribers: rjmccall, dblaikie, jkorous, cfe-commits

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

Added:
cfe/trunk/test/Driver/embed-bitcode.s
Modified:
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/lib/Driver/ToolChains/Clang.cpp
cfe/trunk/tools/driver/cc1as_main.cpp

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=348943&r1=348942&r2=348943&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed Dec 12 09:30:16 2018
@@ -675,7 +675,7 @@ def fno_coroutines_ts : Flag <["-"], "fn
   Flags<[DriverOption]>;
 
 def fembed_bitcode_EQ : Joined<["-"], "fembed-bitcode=">,
-Group, Flags<[DriverOption, CC1Option]>, MetaVarName<"">,
+Group, Flags<[DriverOption, CC1Option, CC1AsOption]>, 
MetaVarName<"">,
 HelpText<"Embed LLVM bitcode (option: off, all, bitcode, marker)">;
 def fembed_bitcode : Flag<["-"], "fembed-bitcode">, Group,
   Alias, AliasArgs<["all"]>,

Modified: cfe/trunk/lib/Driver/ToolChains/Clang.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Clang.cpp?rev=348943&r1=348942&r2=348943&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Clang.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Clang.cpp Wed Dec 12 09:30:16 2018
@@ -2167,6 +2167,11 @@ static void CollectArgsForIntegratedAsse
 CmdArgs.push_back("-target-feature");
 CmdArgs.push_back(MipsTargetFeature);
   }
+
+  // forward -fembed-bitcode to assmebler
+  if (C.getDriver().embedBitcodeEnabled() ||
+  C.getDriver().embedBitcodeMarkerOnly())
+Args.AddLastArg(CmdArgs, options::OPT_fembed_bitcode_EQ);
 }
 
 static void RenderFloatingPointOptions(const ToolChain &TC, const Driver &D,

Added: cfe/trunk/test/Driver/embed-bitcode.s
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/embed-bitcode.s?rev=348943&view=auto
==
--- cfe/trunk/test/Driver/embed-bitcode.s (added)
+++ cfe/trunk/test/Driver/embed-bitcode.s Wed Dec 12 09:30:16 2018
@@ -0,0 +1,12 @@
+// REQUIRES: arm-registered-target
+
+// RUN: %clang -c -target armv7-apple-ios10 %s -fembed-bitcode -### 2>&1 | 
FileCheck %s -check-prefix=CHECK-AS
+// RUN: %clang -c -target armv7-apple-ios10 %s -fembed-bitcode-marker -### 
2>&1 | FileCheck %s -check-prefix=CHECK-AS-MARKER
+// CHECK-AS: -cc1as
+// CHECK-AS: -fembed-bitcode=all
+// CHECK-AS-MARKER: -fembed-bitcode=marker
+
+// RUN: %clang -c -target armv7-apple-ios10 %s -fembed-bitcode -o %t.o
+// RUN: llvm-readobj -section-headers %t.o | FileCheck 
--check-prefix=CHECK-SECTION %s
+// CHECK-SECTION: Name: __asm
+// CHECK-SECTION-NEXT: Segment: __LLVM

Modified: cfe/trunk/tools/driver/cc1as_main.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/tools/driver/cc1as_main.cpp?rev=348943&r1=348942&r2=348943&view=diff
==
--- cfe/trunk/tools/driver/cc1as_main.cpp (original)
+++ cfe/trunk/tools/driver/cc1as_main.cpp Wed Dec 12 09:30:16 2018
@@ -33,6 +33,7 @@
 #include "llvm/MC/MCParser/MCAsmParser.h"
 #include "llvm/MC/MCParser/MCTargetAsmParser.h"
 #include "llvm/MC/MCRegisterInfo.h"
+#include "llvm/MC/MCSectionMachO.h"
 #include "llvm/MC/MCStreamer.h"
 #include "llvm/MC/MCSubtargetInfo.h"
 #include "llvm/MC/MCTargetOptions.h"
@@ -132,6 +133,7 @@ struct AssemblerInvocation {
   unsigned NoExecStack : 1;
   unsigned FatalWarnings : 1;
   unsigned IncrementalLinkerCompatible : 1;
+  unsigned EmbedBitcode : 1;
 
   /// The name of the relocation model to use.
   std::string RelocationModel;
@@ -153,6 +155,7 @@ public:
 FatalWarnings = 0;
 IncrementalLinkerCompatible = 0;
 DwarfVersion = 0;
+EmbedBitcode = 0;
   }
 
   static bool CreateFromArgs(AssemblerInvocation &Res,
@@ -284,6 +287,16 @@ bool AssemblerInvocation::CreateFromArgs
   Args.hasArg(OPT_mincremental_linker_compatible);
   Opts.SymbolDefs = Args.getAllArgValues(OPT_defsym);
 
+  // EmbedBitcode Option. If -fembed-bitcode is enabled, set the flag.
+  // EmbedBitcode behaves the same for all embed options for assembly files.
+  if (auto *A = Args.getLastArg(OPT_fembed_bitcode_EQ)) {
+Opts.EmbedBitcode = llvm::StringSwitch(A->getValue())
+.Case("all", 1)
+.Case("bitcode",

r330166 - [Availability] Improve availability to consider functions run at load time

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Mon Apr 16 16:34:18 2018
New Revision: 330166

URL: http://llvm.org/viewvc/llvm-project?rev=330166&view=rev
Log:
[Availability] Improve availability to consider functions run at load time

Summary:
There are some functions/methods that run when the application launches
or the library loads. Those functions will run reguardless the OS
version as long as it satifies the minimum deployment target. Annotate
them with availability attributes doesn't really make sense because they
are essentially available on all targets since minimum deployment
target.

rdar://problem/36093384

Reviewers: arphaman, erik.pilkington

Reviewed By: erik.pilkington

Subscribers: erik.pilkington, cfe-commits

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

Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/lib/Sema/SemaDeclAttr.cpp
cfe/trunk/lib/Sema/SemaDeclObjC.cpp
cfe/trunk/test/SemaObjC/unguarded-availability.m

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=330166&r1=330165&r2=330166&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Mon Apr 16 16:34:18 
2018
@@ -2912,6 +2912,10 @@ def warn_mismatched_availability_overrid
   "%select{the protocol method it implements|its overridden method}1 is "
   "available">,
   InGroup;
+def warn_availability_on_static_initializer : Warning<
+  "ignoring availability attribute %select{on '+load' method|"
+  "with constructor attribute|with destructor attribute}0">,
+  InGroup;
 def note_overridden_method : Note<
   "overridden method is here">;
 def note_protocol_method : Note<

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=330166&r1=330165&r2=330166&view=diff
==
--- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDecl.cpp Mon Apr 16 16:34:18 2018
@@ -9139,6 +9139,21 @@ Sema::ActOnFunctionDeclarator(Scope *S,
 AddToScope = false;
   }
 
+  // Diagnose availability attributes. Availability cannot be used on functions
+  // that are run during load/unload.
+  if (const auto *attr = NewFD->getAttr()) {
+if (NewFD->hasAttr()) {
+  Diag(attr->getLocation(), diag::warn_availability_on_static_initializer)
+  << 1;
+  NewFD->dropAttr();
+}
+if (NewFD->hasAttr()) {
+  Diag(attr->getLocation(), diag::warn_availability_on_static_initializer)
+  << 2;
+  NewFD->dropAttr();
+}
+  }
+
   return NewFD;
 }
 

Modified: cfe/trunk/lib/Sema/SemaDeclAttr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclAttr.cpp?rev=330166&r1=330165&r2=330166&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclAttr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclAttr.cpp Mon Apr 16 16:34:18 2018
@@ -6823,6 +6823,12 @@ static bool ShouldDiagnoseAvailabilityIn
   return false;
 
 // An implementation implicitly has the availability of the interface.
+// Unless it is "+load" method.
+if (const auto *MethodD = dyn_cast(Ctx))
+  if (MethodD->isClassMethod() &&
+  MethodD->getSelector().getAsString() == "load")
+return true;
+
 if (const auto *CatOrImpl = dyn_cast(Ctx)) {
   if (const ObjCInterfaceDecl *Interface = CatOrImpl->getClassInterface())
 if (CheckContext(Interface))

Modified: cfe/trunk/lib/Sema/SemaDeclObjC.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDeclObjC.cpp?rev=330166&r1=330165&r2=330166&view=diff
==
--- cfe/trunk/lib/Sema/SemaDeclObjC.cpp (original)
+++ cfe/trunk/lib/Sema/SemaDeclObjC.cpp Mon Apr 16 16:34:18 2018
@@ -4734,6 +4734,17 @@ Decl *Sema::ActOnMethodDeclaration(
   Context.getTargetInfo().getTriple().getArch() == llvm::Triple::x86)
 checkObjCMethodX86VectorTypes(*this, ObjCMethod);
 
+  // + load method cannot have availability attributes. It get called on
+  // startup, so it has to have the availability of the deployment target.
+  if (const auto *attr = ObjCMethod->getAttr()) {
+if (ObjCMethod->isClassMethod() &&
+ObjCMethod->getSelector().getAsString() == "load") {
+  Diag(attr->getLocation(), diag::warn_availability_on_static_initializer)
+  << 0;
+  ObjCMethod->dropAttr();
+}
+  }
+
   ActOnDocumentableDecl(ObjCMethod);
 
   return ObjCMethod;

Modified: cfe/trunk/test/SemaObjC/unguarded-availability.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaObjC/unguarded-availability.m?rev=330166&r1=330165&r2=330166&view=d

r330338 - [CXX] Templates specialization visibility can be wrong

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Thu Apr 19 08:46:43 2018
New Revision: 330338

URL: http://llvm.org/viewvc/llvm-project?rev=330338&view=rev
Log:
[CXX] Templates specialization visibility can be wrong

Summary:
Under some conditions, LinkageComputer can get the visibility for
ClassTemplateSpecializationDecl wrong because it failed to find the Decl
that has the explicit visibility.

This fixes:
llvm.org/bugs/pr36810
rdar://problem/38080953

Reviewers: rsmith, arphaman, doug.gregor

Reviewed By: doug.gregor

Subscribers: doug.gregor, cfe-commits

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

Added:
cfe/trunk/test/CodeGenCXX/visibility-pr36810.cpp
Modified:
cfe/trunk/lib/AST/Decl.cpp

Modified: cfe/trunk/lib/AST/Decl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/Decl.cpp?rev=330338&r1=330337&r2=330338&view=diff
==
--- cfe/trunk/lib/AST/Decl.cpp (original)
+++ cfe/trunk/lib/AST/Decl.cpp Thu Apr 19 08:46:43 2018
@@ -1092,9 +1092,18 @@ getExplicitVisibilityAux(const NamedDecl
   // If there wasn't explicit visibility there, and this is a
   // specialization of a class template, check for visibility
   // on the pattern.
-  if (const auto *spec = dyn_cast(ND))
-return getVisibilityOf(spec->getSpecializedTemplate()->getTemplatedDecl(),
-   kind);
+  if (const auto *spec = dyn_cast(ND)) {
+// Walk all the template decl till this point to see if there are
+// explicit visibility attributes.
+const auto *TD = spec->getSpecializedTemplate()->getTemplatedDecl();
+while (TD != nullptr) {
+  auto Vis = getVisibilityOf(TD, kind);
+  if (Vis != None)
+return Vis;
+  TD = TD->getPreviousDecl();
+}
+return None;
+  }
 
   // Use the most recent declaration.
   if (!IsMostRecent && !isa(ND)) {

Added: cfe/trunk/test/CodeGenCXX/visibility-pr36810.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/visibility-pr36810.cpp?rev=330338&view=auto
==
--- cfe/trunk/test/CodeGenCXX/visibility-pr36810.cpp (added)
+++ cfe/trunk/test/CodeGenCXX/visibility-pr36810.cpp Thu Apr 19 08:46:43 2018
@@ -0,0 +1,23 @@
+// RUN: %clang_cc1 -triple x86_64-apple-macosx -std=c++11 -fvisibility hidden 
-emit-llvm -o - %s -O2 -disable-llvm-passes | FileCheck %s
+// RUN: %clang_cc1 -triple x86_64-apple-macosx -DUNDEF_G -std=c++11 
-fvisibility hidden -emit-llvm -o - %s -O2 -disable-llvm-passes | FileCheck %s
+
+namespace std {
+template 
+class __attribute__((__type_visibility__("default"))) shared_ptr {
+  template  friend class shared_ptr;
+};
+}
+struct dict;
+#ifndef UNDEF_G
+std::shared_ptr g;
+#endif
+class __attribute__((visibility("default"))) Bar;
+template >
+class __attribute__((visibility("default"))) i {
+  std::shared_ptr foo() const;
+};
+
+// CHECK: define void @_ZNK1iISt10shared_ptrI3BarEE3fooEv
+template <> std::shared_ptr i<>::foo() const {
+  return std::shared_ptr();
+}


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

r336168 - [Driver][Darwin] Use Host Triple to infer target os version

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Mon Jul  2 21:15:49 2018
New Revision: 336168

URL: http://llvm.org/viewvc/llvm-project?rev=336168&view=rev
Log:
[Driver][Darwin] Use Host Triple to infer target os version

Summary:
When clang required to infer target os version from --target option and
the os version is not specified in targets, check the host triple. If the
host and target are both macOS, use host triple to infer target os
version.

rdar://problem/41651999

Reviewers: arphaman, dexonsmith

Reviewed By: arphaman

Subscribers: cfe-commits

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

Modified:
cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
cfe/trunk/test/Driver/clang-g-opts.c
cfe/trunk/test/Driver/target-triple-deployment.c

Modified: cfe/trunk/lib/Driver/ToolChains/Darwin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/ToolChains/Darwin.cpp?rev=336168&r1=336167&r2=336168&view=diff
==
--- cfe/trunk/lib/Driver/ToolChains/Darwin.cpp (original)
+++ cfe/trunk/lib/Driver/ToolChains/Darwin.cpp Mon Jul  2 21:15:49 2018
@@ -1472,10 +1472,16 @@ Optional inferDeployment
 std::string getOSVersion(llvm::Triple::OSType OS, const llvm::Triple &Triple,
  const Driver &TheDriver) {
   unsigned Major, Minor, Micro;
+  llvm::Triple SystemTriple(llvm::sys::getProcessTriple());
   switch (OS) {
   case llvm::Triple::Darwin:
   case llvm::Triple::MacOSX:
-if (!Triple.getMacOSXVersion(Major, Minor, Micro))
+// If there is no version specified on triple, and both host and target are
+// macos, use the host triple to infer OS version.
+if (Triple.isMacOSX() && SystemTriple.isMacOSX() &&
+!Triple.getOSMajorVersion())
+  SystemTriple.getMacOSXVersion(Major, Minor, Micro);
+else if (!Triple.getMacOSXVersion(Major, Minor, Micro))
   TheDriver.Diag(diag::err_drv_invalid_darwin_version)
   << Triple.getOSName();
 break;

Modified: cfe/trunk/test/Driver/clang-g-opts.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/clang-g-opts.c?rev=336168&r1=336167&r2=336168&view=diff
==
--- cfe/trunk/test/Driver/clang-g-opts.c (original)
+++ cfe/trunk/test/Driver/clang-g-opts.c Mon Jul  2 21:15:49 2018
@@ -3,7 +3,7 @@
 // RUN: | FileCheck --check-prefix=CHECK-WITH-G %s
 
 // Assert that the toolchains which should default to a lower Dwarf version do 
so.
-// RUN: %clang -### -S %s -g -target x86_64-apple-darwin 2>&1 \
+// RUN: %clang -### -S %s -g -target x86_64-apple-darwin8 2>&1 \
 // RUN: | FileCheck --check-prefix=CHECK-WITH-G-DWARF2 %s
 // RUN: %clang -### -S %s -g -target i686-pc-openbsd 2>&1 \
 // RUN: | FileCheck --check-prefix=CHECK-WITH-G-DWARF2 %s
@@ -21,7 +21,7 @@
 //
 // RUN: %clang -### -S %s -g0 -g -target x86_64-linux-gnu 2>&1 \
 // RUN: | FileCheck --check-prefix=CHECK-WITH-G %s
-// RUN: %clang -### -S %s -g0 -g -target x86_64-apple-darwin 2>&1 \
+// RUN: %clang -### -S %s -g0 -g -target x86_64-apple-darwin8 2>&1 \
 // RUN: | FileCheck --check-prefix=CHECK-WITH-G-STANDALONE %s
 // RUN: %clang -### -S %s -g0 -g -target i686-pc-openbsd 2>&1 \
 // RUN: | FileCheck --check-prefix=CHECK-WITH-G-DWARF2 %s

Modified: cfe/trunk/test/Driver/target-triple-deployment.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/target-triple-deployment.c?rev=336168&r1=336167&r2=336168&view=diff
==
--- cfe/trunk/test/Driver/target-triple-deployment.c (original)
+++ cfe/trunk/test/Driver/target-triple-deployment.c Mon Jul  2 21:15:49 2018
@@ -1,5 +1,5 @@
 // RUN: touch %t.o
-// RUN: %clang -target x86_64-apple-macosx -### %t.o 2> %t.log
+// RUN: %clang -target x86_64-apple-macosx10.4 -### %t.o 2> %t.log
 // RUN: %clang -target x86_64-apple-darwin9 -### %t.o 2>> %t.log
 // RUN: %clang -target x86_64-apple-macosx10.7 -### %t.o 2>> %t.log
 //


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

r375027 - Fix darwin-ld-lto test for some speical path

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Wed Oct 16 11:12:41 2019
New Revision: 375027

URL: http://llvm.org/viewvc/llvm-project?rev=375027&view=rev
Log:
Fix darwin-ld-lto test for some speical path

Fix the test by not assuming the prefix path of the temp directory can
be matched by a regex.

rdar://problem/56259195

Modified:
cfe/trunk/test/Driver/darwin-ld-lto.c

Modified: cfe/trunk/test/Driver/darwin-ld-lto.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/darwin-ld-lto.c?rev=375027&r1=375026&r2=375027&view=diff
==
--- cfe/trunk/test/Driver/darwin-ld-lto.c (original)
+++ cfe/trunk/test/Driver/darwin-ld-lto.c Wed Oct 16 11:12:41 2019
@@ -23,8 +23,10 @@
 // RUN: %clang -target x86_64-apple-darwin10 %s -flto=full -### 2>&1 | \
 // RUN:   FileCheck -check-prefix=FULL_LTO_OBJECT_PATH %s
 // FULL_LTO_OBJECT_PATH: {{ld(.exe)?"}}
-// FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto" 
"{{[a-zA-Z0-9_\/]+\/cc\-[a-zA-Z0-9_]+.o}}"
+// FULL_LTO_OBJECT_PATH-SAME: "-object_path_lto"
+// FULL_LTO_OBJECT_PATH-SAME: {{cc\-[a-zA-Z0-9_]+.o}}"
 // RUN: %clang -target x86_64-apple-darwin10 %s -flto=thin -### 2>&1 | \
 // RUN:   FileCheck -check-prefix=THIN_LTO_OBJECT_PATH %s
 // THIN_LTO_OBJECT_PATH: {{ld(.exe)?"}}
-// THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto" 
"{{[a-zA-Z0-9_\/]+\/thinlto\-[a-zA-Z0-9_]+}}"
+// THIN_LTO_OBJECT_PATH-SAME: "-object_path_lto"
+// THIN_LTO_OBJECT_PATH-SAME: {{thinlto\-[a-zA-Z0-9_]+}}


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

[clang] 2b42080 - [clang] Teach -fembed-bitcode option not to embed W_value Group

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2020-07-14T14:40:43-07:00
New Revision: 2b42080b51c9a0c5ed733b30da165774dcd0d595

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

LOG: [clang] Teach -fembed-bitcode option not to embed W_value Group

Summary:
-fembed-bitcode options doesn't embed warning options since they are
useless to code generation. Make sure it handles the W_value group and
not embed those options in the output.

Reviewers: zixuw, arphaman

Reviewed By: zixuw

Subscribers: jkorous, dexonsmith, ributzka, cfe-commits

Tags: #clang

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

Added: 


Modified: 
clang/lib/Frontend/CompilerInvocation.cpp
clang/test/Frontend/embed-bitcode.ll

Removed: 




diff  --git a/clang/lib/Frontend/CompilerInvocation.cpp 
b/clang/lib/Frontend/CompilerInvocation.cpp
index 863c6b3ca4f3..75d7cf5d26d3 100644
--- a/clang/lib/Frontend/CompilerInvocation.cpp
+++ b/clang/lib/Frontend/CompilerInvocation.cpp
@@ -1086,8 +1086,7 @@ static bool ParseCodeGenArgs(CodeGenOptions &Opts, 
ArgList &Args, InputKind IK,
   A->getOption().getID() == options::OPT_INPUT ||
   A->getOption().getID() == options::OPT_x ||
   A->getOption().getID() == options::OPT_fembed_bitcode ||
-  (A->getOption().getGroup().isValid() &&
-   A->getOption().getGroup().getID() == options::OPT_W_Group))
+  A->getOption().matches(options::OPT_W_Group))
 continue;
   ArgStringList ASL;
   A->render(Args, ASL);

diff  --git a/clang/test/Frontend/embed-bitcode.ll 
b/clang/test/Frontend/embed-bitcode.ll
index bd2afb44bb0f..75cdc5f657fc 100644
--- a/clang/test/Frontend/embed-bitcode.ll
+++ b/clang/test/Frontend/embed-bitcode.ll
@@ -37,6 +37,11 @@
 ; CHECK: @llvm.cmdline = private constant
 ; CHECK: section "__LLVM,__cmdline"
 
+; check warning options are not embedded
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - -Wall -Wundef-prefix=TEST \
+; RUN:| FileCheck %s -check-prefix=CHECK-WARNING
+
 ; CHECK-ELF: @llvm.embedded.module
 ; CHECK-ELF: section ".llvmbc"
 ; CHECK-ELF: @llvm.cmdline
@@ -54,6 +59,9 @@
 ; CHECK-MARKER: @llvm.cmdline
 ; CHECK-MARKER: section "__LLVM,__cmdline"
 
+; CHECK-WARNING-NOT: Wall
+; CHECK-WARNING-NOT: Wundef-prefix
+
 define i32 @f0() {
   ret i32 0
 }



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

[libunwind] 4cd0937 - [libunwind] Remove compatibility support for macOS 10.6

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2020-08-17T14:09:03-07:00
New Revision: 4cd09374cdb163573007ccb402f5ba8970eb6134

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

LOG: [libunwind] Remove compatibility support for macOS 10.6

Remove `_dyld_find_unwind_sections` implementation for macOS that is
10.6 or previous. 10.6 is no longer supported for TOT libunwind after
removing its libkeymgr dependency.

Reviewed By: mstorsjo, pete, #libunwind

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

Added: 


Modified: 
libunwind/src/AddressSpace.hpp

Removed: 




diff  --git a/libunwind/src/AddressSpace.hpp b/libunwind/src/AddressSpace.hpp
index 3d1e810f43c0..78d2dd110865 100644
--- a/libunwind/src/AddressSpace.hpp
+++ b/libunwind/src/AddressSpace.hpp
@@ -55,43 +55,9 @@ struct EHABIIndexEntry {
 const void* compact_unwind_section;
 uintptr_t   compact_unwind_section_length;
   };
-  #if (defined(__MAC_OS_X_VERSION_MIN_REQUIRED) \
- && (__MAC_OS_X_VERSION_MIN_REQUIRED >= 1070)) 
\
-  || defined(__IPHONE_OS_VERSION_MIN_REQUIRED)
-// In 10.7.0 or later, libSystem.dylib implements this function.
-extern "C" bool _dyld_find_unwind_sections(void *, dyld_unwind_sections *);
-  #else
-// In 10.6.x and earlier, we need to implement this functionality. Note
-// that this requires a newer version of libmacho (from cctools) than is
-// present in libSystem on 10.6.x (for getsectiondata).
-static inline bool _dyld_find_unwind_sections(void* addr,
-dyld_unwind_sections* 
info) {
-  // Find mach-o image containing address.
-  Dl_info dlinfo;
-  if (!dladdr(addr, &dlinfo))
-return false;
-#if __LP64__
-  const struct mach_header_64 *mh = (const struct mach_header_64 
*)dlinfo.dli_fbase;
-#else
-  const struct mach_header *mh = (const struct mach_header 
*)dlinfo.dli_fbase;
-#endif
-
-  // Initialize the return struct
-  info->mh = (const struct mach_header *)mh;
-  info->dwarf_section = getsectiondata(mh, "__TEXT", "__eh_frame", 
&info->dwarf_section_length);
-  info->compact_unwind_section = getsectiondata(mh, "__TEXT", 
"__unwind_info", &info->compact_unwind_section_length);
-
-  if (!info->dwarf_section) {
-info->dwarf_section_length = 0;
-  }
 
-  if (!info->compact_unwind_section) {
-info->compact_unwind_section_length = 0;
-  }
-
-  return true;
-}
-  #endif
+  // In 10.7.0 or later, libSystem.dylib implements this function.
+  extern "C" bool _dyld_find_unwind_sections(void *, dyld_unwind_sections *);
 
 #elif defined(_LIBUNWIND_SUPPORT_DWARF_UNWIND) && 
defined(_LIBUNWIND_IS_BAREMETAL)
 



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

[clang] 493766e - Frontend: Respect -working-directory when checking if output files can be written

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2022-09-09T08:57:12-07:00
New Revision: 493766e068474a80a790ac41c667061229d2262d

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

LOG: Frontend: Respect -working-directory when checking if output files can be 
written

Call `FixupRelativePath` when opening output files to ensure that
`-working-directory` is used when checking up front for write failures,
not just when finalizing the files at the end. This also moves the
temporary file into the same directory as the output file.

Reviewed By: benlangmuir

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

Added: 


Modified: 
clang/lib/Frontend/CompilerInstance.cpp
clang/test/Frontend/output-paths.c

Removed: 




diff  --git a/clang/lib/Frontend/CompilerInstance.cpp 
b/clang/lib/Frontend/CompilerInstance.cpp
index b187bdc044c08..995c94bb6912b 100644
--- a/clang/lib/Frontend/CompilerInstance.cpp
+++ b/clang/lib/Frontend/CompilerInstance.cpp
@@ -781,12 +781,7 @@ void CompilerInstance::clearOutputFiles(bool EraseFiles) {
   continue;
 }
 
-// If '-working-directory' was passed, the output filename should be
-// relative to that.
-SmallString<128> NewOutFile(OF.Filename);
-FileMgr->FixupRelativePath(NewOutFile);
-
-llvm::Error E = OF.File->keep(NewOutFile);
+llvm::Error E = OF.File->keep(OF.Filename);
 if (!E)
   continue;
 
@@ -849,6 +844,15 @@ CompilerInstance::createOutputFileImpl(StringRef 
OutputPath, bool Binary,
   assert((!CreateMissingDirectories || UseTemporary) &&
  "CreateMissingDirectories is only allowed when using temporary 
files");
 
+  // If '-working-directory' was passed, the output filename should be
+  // relative to that.
+  Optional> AbsPath;
+  if (OutputPath != "-" && !llvm::sys::path::is_absolute(OutputPath)) {
+AbsPath.emplace(OutputPath);
+FileMgr->FixupRelativePath(*AbsPath);
+OutputPath = *AbsPath;
+  }
+
   std::unique_ptr OS;
   Optional OSFile;
 

diff  --git a/clang/test/Frontend/output-paths.c 
b/clang/test/Frontend/output-paths.c
index 5b0cbb4d77cc4..836fe971de5e8 100644
--- a/clang/test/Frontend/output-paths.c
+++ b/clang/test/Frontend/output-paths.c
@@ -2,3 +2,12 @@
 // RUN: FileCheck -check-prefix=OUTPUTFAIL -DMSG=%errc_ENOENT -input-file=%t %s
 
 // OUTPUTFAIL: error: unable to open output file 
'{{.*}}doesnotexist{{.}}somename': '[[MSG]]'
+
+// Check that -working-directory is respected when diagnosing output failures.
+//
+// RUN: rm -rf %t.d && mkdir -p %t.d/%basename_t-inner.d
+// RUN: %clang_cc1 -emit-llvm -working-directory %t.d -E -o 
%basename_t-inner.d/somename %s -verify
+// expected-no-diagnostics
+
+// RUN: %clang_cc1 -working-directory %t.d -E %s -o - | FileCheck %s
+// CHECK: # 1



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

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

[Steven Wu via cfe-commits]

https://github.com/cachemeifyoucan edited 
https://github.com/llvm/llvm-project/pull/74782
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

[Steven Wu via cfe-commits]

https://github.com/cachemeifyoucan approved this pull request.

LGTM with small comments.

https://github.com/llvm/llvm-project/pull/74782
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

[Steven Wu via cfe-commits]

@@ -2466,15 +2466,21 @@ Preprocessor::ImportAction 
Preprocessor::HandleHeaderIncludeOrImport(
 // The drive letter is optional for absolute paths on Windows, but
 // clang currently cannot process absolute paths in #include lines that
 // don't have a drive.
-// If the first entry in Components is a directory separator,
-// then the code at the bottom of this loop that keeps the original
-// directory separator style copies it. If the second entry is
-// a directory separator (the C:\ case), then that separator already
-// got copied when the C: was processed and we want to skip that entry.
-if (!(Component.size() == 1 && IsSep(Component[0])))
+if (Component.size() == 1 && IsSep(Component[0])) {
+  // Note: Path always contains at least '<' or '"'.
+  if (Path.size() == 1) {

cachemeifyoucan wrote:

I will just do:
`Path.size() != 1` and `continue`. Do an if condition with just comments as 
body is weird, you can add the comments after the if inverse condition instead.

https://github.com/llvm/llvm-project/pull/74782
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

[Steven Wu via cfe-commits]

@@ -2466,15 +2466,21 @@ Preprocessor::ImportAction 
Preprocessor::HandleHeaderIncludeOrImport(
 // The drive letter is optional for absolute paths on Windows, but
 // clang currently cannot process absolute paths in #include lines that
 // don't have a drive.
-// If the first entry in Components is a directory separator,
-// then the code at the bottom of this loop that keeps the original
-// directory separator style copies it. If the second entry is
-// a directory separator (the C:\ case), then that separator already
-// got copied when the C: was processed and we want to skip that entry.
-if (!(Component.size() == 1 && IsSep(Component[0])))
+if (Component.size() == 1 && IsSep(Component[0])) {
+  // Note: Path always contains at least '<' or '"'.
+  if (Path.size() == 1) {
+// If the first entry in Components is a directory separator,
+// then the code at the bottom of this loop that keeps the original
+// directory separator style copies it.
+  } else {
+// If the second entry is a directory separator (the C:\ case),
+// then that separator already got copied when the C: was processed
+// and we want to skip that entry.
+continue;
+  }
+} else {
   Path.append(Component);
-else if (!Path.empty())
-  continue;
+}

cachemeifyoucan wrote:

Don't need to spell out `{}` for a single line body.

https://github.com/llvm/llvm-project/pull/74782
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

[Steven Wu via cfe-commits]

@@ -2466,15 +2466,21 @@ Preprocessor::ImportAction 
Preprocessor::HandleHeaderIncludeOrImport(
 // The drive letter is optional for absolute paths on Windows, but
 // clang currently cannot process absolute paths in #include lines that
 // don't have a drive.
-// If the first entry in Components is a directory separator,
-// then the code at the bottom of this loop that keeps the original
-// directory separator style copies it. If the second entry is
-// a directory separator (the C:\ case), then that separator already
-// got copied when the C: was processed and we want to skip that entry.
-if (!(Component.size() == 1 && IsSep(Component[0])))
+if (Component.size() == 1 && IsSep(Component[0])) {
+  // Note: Path always contains at least '<' or '"'.
+  if (Path.size() == 1) {

cachemeifyoucan wrote:

I feel better if the comment just explains both branches, instead of using `if` 
to separate comments. I might even consider write a big block to combine with 
the comments before `if (Component.size() == 1 && IsSep(Component[0]))`. I 
don't feel the this code is very easy to understand with current comment.

https://github.com/llvm/llvm-project/pull/74782
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [ClangModule] Fix decl-params-determinisim test after serialization change (PR #72572)

[Steven Wu via cfe-commits]

https://github.com/cachemeifyoucan created 
https://github.com/llvm/llvm-project/pull/72572

Fix decl-params-determinisim test after 48be81e1 packed some information in the 
clang module. The test is to make sure the decls are appearing in a strict 
ordering and it relies on check the correct field in the bitcode format.

Add more explanation in the comments to help future updates when serialization 
format affects this test.

>From 89938936f2e021360e3889548608e76022c3d73b Mon Sep 17 00:00:00 2001
From: Steven Wu 
Date: Thu, 16 Nov 2023 13:21:27 -0800
Subject: [PATCH] [ClangModule] Fix decl-params-determinisim test after
 serialization change

Fix decl-params-determinisim test after 48be81e1 packed some information
in the clang module. The test is to make sure the decls are appearing in
a strict ordering and it relies on check the correct field in the
bitcode format.

Add more explanation in the comments to help future updates when
serialization format affects this test.
---
 clang/test/Modules/decl-params-determinisim.m | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/clang/test/Modules/decl-params-determinisim.m 
b/clang/test/Modules/decl-params-determinisim.m
index ccad40b98d8edf4..be8c92e587cade1 100644
--- a/clang/test/Modules/decl-params-determinisim.m
+++ b/clang/test/Modules/decl-params-determinisim.m
@@ -23,27 +23,28 @@
 
 /// NOTE: This test case is on determinism of TypeID for function declaration.
 /// Change related to TypeID (or PredefinedTypeIDs) will affect the result and
-/// will require update for this test case.
+/// will require update for this test case. Currently, TypeID is at op6 and the
+/// test checks the IDs are in strict ordering.
 
 // CHECK: https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [ClangModule] Fix decl-params-determinisim test after serialization change (PR #72572)

[Steven Wu via cfe-commits]

https://github.com/cachemeifyoucan updated 
https://github.com/llvm/llvm-project/pull/72572

>From 89938936f2e021360e3889548608e76022c3d73b Mon Sep 17 00:00:00 2001
From: Steven Wu 
Date: Thu, 16 Nov 2023 13:21:27 -0800
Subject: [PATCH 1/2] [ClangModule] Fix decl-params-determinisim test after
 serialization change

Fix decl-params-determinisim test after 48be81e1 packed some information
in the clang module. The test is to make sure the decls are appearing in
a strict ordering and it relies on check the correct field in the
bitcode format.

Add more explanation in the comments to help future updates when
serialization format affects this test.
---
 clang/test/Modules/decl-params-determinisim.m | 19 ++-
 1 file changed, 10 insertions(+), 9 deletions(-)

diff --git a/clang/test/Modules/decl-params-determinisim.m 
b/clang/test/Modules/decl-params-determinisim.m
index ccad40b98d8edf4..be8c92e587cade1 100644
--- a/clang/test/Modules/decl-params-determinisim.m
+++ b/clang/test/Modules/decl-params-determinisim.m
@@ -23,27 +23,28 @@
 
 /// NOTE: This test case is on determinism of TypeID for function declaration.
 /// Change related to TypeID (or PredefinedTypeIDs) will affect the result and
-/// will require update for this test case.
+/// will require update for this test case. Currently, TypeID is at op6 and the
+/// test checks the IDs are in strict ordering.
 
 // CHECK: From c13f8684239281896d3d3572ea90b9b1e941d755 Mon Sep 17 00:00:00 2001
From: Steven Wu 
Date: Thu, 16 Nov 2023 14:01:30 -0800
Subject: [PATCH 2/2] fixup! [ClangModule] Fix decl-params-determinisim test
 after serialization change

---
 clang/test/Modules/decl-params-determinisim.m | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/clang/test/Modules/decl-params-determinisim.m 
b/clang/test/Modules/decl-params-determinisim.m
index be8c92e587cade1..351403d9af947e2 100644
--- a/clang/test/Modules/decl-params-determinisim.m
+++ b/clang/test/Modules/decl-params-determinisim.m
@@ -19,7 +19,7 @@
 // RUN: diff %t1.pcm %t2.pcm
 
 /// Spot check entries to make sure they are in current ordering.
-/// op13 encodes the anonymous decl number which should be in order.
+/// op6 encodes the anonymous decl number which should be in order.
 
 /// NOTE: This test case is on determinism of TypeID for function declaration.
 /// Change related to TypeID (or PredefinedTypeIDs) will affect the result and

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

[clang] [ClangModule] Fix decl-params-determinisim test after serialization change (PR #72572)

[Steven Wu via cfe-commits]

https://github.com/cachemeifyoucan closed 
https://github.com/llvm/llvm-project/pull/72572
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][lex] Fix non-portability diagnostics with absolute path (PR #74782)

[Steven Wu via cfe-commits]

https://github.com/cachemeifyoucan approved this pull request.


https://github.com/llvm/llvm-project/pull/74782
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] d072826 - [Darwin toolchain] Tune the logic for finding arclite.

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2022-07-20T16:45:52-07:00
New Revision: d0728260577d66b4b4d922adf0a40de86f09ccf5

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

LOG: [Darwin toolchain] Tune the logic for finding arclite.

The heuristic used to determine where the arclite libraries are to be
found was based on the path of the `clang` executable. However, in some
scenarios the `clang` executable is within a toolchain that does not
have arclite. When this happens, derive the arclite paths from the
sysroot option.

This allows Clang to correctly derive the arclite directory in, e.g.,
Swift CI, using similar logic to what the Swift driver has been doing
for several years.

Patched by Doug Gregor.

Reviewed By: keith

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

Added: 


Modified: 
clang/lib/Driver/ToolChains/Darwin.cpp

Removed: 




diff  --git a/clang/lib/Driver/ToolChains/Darwin.cpp 
b/clang/lib/Driver/ToolChains/Darwin.cpp
index 71b0c5bc9c71..bada811daadf 100644
--- a/clang/lib/Driver/ToolChains/Darwin.cpp
+++ b/clang/lib/Driver/ToolChains/Darwin.cpp
@@ -1141,25 +1141,38 @@ void DarwinClang::AddLinkARCArgs(const ArgList &Args,
   SmallString<128> P(getDriver().ClangExecutable);
   llvm::sys::path::remove_filename(P); // 'clang'
   llvm::sys::path::remove_filename(P); // 'bin'
+  llvm::sys::path::append(P, "lib", "arc");
 
   // 'libarclite' usually lives in the same toolchain as 'clang'. However, the
   // Swift open source toolchains for macOS distribute Clang without 
libarclite.
   // In that case, to allow the linker to find 'libarclite', we point to the
   // 'libarclite' in the XcodeDefault toolchain instead.
-  if (getXcodeDeveloperPath(P).empty()) {
-if (const Arg *A = Args.getLastArg(options::OPT_isysroot)) {
+  if (!getVFS().exists(P)) {
+auto updatePath = [&](const Arg *A) {
   // Try to infer the path to 'libarclite' in the toolchain from the
   // specified SDK path.
   StringRef XcodePathForSDK = getXcodeDeveloperPath(A->getValue());
-  if (!XcodePathForSDK.empty()) {
-P = XcodePathForSDK;
-llvm::sys::path::append(P, "Toolchains/XcodeDefault.xctoolchain/usr");
-  }
+  if (XcodePathForSDK.empty())
+return false;
+
+  P = XcodePathForSDK;
+  llvm::sys::path::append(P, "Toolchains/XcodeDefault.xctoolchain/usr",
+  "lib", "arc");
+  return getVFS().exists(P);
+};
+
+bool updated = false;
+if (const Arg *A = Args.getLastArg(options::OPT_isysroot))
+  updated = updatePath(A);
+
+if (!updated) {
+  if (const Arg *A = Args.getLastArg(options::OPT__sysroot_EQ))
+updatePath(A);
 }
   }
 
   CmdArgs.push_back("-force_load");
-  llvm::sys::path::append(P, "lib", "arc", "libarclite_");
+  llvm::sys::path::append(P, "libarclite_");
   // Mash in the platform.
   if (isTargetWatchOSSimulator())
 P += "watchsimulator";



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

[clang] [clang][Darwin] Handle reexported library arguments in driver (PR #86980)

[Steven Wu via cfe-commits]

https://github.com/cachemeifyoucan approved this pull request.


https://github.com/llvm/llvm-project/pull/86980
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 9cd6fbe - Fix module build after TargetParser

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2022-12-20T10:31:19-08:00
New Revision: 9cd6fbee7ed881f8e80b735e95567040e56f189e

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

LOG: Fix module build after TargetParser

Need to include the textual header from the correct module.

Added: 


Modified: 
clang/lib/Basic/Targets/X86.cpp
clang/lib/CodeGen/CGBuiltin.cpp
llvm/lib/Analysis/SyncDependenceAnalysis.cpp

Removed: 




diff  --git a/clang/lib/Basic/Targets/X86.cpp b/clang/lib/Basic/Targets/X86.cpp
index b0802b2e37b4..ebbbef2ed005 100644
--- a/clang/lib/Basic/Targets/X86.cpp
+++ b/clang/lib/Basic/Targets/X86.cpp
@@ -1123,7 +1123,7 @@ bool X86TargetInfo::hasFeature(StringRef Feature) const {
 bool X86TargetInfo::validateCpuSupports(StringRef FeatureStr) const {
   return llvm::StringSwitch(FeatureStr)
 #define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY) .Case(STR, true)
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
   .Default(false);
 }
 
@@ -1132,7 +1132,7 @@ static llvm::X86::ProcessorFeatures getFeature(StringRef 
Name) {
 #define X86_FEATURE_COMPAT(ENUM, STR, PRIORITY)
\
   .Case(STR, llvm::X86::FEATURE_##ENUM)
 
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
   ;
   // Note, this function should only be used after ensuring the value is
   // correct, so it asserts if the value is out of range.
@@ -1157,21 +1157,21 @@ bool 
X86TargetInfo::validateCPUSpecificCPUDispatch(StringRef Name) const {
   return llvm::StringSwitch(Name)
 #define CPU_SPECIFIC(NAME, TUNE_NAME, MANGLING, FEATURES) .Case(NAME, true)
 #define CPU_SPECIFIC_ALIAS(NEW_NAME, TUNE_NAME, NAME) .Case(NEW_NAME, true)
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
   .Default(false);
 }
 
 static StringRef CPUSpecificCPUDispatchNameDealias(StringRef Name) {
   return llvm::StringSwitch(Name)
 #define CPU_SPECIFIC_ALIAS(NEW_NAME, TUNE_NAME, NAME) .Case(NEW_NAME, NAME)
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
   .Default(Name);
 }
 
 char X86TargetInfo::CPUSpecificManglingCharacter(StringRef Name) const {
   return llvm::StringSwitch(CPUSpecificCPUDispatchNameDealias(Name))
 #define CPU_SPECIFIC(NAME, TUNE_NAME, MANGLING, FEATURES) .Case(NAME, MANGLING)
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
   .Default(0);
 }
 
@@ -1180,7 +1180,7 @@ void X86TargetInfo::getCPUSpecificCPUDispatchFeatures(
   StringRef WholeList =
   llvm::StringSwitch(CPUSpecificCPUDispatchNameDealias(Name))
 #define CPU_SPECIFIC(NAME, TUNE_NAME, MANGLING, FEATURES) .Case(NAME, FEATURES)
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
   .Default("");
   WholeList.split(Features, ',', /*MaxSplit=*/-1, /*KeepEmpty=*/false);
 }
@@ -1189,7 +1189,7 @@ StringRef X86TargetInfo::getCPUSpecificTuneName(StringRef 
Name) const {
   return llvm::StringSwitch(Name)
 #define CPU_SPECIFIC(NAME, TUNE_NAME, MANGLING, FEATURES) .Case(NAME, 
TUNE_NAME)
 #define CPU_SPECIFIC_ALIAS(NEW_NAME, TUNE_NAME, NAME) .Case(NEW_NAME, 
TUNE_NAME)
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
   .Default("");
 }
 
@@ -1204,7 +1204,7 @@ bool X86TargetInfo::validateCpuIs(StringRef FeatureStr) 
const {
 #define X86_CPU_TYPE(ENUM, STR) .Case(STR, true)
 #define X86_CPU_SUBTYPE_ALIAS(ENUM, ALIAS) .Case(ALIAS, true)
 #define X86_CPU_SUBTYPE(ENUM, STR) .Case(STR, true)
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
   .Default(false);
 }
 

diff  --git a/clang/lib/CodeGen/CGBuiltin.cpp b/clang/lib/CodeGen/CGBuiltin.cpp
index 7cf7bd2c21f4..ed782de5400a 100644
--- a/clang/lib/CodeGen/CGBuiltin.cpp
+++ b/clang/lib/CodeGen/CGBuiltin.cpp
@@ -12956,7 +12956,7 @@ Value *CodeGenFunction::EmitX86CpuIs(StringRef CPUStr) {
   .Case(ALIAS, {2u, static_cast(llvm::X86::ENUM)})
 #define X86_CPU_SUBTYPE(ENUM, STR) 
\
   .Case(STR, {2u, static_cast(llvm::X86::ENUM)})
-#include "llvm/Support/X86TargetParser.def"
+#include "llvm/TargetParser/X86TargetParser.def"
.Default({0, 0});
   assert(Value != 0 && "Invalid CPUStr passed to CpuIs");
 

diff  --git a/llvm/lib/Analysis/SyncDependenceAnalysis.cpp 
b/llvm/lib/Analysis/SyncDependenceAnalysis.cpp
index 3446e50a4344..17d7676024a5 100644
--- a/llvm/lib/Analysis/SyncDependenceAnalysis.cpp
+++ b/llvm/lib/Analysis/SyncDependenceAnalysis.cpp
@@ -257,6 +257,7 @@ SyncDependenceAnalysis::SyncDependenceAnalysis(const 
DominatorTree &DT,
 
 SyncDepe

[clang] 516e301 - [NFC][Profile] Access profile through VirtualFileSystem

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2023-02-01T09:25:02-08:00
New Revision: 516e301752560311d2cd8c2b549493eb0f98d01b

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

LOG: [NFC][Profile] Access profile through VirtualFileSystem

Make the access to profile data going through virtual file system so the
inputs can be remapped. In the context of the caching, it can make sure
we capture the inputs and provided an immutable input as profile data.

Reviewed By: akyrtzi, benlangmuir

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

Added: 
llvm/lib/Support/PGOOptions.cpp

Modified: 
clang/include/clang/CodeGen/BackendUtil.h
clang/lib/CodeGen/BackendUtil.cpp
clang/lib/CodeGen/CodeGenAction.cpp
clang/lib/CodeGen/CodeGenModule.cpp
clang/lib/CodeGen/ObjectFilePCHContainerOperations.cpp
clang/lib/Frontend/CompilerInvocation.cpp
llvm/include/llvm/CodeGen/MIRSampleProfile.h
llvm/include/llvm/CodeGen/Passes.h
llvm/include/llvm/Passes/PassBuilder.h
llvm/include/llvm/ProfileData/Coverage/CoverageMapping.h
llvm/include/llvm/ProfileData/InstrProfReader.h
llvm/include/llvm/ProfileData/SampleProfReader.h
llvm/include/llvm/Support/PGOOptions.h
llvm/include/llvm/Transforms/IPO/SampleProfile.h
llvm/include/llvm/Transforms/Instrumentation/PGOInstrumentation.h
llvm/include/llvm/Transforms/Utils/SampleProfileLoaderBaseImpl.h
llvm/lib/CodeGen/MIRSampleProfile.cpp
llvm/lib/CodeGen/TargetPassConfig.cpp
llvm/lib/LTO/LTOBackend.cpp
llvm/lib/Passes/PassBuilderPipelines.cpp
llvm/lib/ProfileData/Coverage/CoverageMapping.cpp
llvm/lib/ProfileData/InstrProf.cpp
llvm/lib/ProfileData/InstrProfReader.cpp
llvm/lib/ProfileData/SampleProfReader.cpp
llvm/lib/Support/CMakeLists.txt
llvm/lib/Target/X86/X86InsertPrefetch.cpp
llvm/lib/Transforms/IPO/SampleProfile.cpp
llvm/lib/Transforms/Instrumentation/PGOInstrumentation.cpp
llvm/tools/llvm-cov/CodeCoverage.cpp
llvm/tools/llvm-profdata/llvm-profdata.cpp
llvm/tools/llvm-profgen/llvm-profgen.cpp
llvm/tools/opt/NewPMDriver.cpp
llvm/unittests/ProfileData/SampleProfTest.cpp

Removed: 




diff  --git a/clang/include/clang/CodeGen/BackendUtil.h 
b/clang/include/clang/CodeGen/BackendUtil.h
index d97af65a3d01..cdbfe4ca5e65 100644
--- a/clang/include/clang/CodeGen/BackendUtil.h
+++ b/clang/include/clang/CodeGen/BackendUtil.h
@@ -16,8 +16,12 @@
 namespace llvm {
   class BitcodeModule;
   template  class Expected;
+  template  class IntrusiveRefCntPtr;
   class Module;
   class MemoryBufferRef;
+  namespace vfs {
+  class FileSystem;
+  } // namespace vfs
 }
 
 namespace clang {
@@ -40,6 +44,7 @@ namespace clang {
  const CodeGenOptions &CGOpts,
  const TargetOptions &TOpts, const LangOptions &LOpts,
  StringRef TDesc, llvm::Module *M, BackendAction 
Action,
+ llvm::IntrusiveRefCntPtr VFS,
  std::unique_ptr OS);
 
   void EmbedBitcode(llvm::Module *M, const CodeGenOptions &CGOpts,

diff  --git a/clang/lib/CodeGen/BackendUtil.cpp 
b/clang/lib/CodeGen/BackendUtil.cpp
index 10d6bff25e6d..2b43d0e38bf7 100644
--- a/clang/lib/CodeGen/BackendUtil.cpp
+++ b/clang/lib/CodeGen/BackendUtil.cpp
@@ -52,6 +52,7 @@
 #include "llvm/Support/TimeProfiler.h"
 #include "llvm/Support/Timer.h"
 #include "llvm/Support/ToolOutputFile.h"
+#include "llvm/Support/VirtualFileSystem.h"
 #include "llvm/Support/raw_ostream.h"
 #include "llvm/Target/TargetMachine.h"
 #include "llvm/Target/TargetOptions.h"
@@ -123,6 +124,7 @@ class EmitAssemblyHelper {
   const clang::TargetOptions &TargetOpts;
   const LangOptions &LangOpts;
   Module *TheModule;
+  IntrusiveRefCntPtr VFS;
 
   Timer CodeGenerationTime;
 
@@ -187,9 +189,10 @@ class EmitAssemblyHelper {
  const HeaderSearchOptions &HeaderSearchOpts,
  const CodeGenOptions &CGOpts,
  const clang::TargetOptions &TOpts,
- const LangOptions &LOpts, Module *M)
+ const LangOptions &LOpts, Module *M,
+ IntrusiveRefCntPtr VFS)
   : Diags(_Diags), HSOpts(HeaderSearchOpts), CodeGenOpts(CGOpts),
-TargetOpts(TOpts), LangOpts(LOpts), TheModule(M),
+TargetOpts(TOpts), LangOpts(LOpts), TheModule(M), VFS(std::move(VFS)),
 CodeGenerationTime("codegen", "Code Generation Time"),
 TargetTriple(TheModule->getTargetTriple()) {}
 
@@ -767,32 +770,33 @@ void EmitAssemblyHelper::RunOptimizationPipeline(
 
   if (CodeGenOpts.hasProfileIRInstr())
 // -fprofile-generate.
-PGOOpt = PGOOptions(CodeGenOpts.InstrProfileOutput.empty()
-? getDefaultProfileGenName()
-

[clang] 5cff68f - [Module] Respect `-fno-pch-timestamps` when building modules

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2023-02-01T10:34:35-08:00
New Revision: 5cff68fca0bc21ccad20cc7c8fb9845e32b4c925

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

LOG: [Module] Respect `-fno-pch-timestamps` when building modules

Always respect the FrontendOption to not include timestamps in PCH or
Modules when `-fno-pch-timestamps` is specified.

Reviewed By: benlangmuir

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

Added: 
clang/test/Modules/timestamps.c

Modified: 
clang/lib/Frontend/FrontendActions.cpp

Removed: 




diff  --git a/clang/lib/Frontend/FrontendActions.cpp 
b/clang/lib/Frontend/FrontendActions.cpp
index 2d81178fa60e2..b5e868fd67687 100644
--- a/clang/lib/Frontend/FrontendActions.cpp
+++ b/clang/lib/Frontend/FrontendActions.cpp
@@ -202,7 +202,8 @@ GenerateModuleAction::CreateASTConsumer(CompilerInstance 
&CI,
   /*AllowASTWithErrors=*/
   +CI.getFrontendOpts().AllowPCMWithCompilerErrors,
   /*IncludeTimestamps=*/
-  +CI.getFrontendOpts().BuildingImplicitModule,
+  +CI.getFrontendOpts().BuildingImplicitModule &&
+  +CI.getFrontendOpts().IncludeTimestamps,
   /*ShouldCacheASTInMemory=*/
   +CI.getFrontendOpts().BuildingImplicitModule));
   Consumers.push_back(CI.getPCHContainerWriter().CreatePCHContainerGenerator(

diff  --git a/clang/test/Modules/timestamps.c b/clang/test/Modules/timestamps.c
new file mode 100644
index 0..5315750b81590
--- /dev/null
+++ b/clang/test/Modules/timestamps.c
@@ -0,0 +1,30 @@
+/// Verify timestamps that gets embedded in the module
+#include 
+
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fdisable-module-hash \
+// RUN:   -fmodules-cache-path=%t -I %S/Inputs %s
+// RUN: cp %t/c_library.pcm %t1.pcm
+// RUN: llvm-bcanalyzer --dump --disable-histogram %t1.pcm > %t1.dump
+// RUN: FileCheck %s --check-prefix=CHECK --check-prefix=TIMESTAMP 
--input-file %t1.dump
+// RUN: rm -rf %t
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -fdisable-module-hash \
+// RUN:   -fmodules-cache-path=%t -I %S/Inputs -fno-pch-timestamp %s
+// RUN: cp %t/c_library.pcm %t2.pcm
+// RUN: llvm-bcanalyzer --dump --disable-histogram %t2.pcm > %t2.dump
+// RUN: FileCheck %s --check-prefix=CHECK --check-prefix=NOTIMESTAMP 
--input-file %t2.dump
+// RUN: not 
diff  %t1.dump %t2.dump
+
+
+// CHECK: 
+// CHECK-NEXT: 
+// CHECK-NEXT: 
+// CHECK-NEXT: 



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

[clang] 0480748 - [DeclContext] Sort the Decls before adding into DeclContext

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2023-02-02T15:16:20-08:00
New Revision: 0480748ea6728392886931b8470969ae17aaa91f

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

LOG: [DeclContext] Sort the Decls before adding into DeclContext

Fix a non-deterministic issue in clang module generation, which the
anonymous declaration number from a function context is not
deterministic. This is due to the unstable iteration order for decls in
scope so the order after moving the decls into function decl context is
not deterministic.

>From https://reviews.llvm.org/D135118, we can't use a set that preserves
the order without the performance penalty. Fix the issue by sorting the
decls based on raw encoding of their source location.

rdar://104097976

Reviewed By: akyrtzi, vsapsai

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

Added: 
clang/test/Modules/decl-params-determinisim.m

Modified: 
clang/lib/Parse/ParseDecl.cpp

Removed: 




diff  --git a/clang/lib/Parse/ParseDecl.cpp b/clang/lib/Parse/ParseDecl.cpp
index e6812ac72c885..96c25ba0c853c 100644
--- a/clang/lib/Parse/ParseDecl.cpp
+++ b/clang/lib/Parse/ParseDecl.cpp
@@ -6987,6 +6987,15 @@ void Parser::ParseFunctionDeclarator(Declarator &D,
 continue;
   DeclsInPrototype.push_back(ND);
 }
+// Sort DeclsInPrototype based on raw encoding of the source location.
+// Scope::decls() is iterating over a SmallPtrSet so sort the Decls before
+// moving to DeclContext. This provides a stable ordering for traversing
+// Decls in DeclContext, which is important for tasks like ASTWriter for
+// deterministic output.
+llvm::sort(DeclsInPrototype, [](Decl *D1, Decl *D2) {
+  return D1->getLocation().getRawEncoding() <
+ D2->getLocation().getRawEncoding();
+});
   }
 
   // Remember that we parsed a function type, and remember the attributes.

diff  --git a/clang/test/Modules/decl-params-determinisim.m 
b/clang/test/Modules/decl-params-determinisim.m
new file mode 100644
index 0..d7e873bb4938e
--- /dev/null
+++ b/clang/test/Modules/decl-params-determinisim.m
@@ -0,0 +1,96 @@
+/// Test determinisim when serializing anonymous decls. Create enough Decls in
+/// DeclContext that can overflow the small storage of SmallPtrSet to make sure
+/// the serialization does not rely on iteration order of SmallPtrSet.
+// RUN: rm -rf %t.dir
+// RUN: split-file %s %t.dir
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps \
+// RUN:   -fmodules-cache-path=%t.dir/cache -triple x86_64-apple-macosx10.11.0 
\
+// RUN:   -I%t.dir/headers %t.dir/main.m -fdisable-module-hash -Wno-visibility
+// RUN: mv %t.dir/cache/A.pcm %t1.pcm
+/// Check the order of the decls first. If LLVM_ENABLE_REVERSE_ITERATION is on,
+/// it will fail the test early if the output is depending on the order of 
items
+/// in containers that has non-deterministic orders.
+// RUN: llvm-bcanalyzer --dump --disable-histogram %t1.pcm | FileCheck %s
+// RUN: rm -rf %t.dir/cache
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps \
+// RUN:   -fmodules-cache-path=%t.dir/cache -triple x86_64-apple-macosx10.11.0 
\
+// RUN:   -I%t.dir/headers %t.dir/main.m -fdisable-module-hash -Wno-visibility
+// RUN: mv %t.dir/cache/A.pcm %t2.pcm
+// RUN: 
diff  %t1.pcm %t2.pcm
+
+/// Spot check entries to make sure they are in current ordering.
+/// op13 encodes the anonymous decl number which should be in order.
+// CHECK: 
+



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

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

[Steven Wu via cfe-commits]

https://github.com/cachemeifyoucan commented:

I haven't read the PR in details but one thing we found difficult to do is how 
to write a test for daemon spawning logic, because if anything went wrong, you 
left an unbounded daemon process on CI node.

The strategy in this PR (try to kill it after the test finishes) definitely 
doesn't work because 1. if anything failed, you will not hit kill. 2. you are 
going to kill the daemon from a different test that runs in parallel.

Other things we tried and know didn't work:
* explicitly start/stop daemon with command: you might not hit stop due to 
failure
* have a timeout and let the daemon terminate after that: you can have some 
infinite loop that prevents daemon cleanup

What we ended up is to have a server process that spawns clang job that needs 
to talk to it. We eliminated the run off daemons but we don't really have 
coverage for how clang spawns a daemon when needed.

https://github.com/llvm/llvm-project/pull/67562
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

[Steven Wu via cfe-commits]

@@ -0,0 +1,302 @@
+//===--- cc1modbuildd_main.cpp - Clang CC1 Module Build Daemon 
===//
+//
+// 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
+//
+//===--===//
+
+#include "clang/Tooling/ModuleBuildDaemon/SocketMsgSupport.h"
+#include "clang/Tooling/ModuleBuildDaemon/SocketSupport.h"
+#include "clang/Tooling/ModuleBuildDaemon/Utils.h"
+#include "llvm/ADT/ArrayRef.h"
+#include "llvm/ADT/SmallString.h"
+#include "llvm/Support/Program.h"
+#include "llvm/Support/ThreadPool.h"
+#include "llvm/Support/Threading.h"
+#include "llvm/Support/YAMLParser.h"
+#include "llvm/Support/YAMLTraits.h"
+
+// TODO: Make portable
+#if LLVM_ON_UNIX
+
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+#include 
+
+using namespace llvm;
+using namespace clang;
+using namespace cc1modbuildd;
+
+// Create unbuffered STDOUT stream so that any logging done by module build
+// daemon can be viewed without having to terminate the process
+static raw_fd_ostream &unbuff_outs() {
+  static raw_fd_ostream S(STDOUT_FILENO, false, true);
+  return S;
+}
+
+namespace {
+
+struct ClientConnection {
+  int ClientFD;
+  std::string Buffer;
+};
+
+class ModuleBuildDaemonServer {
+public:
+  SmallString<256> SocketPath;
+  SmallString<256> STDERR;
+  SmallString<256> STDOUT;
+
+  ModuleBuildDaemonServer(StringRef Path, ArrayRef Argv)
+  : SocketPath(Path), STDERR(Path), STDOUT(Path) {
+llvm::sys::path::append(SocketPath, SOCKET_FILE_NAME);
+llvm::sys::path::append(STDOUT, STDOUT_FILE_NAME);
+llvm::sys::path::append(STDERR, STDERR_FILE_NAME);
+  }
+
+  ~ModuleBuildDaemonServer() { shutdownDaemon(); }
+
+  int forkDaemon();
+  int createDaemonSocket();
+  int listenForClients();
+
+  static void handleClient(ClientConnection Connection);
+
+  void shutdownDaemon() {
+int SocketFD = ListenSocketFD.load();
+
+unlink(SocketPath.c_str());
+shutdown(SocketFD, SHUT_RD);
+close(SocketFD);
+exit(EXIT_SUCCESS);

cachemeifyoucan wrote:

Right, I like a soft shutdown mode, which daemon can still finish jobs that are 
in process but not accepting new jobs, at the same time, allows a new daemon to 
spawn and start working before it completely terminates itself.

https://github.com/llvm/llvm-project/pull/67562
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [clang][MBD] set up module build daemon infrastructure (PR #67562)

[Steven Wu via cfe-commits]

cachemeifyoucan wrote:

> Implementing a timeout as part of this patch as a safety measure seems worth 
> while too but I'm not sure I understand your final solution. You all spawned 
> a clang job that had to communicate with the daemon to make sure one did not 
> exist?

It is something like this: 
https://github.com/apple/llvm-project/blob/next/clang/test/CAS/fdepscan-daemon.c

The "daemon" binary can be launched as a normal process and it takes `--` 
option, which has the arguments of the clang process it needs to run that talk 
to itself. The lifetime of the "daemon" is now bounded to that normal process 
and will not be left behind after testing is done.

https://github.com/llvm/llvm-project/pull/67562
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] [Support] Add VirtualOutputBackends to virtualize the output from tools (PR #68447)

[Steven Wu via cfe-commits]

@@ -0,0 +1,158 @@
+//===- raw_ostream_proxy.h - Proxies for raw output streams -*- C++ 
-*-===//
+//
+// 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
+//
+//===--===//
+
+#ifndef LLVM_SUPPORT_RAW_OSTREAM_PROXY_H
+#define LLVM_SUPPORT_RAW_OSTREAM_PROXY_H
+
+#include "llvm/Support/raw_ostream.h"
+
+namespace llvm {
+
+/// Common bits for \a raw_ostream_proxy_adaptor<>, split out to dedup in
+/// template instantions.
+class raw_ostream_proxy_adaptor_base {
+protected:
+  raw_ostream_proxy_adaptor_base() = delete;
+  raw_ostream_proxy_adaptor_base(const raw_ostream_proxy_adaptor_base &) =
+  delete;
+
+  explicit raw_ostream_proxy_adaptor_base(raw_ostream &OS)
+  : OS(&OS), PreferredBufferSize(OS.GetBufferSize()) {
+// Drop OS's buffer to make this->flush() forward. This proxy will add a
+// buffer in its place.
+OS.SetUnbuffered();
+  }
+
+  ~raw_ostream_proxy_adaptor_base() {
+assert(!OS && "Derived objects should call resetProxiedOS()");
+  }
+
+  /// Stop proxying the stream, taking the derived object by reference as \p
+  /// ThisProxyOS.  Updates \p ThisProxyOS to stop buffering before setting \a
+  /// OS to \c nullptr, ensuring that future writes crash immediately.
+  void resetProxiedOS(raw_ostream &ThisProxyOS) {
+ThisProxyOS.SetUnbuffered();
+OS = nullptr;
+  }
+
+  bool hasProxiedOS() const { return OS; }
+  raw_ostream &getProxiedOS() const {
+assert(OS && "raw_ostream_proxy_adaptor use after reset");
+return *OS;
+  }
+  size_t getPreferredBufferSize() const { return PreferredBufferSize; }
+
+private:
+  raw_ostream *OS;
+
+  /// Caches the value of OS->GetBufferSize() at construction time.
+  size_t PreferredBufferSize;
+};
+
+/// Adaptor to create a stream class that proxies another \a raw_ostream.

cachemeifyoucan wrote:

The goal for this class is to bridge some current usages of raw_ostream output 
to use VirtualOutputBackend/VirtualOutputFile. It would make more sense if look 
at it together with the 2nd commit.

After virtualizing the output, we have `VirtualOutputFile` that represents the 
output from llvm tools and the file can be `keep()` or `discard()` with proper 
error handling, etc. `VirtualOutputFile` should be owning the underlying output 
stream, for example, `raw_fd_ostream`. On the other hand, there are certain 
function/tool want to own its output stream, and a proxy to the actual 
underlying output stream can be created from `VirtualOutputFile` and the proxy 
can be owned by other part of the code.

Of course, when the `VirtualOutputFile` going to close the owning stream, it 
will make sure all proxies will be close and further write to the proxy will 
cause crash. This actually caught some bugs in our tools.

https://github.com/llvm/llvm-project/pull/68447
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[clang] 4098e13 - Revert "[clang][DeclPrinter] Fix missing semicolon in AST print for methods that are definitions without having a body"

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2023-07-28T11:39:46-07:00
New Revision: 4098e13a71464cc4747528edd8a41e5a4eaa1b23

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

LOG: Revert "[clang][DeclPrinter] Fix missing semicolon in AST print for 
methods that are definitions without having a body"

This reverts commit a3da6284c23affdd9092b2641017e99d85c2d89b. It breaks
tests on macOS as macOS doesn't support attribute alias.

Added: 


Modified: 
clang/lib/AST/DeclPrinter.cpp
clang/test/AST/ast-print-method-decl.cpp

Removed: 




diff  --git a/clang/lib/AST/DeclPrinter.cpp b/clang/lib/AST/DeclPrinter.cpp
index 0608b48f3a880e..bf4d26c723d2e6 100644
--- a/clang/lib/AST/DeclPrinter.cpp
+++ b/clang/lib/AST/DeclPrinter.cpp
@@ -463,12 +463,12 @@ void DeclPrinter::VisitDeclContext(DeclContext *DC, bool 
Indent) {
 else if (isa(*D) && cast(*D)->hasBody())
   Terminator = nullptr;
 else if (auto FD = dyn_cast(*D)) {
-  if (FD->doesThisDeclarationHaveABody() && !FD->isDefaulted())
+  if (FD->isThisDeclarationADefinition())
 Terminator = nullptr;
   else
 Terminator = ";";
 } else if (auto TD = dyn_cast(*D)) {
-  if (TD->getTemplatedDecl()->doesThisDeclarationHaveABody())
+  if (TD->getTemplatedDecl()->isThisDeclarationADefinition())
 Terminator = nullptr;
   else
 Terminator = ";";

diff  --git a/clang/test/AST/ast-print-method-decl.cpp 
b/clang/test/AST/ast-print-method-decl.cpp
index 3c3b8ceaf86389..505e07dde1a868 100644
--- a/clang/test/AST/ast-print-method-decl.cpp
+++ b/clang/test/AST/ast-print-method-decl.cpp
@@ -85,18 +85,3 @@ struct CurlyCtorInit {
 
   // CHECK-NEXT: };
 };
-
-
-// CHECK: struct DefMethodsWithoutBody {
-struct DefMethodsWithoutBody {
-  // CHECK-NEXT: DefMethodsWithoutBody() = delete;
-  DefMethodsWithoutBody() = delete;
-
-  // CHECK-NEXT: DefMethodsWithoutBody() = default;
-  ~DefMethodsWithoutBody() = default;
-
-  // CHECK-NEXT: void m1() __attribute__((alias("X")));
-  void m1() __attribute__((alias("X")));
-
-  // CHECK-NEXT: };
-};



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

[clang] 42c9354 - Revert "Reland "[LoongArch] Support -march=native and -mtune=""

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2023-07-31T16:57:06-07:00
New Revision: 42c9354a928d4d9459504527085fccc91b46aed3

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

LOG: Revert "Reland "[LoongArch] Support -march=native and -mtune=""

This reverts commit c56514f21b2cf08eaa7ac3a57ba4ce403a9c8956. This
commit adds global state that is shared between clang driver and clang
cc1, which is not correct when clang is used with `-fno-integrated-cc1`
option (no integrated cc1). The -march and -mtune option needs to be
properly passed through cc1 command-line and stored in TargetInfo.

Added: 


Modified: 
clang/docs/ReleaseNotes.rst
clang/lib/Basic/Targets/LoongArch.cpp
clang/lib/Basic/Targets/LoongArch.h
clang/lib/Driver/ToolChains/Arch/LoongArch.cpp
clang/lib/Driver/ToolChains/Clang.cpp
clang/test/Preprocessor/init-loongarch.c
llvm/include/llvm/TargetParser/LoongArchTargetParser.h
llvm/lib/Target/LoongArch/LoongArch.td
llvm/lib/TargetParser/LoongArchTargetParser.cpp

Removed: 
clang/test/Driver/loongarch-mtune-error.c
clang/test/Driver/loongarch-mtune.c
llvm/test/CodeGen/LoongArch/cpus-invalid.ll
llvm/test/CodeGen/LoongArch/cpus.ll



diff  --git a/clang/docs/ReleaseNotes.rst b/clang/docs/ReleaseNotes.rst
index 55189cbd659087..a6b70042cc50f9 100644
--- a/clang/docs/ReleaseNotes.rst
+++ b/clang/docs/ReleaseNotes.rst
@@ -156,9 +156,6 @@ Windows Support
 LoongArch Support
 ^
 
-- The ``-march=native`` ``-mtune=`` options and ``__loongarch_{arch,tune}``
-  macros are now supported.
-
 RISC-V Support
 ^^
 

diff  --git a/clang/lib/Basic/Targets/LoongArch.cpp 
b/clang/lib/Basic/Targets/LoongArch.cpp
index f08e5e732b0354..6958479cd7c42d 100644
--- a/clang/lib/Basic/Targets/LoongArch.cpp
+++ b/clang/lib/Basic/Targets/LoongArch.cpp
@@ -15,7 +15,7 @@
 #include "clang/Basic/MacroBuilder.h"
 #include "clang/Basic/TargetBuiltins.h"
 #include "llvm/Support/raw_ostream.h"
-#include "llvm/TargetParser/LoongArchTargetParser.h"
+#include "llvm/TargetParser/TargetParser.h"
 
 using namespace clang;
 using namespace clang::targets;
@@ -198,19 +198,7 @@ void LoongArchTargetInfo::getTargetDefines(const 
LangOptions &Opts,
   else
 Builder.defineMacro("__loongarch_frlen", "0");
 
-  // Define __loongarch_arch.
-  StringRef Arch = llvm::LoongArch::getArch();
-  if (Arch.empty())
-Arch = llvm::LoongArch::getDefaultArch(GRLen == 64);
-  if (!Arch.empty())
-Builder.defineMacro("__loongarch_arch", Arch);
-
-  // Define __loongarch_tune.
-  StringRef TuneCPU = llvm::LoongArch::getTuneCPU();
-  if (TuneCPU.empty())
-TuneCPU = Arch;
-  if (!TuneCPU.empty())
-Builder.defineMacro("__loongarch_tune", TuneCPU);
+  // TODO: define __loongarch_arch and __loongarch_tune.
 
   StringRef ABI = getABI();
   if (ABI == "lp64d" || ABI == "lp64f" || ABI == "lp64s")
@@ -282,12 +270,3 @@ bool LoongArchTargetInfo::handleTargetFeatures(
   }
   return true;
 }
-
-bool LoongArchTargetInfo::isValidTuneCPUName(StringRef Name) const {
-  return llvm::LoongArch::isValidTuneCPUName(Name);
-}
-
-void LoongArchTargetInfo::fillValidTuneCPUList(
-SmallVectorImpl &Values) const {
-  llvm::LoongArch::fillValidTuneCPUList(Values);
-}

diff  --git a/clang/lib/Basic/Targets/LoongArch.h 
b/clang/lib/Basic/Targets/LoongArch.h
index 60d545566b30fb..52c4ce4253689e 100644
--- a/clang/lib/Basic/Targets/LoongArch.h
+++ b/clang/lib/Basic/Targets/LoongArch.h
@@ -80,9 +80,6 @@ class LLVM_LIBRARY_VISIBILITY LoongArchTargetInfo : public 
TargetInfo {
  const std::vector &FeaturesVec) const override;
 
   bool hasFeature(StringRef Feature) const override;
-
-  bool isValidTuneCPUName(StringRef Name) const override;
-  void fillValidTuneCPUList(SmallVectorImpl &Values) const override;
 };
 
 class LLVM_LIBRARY_VISIBILITY LoongArch32TargetInfo

diff  --git a/clang/lib/Driver/ToolChains/Arch/LoongArch.cpp 
b/clang/lib/Driver/ToolChains/Arch/LoongArch.cpp
index 6cbb06b9a91f5e..856ad58f3bd9db 100644
--- a/clang/lib/Driver/ToolChains/Arch/LoongArch.cpp
+++ b/clang/lib/Driver/ToolChains/Arch/LoongArch.cpp
@@ -12,7 +12,6 @@
 #include "clang/Driver/Driver.h"
 #include "clang/Driver/DriverDiagnostic.h"
 #include "clang/Driver/Options.h"
-#include "llvm/TargetParser/Host.h"
 #include "llvm/TargetParser/LoongArchTargetParser.h"
 
 using namespace clang::driver;
@@ -129,29 +128,21 @@ void loongarch::getLoongArchTargetFeatures(const Driver 
&D,
std::vector &Features) {
   StringRef ArchName;
   if (const Arg *A = Args.getLastArg(options::OPT_march_EQ)) {
-ArchName = A->getValue();
-
-// Handle -march=native.
-if (ArchName == "native") {
-  ArchName = llvm::sys::getHostCPUName();
-  if (ArchName == "generic")
- 

[libunwind] 9366397 - [libunwind] Fix evaluating DWARF operation DW_OP_pick

[Steven Wu via cfe-commits]

Author: Steven Wu
Date: 2019-12-18T12:22:21-08:00
New Revision: 9366397f057d18401e680b2cb28a0ee17c59d4a6

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

LOG: [libunwind] Fix evaluating DWARF operation DW_OP_pick

reg is unsigned type and used here for getting array element from the end by
negating it. negation of unsigned can result in large number and array access
with that index will result in segmentation fault.

Fixes: https://bugs.llvm.org/show_bug.cgi?id=43872

Patched by: kamlesh kumar

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

Added: 


Modified: 
libunwind/src/DwarfInstructions.hpp

Removed: 




diff  --git a/libunwind/src/DwarfInstructions.hpp 
b/libunwind/src/DwarfInstructions.hpp
index 48ef1866d6e1..ee98f538d437 100644
--- a/libunwind/src/DwarfInstructions.hpp
+++ b/libunwind/src/DwarfInstructions.hpp
@@ -433,7 +433,7 @@ DwarfInstructions::evaluateExpression(pint_t 
expression, A &addressSpace,
   // pick from
   reg = addressSpace.get8(p);
   p += 1;
-  value = sp[-reg];
+  value = sp[-(int)reg];
   *(++sp) = value;
   if (log)
 fprintf(stderr, "duplicate %d in stack\n", reg);



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

r317860 - [Driver] Make clang/cc conforms to UNIX standard

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Thu Nov  9 17:32:47 2017
New Revision: 317860

URL: http://llvm.org/viewvc/llvm-project?rev=317860&view=rev
Log:
[Driver] Make clang/cc conforms to UNIX standard

Summary:
This is basically reverting r261774 with a tweak for clang-cl. UNIX
standard states:
When c99 encounters a compilation error that causes an object file not
to be created, it shall write a diagnostic to standard error and
continue to compile other source code operands, but it shall not perform
the link phase and it shall return a non-zero exit status

The same goes for c89 or cc. And they are all alias or shims pointing to
clang on Darwin.

The original commit was intended for CUDA so the error message doesn't
get emit twice for both host and device. It seems that the clang driver
has been changed to model the CUDA dependency differently. Now the
driver behaves the same without this commit.

rdar://problem/32223263

Reviewers: thakis, dexonsmith, tra

Reviewed By: tra

Subscribers: jlebar, cfe-commits

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

Added:
cfe/trunk/test/Driver/cuda-bail-out.cu
cfe/trunk/test/Driver/unix-conformance.c
Modified:
cfe/trunk/lib/Driver/Compilation.cpp
cfe/trunk/test/Driver/output-file-cleanup.c

Modified: cfe/trunk/lib/Driver/Compilation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Compilation.cpp?rev=317860&r1=317859&r2=317860&view=diff
==
--- cfe/trunk/lib/Driver/Compilation.cpp (original)
+++ cfe/trunk/lib/Driver/Compilation.cpp Thu Nov  9 17:32:47 2017
@@ -182,16 +182,51 @@ int Compilation::ExecuteCommand(const Co
   return ExecutionFailed ? 1 : Res;
 }
 
-void Compilation::ExecuteJobs(
-const JobList &Jobs,
-SmallVectorImpl> &FailingCommands) const {
+using FailingCommandList = SmallVectorImpl>;
+
+static bool ActionFailed(const Action *A,
+ const FailingCommandList &FailingCommands) {
+
+  if (FailingCommands.empty())
+return false;
+
+  // CUDA can have the same input source code compiled multiple times so do not
+  // compiled again if there are already failures. It is OK to abort the CUDA
+  // pipeline on errors.
+  if (A->isOffloading(Action::OFK_Cuda))
+return true;
+
+  for (const auto &CI : FailingCommands)
+if (A == &(CI.second->getSource()))
+  return true;
+
+  for (const Action *AI : A->inputs())
+if (ActionFailed(AI, FailingCommands))
+  return true;
+
+  return false;
+}
+
+static bool InputsOk(const Command &C,
+ const FailingCommandList &FailingCommands) {
+  return !ActionFailed(&C.getSource(), FailingCommands);
+}
+
+void Compilation::ExecuteJobs(const JobList &Jobs,
+  FailingCommandList &FailingCommands) const {
+  // According to UNIX standard, driver need to continue compiling all the
+  // inputs on the command line even one of them failed.
+  // In all but CLMode, execute all the jobs unless the necessary inputs for 
the
+  // job is missing due to previous failures.
   for (const auto &Job : Jobs) {
+if (!InputsOk(Job, FailingCommands))
+  continue;
 const Command *FailingCommand = nullptr;
 if (int Res = ExecuteCommand(Job, FailingCommand)) {
   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
-  // Bail as soon as one command fails, so we don't output duplicate error
-  // messages if we die on e.g. the same file.
-  return;
+  // Bail as soon as one command fails in cl driver mode.
+  if (TheDriver.IsCLMode())
+return;
 }
   }
 }

Added: cfe/trunk/test/Driver/cuda-bail-out.cu
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cuda-bail-out.cu?rev=317860&view=auto
==
--- cfe/trunk/test/Driver/cuda-bail-out.cu (added)
+++ cfe/trunk/test/Driver/cuda-bail-out.cu Thu Nov  9 17:32:47 2017
@@ -0,0 +1,54 @@
+// Test clang driver bails out after one error during CUDA compilation.
+
+// REQUIRES: clang-driver
+// REQUIRES: powerpc-registered-target
+// REQUIRES: nvptx-registered-target
+
+#ifdef FORCE_ERROR
+#error compilation failed
+#endif
+
+// RUN: not %clang -target powerpc64le-ibm-linux-gnu -fsyntax-only -nocudalib \
+// RUN:   -nocudainc -DFORCE_ERROR %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc64le-ibm-linux-gnu -fsyntax-only -nocudalib \
+// RUN:   -nocudainc -DFORCE_ERROR --cuda-gpu-arch=sm_35 --cuda-gpu-arch=sm_60 
\
+// RUN:   %s 2>&1 | FileCheck %s
+// RUN: not %clang -target powerpc64le-ibm-linux-gnu -fsyntax-only -nocudalib \
+// RUN:   -nocudainc -DFORCE_ERROR --cuda-gpu-arch=sm_35 --cuda-gpu-arch=sm_60 
\
+// RUN:   --cuda-device-only %s 2>&1 | FileCheck %s
+
+#if defined(ERROR_HOST) && !defined(__CUDA_ARCH__)
+#error compilation failed
+#endif
+
+#if defined(ERROR_SM35) && (__CUDA_ARCH__ == 350)
+#error compilation failed
+#endif
+
+#if defined(ERROR_SM60)

Re: [libcxx] r295417 - Work around Clang assertion when testing C++17 deduction guides with '-g'.

[Steven Wu via cfe-commits]

Hi Eric

Looks like the issue is fixed in r295794? Now green dragon is failing due to 
XPASS.
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/3018/testReport/

Can we remove that XFAILs in these two files?
std/strings/basic_string/string_cons.implicit_deduction_guides.pass.cpp
std/strings/string_view/string_view_cons.implicit_deduction_guides.pass.cpp

Thanks

Steven

> On Feb 16, 2017, at 9:04 PM, Eric Fiselier via cfe-commits 
>  wrote:
> 
> Author: ericwf
> Date: Thu Feb 16 23:04:09 2017
> New Revision: 295417
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=295417&view=rev
> Log:
> Work around Clang assertion when testing C++17  deduction guides with '-g'.
> 
> Modified:
>
> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
> 
> Modified: 
> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp?rev=295417&r1=295416&r2=295417&view=diff
> ==
> --- 
> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>  (original)
> +++ 
> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>  Thu Feb 16 23:04:09 2017
> @@ -10,6 +10,10 @@
> // UNSUPPORTED: c++98, c++03, c++11, c++14
> // UNSUPPORTED: libcpp-no-deduction-guides
> 
> +// FIXME(EricWF): As of 16/Feb/2017 Clang hits an assertion when compiling 
> this
> +// test with '-g' (as the sanitizers do).
> +// XFAIL: ubsan, asan, msan, tsan
> +
> // 
> 
> // Test that the constructors offered by std::basic_string are formulated
> 
> 
> ___
> 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: [libcxx] r295417 - Work around Clang assertion when testing C++17 deduction guides with '-g'.

[Steven Wu via cfe-commits]

Hi Eric

This has been failing for one week on green dragon. I think all the bots 
running sanitizer should pick up the clang with the fix already if they are 
building from trunk. Should I try remove the XFAIL?

Steven

> On Feb 23, 2017, at 11:48 AM, Steven Wu  wrote:
> 
> Hi Eric
> 
> Looks like the issue is fixed in r295794? Now green dragon is failing due to 
> XPASS.
> http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/3018/testReport/
> 
> Can we remove that XFAILs in these two files?
> std/strings/basic_string/string_cons.implicit_deduction_guides.pass.cpp
> std/strings/string_view/string_view_cons.implicit_deduction_guides.pass.cpp
> 
> Thanks
> 
> Steven
> 
>> On Feb 16, 2017, at 9:04 PM, Eric Fiselier via cfe-commits 
>>  wrote:
>> 
>> Author: ericwf
>> Date: Thu Feb 16 23:04:09 2017
>> New Revision: 295417
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=295417&view=rev
>> Log:
>> Work around Clang assertion when testing C++17  deduction guides with '-g'.
>> 
>> Modified:
>>   
>> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>> 
>> Modified: 
>> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp?rev=295417&r1=295416&r2=295417&view=diff
>> ==
>> --- 
>> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>>  (original)
>> +++ 
>> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>>  Thu Feb 16 23:04:09 2017
>> @@ -10,6 +10,10 @@
>> // UNSUPPORTED: c++98, c++03, c++11, c++14
>> // UNSUPPORTED: libcpp-no-deduction-guides
>> 
>> +// FIXME(EricWF): As of 16/Feb/2017 Clang hits an assertion when compiling 
>> this
>> +// test with '-g' (as the sanitizers do).
>> +// XFAIL: ubsan, asan, msan, tsan
>> +
>> // 
>> 
>> // Test that the constructors offered by std::basic_string are formulated
>> 
>> 
>> ___
>> 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

[libcxx] r296385 - Remove XFAIL in implicit_deduction_guides tests

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Mon Feb 27 15:10:41 2017
New Revision: 296385

URL: http://llvm.org/viewvc/llvm-project?rev=296385&view=rev
Log:
Remove XFAIL in implicit_deduction_guides tests

The clang assertion causing these tests failing with sanitizer is fixed
in r295794. All the bots running libcxx tests should be upgraded and
running the compiler with the fix.

Modified:

libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp

libcxx/trunk/test/std/strings/string.view/string.view.cons/implicit_deduction_guides.pass.cpp

Modified: 
libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp?rev=296385&r1=296384&r2=296385&view=diff
==
--- 
libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
 Mon Feb 27 15:10:41 2017
@@ -10,10 +10,6 @@
 // UNSUPPORTED: c++98, c++03, c++11, c++14
 // UNSUPPORTED: libcpp-no-deduction-guides
 
-// FIXME(EricWF): As of 16/Feb/2017 Clang hits an assertion when compiling this
-// test with '-g' (as the sanitizers do).
-// XFAIL: ubsan, asan, msan, tsan
-
 // 
 
 // Test that the constructors offered by std::basic_string are formulated

Modified: 
libcxx/trunk/test/std/strings/string.view/string.view.cons/implicit_deduction_guides.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/string.view/string.view.cons/implicit_deduction_guides.pass.cpp?rev=296385&r1=296384&r2=296385&view=diff
==
--- 
libcxx/trunk/test/std/strings/string.view/string.view.cons/implicit_deduction_guides.pass.cpp
 (original)
+++ 
libcxx/trunk/test/std/strings/string.view/string.view.cons/implicit_deduction_guides.pass.cpp
 Mon Feb 27 15:10:41 2017
@@ -10,10 +10,6 @@
 // UNSUPPORTED: c++98, c++03, c++11, c++14
 // UNSUPPORTED: libcpp-no-deduction-guides
 
-// FIXME(EricWF): As of 16/Feb/2017 Clang hits an assertion when compiling this
-// test with '-g' (as the sanitizers do).
-// XFAIL: ubsan, asan, msan, tsan
-
 // 
 
 // Test that the constructors offered by std::basic_string_view are formulated


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

Re: [libcxx] r295417 - Work around Clang assertion when testing C++17 deduction guides with '-g'.

[Steven Wu via cfe-commits]

For those watch the bots, Eric upgrade the bots with the new compiler and I 
remove the XFAIL in r296385.

Thanks

Steven

> On Feb 23, 2017, at 11:48 AM, Steven Wu via cfe-commits 
>  wrote:
> 
> Hi Eric
> 
> Looks like the issue is fixed in r295794? Now green dragon is failing due to 
> XPASS.
> http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/3018/testReport/
> 
> Can we remove that XFAILs in these two files?
> std/strings/basic_string/string_cons.implicit_deduction_guides.pass.cpp
> std/strings/string_view/string_view_cons.implicit_deduction_guides.pass.cpp
> 
> Thanks
> 
> Steven
> 
>> On Feb 16, 2017, at 9:04 PM, Eric Fiselier via cfe-commits 
>>  wrote:
>> 
>> Author: ericwf
>> Date: Thu Feb 16 23:04:09 2017
>> New Revision: 295417
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=295417&view=rev
>> Log:
>> Work around Clang assertion when testing C++17  deduction guides with '-g'.
>> 
>> Modified:
>>   
>> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>> 
>> Modified: 
>> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp?rev=295417&r1=295416&r2=295417&view=diff
>> ==
>> --- 
>> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>>  (original)
>> +++ 
>> libcxx/trunk/test/std/strings/basic.string/string.cons/implicit_deduction_guides.pass.cpp
>>  Thu Feb 16 23:04:09 2017
>> @@ -10,6 +10,10 @@
>> // UNSUPPORTED: c++98, c++03, c++11, c++14
>> // UNSUPPORTED: libcpp-no-deduction-guides
>> 
>> +// FIXME(EricWF): As of 16/Feb/2017 Clang hits an assertion when compiling 
>> this
>> +// test with '-g' (as the sanitizers do).
>> +// XFAIL: ubsan, asan, msan, tsan
>> +
>> // 
>> 
>> // Test that the constructors offered by std::basic_string are formulated
>> 
>> 
>> ___
>> 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

[PATCH] D26690: [Driver] Infer the correct option to ld64 for -fembed-bitcode

[Steven Wu via cfe-commits]

steven_wu created this revision.
steven_wu added a reviewer: mehdi_amini.
steven_wu added a subscriber: cfe-commits.

-fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly
passed when using LTO. LTO is a special case of -fembed-bitcode which
it doesn't require embed the bitcode in a special section in the object
file but it requires linker to save that as part of the final executable.

rdar://problem/28461437


https://reviews.llvm.org/D26690

Files:
  lib/Driver/Tools.cpp
  test/Driver/embed-bitcode.c


Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -41,3 +41,15 @@
 // CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s 
-fembed-bitcode=all -fintegrated-as 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s 
-fembed-bitcode=marker -fintegrated-as 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s 
-flto=full -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s 
-flto=thin -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s 
-fembed-bitcode=off -fintegrated-as 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-NO-LINKER
+// CHECK-LINKER: ld
+// CHECK-LINKER: -bitcode_bundle
+// CHECK-NO-LINKER-NOT: -bitcode_bundle
+
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=5.0 %s 
-fembed-bitcode -### 2>&1 | \
+// RUN:   FileCheck %s -check-prefix=CHECK-PLATFORM-UNSUPPORTED
+// CHECK-PLATFORM-UNSUPPORTED: -fembed-bitcode is not supported on versions of 
iOS prior to 6.0
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -8321,14 +8321,17 @@
 else
   CmdArgs.push_back("-no_pie");
   }
+
   // for embed-bitcode, use -bitcode_bundle in linker command
-  if (C.getDriver().embedBitcodeEnabled() ||
-  C.getDriver().embedBitcodeMarkerOnly()) {
-// Check if the toolchain supports bitcode build flow.
-if (MachOTC.SupportsEmbeddedBitcode())
-  CmdArgs.push_back("-bitcode_bundle");
-else
-  D.Diag(diag::err_drv_bitcode_unsupported_on_toolchain);
+  if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
+StringRef Value = A->getValue();
+if (Value != "off") {
+  // Check if the toolchain supports bitcode build flow.
+  if (MachOTC.SupportsEmbeddedBitcode())
+CmdArgs.push_back("-bitcode_bundle");
+  else
+D.Diag(diag::err_drv_bitcode_unsupported_on_toolchain);
+}
   }
 
   Args.AddLastArg(CmdArgs, options::OPT_prebind);


Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -41,3 +41,15 @@
 // CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=all -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -flto=full -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -flto=thin -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=off -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-NO-LINKER
+// CHECK-LINKER: ld
+// CHECK-LINKER: -bitcode_bundle
+// CHECK-NO-LINKER-NOT: -bitcode_bundle
+
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=5.0 %s -fembed-bitcode -### 2>&1 | \
+// RUN:   FileCheck %s -check-prefix=CHECK-PLATFORM-UNSUPPORTED
+// CHECK-PLATFORM-UNSUPPORTED: -fembed-bitcode is not supported on versions of iOS prior to 6.0
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -8321,14 +8321,17 @@
 else
   CmdArgs.push_back("-no_pie");
   }
+
   // for embed-bitcode, use -bitcode_bundle in linker command
-  if (C.getDriver().embedBitcodeEnabled() ||
-  C.getDriver().embedBitcodeMarkerOnly()) {
-// Check if the toolchain supports bitcode build flow.
-if (MachOTC.SupportsEmbeddedBitcode())
-  CmdArgs.push

[PATCH] D26690: [Driver] Infer the correct option to ld64 for -fembed-bitcode

[Steven Wu via cfe-commits]

steven_wu added inline comments.



Comment at: lib/Driver/Tools.cpp:8326
-  if (C.getDriver().embedBitcodeEnabled() ||
-  C.getDriver().embedBitcodeMarkerOnly()) {
-// Check if the toolchain supports bitcode build flow.

mehdi_amini wrote:
> Why aren't these tests returning true when LTO is enabled?
> I'm not sure why this is not the part that should be fixed instead.
These flags controls if there should be bitcode embedded in the object file. 
For the case of LTO, there is no object file thus there is no embedding.
If change the meaning of this flag, it will complicate the logic around line 
6355 and 4169. The other option is to add another flag but it seems little too 
much for passing one flag to ld.


https://reviews.llvm.org/D26690



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

[PATCH] D26690: [Driver] Infer the correct option to ld64 for -fembed-bitcode

[Steven Wu via cfe-commits]

steven_wu updated this revision to Diff 78111.
steven_wu added a comment.

Rename the functions to clarify the intention.
embedBitcodeEnabled means if any flag in -fembed-bitcode family is used so the
corresponding linker flag should be inferred. embedBitcodeInObject means if
the bitcode should be embedded in the object file which returns false for LTO.


https://reviews.llvm.org/D26690

Files:
  include/clang/Driver/Driver.h
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  test/Driver/embed-bitcode.c

Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -41,3 +41,15 @@
 // CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=all -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -flto=full -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -flto=thin -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=off -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-NO-LINKER
+// CHECK-LINKER: ld
+// CHECK-LINKER: -bitcode_bundle
+// CHECK-NO-LINKER-NOT: -bitcode_bundle
+
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=5.0 %s -fembed-bitcode -### 2>&1 | \
+// RUN:   FileCheck %s -check-prefix=CHECK-PLATFORM-UNSUPPORTED
+// CHECK-PLATFORM-UNSUPPORTED: -fembed-bitcode is not supported on versions of iOS prior to 6.0
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -4162,7 +4162,7 @@
   }
 
   // Embed-bitcode option.
-  if (C.getDriver().embedBitcodeEnabled() &&
+  if (C.getDriver().embedBitcodeInObject() &&
   (isa(JA) || isa(JA))) {
 // Add flags implied by -fembed-bitcode.
 Args.AddLastArg(CmdArgs, options::OPT_fembed_bitcode_EQ);
@@ -6352,7 +6352,7 @@
   // pristine IR generated by the frontend. Ideally, a new compile action should
   // be added so both IR can be captured.
   if (C.getDriver().isSaveTempsEnabled() &&
-  !C.getDriver().embedBitcodeEnabled() && isa(JA))
+  !C.getDriver().embedBitcodeInObject() && isa(JA))
 CmdArgs.push_back("-disable-llvm-passes");
 
   if (Output.getType() == types::TY_Dependencies) {
@@ -8321,9 +8321,9 @@
 else
   CmdArgs.push_back("-no_pie");
   }
+
   // for embed-bitcode, use -bitcode_bundle in linker command
-  if (C.getDriver().embedBitcodeEnabled() ||
-  C.getDriver().embedBitcodeMarkerOnly()) {
+  if (C.getDriver().embedBitcodeEnabled()) {
 // Check if the toolchain supports bitcode build flow.
 if (MachOTC.SupportsEmbeddedBitcode())
   CmdArgs.push_back("-bitcode_bundle");
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -626,26 +626,20 @@
 
   setLTOMode(Args);
 
-  // Ignore -fembed-bitcode options with LTO
-  // since the output will be bitcode anyway.
-  if (getLTOMode() == LTOK_None) {
-if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
-  StringRef Name = A->getValue();
-  unsigned Model = llvm::StringSwitch(Name)
-  .Case("off", EmbedNone)
-  .Case("all", EmbedBitcode)
-  .Case("bitcode", EmbedBitcode)
-  .Case("marker", EmbedMarker)
-  .Default(~0U);
-  if (Model == ~0U) {
-Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
-  << Name;
-  } else
-BitcodeEmbed = static_cast(Model);
-}
-  } else {
-// claim the bitcode option under LTO so no warning is issued.
-Args.ClaimAllArgs(options::OPT_fembed_bitcode_EQ);
+  // Process -fembed-bitcode= flags.
+  if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();
+unsigned Model = llvm::StringSwitch(Name)
+.Case("off", EmbedNone)
+.Case("all", EmbedBitcode)
+.Case("bitcode", EmbedBitcode)
+.Case("marker", EmbedMarker)
+.Default(~0U);
+if (Model == ~0U) {
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
+<< Name;
+} else
+  BitcodeEmbed = static_cast(Model);
   }
 
   std::unique_ptr UArgs =
@@ -3059,7 +3053,7 @@
   const JobAction *JA = cast(A);
   ActionList CollapsedOffloadActions;
 
-  ToolSelector TS(JA, *TC, C, 

r287084 - [Driver] Infer the correct option to ld64 for -fembed-bitcode

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Wed Nov 16 00:06:44 2016
New Revision: 287084

URL: http://llvm.org/viewvc/llvm-project?rev=287084&view=rev
Log:
[Driver] Infer the correct option to ld64 for -fembed-bitcode

Summary:
-fembed-bitcode infers -bitcode_bundle to ld64 but it is not correctly
passed when using LTO. LTO is a special case of -fembed-bitcode which
it doesn't require embed the bitcode in a special section in the object
file but it requires linker to save that as part of the final executable.

rdar://problem/29274226

Reviewers: mehdi_amini

Subscribers: cfe-commits

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

Modified:
cfe/trunk/include/clang/Driver/Driver.h
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/test/Driver/embed-bitcode.c

Modified: cfe/trunk/include/clang/Driver/Driver.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Driver.h?rev=287084&r1=287083&r2=287084&view=diff
==
--- cfe/trunk/include/clang/Driver/Driver.h (original)
+++ cfe/trunk/include/clang/Driver/Driver.h Wed Nov 16 00:06:44 2016
@@ -289,8 +289,14 @@ public:
   bool isSaveTempsEnabled() const { return SaveTemps != SaveTempsNone; }
   bool isSaveTempsObj() const { return SaveTemps == SaveTempsObj; }
 
-  bool embedBitcodeEnabled() const { return BitcodeEmbed == EmbedBitcode; }
-  bool embedBitcodeMarkerOnly() const { return BitcodeEmbed == EmbedMarker; }
+  bool embedBitcodeEnabled() const { return BitcodeEmbed != EmbedNone; }
+  bool embedBitcodeInObject() const {
+// LTO has no object file output so ignore embed bitcode option in LTO.
+return (BitcodeEmbed == EmbedBitcode) && !isUsingLTO();
+  }
+  bool embedBitcodeMarkerOnly() const {
+return (BitcodeEmbed == EmbedMarker) && !isUsingLTO();
+  }
 
   /// Compute the desired OpenMP runtime from the flags provided.
   OpenMPRuntimeKind getOpenMPRuntime(const llvm::opt::ArgList &Args) const;

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=287084&r1=287083&r2=287084&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed Nov 16 00:06:44 2016
@@ -626,26 +626,20 @@ Compilation *Driver::BuildCompilation(Ar
 
   setLTOMode(Args);
 
-  // Ignore -fembed-bitcode options with LTO
-  // since the output will be bitcode anyway.
-  if (getLTOMode() == LTOK_None) {
-if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
-  StringRef Name = A->getValue();
-  unsigned Model = llvm::StringSwitch(Name)
-  .Case("off", EmbedNone)
-  .Case("all", EmbedBitcode)
-  .Case("bitcode", EmbedBitcode)
-  .Case("marker", EmbedMarker)
-  .Default(~0U);
-  if (Model == ~0U) {
-Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
-  << Name;
-  } else
-BitcodeEmbed = static_cast(Model);
-}
-  } else {
-// claim the bitcode option under LTO so no warning is issued.
-Args.ClaimAllArgs(options::OPT_fembed_bitcode_EQ);
+  // Process -fembed-bitcode= flags.
+  if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();
+unsigned Model = llvm::StringSwitch(Name)
+.Case("off", EmbedNone)
+.Case("all", EmbedBitcode)
+.Case("bitcode", EmbedBitcode)
+.Case("marker", EmbedMarker)
+.Default(~0U);
+if (Model == ~0U) {
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
+<< Name;
+} else
+  BitcodeEmbed = static_cast(Model);
   }
 
   std::unique_ptr UArgs =
@@ -3059,7 +3053,7 @@ InputInfo Driver::BuildJobsForActionNoCa
   const JobAction *JA = cast(A);
   ActionList CollapsedOffloadActions;
 
-  ToolSelector TS(JA, *TC, C, isSaveTempsEnabled(), embedBitcodeEnabled());
+  ToolSelector TS(JA, *TC, C, isSaveTempsEnabled(), embedBitcodeInObject());
   const Tool *T = TS.getTool(Inputs, CollapsedOffloadActions);
 
   if (!T)

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=287084&r1=287083&r2=287084&view=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Wed Nov 16 00:06:44 2016
@@ -4162,7 +4162,7 @@ void Clang::ConstructJob(Compilation &C,
   }
 
   // Embed-bitcode option.
-  if (C.getDriver().embedBitcodeEnabled() &&
+  if (C.getDriver().embedBitcodeInObject() &&
   (isa(JA) || isa(JA))) {
 // Add flags implied by -fembed-bitcode.
 Args.AddLastArg(CmdArgs, options::OPT_fembed_bitcode_EQ);
@@ -6352,7 +6352,7 @@ void Clang::ConstructJob(Compilation &C,
   // pristine IR

[PATCH] D26690: [Driver] Infer the correct option to ld64 for -fembed-bitcode

[Steven Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL287084: [Driver] Infer the correct option to ld64 for 
-fembed-bitcode (authored by steven_wu).

Changed prior to commit:
  https://reviews.llvm.org/D26690?vs=78111&id=78140#toc

Repository:
  rL LLVM

https://reviews.llvm.org/D26690

Files:
  cfe/trunk/include/clang/Driver/Driver.h
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/test/Driver/embed-bitcode.c

Index: cfe/trunk/include/clang/Driver/Driver.h
===
--- cfe/trunk/include/clang/Driver/Driver.h
+++ cfe/trunk/include/clang/Driver/Driver.h
@@ -289,8 +289,14 @@
   bool isSaveTempsEnabled() const { return SaveTemps != SaveTempsNone; }
   bool isSaveTempsObj() const { return SaveTemps == SaveTempsObj; }
 
-  bool embedBitcodeEnabled() const { return BitcodeEmbed == EmbedBitcode; }
-  bool embedBitcodeMarkerOnly() const { return BitcodeEmbed == EmbedMarker; }
+  bool embedBitcodeEnabled() const { return BitcodeEmbed != EmbedNone; }
+  bool embedBitcodeInObject() const {
+// LTO has no object file output so ignore embed bitcode option in LTO.
+return (BitcodeEmbed == EmbedBitcode) && !isUsingLTO();
+  }
+  bool embedBitcodeMarkerOnly() const {
+return (BitcodeEmbed == EmbedMarker) && !isUsingLTO();
+  }
 
   /// Compute the desired OpenMP runtime from the flags provided.
   OpenMPRuntimeKind getOpenMPRuntime(const llvm::opt::ArgList &Args) const;
Index: cfe/trunk/test/Driver/embed-bitcode.c
===
--- cfe/trunk/test/Driver/embed-bitcode.c
+++ cfe/trunk/test/Driver/embed-bitcode.c
@@ -41,3 +41,15 @@
 // CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=all -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -flto=full -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -flto=thin -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-LINKER
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode=off -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-NO-LINKER
+// CHECK-LINKER: ld
+// CHECK-LINKER: -bitcode_bundle
+// CHECK-NO-LINKER-NOT: -bitcode_bundle
+
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=5.0 %s -fembed-bitcode -### 2>&1 | \
+// RUN:   FileCheck %s -check-prefix=CHECK-PLATFORM-UNSUPPORTED
+// CHECK-PLATFORM-UNSUPPORTED: -fembed-bitcode is not supported on versions of iOS prior to 6.0
Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -626,26 +626,20 @@
 
   setLTOMode(Args);
 
-  // Ignore -fembed-bitcode options with LTO
-  // since the output will be bitcode anyway.
-  if (getLTOMode() == LTOK_None) {
-if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
-  StringRef Name = A->getValue();
-  unsigned Model = llvm::StringSwitch(Name)
-  .Case("off", EmbedNone)
-  .Case("all", EmbedBitcode)
-  .Case("bitcode", EmbedBitcode)
-  .Case("marker", EmbedMarker)
-  .Default(~0U);
-  if (Model == ~0U) {
-Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
-  << Name;
-  } else
-BitcodeEmbed = static_cast(Model);
-}
-  } else {
-// claim the bitcode option under LTO so no warning is issued.
-Args.ClaimAllArgs(options::OPT_fembed_bitcode_EQ);
+  // Process -fembed-bitcode= flags.
+  if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();
+unsigned Model = llvm::StringSwitch(Name)
+.Case("off", EmbedNone)
+.Case("all", EmbedBitcode)
+.Case("bitcode", EmbedBitcode)
+.Case("marker", EmbedMarker)
+.Default(~0U);
+if (Model == ~0U) {
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args)
+<< Name;
+} else
+  BitcodeEmbed = static_cast(Model);
   }
 
   std::unique_ptr UArgs =
@@ -3059,7 +3053,7 @@
   const JobAction *JA = cast(A);
   ActionList CollapsedOffloadActions;
 
-  ToolSelector TS(JA, *TC, C, isSaveTempsEnabled(), embedBitcodeEnabled());
+  ToolSelector TS(JA, *TC, C, isSaveTempsEnabled(), embedBitcodeInObject());
   const Tool *T = TS.getTool(Inputs, CollapsedOffloadActions);
 
   if (!T)
In

Re: Embedded Bitcode in Object Files

[Steven Wu via cfe-commits]

Thanks for reviewing the patches. And yes, 3 and 4 are no longer useful. I am 
seeking better alternatives to achieve them.

Steven 

> On Nov 30, 2016, at 1:35 AM, Nico Weber  wrote:
> 
> It looks like patches 1 and  2 made it but 3 and 4 didn't. Do you no longer 
> need them?
> 
>> On Mon, Feb 29, 2016 at 2:08 PM, Steven Wu via cfe-commits 
>>  wrote:
>> Ping. I don't know who is the best review for the patches. Thanks for Rafael 
>> looking at the LLVM change. Richard, do you have any opinions on the clang 
>> changes?
>> 
>> Thanks
>> 
>> Steven
>> 
>> > On Feb 18, 2016, at 9:57 AM, Steven Wu  wrote:
>> >
>> > Hi all
>> >
>> > I put up some patches for embedding bitcode inside the object file 
>> > (-fembed-bitcode) option. As I described in the dev list before, the new 
>> > option can create normal object file with bitcode embedded in a special 
>> > section. You can easily recreate the same object file with the embedded 
>> > bitcode in it.
>> >
>> > I split the patch into several parts:
>> > llvm patch:
>> > http://reviews.llvm.org/D17388: Introduce the section for embedding 
>> > bitcode in MachO file.
>> >
>> > There are four clang patches:
>> > http://reviews.llvm.org/D17390: Implementing the clang driver for the new 
>> > option.
>> > http://reviews.llvm.org/D17392: Teach clang how to embed bitcode into the 
>> > object file.
>> > http://reviews.llvm.org/D17393: Slightly tweak the bitcode emitted in 
>> > embed bitcode stage 1.
>> > http://reviews.llvm.org/D17394: Reduce the amount of option gets embedded 
>> > in the bitcode by introducing a whitelist and a blacklist.
>> >
>> > Let me know if anyone is interested in helping reviewing these changes.
>> >
>> > Thanks
>> >
>> > Steven
>> >
>> >
>> >
>> 
>> ___
>> 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: r261774 - Bail on compilation as soon as a job fails.

[Steven Wu via cfe-commits]

Hi Nico

Now that r262420 is landed. Is there any plan to move CUDA to the new approach 
so we can fix the UNIX conformance test?

Thanks

Steven

> On Apr 22, 2017, at 8:08 PM, Nico Weber via cfe-commits 
>  wrote:
> 
> On Sat, Apr 22, 2017 at 8:40 PM, Duncan P. N. Exon Smith via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> [Some necromancy here...]
> 
> This commit effectively reverted r173361 and r173825, breaking UNIX 
> conformance for our c99 wrapper.
> 
> See:
> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html 
> 
>> When c99 encounters a compilation error that causes an object file not to be 
>> created, it shall write a diagnostic to standard error and continue to 
>> compile other source code operands, but it shall not perform the link phase 
>> and it shall return a non-zero exit status.
> 
> 
> We had a test, but this commit changed that as well (I suppose it could have 
> been better documented).
> 
> How easily could this be restricted to only affect CUDA jobs?
> 
> If this gets reverted, the clang-cl PCH code needs to use the approach in 
> https://reviews.llvm.org/D17695  before I 
> rebased that patch over this revision here, so that a PCH compilation failure 
> stops the compilation of the main TU.
>  
> 
>> On Feb 24, 2016, at 13:49, Justin Lebar via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> 
>> Author: jlebar
>> Date: Wed Feb 24 15:49:28 2016
>> New Revision: 261774
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=261774&view=rev 
>> 
>> Log:
>> Bail on compilation as soon as a job fails.
>> 
>> Summary:
>> (Re-land of r260448, which was reverted in r260522 due to a test failure
>> in Driver/output-file-cleanup.c that only showed up in fresh builds.)
>> 
>> Previously we attempted to be smart; if one job failed, we'd run all
>> jobs that didn't depend on the failing job.
>> 
>> Problem is, this doesn't work well for e.g. CUDA compilation without
>> -save-temps.  In this case, the device-side and host-side Assemble
>> actions (which actually are responsible for preprocess, compile,
>> backend, and assemble, since we're not saving temps) are necessarily
>> distinct.  So our clever heuristic doesn't help us, and we repeat every
>> error message once for host and once for each device arch.
>> 
>> The main effect of this change, other than fixing CUDA, is that if you
>> pass multiple cc files to one instance of clang and you get a compile
>> error, we'll stop when the first cc1 job fails.
>> 
>> Reviewers: echristo
>> 
>> Subscribers: cfe-commits, jhen, echristo, tra, rafael
>> 
>> Differential Revision: http://reviews.llvm.org/D17217 
>> 
>> 
>> Modified:
>>cfe/trunk/lib/Driver/Compilation.cpp
>>cfe/trunk/test/Driver/output-file-cleanup.c
>> 
>> Modified: cfe/trunk/lib/Driver/Compilation.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Compilation.cpp?rev=261774&r1=261773&r2=261774&view=diff
>>  
>> 
>> ==
>> --- cfe/trunk/lib/Driver/Compilation.cpp (original)
>> +++ cfe/trunk/lib/Driver/Compilation.cpp Wed Feb 24 15:49:28 2016
>> @@ -163,39 +163,17 @@ int Compilation::ExecuteCommand(const Co
>>   return ExecutionFailed ? 1 : Res;
>> }
>> 
>> -typedef SmallVectorImpl< std::pair > 
>> FailingCommandList;
>> -
>> -static bool ActionFailed(const Action *A,
>> - const FailingCommandList &FailingCommands) {
>> -
>> -  if (FailingCommands.empty())
>> -return false;
>> -
>> -  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
>> - CE = FailingCommands.end(); CI != CE; ++CI)
>> -if (A == &(CI->second->getSource()))
>> -  return true;
>> -
>> -  for (const Action *AI : A->inputs())
>> -if (ActionFailed(AI, FailingCommands))
>> -  return true;
>> -
>> -  return false;
>> -}
>> -
>> -static bool InputsOk(const Command &C,
>> - const FailingCommandList &FailingCommands) {
>> -  return !ActionFailed(&C.getSource(), FailingCommands);
>> -}
>> -
>> -void Compilation::ExecuteJobs(const JobList &Jobs,
>> -  FailingCommandList &FailingCommands) const {
>> +void Compilation::ExecuteJobs(
>> +const JobList &Jobs,
>> +SmallVectorImpl> &FailingCommands) 
>> const {
>>   for (const auto &Job : Jobs) {
>> -if (!InputsOk(Job, FailingCommands))
>> -  continue;
>> const Command *FailingCommand = nullptr;
>> -if (int Res = ExecuteCommand(Job, FailingCommand))
>> +if (int Res = ExecuteCommand(Job, FailingCommand)) {
>>   FailingCommands.push_back(std::make_pair(Res, FailingCommand));
>> +  // Bail as soon 

Re: r261774 - Bail on compilation as soon as a job fails.

[Steven Wu via cfe-commits]

The other option is to make this behavior configurable so that clang on UNIX 
behaves differently than clang-cl or CUDA. I am not sure what problem CUDA is 
hitting. Is there a test case for that?

Steven

> On May 15, 2017, at 12:42 PM, Nico Weber  wrote:
> 
> r262420 landed in a way adapted to Justin's change. An earlier version of 
> https://reviews.llvm.org/D17695  had a 
> different approach. I don't know if that approach could be used for CUDA. 
> Justin should reply here.
> 
> On Mon, May 15, 2017 at 1:32 PM, Steven Wu  > wrote:
> Hi Nico
> 
> Now that r262420 is landed. Is there any plan to move CUDA to the new 
> approach so we can fix the UNIX conformance test?
> 
> Thanks
> 
> Steven
> 
>> On Apr 22, 2017, at 8:08 PM, Nico Weber via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> 
>> On Sat, Apr 22, 2017 at 8:40 PM, Duncan P. N. Exon Smith via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> [Some necromancy here...]
>> 
>> This commit effectively reverted r173361 and r173825, breaking UNIX 
>> conformance for our c99 wrapper.
>> 
>> See:
>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html 
>> 
>>> When c99 encounters a compilation error that causes an object file not to 
>>> be created, it shall write a diagnostic to standard error and continue to 
>>> compile other source code operands, but it shall not perform the link phase 
>>> and it shall return a non-zero exit status.
>> 
>> 
>> We had a test, but this commit changed that as well (I suppose it could have 
>> been better documented).
>> 
>> How easily could this be restricted to only affect CUDA jobs?
>> 
>> If this gets reverted, the clang-cl PCH code needs to use the approach in 
>> https://reviews.llvm.org/D17695  before I 
>> rebased that patch over this revision here, so that a PCH compilation 
>> failure stops the compilation of the main TU.
>>  
>> 
>>> On Feb 24, 2016, at 13:49, Justin Lebar via cfe-commits 
>>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>> 
>>> Author: jlebar
>>> Date: Wed Feb 24 15:49:28 2016
>>> New Revision: 261774
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=261774&view=rev 
>>> 
>>> Log:
>>> Bail on compilation as soon as a job fails.
>>> 
>>> Summary:
>>> (Re-land of r260448, which was reverted in r260522 due to a test failure
>>> in Driver/output-file-cleanup.c that only showed up in fresh builds.)
>>> 
>>> Previously we attempted to be smart; if one job failed, we'd run all
>>> jobs that didn't depend on the failing job.
>>> 
>>> Problem is, this doesn't work well for e.g. CUDA compilation without
>>> -save-temps.  In this case, the device-side and host-side Assemble
>>> actions (which actually are responsible for preprocess, compile,
>>> backend, and assemble, since we're not saving temps) are necessarily
>>> distinct.  So our clever heuristic doesn't help us, and we repeat every
>>> error message once for host and once for each device arch.
>>> 
>>> The main effect of this change, other than fixing CUDA, is that if you
>>> pass multiple cc files to one instance of clang and you get a compile
>>> error, we'll stop when the first cc1 job fails.
>>> 
>>> Reviewers: echristo
>>> 
>>> Subscribers: cfe-commits, jhen, echristo, tra, rafael
>>> 
>>> Differential Revision: http://reviews.llvm.org/D17217 
>>> 
>>> 
>>> Modified:
>>>cfe/trunk/lib/Driver/Compilation.cpp
>>>cfe/trunk/test/Driver/output-file-cleanup.c
>>> 
>>> Modified: cfe/trunk/lib/Driver/Compilation.cpp
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Compilation.cpp?rev=261774&r1=261773&r2=261774&view=diff
>>>  
>>> 
>>> ==
>>> --- cfe/trunk/lib/Driver/Compilation.cpp (original)
>>> +++ cfe/trunk/lib/Driver/Compilation.cpp Wed Feb 24 15:49:28 2016
>>> @@ -163,39 +163,17 @@ int Compilation::ExecuteCommand(const Co
>>>   return ExecutionFailed ? 1 : Res;
>>> }
>>> 
>>> -typedef SmallVectorImpl< std::pair > 
>>> FailingCommandList;
>>> -
>>> -static bool ActionFailed(const Action *A,
>>> - const FailingCommandList &FailingCommands) {
>>> -
>>> -  if (FailingCommands.empty())
>>> -return false;
>>> -
>>> -  for (FailingCommandList::const_iterator CI = FailingCommands.begin(),
>>> - CE = FailingCommands.end(); CI != CE; ++CI)
>>> -if (A == &(CI->second->getSource()))
>>> -  return true;
>>> -
>>> -  for (const Action *AI : A->inputs())
>>> -if (ActionFailed(AI, FailingCommands))
>>> -  return true;
>>> -
>>> -  return false;
>>> -}
>>> -
>>> -static bool InputsOk(const Command &C,
>>>

Re: r261774 - Bail on compilation as soon as a job fails.

[Steven Wu via cfe-commits]

> On May 15, 2017, at 3:03 PM, Nico Weber  wrote:
> 
> test/Driver/cl-pch-errorhandling.cpp tests the clang-cl pch bits.

I don't think reverting r261774 will break any cl-pch tests (didn't try 
windows). That is why I wondering if there is any test case for CUDA so I don't 
break them when fixing UNIX conformance.

Steven

> 
> On Mon, May 15, 2017 at 5:42 PM, Steven Wu  > wrote:
> The other option is to make this behavior configurable so that clang on UNIX 
> behaves differently than clang-cl or CUDA. I am not sure what problem CUDA is 
> hitting. Is there a test case for that?
> 
> Steven
> 
>> On May 15, 2017, at 12:42 PM, Nico Weber > > wrote:
>> 
>> r262420 landed in a way adapted to Justin's change. An earlier version of 
>> https://reviews.llvm.org/D17695  had a 
>> different approach. I don't know if that approach could be used for CUDA. 
>> Justin should reply here.
>> 
>> On Mon, May 15, 2017 at 1:32 PM, Steven Wu > > wrote:
>> Hi Nico
>> 
>> Now that r262420 is landed. Is there any plan to move CUDA to the new 
>> approach so we can fix the UNIX conformance test?
>> 
>> Thanks
>> 
>> Steven
>> 
>>> On Apr 22, 2017, at 8:08 PM, Nico Weber via cfe-commits 
>>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>> 
>>> On Sat, Apr 22, 2017 at 8:40 PM, Duncan P. N. Exon Smith via cfe-commits 
>>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>> [Some necromancy here...]
>>> 
>>> This commit effectively reverted r173361 and r173825, breaking UNIX 
>>> conformance for our c99 wrapper.
>>> 
>>> See:
>>> http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html 
>>> 
 When c99 encounters a compilation error that causes an object file not to 
 be created, it shall write a diagnostic to standard error and continue to 
 compile other source code operands, but it shall not perform the link 
 phase and it shall return a non-zero exit status.
>>> 
>>> 
>>> We had a test, but this commit changed that as well (I suppose it could 
>>> have been better documented).
>>> 
>>> How easily could this be restricted to only affect CUDA jobs?
>>> 
>>> If this gets reverted, the clang-cl PCH code needs to use the approach in 
>>> https://reviews.llvm.org/D17695  before I 
>>> rebased that patch over this revision here, so that a PCH compilation 
>>> failure stops the compilation of the main TU.
>>>  
>>> 
 On Feb 24, 2016, at 13:49, Justin Lebar via cfe-commits 
 mailto:cfe-commits@lists.llvm.org>> wrote:
 
 Author: jlebar
 Date: Wed Feb 24 15:49:28 2016
 New Revision: 261774
 
 URL: http://llvm.org/viewvc/llvm-project?rev=261774&view=rev 
 
 Log:
 Bail on compilation as soon as a job fails.
 
 Summary:
 (Re-land of r260448, which was reverted in r260522 due to a test failure
 in Driver/output-file-cleanup.c that only showed up in fresh builds.)
 
 Previously we attempted to be smart; if one job failed, we'd run all
 jobs that didn't depend on the failing job.
 
 Problem is, this doesn't work well for e.g. CUDA compilation without
 -save-temps.  In this case, the device-side and host-side Assemble
 actions (which actually are responsible for preprocess, compile,
 backend, and assemble, since we're not saving temps) are necessarily
 distinct.  So our clever heuristic doesn't help us, and we repeat every
 error message once for host and once for each device arch.
 
 The main effect of this change, other than fixing CUDA, is that if you
 pass multiple cc files to one instance of clang and you get a compile
 error, we'll stop when the first cc1 job fails.
 
 Reviewers: echristo
 
 Subscribers: cfe-commits, jhen, echristo, tra, rafael
 
 Differential Revision: http://reviews.llvm.org/D17217 
 
 
 Modified:
cfe/trunk/lib/Driver/Compilation.cpp
cfe/trunk/test/Driver/output-file-cleanup.c
 
 Modified: cfe/trunk/lib/Driver/Compilation.cpp
 URL: 
 http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Compilation.cpp?rev=261774&r1=261773&r2=261774&view=diff
  
 
 ==
 --- cfe/trunk/lib/Driver/Compilation.cpp (original)
 +++ cfe/trunk/lib/Driver/Compilation.cpp Wed Feb 24 15:49:28 2016
 @@ -163,39 +163,17 @@ int Compilation::ExecuteCommand(const Co
   return ExecutionFailed ? 1 : Res;
 }
 
 -typedef SmallVectorImpl< std::pair > 
 FailingCommandList;
 -
 -static bool ActionFailed(const Action *A,
>

Re: r246985 - Compute and preserve alignment more faithfully in IR-generation.

[Steven Wu via cfe-commits]

CreateElementBitcast doesn’t seem to do what the name suggested. If you give it 
VTy, it doesn’t grab the element type to generate bitcast. Is this by-design? 
If so, I need to do this:
PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy->getElementType()); 

Steven

>> On Sep 8, 2015, at 5:14 PM, Steven Wu > > wrote:
>> Hi John
>> 
>> It seems this commit breaks arm “vld1_lane” intrinsics. When emitting 
>> “vld1_lane” Ops[0] gets updated so PtrOp0 no longer have the same type as 
>> Ops[0].
> 
> Sorry about that.
> 
>> Here a patch for the fix. Can you review it?
> 
> Slight tweak:
> 
>> From daea3a26c6df07530407318e4f0819e6e2ff9aea Mon Sep 17 00:00:00 2001
>> From: Steven Wu mailto:steve...@apple.com>>
>> Date: Tue, 8 Sep 2015 17:10:25 -0700
>> Subject: [PATCH] Fix assertion when emiting NEON builtin
>> 
>> ---
>> lib/CodeGen/CGBuiltin.cpp | 1 +
>> 1 file changed, 1 insertion(+)
>> 
>> diff --git a/lib/CodeGen/CGBuiltin.cpp b/lib/CodeGen/CGBuiltin.cpp
>> index 729c0a1..ed3f9f6 100644
>> --- a/lib/CodeGen/CGBuiltin.cpp
>> +++ b/lib/CodeGen/CGBuiltin.cpp
>> @@ -3772,6 +3772,7 @@ Value *CodeGenFunction::EmitARMBuiltinExpr(unsigned 
>> BuiltinID,
>>Ops[1] = Builder.CreateBitCast(Ops[1], Ty);
>>Ty = llvm::PointerType::getUnqual(VTy->getElementType());
>>Ops[0] = Builder.CreateBitCast(Ops[0], Ty);
> 
> Please remove these two lines and replace them with:
>  PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy);
> 
> You then shouldn’t need this line:
> 
>> +PtrOp0 = Address(Ops[0], PtrOp0.getAlignment());
> 
> Thanks!
> 
> John.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r247117 - Fix vld1_lane intrinsic generation

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Tue Sep  8 20:37:18 2015
New Revision: 247117

URL: http://llvm.org/viewvc/llvm-project?rev=247117&view=rev
Log:
Fix vld1_lane intrinsic generation

Fix a bug introduced in r246985 which causes assertion when generating
vld1_lane.

Modified:
cfe/trunk/lib/CodeGen/CGBuiltin.cpp

Modified: cfe/trunk/lib/CodeGen/CGBuiltin.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGBuiltin.cpp?rev=247117&r1=247116&r2=247117&view=diff
==
--- cfe/trunk/lib/CodeGen/CGBuiltin.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGBuiltin.cpp Tue Sep  8 20:37:18 2015
@@ -3770,8 +3770,7 @@ Value *CodeGenFunction::EmitARMBuiltinEx
 // fall through
   case NEON::BI__builtin_neon_vld1_lane_v: {
 Ops[1] = Builder.CreateBitCast(Ops[1], Ty);
-Ty = llvm::PointerType::getUnqual(VTy->getElementType());
-Ops[0] = Builder.CreateBitCast(Ops[0], Ty);
+PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy->getElementType());
 Value *Ld = Builder.CreateLoad(PtrOp0);
 return Builder.CreateInsertElement(Ops[1], Ld, Ops[2], "vld1_lane");
   }


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

Re: r246985 - Compute and preserve alignment more faithfully in IR-generation.

[Steven Wu via cfe-commits]

Thanks. Committed in r247117.

Steven

> On Sep 8, 2015, at 6:32 PM, John McCall  wrote:
> 
>> On Sep 8, 2015, at 6:19 PM, Steven Wu  wrote:
>> CreateElementBitcast doesn’t seem to do what the name suggested. If you give 
>> it VTy, it doesn’t grab the element type to generate bitcast. Is this 
>> by-design? If so, I need to do this:
>> PtrOp0 = Builder.CreateElementBitCast(PtrOp0, VTy->getElementType());
> 
> Yes, I’m sorry, that’s right.  I missed that you were also drilling down to 
> the element type.
> 
> John.

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

r246282 - Revert r246214 and r246213

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Fri Aug 28 02:14:10 2015
New Revision: 246282

URL: http://llvm.org/viewvc/llvm-project?rev=246282&view=rev
Log:
Revert r246214 and r246213

These two commits causes llvm LTO bootstrap to hang in ScalarEvolution.

Removed:
cfe/trunk/test/CodeGenCXX/vtable-assume-load.cpp
Modified:
cfe/trunk/lib/CodeGen/CGCXXABI.h
cfe/trunk/lib/CodeGen/CGCall.cpp
cfe/trunk/lib/CodeGen/CGClass.cpp
cfe/trunk/lib/CodeGen/CGVTables.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
cfe/trunk/test/CodeGen/available-externally-hidden.cpp
cfe/trunk/test/CodeGenCXX/ctor-globalopt.cpp
cfe/trunk/test/CodeGenCXX/thunks.cpp
cfe/trunk/test/CodeGenCXX/virtual-base-ctor.cpp
cfe/trunk/test/CodeGenCXX/vtable-available-externally.cpp

Modified: cfe/trunk/lib/CodeGen/CGCXXABI.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCXXABI.h?rev=246282&r1=246281&r2=246282&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCXXABI.h (original)
+++ cfe/trunk/lib/CodeGen/CGCXXABI.h Fri Aug 28 02:14:10 2015
@@ -218,10 +218,8 @@ public:
   virtual void emitThrow(CodeGenFunction &CGF, const CXXThrowExpr *E) = 0;
   virtual llvm::GlobalVariable *getThrowInfo(QualType T) { return nullptr; }
 
-  /// \brief Determine whether it's possible to emit a vtable for \p RD, even
-  /// though we do not know that the vtable has been marked as used by semantic
-  /// analysis.
-  virtual bool canSpeculativelyEmitVTable(const CXXRecordDecl *RD) const = 0;
+  virtual bool canEmitAvailableExternallyVTable(
+  const CXXRecordDecl *RD) const = 0;
 
   virtual void emitBeginCatch(CodeGenFunction &CGF, const CXXCatchStmt *C) = 0;
 
@@ -348,25 +346,13 @@ public:
   virtual void emitVTableDefinitions(CodeGenVTables &CGVT,
  const CXXRecordDecl *RD) = 0;
 
-  /// Checks if ABI requires extra virtual offset for vtable field.
-  virtual bool
-  isVirtualOffsetNeededForVTableField(CodeGenFunction &CGF,
-  CodeGenFunction::VPtr Vptr) = 0;
-
-  /// Checks if ABI requires to initilize vptrs for given dynamic class.
-  virtual bool doStructorsInitializeVPtrs(const CXXRecordDecl *VTableClass) = 
0;
-
-  /// Get the address point of the vtable for the given base subobject.
-  virtual llvm::Constant *
-  getVTableAddressPoint(BaseSubobject Base,
-const CXXRecordDecl *VTableClass) = 0;
-
   /// Get the address point of the vtable for the given base subobject while
-  /// building a constructor or a destructor.
-  virtual llvm::Value *
-  getVTableAddressPointInStructor(CodeGenFunction &CGF, const CXXRecordDecl 
*RD,
-  BaseSubobject Base,
-  const CXXRecordDecl *NearestVBase) = 0;
+  /// building a constructor or a destructor. On return, NeedsVirtualOffset
+  /// tells if a virtual base adjustment is needed in order to get the offset
+  /// of the base subobject.
+  virtual llvm::Value *getVTableAddressPointInStructor(
+  CodeGenFunction &CGF, const CXXRecordDecl *RD, BaseSubobject Base,
+  const CXXRecordDecl *NearestVBase, bool &NeedsVirtualOffset) = 0;
 
   /// Get the address point of the vtable for the given base subobject while
   /// building a constexpr.

Modified: cfe/trunk/lib/CodeGen/CGCall.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGCall.cpp?rev=246282&r1=246281&r2=246282&view=diff
==
--- cfe/trunk/lib/CodeGen/CGCall.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGCall.cpp Fri Aug 28 02:14:10 2015
@@ -1412,8 +1412,7 @@ void CodeGenModule::ConstructAttributeLi
 
 if (const FunctionDecl *Fn = dyn_cast(TargetDecl)) {
   const FunctionProtoType *FPT = Fn->getType()->getAs();
-  if (FPT && !isUnresolvedExceptionSpec(FPT->getExceptionSpecType()) &&
-  FPT->isNothrow(getContext()))
+  if (FPT && FPT->isNothrow(getContext()))
 FuncAttrs.addAttribute(llvm::Attribute::NoUnwind);
   // Don't use [[noreturn]] or _Noreturn for a call to a virtual function.
   // These attributes are not inherited by overloads.

Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGClass.cpp?rev=246282&r1=246281&r2=246282&view=diff
==
--- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGClass.cpp Fri Aug 28 02:14:10 2015
@@ -1806,14 +1806,12 @@ void CodeGenFunction::EmitCXXConstructor
  bool ForVirtualBase,
  bool Delegating, llvm::Value 
*This,
  const CXXConstructExpr *E) {
-  const CXXRecor

Re: r246214 - Assume loads fix #2

[Steven Wu via cfe-commits]

I am pretty sure this commit and r246213 causes llvm LTO bootstrap to hang in 
ScalarEvolution. Doesn’t look like a bug introduced in the commit but 
definitely triggered something bad. I reverted both commit in r246282.

You should able to reproduce the hang by building llvm-cov using LTO. Let me 
know if you need help for a reduced test case.

Thanks

Steven

> On Aug 27, 2015, at 2:35 PM, Piotr Padlewski via cfe-commits 
>  wrote:
> 
> Author: prazek
> Date: Thu Aug 27 16:35:41 2015
> New Revision: 246214
> 
> URL: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject-3Frev-3D246214-26view-3Drev&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=AyppgLQmqA6F6mGKjHYJQMsYFVSyBzNb052X2-XqxQo&m=74Ho53VBiSjPg1sSirQymG9cfu0g_kH2TPgrIwIkMsA&s=bzaEvH1N-pXVZNnhTXbVnUXyKmR20AciXN_zJ-SETjw&e=
>  
> Log:
> Assume loads fix #2
> 
> There was linker problem, and it turns out that it is not always safe
> to refer to vtable. If the vtable is used, then we can refer to it
> without any problem, but because we don't know when it will be used or
> not, we can only check if vtable is external or it is safe to to emit it
> speculativly (when class it doesn't have any inline virtual functions).
> It should be fixed in the future.
> 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__reviews.llvm.org_D12385&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=AyppgLQmqA6F6mGKjHYJQMsYFVSyBzNb052X2-XqxQo&m=74Ho53VBiSjPg1sSirQymG9cfu0g_kH2TPgrIwIkMsA&s=bMLQH3JdjE2Utt9cC3cfAJOSJ05ZaOoTW7ev_hDFEgQ&e=
>  
> 
> Modified:
>cfe/trunk/lib/CodeGen/CGCXXABI.h
>cfe/trunk/lib/CodeGen/CGClass.cpp
>cfe/trunk/lib/CodeGen/CGVTables.cpp
>cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>cfe/trunk/test/CodeGenCXX/template-instantiation.cpp
>cfe/trunk/test/CodeGenCXX/thunks.cpp
>cfe/trunk/test/CodeGenCXX/vtable-assume-load.cpp
>cfe/trunk/test/CodeGenCXX/vtable-available-externally.cpp
> 
> Modified: cfe/trunk/lib/CodeGen/CGCXXABI.h
> URL: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CGCXXABI.h-3Frev-3D246214-26r1-3D246213-26r2-3D246214-26view-3Ddiff&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=AyppgLQmqA6F6mGKjHYJQMsYFVSyBzNb052X2-XqxQo&m=74Ho53VBiSjPg1sSirQymG9cfu0g_kH2TPgrIwIkMsA&s=leudiFW4SvRTkcpIUEbGg8vvviVI12BygT3LQphKTBc&e=
>  
> ==
> --- cfe/trunk/lib/CodeGen/CGCXXABI.h (original)
> +++ cfe/trunk/lib/CodeGen/CGCXXABI.h Thu Aug 27 16:35:41 2015
> @@ -218,8 +218,10 @@ public:
>   virtual void emitThrow(CodeGenFunction &CGF, const CXXThrowExpr *E) = 0;
>   virtual llvm::GlobalVariable *getThrowInfo(QualType T) { return nullptr; }
> 
> -  virtual bool canEmitAvailableExternallyVTable(
> -  const CXXRecordDecl *RD) const = 0;
> +  /// \brief Determine whether it's possible to emit a vtable for \p RD, even
> +  /// though we do not know that the vtable has been marked as used by 
> semantic
> +  /// analysis.
> +  virtual bool canSpeculativelyEmitVTable(const CXXRecordDecl *RD) const = 0;
> 
>   virtual void emitBeginCatch(CodeGenFunction &CGF, const CXXCatchStmt *C) = 
> 0;
> 
> 
> Modified: cfe/trunk/lib/CodeGen/CGClass.cpp
> URL: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CGClass.cpp-3Frev-3D246214-26r1-3D246213-26r2-3D246214-26view-3Ddiff&d=BQIGaQ&c=eEvniauFctOgLOKGJOplqw&r=AyppgLQmqA6F6mGKjHYJQMsYFVSyBzNb052X2-XqxQo&m=74Ho53VBiSjPg1sSirQymG9cfu0g_kH2TPgrIwIkMsA&s=pjy3fMgGIh-biMJxLcTXYSklw13ul6gAje-Ft1LgxQg&e=
>  
> ==
> --- cfe/trunk/lib/CodeGen/CGClass.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CGClass.cpp Thu Aug 27 16:35:41 2015
> @@ -1857,8 +1857,15 @@ void CodeGenFunction::EmitCXXConstructor
>   // with a vtable.  We don't do this for base subobjects for two reasons:
>   // first, it's incorrect for classes with virtual bases, and second, we're
>   // about to overwrite the vptrs anyway.
> +  // We also have to make sure if we can refer to vtable:
> +  // - If vtable is external then it's safe to use it (for 
> available_externally
> +  //   CGVTables will make sure if it can emit it).
> +  // - Otherwise we can refer to vtable if it's safe to speculatively emit.
> +  // FIXME: If vtable is used by ctor/dtor, we are always safe to refer to 
> it.
>   if (CGM.getCodeGenOpts().OptimizationLevel > 0 &&
> -  ClassDecl->isDynamicClass() && Type != Ctor_Base)
> +  ClassDecl->isDynamicClass() && Type != Ctor_Base &&
> +  (CGM.getVTables().isVTableExternal(ClassDecl) ||
> +   CGM.getCXXABI().canSpeculativelyEmitVTable(ClassDecl)))
> EmitVTableAssumptionLoads(ClassDecl, This);
> }
> 
> 
> Modified: cfe/trunk/lib/CodeGen/CGVTables.cpp
> URL: 
> https://urldefense.proofpoint.com/v2/url?u=http-3A__llvm.org_viewvc_llvm-2Dproject_cfe_trunk_lib_CodeGen_CGVTables.cpp-3Frev-3D246214-26r1-3D2

Re: r246830 - Fix a potential APInt memory leak when using __attribute__((flag_enum)), and

[Steven Wu via cfe-commits]

In case you didn’t get an email from the failure because it was overshadowed by 
the previous error. This commit seems to break the green dragon bots:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/12990/testReport/junit/Clang/Sema/attr_flag_enum_c/
 


Thanks

Steven

> On Sep 3, 2015, at 6:03 PM, Richard Smith via cfe-commits 
>  wrote:
> 
> Author: rsmith
> Date: Thu Sep  3 20:03:03 2015
> New Revision: 246830
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=246830&view=rev
> Log:
> Fix a potential APInt memory leak when using __attribute__((flag_enum)), and
> simplify the implementation a bit.
> 
> Modified:
>cfe/trunk/include/clang/Basic/Attr.td
>cfe/trunk/include/clang/Sema/Sema.h
>cfe/trunk/lib/Sema/SemaDecl.cpp
>cfe/trunk/lib/Sema/SemaStmt.cpp
> 
> Modified: cfe/trunk/include/clang/Basic/Attr.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=246830&r1=246829&r2=246830&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/Attr.td (original)
> +++ cfe/trunk/include/clang/Basic/Attr.td Thu Sep  3 20:03:03 2015
> @@ -747,18 +747,6 @@ def FlagEnum : InheritableAttr {
>   let Subjects = SubjectList<[Enum]>;
>   let Documentation = [FlagEnumDocs];
>   let LangOpts = [COnly];
> -  let AdditionalMembers = [{
> -private:
> -llvm::APInt FlagBits;
> -public:
> -llvm::APInt &getFlagBits() {
> -  return FlagBits;
> -}
> -
> -const llvm::APInt &getFlagBits() const {
> -  return FlagBits;
> -}
> -}];
> }
> 
> def Flatten : InheritableAttr {
> 
> Modified: cfe/trunk/include/clang/Sema/Sema.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=246830&r1=246829&r2=246830&view=diff
> ==
> --- cfe/trunk/include/clang/Sema/Sema.h (original)
> +++ cfe/trunk/include/clang/Sema/Sema.h Thu Sep  3 20:03:03 2015
> @@ -903,6 +903,10 @@ public:
>   /// for C++ records.
>   llvm::FoldingSet SpecialMemberCache;
> 
> +  /// \brief A cache of the flags available in enumerations with the 
> flag_bits
> +  /// attribute.
> +  mutable llvm::DenseMap FlagBitsCache;
> +
>   /// \brief The kind of translation unit we are processing.
>   ///
>   /// When we're processing a complete translation unit, Sema will perform
> 
> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=246830&r1=246829&r2=246830&view=diff
> ==
> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Thu Sep  3 20:03:03 2015
> @@ -14017,14 +14017,21 @@ static void CheckForDuplicateEnumValues(
> bool
> Sema::IsValueInFlagEnum(const EnumDecl *ED, const llvm::APInt &Val,
> bool AllowMask) const {
> -  FlagEnumAttr *FEAttr = ED->getAttr();
> -  assert(FEAttr && "looking for value in non-flag enum");
> +  assert(ED->hasAttr() && "looking for value in non-flag 
> enum");
> 
> -  llvm::APInt FlagMask = ~FEAttr->getFlagBits();
> -  unsigned Width = FlagMask.getBitWidth();
> +  auto R = FlagBitsCache.insert(std::make_pair(ED, llvm::APInt()));
> +  llvm::APInt &FlagBits = R.first->second;
> 
> -  // We will try a zero-extended value for the regular check first.
> -  llvm::APInt ExtVal = Val.zextOrSelf(Width);
> +  if (R.second) {
> +for (auto *E : ED->enumerators()) {
> +  const auto &Val = E->getInitVal();
> +  // Only single-bit enumerators introduce new flag values.
> +  if (Val.isPowerOf2())
> +FlagBits = FlagBits.zextOrSelf(Val.getBitWidth()) | Val;
> +}
> +  }
> +
> +  llvm::APInt FlagMask = ~FlagBits.zextOrTrunc(Val.getBitWidth());
> 
>   // A value is in a flag enum if either its bits are a subset of the enum's
>   // flag bits (the first condition) or we are allowing masks and the same is
> @@ -14034,26 +14041,10 @@ Sema::IsValueInFlagEnum(const EnumDecl *
>   // While it's true that any value could be used as a mask, the assumption is
>   // that a mask will have all of the insignificant bits set. Anything else is
>   // likely a logic error.
> -  if (!(FlagMask & ExtVal))
> +  if (!(FlagMask & Val) ||
> +  (AllowMask && !(FlagMask & ~Val)))
> return true;
> 
> -  if (AllowMask) {
> -// Try a one-extended value instead. This can happen if the enum is wider
> -// than the constant used, in C with extensions to allow for wider enums.
> -// The mask will still have the correct behaviour, so we give the user 
> the
> -// benefit of the doubt.
> -//
> -// FIXME: This heuristic can cause weird results if the enum was extended
> -// to a larger type and is signed, because then bit-masks of smaller 

Re: r246830 - Fix a potential APInt memory leak when using __attribute__((flag_enum)), and

[Steven Wu via cfe-commits]

Sorry I just get back to my computer. I will watch the bots going. I will try 
investigating if it is still failing.
As far as I know, there is no special settingl about the bots and all our bots 
are complaining about it. 

Steven

> On Sep 3, 2015, at 9:09 PM, Richard Smith  wrote:
> 
> OK, should be fixed in r246836.
> 
> On Thu, Sep 3, 2015 at 7:50 PM, Richard Smith  <mailto:rich...@metafoo.co.uk>> wrote:
> On Thu, Sep 3, 2015 at 6:21 PM, Steven Wu via cfe-commits 
> mailto:cfe-commits@lists.llvm.org>> wrote:
> In case you didn’t get an email from the failure because it was overshadowed 
> by the previous error. This commit seems to break the green dragon bots:
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/12990/testReport/junit/Clang/Sema/attr_flag_enum_c/
>  
> <http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/12990/testReport/junit/Clang/Sema/attr_flag_enum_c/>
> 
> I have no idea what's wrong here; is there anything unusual about that bot 
> that might give me a clue? (This bot: 
> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/4637 
> <http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/4637> seems to 
> be failing the same way.)
>  
> Thanks
> 
> Steven
> 
>> On Sep 3, 2015, at 6:03 PM, Richard Smith via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> 
>> Author: rsmith
>> Date: Thu Sep  3 20:03:03 2015
>> New Revision: 246830
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=246830&view=rev 
>> <http://llvm.org/viewvc/llvm-project?rev=246830&view=rev>
>> Log:
>> Fix a potential APInt memory leak when using __attribute__((flag_enum)), and
>> simplify the implementation a bit.
>> 
>> Modified:
>>cfe/trunk/include/clang/Basic/Attr.td
>>cfe/trunk/include/clang/Sema/Sema.h
>>cfe/trunk/lib/Sema/SemaDecl.cpp
>>cfe/trunk/lib/Sema/SemaStmt.cpp
>> 
>> Modified: cfe/trunk/include/clang/Basic/Attr.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=246830&r1=246829&r2=246830&view=diff
>>  
>> <http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=246830&r1=246829&r2=246830&view=diff>
>> ==
>> --- cfe/trunk/include/clang/Basic/Attr.td (original)
>> +++ cfe/trunk/include/clang/Basic/Attr.td Thu Sep  3 20:03:03 2015
>> @@ -747,18 +747,6 @@ def FlagEnum : InheritableAttr {
>>   let Subjects = SubjectList<[Enum]>;
>>   let Documentation = [FlagEnumDocs];
>>   let LangOpts = [COnly];
>> -  let AdditionalMembers = [{
>> -private:
>> -llvm::APInt FlagBits;
>> -public:
>> -llvm::APInt &getFlagBits() {
>> -  return FlagBits;
>> -}
>> -
>> -const llvm::APInt &getFlagBits() const {
>> -  return FlagBits;
>> -}
>> -}];
>> }
>> 
>> def Flatten : InheritableAttr {
>> 
>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=246830&r1=246829&r2=246830&view=diff
>>  
>> <http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=246830&r1=246829&r2=246830&view=diff>
>> ==
>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>> +++ cfe/trunk/include/clang/Sema/Sema.h Thu Sep  3 20:03:03 2015
>> @@ -903,6 +903,10 @@ public:
>>   /// for C++ records.
>>   llvm::FoldingSet SpecialMemberCache;
>> 
>> +  /// \brief A cache of the flags available in enumerations with the 
>> flag_bits
>> +  /// attribute.
>> +  mutable llvm::DenseMap FlagBitsCache;
>> +
>>   /// \brief The kind of translation unit we are processing.
>>   ///
>>   /// When we're processing a complete translation unit, Sema will perform
>> 
>> Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=246830&r1=246829&r2=246830&view=diff
>>  
>> <http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=246830&r1=246829&r2=246830&view=diff>
>> ==
>> --- cfe/trunk/lib/Sema/SemaDecl.cpp (original)
>> +++ cfe/trunk/lib/Sema/SemaDecl.cpp Thu Sep  3 20:03:03 2015
>> @@ -140

Re: r246830 - Fix a potential APInt memory leak when using __attribute__((flag_enum)), and

[Steven Wu via cfe-commits]

Looks fixed. Thank a lot for investigating!

> On Sep 3, 2015, at 9:21 PM, Steven Wu via cfe-commits 
>  wrote:
> 
> Sorry I just get back to my computer. I will watch the bots going. I will try 
> investigating if it is still failing.
> As far as I know, there is no special settingl about the bots and all our 
> bots are complaining about it. 
> 
> Steven
> 
>> On Sep 3, 2015, at 9:09 PM, Richard Smith > <mailto:rich...@metafoo.co.uk>> wrote:
>> 
>> OK, should be fixed in r246836.
>> 
>> On Thu, Sep 3, 2015 at 7:50 PM, Richard Smith > <mailto:rich...@metafoo.co.uk>> wrote:
>> On Thu, Sep 3, 2015 at 6:21 PM, Steven Wu via cfe-commits 
>> mailto:cfe-commits@lists.llvm.org>> wrote:
>> In case you didn’t get an email from the failure because it was overshadowed 
>> by the previous error. This commit seems to break the green dragon bots:
>> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/12990/testReport/junit/Clang/Sema/attr_flag_enum_c/
>>  
>> <http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_check/12990/testReport/junit/Clang/Sema/attr_flag_enum_c/>
>> 
>> I have no idea what's wrong here; is there anything unusual about that bot 
>> that might give me a clue? (This bot: 
>> http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/4637 
>> <http://lab.llvm.org:8011/builders/clang-x64-ninja-win7/builds/4637> seems 
>> to be failing the same way.)
>>  
>> Thanks
>> 
>> Steven
>> 
>>> On Sep 3, 2015, at 6:03 PM, Richard Smith via cfe-commits 
>>> mailto:cfe-commits@lists.llvm.org>> wrote:
>>> 
>>> Author: rsmith
>>> Date: Thu Sep  3 20:03:03 2015
>>> New Revision: 246830
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=246830&view=rev 
>>> <http://llvm.org/viewvc/llvm-project?rev=246830&view=rev>
>>> Log:
>>> Fix a potential APInt memory leak when using __attribute__((flag_enum)), and
>>> simplify the implementation a bit.
>>> 
>>> Modified:
>>>cfe/trunk/include/clang/Basic/Attr.td
>>>cfe/trunk/include/clang/Sema/Sema.h
>>>cfe/trunk/lib/Sema/SemaDecl.cpp
>>>cfe/trunk/lib/Sema/SemaStmt.cpp
>>> 
>>> Modified: cfe/trunk/include/clang/Basic/Attr.td
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=246830&r1=246829&r2=246830&view=diff
>>>  
>>> <http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Attr.td?rev=246830&r1=246829&r2=246830&view=diff>
>>> ==
>>> --- cfe/trunk/include/clang/Basic/Attr.td (original)
>>> +++ cfe/trunk/include/clang/Basic/Attr.td Thu Sep  3 20:03:03 2015
>>> @@ -747,18 +747,6 @@ def FlagEnum : InheritableAttr {
>>>   let Subjects = SubjectList<[Enum]>;
>>>   let Documentation = [FlagEnumDocs];
>>>   let LangOpts = [COnly];
>>> -  let AdditionalMembers = [{
>>> -private:
>>> -llvm::APInt FlagBits;
>>> -public:
>>> -llvm::APInt &getFlagBits() {
>>> -  return FlagBits;
>>> -}
>>> -
>>> -const llvm::APInt &getFlagBits() const {
>>> -  return FlagBits;
>>> -}
>>> -}];
>>> }
>>> 
>>> def Flatten : InheritableAttr {
>>> 
>>> Modified: cfe/trunk/include/clang/Sema/Sema.h
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=246830&r1=246829&r2=246830&view=diff
>>>  
>>> <http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=246830&r1=246829&r2=246830&view=diff>
>>> ==
>>> --- cfe/trunk/include/clang/Sema/Sema.h (original)
>>> +++ cfe/trunk/include/clang/Sema/Sema.h Thu Sep  3 20:03:03 2015
>>> @@ -903,6 +903,10 @@ public:
>>>   /// for C++ records.
>>>   llvm::FoldingSet SpecialMemberCache;
>>> 
>>> +  /// \brief A cache of the flags available in enumerations with the 
>>> flag_bits
>>> +  /// attribute.
>>> +  mutable llvm::DenseMap FlagBitsCache;
>>> +
>>>   /// \brief The kind of translation unit we are processing.
>>>   ///
>>>   /// When we're processing a complete translation unit, Sema will perform
>>> 
>&

[PATCH] D12644: Using -isysroot on Apple platform

[Steven Wu via cfe-commits]

steven_wu created this revision.
steven_wu added a reviewer: EricWF.
steven_wu added a subscriber: cfe-commits.

--sysroot might cause inconsistency between the header gets used and the
library gets linked on Apple platform. Use -isysroot instead.

http://reviews.llvm.org/D12644

Files:
  CMakeLists.txt

Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -209,7 +209,11 @@
 # Target flags 
 add_flags_if(LIBCXX_BUILD_32_BITS -m32)
 add_flags_if(LIBCXX_TARGET_TRIPLE "-target ${LIBCXX_TARGET_TRIPLE}")
-add_flags_if(LIBCXX_SYSROOT "--sysroot ${LIBCXX_SYSROOT}")
+if (APPLE)
+  add_flags_if(LIBCXX_SYSROOT "-isysroot ${LIBCXX_SYSROOT}")
+else
+  add_flags_if(LIBCXX_SYSROOT "--sysroot ${LIBCXX_SYSROOT}")
+endif()
 add_flags_if(LIBCXX_GCC_TOOLCHAIN "-gcc-toolchain ${LIBCXX_GCC_TOOLCHAIN}")
 
 # Warning flags ===


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -209,7 +209,11 @@
 # Target flags 
 add_flags_if(LIBCXX_BUILD_32_BITS -m32)
 add_flags_if(LIBCXX_TARGET_TRIPLE "-target ${LIBCXX_TARGET_TRIPLE}")
-add_flags_if(LIBCXX_SYSROOT "--sysroot ${LIBCXX_SYSROOT}")
+if (APPLE)
+  add_flags_if(LIBCXX_SYSROOT "-isysroot ${LIBCXX_SYSROOT}")
+else
+  add_flags_if(LIBCXX_SYSROOT "--sysroot ${LIBCXX_SYSROOT}")
+endif()
 add_flags_if(LIBCXX_GCC_TOOLCHAIN "-gcc-toolchain ${LIBCXX_GCC_TOOLCHAIN}")
 
 # Warning flags ===
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12644: Using -isysroot on Apple platform

[Steven Wu via cfe-commits]

steven_wu updated this revision to Diff 34073.
steven_wu added a comment.

Sorry, made a typo on the previous patch.

A little background information. When the greendragon jenkins make an
system upgrade in the future, it will need this flag as well to build and
test libcxx through cmake/ninja.


http://reviews.llvm.org/D12644

Files:
  CMakeLists.txt

Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -209,7 +209,11 @@
 # Target flags 
 add_flags_if(LIBCXX_BUILD_32_BITS -m32)
 add_flags_if(LIBCXX_TARGET_TRIPLE "-target ${LIBCXX_TARGET_TRIPLE}")
-add_flags_if(LIBCXX_SYSROOT "--sysroot ${LIBCXX_SYSROOT}")
+if (APPLE)
+  add_flags_if(LIBCXX_SYSROOT "-isysroot ${LIBCXX_SYSROOT}")
+else()
+  add_flags_if(LIBCXX_SYSROOT "--sysroot ${LIBCXX_SYSROOT}")
+endif()
 add_flags_if(LIBCXX_GCC_TOOLCHAIN "-gcc-toolchain ${LIBCXX_GCC_TOOLCHAIN}")
 
 # Warning flags ===


Index: CMakeLists.txt
===
--- CMakeLists.txt
+++ CMakeLists.txt
@@ -209,7 +209,11 @@
 # Target flags 
 add_flags_if(LIBCXX_BUILD_32_BITS -m32)
 add_flags_if(LIBCXX_TARGET_TRIPLE "-target ${LIBCXX_TARGET_TRIPLE}")
-add_flags_if(LIBCXX_SYSROOT "--sysroot ${LIBCXX_SYSROOT}")
+if (APPLE)
+  add_flags_if(LIBCXX_SYSROOT "-isysroot ${LIBCXX_SYSROOT}")
+else()
+  add_flags_if(LIBCXX_SYSROOT "--sysroot ${LIBCXX_SYSROOT}")
+endif()
 add_flags_if(LIBCXX_GCC_TOOLCHAIN "-gcc-toolchain ${LIBCXX_GCC_TOOLCHAIN}")
 
 # Warning flags ===
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D12169: Relax constexpr rules to improve __builtin_object_size's accuracy

[Steven Wu via cfe-commits]

steven_wu added a subscriber: steven_wu.
steven_wu added a comment.

This commit seems to cause miscompile in LNT testsuite with -O0 and -O3
http://lab.llvm.org:8080/green/job/perf_o0g_run/7070/warnings2Result/new/
http://lab.llvm.org:8080/green/job/perf_o3lto_run/15591/warnings2Result/new/

Looks like there is an undefined in LNT testsuite, here is the relevant code 
for consumer-lame:

  typedef struct
  
  { 
  
int used;   
  
int valid;  
  
char title[31]; 
  
char artist[31];
  
char album[31]; 
  
char year[5];   
  
char comment[31];   
  
char tagtext[128];  
  
char genre[1];  
  
unsigned char track;
  

  
  }   ID3TAGDATA; 
  void id3_inittag(ID3TAGDATA *tag) {   
  
...
strcpy( tag->genre, "ÿ"); /* unset genre */  
... 
  }

Here is the suggested change:

  diff --git a/MultiSource/Benchmarks/MiBench/consumer-lame/id3tag.c 
b/MultiSource/Benchmarks/MiBench/consumer-lame/id3tag.c
  index e24a966..23f2b86 100644
  --- a/MultiSource/Benchmarks/MiBench/consumer-lame/id3tag.c
  +++ b/MultiSource/Benchmarks/MiBench/consumer-lame/id3tag.c
  @@ -34,7 +34,7 @@ void id3_inittag(ID3TAGDATA *tag) {
  strcpy( tag->album, "");
  strcpy( tag->year, "");
  strcpy( tag->comment, "");
  -   strcpy( tag->genre, "");/* unset genre */
  +   tag->genre[0] = ''; /* unset genre */
  tag->track = 0;
   
  tag->valid = 0; /* not ready for writing*/

However, I have trouble understand the code in consumer-typeset. It crashes in 
z07.c:138
By the looks of it, the code is trying to copy the include path (specified on 
command line), which is setup to be 
"$PATH_TO_TEST_SUITE/MultiSource/Benchmarks/MiBench/consumer-typeset/data/include"
 into unsigned char ostring[4]. From the look of the code, it is trying to 
utilize all the size in OBJECT to store the entire string. I don't know if that 
is fixable. Let me know if you have any better idea of how to fix that.


http://reviews.llvm.org/D12169



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

Re: [PATCH] D12644: Using -isysroot on Apple platform

[Steven Wu via cfe-commits]

steven_wu added a comment.

That works as well. I am not sure if there is any specific reason for using 
"--sysroot" so I proposed a safer fix.


http://reviews.llvm.org/D12644



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

Re: [libcxx] r249798 - Split out of .

[Steven Wu via cfe-commits]

Hi Richard

Your splitting seems causing problem when using extern "C". Here is a test case:

$ cat test.cpp 
#ifdef __cplusplus
extern "C" {
#endif
#include 
#ifdef __cplusplus
}
#endif

Error:
clang -fsyntax-only test.cpp 
In file included from test.cpp:4:
In file included from /usr/bin/../include/c++/v1/stdio.h:102:
/usr/bin/../include/c++/v1/__config:593:1: error: 
  templates must have C++ linkage
template  struct __static_assert_test;
^~~
/usr/bin/../include/c++/v1/__config:594:20: error: 
  explicit specialization of non-template struct '__static_assert_test'
template <> struct __static_assert_test {};
   ^   ~~
/usr/bin/../include/c++/v1/__config:595:1: error: 
  templates must have C++ linkage
template  struct __static_assert_check {};
^~~
3 errors generated.

Because the code is actually compiled in C++, the guard in the header failed to 
exclude the templates. In the meantime, I don't know if there are ways to 
detect the header is in extern "C".

Steven


> On Oct 8, 2015, at 6:29 PM, Richard Smith via cfe-commits 
>  wrote:
> 
> Author: rsmith
> Date: Thu Oct  8 20:29:09 2015
> New Revision: 249798
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=249798&view=rev
> Log:
> Split  out of .
> 
> As with , skip our custom header if __need_FILE or __need___FILE is 
> defined.
> 
> Added:
>libcxx/trunk/include/stdio.h
>  - copied, changed from r249736, libcxx/trunk/include/cstdio
> Modified:
>libcxx/trunk/include/cstdio
>libcxx/trunk/test/std/depr/depr.c.headers/stdio_h.pass.cpp
> 
> Modified: libcxx/trunk/include/cstdio
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/cstdio?rev=249798&r1=249797&r2=249798&view=diff
> ==
> --- libcxx/trunk/include/cstdio (original)
> +++ libcxx/trunk/include/cstdio Thu Oct  8 20:29:09 2015
> @@ -103,16 +103,6 @@ void perror(const char* s);
> #pragma GCC system_header
> #endif
> 
> -// snprintf
> -#if defined(_LIBCPP_MSVCRT)
> -#include "support/win32/support.h"
> -#endif
> -
> -#undef getc
> -#undef putc
> -#undef clearerr
> -#undef feof
> -#undef ferror
> _LIBCPP_BEGIN_NAMESPACE_STD
> 
> using ::FILE;
> 
> Copied: libcxx/trunk/include/stdio.h (from r249736, 
> libcxx/trunk/include/cstdio)
> URL: 
> http://llvm.org/viewvc/llvm-project/libcxx/trunk/include/stdio.h?p2=libcxx/trunk/include/stdio.h&p1=libcxx/trunk/include/cstdio&r1=249736&r2=249798&rev=249798&view=diff
> ==
> --- libcxx/trunk/include/cstdio (original)
> +++ libcxx/trunk/include/stdio.h Thu Oct  8 20:29:09 2015
> @@ -1,5 +1,5 @@
> // -*- C++ -*-
> -//=== cstdio 
> --===//
> +//=== stdio.h 
> -===//
> //
> // The LLVM Compiler Infrastructure
> //
> @@ -8,11 +8,19 @@
> //
> //===--===//
> 
> -#ifndef _LIBCPP_CSTDIO
> -#define _LIBCPP_CSTDIO
> +#if defined(__need_FILE) || defined(__need___FILE)
> +
> +#if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
> +#pragma GCC system_header
> +#endif
> +
> +#include_next 
> +
> +#elif !defined(_LIBCPP_STDIO_H)
> +#define _LIBCPP_STDIO_H
> 
> /*
> -cstdio synopsis
> +stdio.h synopsis
> 
> Macros:
> 
> @@ -33,9 +41,6 @@ Macros:
> stdin
> stdout
> 
> -namespace std
> -{
> -
> Types:
> 
> FILE
> @@ -92,20 +97,23 @@ void clearerr(FILE* stream);
> int feof(FILE* stream);
> int ferror(FILE* stream);
> void perror(const char* s);
> -
> -}  // std
> */
> 
> #include <__config>
> -#include 
> 
> #if !defined(_LIBCPP_HAS_NO_PRAGMA_SYSTEM_HEADER)
> #pragma GCC system_header
> #endif
> 
> +#include_next 
> +
> +#ifdef __cplusplus
> +
> // snprintf
> #if defined(_LIBCPP_MSVCRT)
> +extern "C++" {
> #include "support/win32/support.h"
> +}
> #endif
> 
> #undef getc
> @@ -113,72 +121,7 @@ void perror(const char* s);
> #undef clearerr
> #undef feof
> #undef ferror
> -_LIBCPP_BEGIN_NAMESPACE_STD
> -
> -using ::FILE;
> -using ::fpos_t;
> -using ::size_t;
> -
> -using ::fclose;
> -using ::fflush;
> -using ::setbuf;
> -using ::setvbuf;
> -using ::fprintf;
> -using ::fscanf;
> -using ::snprintf;
> -using ::sprintf;
> -using ::sscanf;
> -#ifndef _LIBCPP_MSVCRT
> -using ::vfprintf;
> -using ::vfscanf;
> -using ::vsscanf;
> -#endif // _LIBCPP_MSVCRT
> -using ::vsnprintf;
> -using ::vsprintf;
> -using ::fgetc;
> -using ::fgets;
> -using ::fputc;
> -using ::fputs;
> -using ::getc;
> -using ::putc;
> -using ::ungetc;
> -using ::fread;
> -using ::fwrite;
> -using ::fgetpos;
> -using ::fseek;
> -using ::fsetpos;
> -using ::ftell;
> -using ::rewind;
> -using ::clearerr;
> -using ::feof;
> -using ::ferror;
> -using ::perror;
> -
> -#ifndef _LIBCPP_HAS_NO_GLOBAL_FILESYSTEM_NAMESPACE
> -using ::fopen;
> -using ::freopen;
> -usi

Re: [llvm-dev] [RFC] Embedded bitcode and related upstream (Part II)

[Steven Wu via cfe-commits]

> On Jul 25, 2016, at 3:24 AM, Jonas Devlieghere  wrote:
> 
> Hi,
> 
> I hope I'm not breaking any mailing list etiquette by replying to this
> mail, but if I am then please accept my apologies.
> 
> On Fri, Jun 3, 2016 at 8:36 PM, Steven Wu via llvm-dev
>  wrote:
>> Hi everyone
>> 
>> I am still in the process of upstreaming some improvements to the embed
>> bitcode option. If you want more background, you can read the previous RFC
>> (http://lists.llvm.org/pipermail/llvm-dev/2016-February/094851.html). This
>> is part II of the discussion.
>> 
>> Current Status:
>> A basic version of -fembed-bitcode option is upstreamed and functioning.
>> You can use -fembed-bitcode={off, all, bitcode, marker} option to control
>> what gets embedded in the final object file output:
>> off: default, nothing gets embedded.
>> all: optimized bitcode and command line options gets embedded in the object
>> file.
>> bitcode: only optimized bitcode is embedded
>> marker: only put a marker in the object file
>> 
>> What needs to be improved:
>> 1. Whitelist for command line options that can be used with bitcode:
>> Current trunk implementation embeds all the cc1 command line options (that
>> includes header include paths, warning flags and other front-end options) in
>> the command line section. That is lot of redundant information. To re-create
>> the object file from the embedded optimized bitcode, most of these options
>> are useless. On the other hand, they can leak information of the source
>> code. One solution will be keeping a list of all the options that can affect
>> code generation but not encoded in the bitcode. I have internally prototyped
>> with disallowing these options explicitly and allowed only the reminder of
>> the  options to be embedded (http://reviews.llvm.org/D17394). A better
>> solution might be encoding that information in "Options.td" as specific
>> group.
>> 
>> 2. Assembly input handling:
>> This is a workaround to allow source code written in assembly to work with
>> "-fembed-bitcode" options. When compiling assembly source code with
>> "-fembed-bitcode", clang-as creates an empty section "__LLVM, __asm" in the
>> object file. That is just a way to distinguish object files compiled from
>> assembly source from those compiled from higher level source code but forgot
>> to use "-fembed-bitcode" options. Linker can use this section to diagnose if
>> "-fembed-bitcode" is consistently used on all the object files participated
>> in the linking.
>> 
>> 3. Bitcode symbol hiding:
>> There was some concerns for leaking source code information when using
>> bitcode feature. One approach to avoid the leak is to add a pass which
>> renames all the globals and metadata strings. The also keeps a reverse map
>> in case the original name needs to be recovered. The final bitcode should
>> contain no more symbols or debug info than a stripped binary. To make sure
>> modified bitcode can still be linked correctly, the renaming need to be
>> consistent across all bitcode participated in the linking and everything
>> that is external of the linkage unit need to be preserved. This means the
>> pass can only be run during the linking and requires some LTO api.
> 
> Regarding the symbol map, are you planning to upstream a pass that
> restores the symbols? I have been trying to do this myself in order to
> reverse the "BCSymbolMap". However this turned out to be less
> straightforward than I'd hoped. Any info on this would be greatly
> appreciated!

We have tools to restore symbols in the dSYM bundle (check dsymutil -symbol-map 
option in the Apple toolchain). 
I don't think we have a pass to restore the symbols in the bitcode now but that 
should be very straight forward and I am happy to implement one as a part of 
the item 3. 
Of course, that will only happen if the community thinks this feature is 
beneficial to them. At the meantime, if you need assist, please file a radar to 
Apple at https://bugreport.apple.com .

Steven


> 
>> 4. Debug info strip to line-tables pass:
>> As the name suggested, this pass strip down the full debug info to
>> line-tables only. This is also one of the steps we took to prevent the leak
>> of source code information in bitcode.
>> 
>> Please let me know what do you think about the pieces above or if you have
>> any concerns about the methodology. I will put up patches for review soon.
>> 
>> Thanks
>> 
>> Steven
>> 
>> ___
>> LLVM Developers mailing list
>> llvm-...@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/llvm-dev
> 
> Cheers,
> Jonas

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

[PATCH] D17389: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu created this revision.
steven_wu added a subscriber: cfe-commits.
Herald added subscribers: dschuff, jfb.

Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file.  Using -fembed-bitcode-marker will only introduce a
marker in both sections.

Don't emit uselist order for -fembed-bitcode

Embedded bitcode are embedded without serialization in their normal
flow. No uselist order need to be recorded.

Apply whitelist to options used in embedded bitcode

Add a whitelist for the options that are allowed to be used with
-fembed-bitcode. That is minimize the number of the cc1 command
that needs to be embedded in the object file.

http://reviews.llvm.org/D17389

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/CodeGen/BackendUtil.h
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Tools.cpp
  lib/Driver/Tools.h
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/embed-bitcode.c
  test/Frontend/embed-bitcode.ll

Index: test/Frontend/embed-bitcode.ll
===
--- /dev/null
+++ test/Frontend/embed-bitcode.ll
@@ -0,0 +1,48 @@
+; check .ll input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode -x ir %s -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode-marker -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+; RUN: %clang_cc1 -triple aarch64-unknown-linux-gnueabi -emit-llvm \
+; RUN:-fembed-bitcode -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ELF
+
+; check .bc input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-x ir %s -o %t.bc
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode -x ir %t.bc -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode-marker -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+
+; run through -fembed-bitcode twice and make sure it doesn't crash
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-fembed-bitcode -x ir %s -o - \
+; RUN: | %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode -x ir - -o /dev/null
+
+; check the magic number of bitcode at the beginning of the string
+; CHECK: @llvm.embedded.module
+; CHECK: c"\DE\C0\17\0B
+; CHECK: section "__LLVM,__bitcode"
+; CHECK: @llvm.cmdline
+; CHECK: section "__LLVM,__cmdline"
+
+; CHECK-ELF: @llvm.embedded.module
+; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF: @llvm.cmdline
+; CHECK-ELF: section ".llvmcmd"
+
+; CHECK-MARKER: @llvm.embedded.module
+; CHECK-MARKER: constant [0 x i8] zeroinitializer
+; CHECK-MARKER: section "__LLVM,__bitcode"
+; CHECK-MARKER: @llvm.cmdline
+; CHECK-MARKER: section "__LLVM,__cmdline"
+
+define i32 @f0() {
+  ret i32 0
+}
Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -5,6 +5,7 @@
 // RUN: %clang %s -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-CC
 // CHECK-CC: -cc1
 // CHECK-CC: -emit-llvm-bc
+// CHECK-CC-NOT: -emit-llvm-uselists
 // CHECK-CC: -cc1
 // CHECK-CC: -emit-obj
 // CHECK-CC: -fembed-bitcode
@@ -24,3 +25,62 @@
 // CHECK-MARKER: -fembed-bitcode-marker
 // CHECK-MARKER-NOT: -cc1
 
+// Check clang complains about ios version min if it is used to generate link command.
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=6.0 %s -fembed-bitcode -### 2>&1 | \
+// RUN:   FileCheck %s -check-prefix=CHECK-PLATFORM-SUPPORTED
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=5.0 %s -fembed-bitcode -### 2>&1 | \
+// RUN:   FileCheck %s -check-prefix=CHECK-PLATFORM-UNSUPPORTED
+// RUN: %clang -target armv7-apple-darwin -miphoneos-version-min=5.0 -c %s -fembed-bitcode -### 2>&1 | \
+// RUN:   FileCheck %s -check-prefix=CHECK-PLATFORM-SUPPORTED
+// CHECK-PLATFORM-SUPPORTED-NOT: -fembed-bitcode is not supported on versions of iOS prior to 6.0
+// CHECK-PLATFORM-UNSUPPORTED: -fembed-bitcode is not supported on versions of iOS prior to 6.0
+
+// RUN: %clang -c %s -fembed-bitcode -mkernel -fapple-kext -ffunction-sections \
+// RUN:   -fno-function-sections -fdata-sections -fno-data-sections \
+// RUN:   -funique-section-names -fno-unique-section-names -mrestrict-it \
+// RUN:   -mno-restrict-it -mstackrealgin -mno-stackrealign -mstack-alignment=8 \
+// RUN:   -mcmodel=small -mlong-calls -mno-long-calls -ggnu-pubnames \
+// RUN:   -gdwarf-arange -fdebug-types-section -fno-debug-types-section \
+// RUN:   -fdwarf-directory-asm -fno-dwarf-dire

[PATCH] D17390: Introduce -fembed-bitcode driver option

[Steven Wu via cfe-commits]

steven_wu created this revision.
steven_wu added a subscriber: cfe-commits.

This is the clang driver part of the change to embedded bitcode. This
includes:
1. -fembed-bitcode option which breaks down the compilation into two
stages. The first stage emits optimized bitcode and the second stage
compiles bitcode into object file.
2. -fembed-bitcode-marker option which doesn't really break down to
two stages to speedup the compilation flow.
3. pass the correct linker flag to darwin linker if tool chains supports
embedded bitcode.

http://reviews.llvm.org/D17390

Files:
  include/clang/Basic/DiagnosticDriverKinds.td
  include/clang/Driver/Driver.h
  include/clang/Driver/Options.td
  include/clang/Driver/ToolChain.h
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains.cpp
  lib/Driver/ToolChains.h
  lib/Driver/Tools.cpp
  test/Driver/embed-bitcode.c

Index: test/Driver/embed-bitcode.c
===
--- /dev/null
+++ test/Driver/embed-bitcode.c
@@ -0,0 +1,26 @@
+// RUN: %clang -ccc-print-bindings -c %s -fembed-bitcode 2>&1 | FileCheck %s
+// CHECK: clang
+// CHECK: clang
+
+// RUN: %clang %s -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-CC
+// CHECK-CC: -cc1
+// CHECK-CC: -emit-llvm-bc
+// CHECK-CC: -cc1
+// CHECK-CC: -emit-obj
+// CHECK-CC: -fembed-bitcode
+// CHECK-CC: ld
+// CHECK-CC: -bitcode_bundle
+
+// RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
+// CHECK-LTO: -cc1
+// CHECK-LTO: -emit-llvm-bc
+// CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
+// CHECK-LTO-NOT: -cc1
+// CHECK-LTO-NOT: -fembed-bitcode
+
+// RUN: %clang -c %s -fembed-bitcode-marker 2>&1 -### | FileCheck %s -check-prefix=CHECK-MARKER
+// CHECK-MARKER: -cc1
+// CHECK-MARKER: -emit-obj
+// CHECK-MARKER: -fembed-bitcode-marker
+// CHECK-MARKER-NOT: -cc1
+
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -3620,6 +3620,17 @@
 Args.AddLastArg(CmdArgs, options::OPT_fthinlto_index_EQ);
   }
 
+  // Embed-bitcode option.
+  if (C.getDriver().embedBitcodeEnabled() &&
+  (isa(JA) || isa(JA))) {
+// Add flags implied by -fembed-bitcode.
+CmdArgs.push_back("-fembed-bitcode");
+// Disable all llvm IR level optimizations.
+CmdArgs.push_back("-disable-llvm-optzns");
+  }
+  if (C.getDriver().embedBitcodeMarkerOnly())
+CmdArgs.push_back("-fembed-bitcode-marker");
+
   // We normally speed up the clang process a bit by skipping destructors at
   // exit, but when we're generating diagnostics we can rely on some of the
   // cleanup.
@@ -7176,6 +7187,15 @@
 else
   CmdArgs.push_back("-no_pie");
   }
+  // for embed-bitcode, use -bitcode_bundle in linker command
+  if (C.getDriver().embedBitcodeEnabled() ||
+  C.getDriver().embedBitcodeMarkerOnly()) {
+// Check if the toolchain supports bitcode build flow.
+if (MachOTC.SupportsEmbeddedBitcode())
+  CmdArgs.push_back("-bitcode_bundle");
+else
+  D.Diag(diag::err_drv_bitcode_unsupported_on_toolchain);
+  }
 
   Args.AddLastArg(CmdArgs, options::OPT_prebind);
   Args.AddLastArg(CmdArgs, options::OPT_noprebind);
Index: lib/Driver/ToolChains.h
===
--- lib/Driver/ToolChains.h
+++ lib/Driver/ToolChains.h
@@ -542,6 +542,8 @@
 
   bool UseSjLjExceptions(const llvm::opt::ArgList &Args) const override;
 
+  bool SupportsEmbeddedBitcode() const override;
+
   SanitizerMask getSupportedSanitizers() const override;
 };
 
Index: lib/Driver/ToolChains.cpp
===
--- lib/Driver/ToolChains.cpp
+++ lib/Driver/ToolChains.cpp
@@ -1103,6 +1103,13 @@
   return !Triple.isWatchABI();
 }
 
+bool Darwin::SupportsEmbeddedBitcode() const {
+  assert(TargetInitialized && "Target not initialized!");
+  if (isTargetIPhoneOS() && isIPhoneOSVersionLT(6, 0))
+return false;
+  return true;
+}
+
 bool MachO::isPICDefault() const { return true; }
 
 bool MachO::isPIEDefault() const { return false; }
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -50,7 +50,7 @@
DiagnosticsEngine &Diags,
IntrusiveRefCntPtr VFS)
 : Opts(createDriverOptTable()), Diags(Diags), VFS(VFS), Mode(GCCMode),
-  SaveTemps(SaveTempsNone), LTOMode(LTOK_None),
+  SaveTemps(SaveTempsNone), BitcodeEmbed(EmbedNone), LTOMode(LTOK_None),
   ClangExecutable(ClangExecutable),
   SysRoot(DEFAULT_SYSROOT), UseStdLib(true),
   DefaultTargetTriple(DefaultTargetTriple),
@@ -479,6 +479,19 @@
 .Default(SaveTempsCwd);
   }
 
+  // Ignore -fembed-bitcode options with LTO
+  // since the output will be bitcode anyway.
+  if (!Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false)) {
+if (

Re: [PATCH] D17389: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu abandoned this revision.
steven_wu added a comment.

I accidentally send this patch with everything in it. I will send out patch in 
small chunks instead.


http://reviews.llvm.org/D17389



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

[PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu created this revision.
steven_wu added a subscriber: cfe-commits.
steven_wu added a dependency: D17390: Introduce -fembed-bitcode driver option.

Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file.  Using -fembed-bitcode-marker will only introduce a
marker in both sections.

Depends on D17390

http://reviews.llvm.org/D17392

Files:
  include/clang/CodeGen/BackendUtil.h
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Frontend/embed-bitcode.ll

Index: test/Frontend/embed-bitcode.ll
===
--- /dev/null
+++ test/Frontend/embed-bitcode.ll
@@ -0,0 +1,48 @@
+; check .ll input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode -x ir %s -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode-marker -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+; RUN: %clang_cc1 -triple aarch64-unknown-linux-gnueabi -emit-llvm \
+; RUN:-fembed-bitcode -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ELF
+
+; check .bc input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-x ir %s -o %t.bc
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode -x ir %t.bc -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode-marker -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+
+; run through -fembed-bitcode twice and make sure it doesn't crash
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-fembed-bitcode -x ir %s -o - \
+; RUN: | %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode -x ir - -o /dev/null
+
+; check the magic number of bitcode at the beginning of the string
+; CHECK: @llvm.embedded.module
+; CHECK: c"\DE\C0\17\0B
+; CHECK: section "__LLVM,__bitcode"
+; CHECK: @llvm.cmdline
+; CHECK: section "__LLVM,__cmdline"
+
+; CHECK-ELF: @llvm.embedded.module
+; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF: @llvm.cmdline
+; CHECK-ELF: section ".llvmcmd"
+
+; CHECK-MARKER: @llvm.embedded.module
+; CHECK-MARKER: constant [0 x i8] zeroinitializer
+; CHECK-MARKER: section "__LLVM,__bitcode"
+; CHECK-MARKER: @llvm.cmdline
+; CHECK-MARKER: section "__LLVM,__cmdline"
+
+define i32 @f0() {
+  ret i32 0
+}
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -616,6 +616,34 @@
   }
 }
   }
+	// Handle -fembed-bitcode option.
+  Opts.EmbedBitcode = Args.hasArg(OPT_fembed_bitcode);
+  Opts.EmbedMarkerOnly = Args.hasArg(OPT_fembed_bitcode_marker);
+  // FIXME: For backend options that are not yet recorded as function
+  // attributes in the IR, keep track of them so we can embed them in a
+  // separate data section and use them when building the bitcode.
+  if (Opts.EmbedBitcode) {
+for (ArgList::const_iterator A = Args.begin(), AE = Args.end();
+ A != AE; ++ A) {
+  // Do not encode output and input.
+  if ((*A)->getOption().getID() == options::OPT_o ||
+  (*A)->getOption().getID() == options::OPT_INPUT ||
+  (*A)->getOption().getID() == options::OPT_x ||
+  (*A)->getOption().getID() == options::OPT_fembed_bitcode ||
+  ((*A)->getOption().getGroup().isValid() &&
+   (*A)->getOption().getGroup().getID() == options::OPT_W_Group))
+continue;
+  ArgStringList ASL;
+  (*A)->render(Args, ASL);
+  for (ArgStringList::iterator it = ASL.begin(), ie = ASL.end();
+  it != ie; ++ it) {
+StringRef ArgStr(*it);
+Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
+// using \00 to seperate each commandline options.
+Opts.CmdArgs.push_back('\0');
+  }
+}
+  }
 
   Opts.InstrumentFunctions = Args.hasArg(OPT_finstrument_functions);
   Opts.InstrumentForProfiling = Args.hasArg(OPT_pg);
Index: lib/Driver/Tools.cpp
===
--- lib/Driver/Tools.cpp
+++ lib/Driver/Tools.cpp
@@ -5553,7 +5553,10 @@
   // With -save-temps, we want to save the unoptimized bitcode output from the
   // CompileJobAction, use -disable-llvm-passes to get pristine IR generated
   // by the frontend.
-  if (C.getDriver().isSaveTempsEnabled() && isa(JA))
+  // When -fembed-bitcode is enabled, optimized bitcode is emitted because it
+  // has slightly different breakdown between stages.
+  if (C.getDrive

Embedded Bitcode in Object Files

[Steven Wu via cfe-commits]

Hi all

I put up some patches for embedding bitcode inside the object file 
(-fembed-bitcode) option. As I described in the dev list before, the new option 
can create normal object file with bitcode embedded in a special section. You 
can easily recreate the same object file with the embedded bitcode in it.

I split the patch into several parts:
llvm patch:
http://reviews.llvm.org/D17388: Introduce the section for embedding bitcode in 
MachO file.

There are four clang patches:
http://reviews.llvm.org/D17390: Implementing the clang driver for the new 
option.
http://reviews.llvm.org/D17392: Teach clang how to embed bitcode into the 
object file.
http://reviews.llvm.org/D17393: Slightly tweak the bitcode emitted in embed 
bitcode stage 1.
http://reviews.llvm.org/D17394: Reduce the amount of option gets embedded in 
the bitcode by introducing a whitelist and a blacklist.

Let me know if anyone is interested in helping reviewing these changes.

Thanks

Steven



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

[PATCH] D17627: Fix false positives for for-loop-analysis warning

[Steven Wu via cfe-commits]

steven_wu created this revision.
steven_wu added reviewers: rtrieu, thakis.
steven_wu added a subscriber: cfe-commits.

-Wfor-loop-analysis was incorrectly warning about certain cases because
the DeclMatcher is not looking pass OpaqueValueExpr.

http://reviews.llvm.org/D17627

Files:
  lib/Sema/SemaStmt.cpp
  test/SemaObjC/warn-loop-analysis.m

Index: test/SemaObjC/warn-loop-analysis.m
===
--- /dev/null
+++ test/SemaObjC/warn-loop-analysis.m
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -Wloop-analysis -verify %s
+// expected-no-diagnostics
+
+@interface MyArray
+- (id)objectAtIndexedSubscript:(unsigned int)idx;
+@end
+
+// Do not warn on objc classes has objectAtIndexedSubscript method.
+MyArray *test;
+void foo(void);
+void foo()
+{
+ unsigned int i;
+  for( i = 42 ; i > 0; ) // No warnings here
+   (void)test[ --i ];
+}
Index: lib/Sema/SemaStmt.cpp
===
--- lib/Sema/SemaStmt.cpp
+++ lib/Sema/SemaStmt.cpp
@@ -1440,6 +1440,11 @@
   FoundDecl = true;
 }
 
+void VisitOpaqueValueExpr(OpaqueValueExpr *OVE) {
+  if (Expr *E = OVE->getSourceExpr())
+Visit(E);
+}
+
 bool FoundDeclInUse() { return FoundDecl; }
 
   };  // end class DeclMatcher


Index: test/SemaObjC/warn-loop-analysis.m
===
--- /dev/null
+++ test/SemaObjC/warn-loop-analysis.m
@@ -0,0 +1,16 @@
+// RUN: %clang_cc1 -fsyntax-only -Wloop-analysis -verify %s
+// expected-no-diagnostics
+
+@interface MyArray
+- (id)objectAtIndexedSubscript:(unsigned int)idx;
+@end
+
+// Do not warn on objc classes has objectAtIndexedSubscript method.
+MyArray *test;
+void foo(void);
+void foo()
+{
+ unsigned int i;
+  for( i = 42 ; i > 0; ) // No warnings here
+   (void)test[ --i ];
+}
Index: lib/Sema/SemaStmt.cpp
===
--- lib/Sema/SemaStmt.cpp
+++ lib/Sema/SemaStmt.cpp
@@ -1440,6 +1440,11 @@
   FoundDecl = true;
 }
 
+void VisitOpaqueValueExpr(OpaqueValueExpr *OVE) {
+  if (Expr *E = OVE->getSourceExpr())
+Visit(E);
+}
+
 bool FoundDeclInUse() { return FoundDecl; }
 
   };  // end class DeclMatcher
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r261767 - Add whole-program vtable optimization feature to Clang.

[Steven Wu via cfe-commits]

Hi Peter

I notice after this commit, I can no longer use cmake option 
-DCLANG_TOOL_DRIVER_BUILD=OFF to choose not to build and link the clang driver. 
When using -DCLANG_TOOL_DRIVER_BUILD=OFF, clang target will not exist so cmake 
will error on the line:
> +add_dependencies(clang vtables_blacklist)

Is it possible to move this line to tools/driver/CMakeLists.txt?

Thanks

Steven


> On Feb 24, 2016, at 12:46 PM, Peter Collingbourne via cfe-commits 
>  wrote:
> 
> Author: pcc
> Date: Wed Feb 24 14:46:36 2016
> New Revision: 261767
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=261767&view=rev
> Log:
> Add whole-program vtable optimization feature to Clang.
> 
> This patch introduces the -fwhole-program-vtables flag, which enables the
> whole-program vtable optimization feature (D16795) in Clang.
> 
> Differential Revision: http://reviews.llvm.org/D16821
> 
> Added:
>cfe/trunk/runtime/vtables_blacklist.txt
>cfe/trunk/test/CodeGenCXX/bitset-blacklist.cpp
>  - copied, changed from r261762, 
> cfe/trunk/test/CodeGenCXX/cfi-blacklist.cpp
>cfe/trunk/test/CodeGenCXX/bitsets.cpp
>  - copied, changed from r261762, cfe/trunk/test/CodeGenCXX/cfi-vcall.cpp
>cfe/trunk/test/Driver/Inputs/resource_dir/vtables_blacklist.txt
>cfe/trunk/test/Driver/whole-program-vtables.c
> Removed:
>cfe/trunk/test/CodeGenCXX/cfi-blacklist.cpp
>cfe/trunk/test/CodeGenCXX/cfi-vcall.cpp
> Modified:
>cfe/trunk/docs/UsersManual.rst
>cfe/trunk/include/clang/Driver/Options.td
>cfe/trunk/include/clang/Frontend/CodeGenOptions.def
>cfe/trunk/include/clang/Frontend/CodeGenOptions.h
>cfe/trunk/lib/CodeGen/CGClass.cpp
>cfe/trunk/lib/CodeGen/CGExprCXX.cpp
>cfe/trunk/lib/CodeGen/CGVTables.cpp
>cfe/trunk/lib/CodeGen/CodeGenFunction.h
>cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>cfe/trunk/lib/CodeGen/CodeGenModule.h
>cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>cfe/trunk/lib/Driver/Tools.cpp
>cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>cfe/trunk/runtime/CMakeLists.txt
> 
> Modified: cfe/trunk/docs/UsersManual.rst
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=261767&r1=261766&r2=261767&view=diff
> ==
> --- cfe/trunk/docs/UsersManual.rst (original)
> +++ cfe/trunk/docs/UsersManual.rst Wed Feb 24 14:46:36 2016
> @@ -1053,6 +1053,21 @@ are listed below.
>the behavior of sanitizers in the ``cfi`` group to allow checking
>of cross-DSO virtual and indirect calls.
> 
> +.. option:: -fwhole-program-vtables
> +
> +   Enable whole-program vtable optimizations, such as single-implementation
> +   devirtualization and virtual constant propagation. Requires ``-flto``.
> +
> +   By default, the compiler will assume that all type hierarchies are
> +   closed except those in the ``std`` namespace, the ``stdext`` namespace
> +   and classes with the ``__declspec(uuid())`` attribute.
> +
> +.. option:: -fwhole-program-vtables-blacklist=path
> +
> +   Allows the user to specify the path to a list of additional classes to
> +   blacklist from whole-program vtable optimizations. This list is in the
> +   :ref:`CFI blacklist ` format.
> +
> .. option:: -fno-assume-sane-operator-new
> 
>Don't assume that the C++'s new operator is sane.
> 
> Modified: cfe/trunk/include/clang/Driver/Options.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=261767&r1=261766&r2=261767&view=diff
> ==
> --- cfe/trunk/include/clang/Driver/Options.td (original)
> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb 24 14:46:36 2016
> @@ -1124,6 +1124,13 @@ def fvisibility_inlines_hidden : Flag<["
> def fvisibility_ms_compat : Flag<["-"], "fvisibility-ms-compat">, 
> Group,
>   HelpText<"Give global types 'default' visibility and global functions and "
>"variables 'hidden' visibility by default">;
> +def fwhole_program_vtables : Flag<["-"], "fwhole-program-vtables">, 
> Group,
> +  Flags<[CC1Option]>,
> +  HelpText<"Enables whole-program vtable optimization. Requires -flto">;
> +def fno_whole_program_vtables : Flag<["-"], "fno-whole-program-vtables">, 
> Group;
> +def fwhole_program_vtables_blacklist_EQ : Joined<["-"], 
> "fwhole-program-vtables-blacklist=">,
> +  Group, Flags<[CC1Option]>,
> +  HelpText<"Path to a blacklist file for whole-program vtable optimization">;
> def fwrapv : Flag<["-"], "fwrapv">, Group, Flags<[CC1Option]>,
>   HelpText<"Treat signed integer overflow as two's complement">;
> def fwritable_strings : Flag<["-"], "fwritable-strings">, Group, 
> Flags<[CC1Option]>,
> 
> Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=261767&r1=261766&r2=261767&view=diff
> ==

Re: r261767 - Add whole-program vtable optimization feature to Clang.

[Steven Wu via cfe-commits]

Thanks a lot! 

Steven


> On Feb 25, 2016, at 7:12 PM, Peter Collingbourne  wrote:
> 
> (I don't understand why this flag needs to exist, but) I've implemented a
> fix in r261960.
> 
> Peter
> 
> On Thu, Feb 25, 2016 at 06:50:52PM -0800, Steven Wu wrote:
>> Hi Peter
>> 
>> I notice after this commit, I can no longer use cmake option 
>> -DCLANG_TOOL_DRIVER_BUILD=OFF to choose not to build and link the clang 
>> driver. When using -DCLANG_TOOL_DRIVER_BUILD=OFF, clang target will not 
>> exist so cmake will error on the line:
>>> +add_dependencies(clang vtables_blacklist)
>> 
>> Is it possible to move this line to tools/driver/CMakeLists.txt?
>> 
>> Thanks
>> 
>> Steven
>> 
>> 
>>> On Feb 24, 2016, at 12:46 PM, Peter Collingbourne via cfe-commits 
>>>  wrote:
>>> 
>>> Author: pcc
>>> Date: Wed Feb 24 14:46:36 2016
>>> New Revision: 261767
>>> 
>>> URL: http://llvm.org/viewvc/llvm-project?rev=261767&view=rev
>>> Log:
>>> Add whole-program vtable optimization feature to Clang.
>>> 
>>> This patch introduces the -fwhole-program-vtables flag, which enables the
>>> whole-program vtable optimization feature (D16795) in Clang.
>>> 
>>> Differential Revision: http://reviews.llvm.org/D16821
>>> 
>>> Added:
>>>   cfe/trunk/runtime/vtables_blacklist.txt
>>>   cfe/trunk/test/CodeGenCXX/bitset-blacklist.cpp
>>> - copied, changed from r261762, 
>>> cfe/trunk/test/CodeGenCXX/cfi-blacklist.cpp
>>>   cfe/trunk/test/CodeGenCXX/bitsets.cpp
>>> - copied, changed from r261762, cfe/trunk/test/CodeGenCXX/cfi-vcall.cpp
>>>   cfe/trunk/test/Driver/Inputs/resource_dir/vtables_blacklist.txt
>>>   cfe/trunk/test/Driver/whole-program-vtables.c
>>> Removed:
>>>   cfe/trunk/test/CodeGenCXX/cfi-blacklist.cpp
>>>   cfe/trunk/test/CodeGenCXX/cfi-vcall.cpp
>>> Modified:
>>>   cfe/trunk/docs/UsersManual.rst
>>>   cfe/trunk/include/clang/Driver/Options.td
>>>   cfe/trunk/include/clang/Frontend/CodeGenOptions.def
>>>   cfe/trunk/include/clang/Frontend/CodeGenOptions.h
>>>   cfe/trunk/lib/CodeGen/CGClass.cpp
>>>   cfe/trunk/lib/CodeGen/CGExprCXX.cpp
>>>   cfe/trunk/lib/CodeGen/CGVTables.cpp
>>>   cfe/trunk/lib/CodeGen/CodeGenFunction.h
>>>   cfe/trunk/lib/CodeGen/CodeGenModule.cpp
>>>   cfe/trunk/lib/CodeGen/CodeGenModule.h
>>>   cfe/trunk/lib/CodeGen/ItaniumCXXABI.cpp
>>>   cfe/trunk/lib/CodeGen/MicrosoftCXXABI.cpp
>>>   cfe/trunk/lib/Driver/Tools.cpp
>>>   cfe/trunk/lib/Frontend/CompilerInvocation.cpp
>>>   cfe/trunk/runtime/CMakeLists.txt
>>> 
>>> Modified: cfe/trunk/docs/UsersManual.rst
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/UsersManual.rst?rev=261767&r1=261766&r2=261767&view=diff
>>> ==
>>> --- cfe/trunk/docs/UsersManual.rst (original)
>>> +++ cfe/trunk/docs/UsersManual.rst Wed Feb 24 14:46:36 2016
>>> @@ -1053,6 +1053,21 @@ are listed below.
>>>   the behavior of sanitizers in the ``cfi`` group to allow checking
>>>   of cross-DSO virtual and indirect calls.
>>> 
>>> +.. option:: -fwhole-program-vtables
>>> +
>>> +   Enable whole-program vtable optimizations, such as single-implementation
>>> +   devirtualization and virtual constant propagation. Requires ``-flto``.
>>> +
>>> +   By default, the compiler will assume that all type hierarchies are
>>> +   closed except those in the ``std`` namespace, the ``stdext`` namespace
>>> +   and classes with the ``__declspec(uuid())`` attribute.
>>> +
>>> +.. option:: -fwhole-program-vtables-blacklist=path
>>> +
>>> +   Allows the user to specify the path to a list of additional classes to
>>> +   blacklist from whole-program vtable optimizations. This list is in the
>>> +   :ref:`CFI blacklist ` format.
>>> +
>>> .. option:: -fno-assume-sane-operator-new
>>> 
>>>   Don't assume that the C++'s new operator is sane.
>>> 
>>> Modified: cfe/trunk/include/clang/Driver/Options.td
>>> URL: 
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=261767&r1=261766&r2=261767&view=diff
>>> ==
>>> --- cfe/trunk/include/clang/Driver/Options.td (original)
>>> +++ cfe/trunk/include/clang/Driver/Options.td Wed Feb 24 14:46:36 2016
>>> @@ -1124,6 +1124,13 @@ def fvisibility_inlines_hidden : Flag<["
>>> def fvisibility_ms_compat : Flag<["-"], "fvisibility-ms-compat">, 
>>> Group,
>>>  HelpText<"Give global types 'default' visibility and global functions and "
>>>   "variables 'hidden' visibility by default">;
>>> +def fwhole_program_vtables : Flag<["-"], "fwhole-program-vtables">, 
>>> Group,
>>> +  Flags<[CC1Option]>,
>>> +  HelpText<"Enables whole-program vtable optimization. Requires -flto">;
>>> +def fno_whole_program_vtables : Flag<["-"], "fno-whole-program-vtables">, 
>>> Group;
>>> +def fwhole_program_vtables_blacklist_EQ : Joined<["-"], 
>>> "fwhole-program-vtables-blacklist=">,
>>> +  Group, Flags<[CC1Option]>,
>>> +  HelpText<"Path to a blacklist file for whole-program vtable 
>>> optimi

Re: [PATCH] D17627: Fix false positives for for-loop-analysis warning

[Steven Wu via cfe-commits]

steven_wu added subscribers: doug.gregor, rjmccall.
steven_wu added reviewers: rjmccall, doug.gregor.
steven_wu added a comment.

Looking through the subscript sounds fine but I would like to know if this is 
indeed the only case that is being ignored because of OpaqueValueExpr and if 
everything is behind OpaqueValueExpr is a bug in building AST.

John, Doug, any opinion on this?


http://reviews.llvm.org/D17627



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

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu added a comment.

Ping.


http://reviews.llvm.org/D17392



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

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu added inline comments.


Comment at: lib/CodeGen/BackendUtil.cpp:769-770
@@ +768,4 @@
+void clang::EmbedBitcode(llvm::Module *M, const CodeGenOptions &CGOpts,
+ llvm::MemoryBufferRef Buf)
+{
+  if (CGOpts.getEmbedBitcode() == CodeGenOptions::Embed_Off)

rsmith wrote:
> Ping.
Sorry, I missed this. Will fix.


Comment at: lib/CodeGen/BackendUtil.cpp:774-806
@@ +773,35 @@
+
+  // Embed the bitcode for the llvm module.
+  std::string Data;
+  ArrayRef ModuleData;
+  Triple T(M->getTargetTriple());
+  if (CGOpts.getEmbedBitcode() != CodeGenOptions::Embed_Marker) {
+if (!isBitcode((const unsigned char *)Buf.getBufferStart(),
+   (const unsigned char *)Buf.getBufferEnd())) {
+  // If the input is LLVM Assembly, bitcode is produced by serializing
+  // the module. Use-lists order need to be perserved in this case.
+  llvm::raw_string_ostream OS(Data);
+  llvm::WriteBitcodeToFile(M, OS, /* ShouldPreserveUseListOrder */ true);
+  ModuleData =
+  ArrayRef((const uint8_t *)OS.str().data(), OS.str().size());
+} else
+  // If the input is LLVM bitcode, write the input byte stream directly.
+  ModuleData = ArrayRef((const uint8_t *)Buf.getBufferStart(),
+ Buf.getBufferSize());
+  }
+  llvm::Constant *ModuleConstant =
+  llvm::ConstantDataArray::get(M->getContext(), ModuleData);
+  // Use Appending linkage so it doesn't get optimized out.
+  llvm::GlobalVariable *GV = new llvm::GlobalVariable(
+  *M, ModuleConstant->getType(), true, llvm::GlobalValue::AppendingLinkage,
+  ModuleConstant);
+  GV->setSection(getSectionNameForBitcode(T));
+  if (llvm::GlobalVariable *Old =
+  M->getGlobalVariable("llvm.embedded.module")) {
+assert(Old->use_empty() && "llvm.embedded.module must have no uses");
+GV->takeName(Old);
+Old->eraseFromParent();
+  } else {
+GV->setName("llvm.embedded.module");
+  }
+

rsmith wrote:
> Can you skip all this if `Buf` is empty (in the common case where the input 
> is not an IR file)?
-fembed-bitcode-marker will actually take this path. -fembed-bitcode-marker 
will not split the compilation into two stages thus the input is not IR and Buf 
is empty but clang needs to generate a marker.


Comment at: lib/Driver/Tools.cpp:3766-3771
@@ -3765,8 +3765,8 @@
 // Add flags implied by -fembed-bitcode.
-CmdArgs.push_back("-fembed-bitcode");
+Args.AddLastArg(CmdArgs, options::OPT_fembed_bitcode_EQ);
 // Disable all llvm IR level optimizations.
 CmdArgs.push_back("-disable-llvm-optzns");
   }
   if (C.getDriver().embedBitcodeMarkerOnly())
-CmdArgs.push_back("-fembed-bitcode-marker");
+CmdArgs.push_back("-fembed-bitcode=marker");
 

rsmith wrote:
> This changes the semantics of `clang -fembed-bitcode -fembed-bitcode-marker` 
> to embed only a marker and no bitcode. Is that OK?
It wasn't clearly defined so I am ok with changing the semantics. It makes even 
more sense that we have different embed options.


Comment at: lib/Driver/Tools.cpp:5724-5728
@@ -5723,4 +5723,7 @@
   // by the frontend.
-  if (C.getDriver().isSaveTempsEnabled() && isa(JA))
+  // When -fembed-bitcode is enabled, optimized bitcode is emitted because it
+  // has slightly different breakdown between stages.
+  if (C.getDriver().isSaveTempsEnabled() &&
+  !C.getDriver().embedBitcodeEnabled() && isa(JA))
 CmdArgs.push_back("-disable-llvm-passes");
 

rsmith wrote:
> Why is this necessary? `-fembed-bitcode` implies `-disable-llvm-optzns` 
> anyway.
-disable-llvm-passes is for -save-temps option. -fembed-bitcode and -save-temps 
disable optzns differently.
-save-temps has following outputs: preprocess source, IR emitted from front 
end, assembly file, object file
-fembed-bitcode has following outputs: optimized IR, object file
They don't share the same intermediate output at all so they need to use 
-disable-llvm-optzns at different stages.



http://reviews.llvm.org/D17392



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

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu updated this revision to Diff 56367.
steven_wu added a comment.

Format update according to review.


http://reviews.llvm.org/D17392

Files:
  include/clang/CodeGen/BackendUtil.h
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/embed-bitcode.c
  test/Frontend/embed-bitcode.ll

Index: test/Frontend/embed-bitcode.ll
===
--- /dev/null
+++ test/Frontend/embed-bitcode.ll
@@ -0,0 +1,59 @@
+; REQUIRES: arm-registered-target
+; REQUIRES: aarch64-registered-target
+; check .ll input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+; RUN: %clang_cc1 -triple aarch64-unknown-linux-gnueabi -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ELF
+
+; check .bc input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-x ir %s -o %t.bc
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %t.bc -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=bitcode -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ONLY-BITCODE
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+
+; run through -fembed-bitcode twice and make sure it doesn't crash
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN: | %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir - -o /dev/null
+
+; check the magic number of bitcode at the beginning of the string
+; CHECK: @llvm.embedded.module
+; CHECK: c"\DE\C0\17\0B
+; CHECK: section "__LLVM,__bitcode"
+; CHECK: @llvm.cmdline
+; CHECK: section "__LLVM,__cmdline"
+
+; CHECK-ELF: @llvm.embedded.module
+; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF: @llvm.cmdline
+; CHECK-ELF: section ".llvmcmd"
+
+; CHECK-ONLY-BITCODE: @llvm.embedded.module
+; CHECK-ONLY-BITCODE: c"\DE\C0\17\0B
+; CHECK-ONLY-BITCODE: section "__LLVM,__bitcode"
+; CHECK-ONLY-BITCODE-NOT: @llvm.cmdline
+; CHECK-ONLY-BITCODE-NOT: section "__LLVM,__cmdline"
+
+; CHECK-MARKER: @llvm.embedded.module
+; CHECK-MARKER: constant [0 x i8] zeroinitializer
+; CHECK-MARKER: section "__LLVM,__bitcode"
+; CHECK-MARKER: @llvm.cmdline
+; CHECK-MARKER: section "__LLVM,__cmdline"
+
+define i32 @f0() {
+  ret i32 0
+}
Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -7,28 +7,35 @@
 // CHECK-CC: -emit-llvm-bc
 // CHECK-CC: -cc1
 // CHECK-CC: -emit-obj
-// CHECK-CC: -fembed-bitcode
+// CHECK-CC: -fembed-bitcode=all
 
+// RUN: %clang %s -c -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-BITCODE
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-llvm-bc
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-obj
+// CHECK-BITCODE: -fembed-bitcode=bitcode
+//
 // RUN: %clang %s -c -save-temps -fembed-bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-SAVE-TEMP
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -E
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -emit-llvm-bc
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -S
-// CHECK-SAVE-TEMP: -fembed-bitcode
+// CHECK-SAVE-TEMP: -fembed-bitcode=all
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
 // CHECK-LTO-NOT: -cc1
-// CHECK-LTO-NOT: -fembed-bitcode
+// CHECK-LTO-NOT: -fembed-bitcode=all
 
 // RUN: %clang -c %s -fembed-bitcode-marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-MARKER
 // CHECK-MARKER: -cc1
 // CHECK-MARKER: -emit-obj
-// CHECK-MARKER: -fembed-bitcode-marker
+// CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -634,6 +634,45 @@
   }
 }
   }
+	// Handle -fembed-bitcode option.
+  if (Arg *A = Args.getLastArg(OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();
+unsigned Model = llvm::StringSwitch(Name)
+.Case("

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu updated this revision to Diff 56371.
steven_wu marked 2 inline comments as done.
steven_wu added a comment.

Add comments to address the feedback fromt the review.


http://reviews.llvm.org/D17392

Files:
  include/clang/CodeGen/BackendUtil.h
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/embed-bitcode.c
  test/Frontend/embed-bitcode.ll

Index: test/Frontend/embed-bitcode.ll
===
--- /dev/null
+++ test/Frontend/embed-bitcode.ll
@@ -0,0 +1,59 @@
+; REQUIRES: arm-registered-target
+; REQUIRES: aarch64-registered-target
+; check .ll input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+; RUN: %clang_cc1 -triple aarch64-unknown-linux-gnueabi -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ELF
+
+; check .bc input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-x ir %s -o %t.bc
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %t.bc -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=bitcode -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ONLY-BITCODE
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+
+; run through -fembed-bitcode twice and make sure it doesn't crash
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN: | %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir - -o /dev/null
+
+; check the magic number of bitcode at the beginning of the string
+; CHECK: @llvm.embedded.module
+; CHECK: c"\DE\C0\17\0B
+; CHECK: section "__LLVM,__bitcode"
+; CHECK: @llvm.cmdline
+; CHECK: section "__LLVM,__cmdline"
+
+; CHECK-ELF: @llvm.embedded.module
+; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF: @llvm.cmdline
+; CHECK-ELF: section ".llvmcmd"
+
+; CHECK-ONLY-BITCODE: @llvm.embedded.module
+; CHECK-ONLY-BITCODE: c"\DE\C0\17\0B
+; CHECK-ONLY-BITCODE: section "__LLVM,__bitcode"
+; CHECK-ONLY-BITCODE-NOT: @llvm.cmdline
+; CHECK-ONLY-BITCODE-NOT: section "__LLVM,__cmdline"
+
+; CHECK-MARKER: @llvm.embedded.module
+; CHECK-MARKER: constant [0 x i8] zeroinitializer
+; CHECK-MARKER: section "__LLVM,__bitcode"
+; CHECK-MARKER: @llvm.cmdline
+; CHECK-MARKER: section "__LLVM,__cmdline"
+
+define i32 @f0() {
+  ret i32 0
+}
Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -7,28 +7,35 @@
 // CHECK-CC: -emit-llvm-bc
 // CHECK-CC: -cc1
 // CHECK-CC: -emit-obj
-// CHECK-CC: -fembed-bitcode
+// CHECK-CC: -fembed-bitcode=all
 
+// RUN: %clang %s -c -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-BITCODE
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-llvm-bc
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-obj
+// CHECK-BITCODE: -fembed-bitcode=bitcode
+//
 // RUN: %clang %s -c -save-temps -fembed-bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-SAVE-TEMP
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -E
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -emit-llvm-bc
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -S
-// CHECK-SAVE-TEMP: -fembed-bitcode
+// CHECK-SAVE-TEMP: -fembed-bitcode=all
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
 // CHECK-LTO-NOT: -cc1
-// CHECK-LTO-NOT: -fembed-bitcode
+// CHECK-LTO-NOT: -fembed-bitcode=all
 
 // RUN: %clang -c %s -fembed-bitcode-marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-MARKER
 // CHECK-MARKER: -cc1
 // CHECK-MARKER: -emit-obj
-// CHECK-MARKER: -fembed-bitcode-marker
+// CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -634,6 +634,45 @@
   }
 }
   }
+	// Handle -fembed-bitcode option.
+  if (Arg *A = Args.getLastArg(OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu added a comment.

Attach a new patch with the comments



Comment at: lib/CodeGen/BackendUtil.cpp:799-831
@@ +798,35 @@
+  // Embed the bitcode for the llvm module.
+  std::string Data;
+  ArrayRef ModuleData;
+  Triple T(M->getTargetTriple());
+  if (CGOpts.getEmbedBitcode() != CodeGenOptions::Embed_Marker) {
+if (!isBitcode((const unsigned char *)Buf.getBufferStart(),
+   (const unsigned char *)Buf.getBufferEnd())) {
+  // If the input is LLVM Assembly, bitcode is produced by serializing
+  // the module. Use-lists order need to be perserved in this case.
+  llvm::raw_string_ostream OS(Data);
+  llvm::WriteBitcodeToFile(M, OS, /* ShouldPreserveUseListOrder */ true);
+  ModuleData =
+  ArrayRef((const uint8_t *)OS.str().data(), OS.str().size());
+} else
+  // If the input is LLVM bitcode, write the input byte stream directly.
+  ModuleData = ArrayRef((const uint8_t *)Buf.getBufferStart(),
+ Buf.getBufferSize());
+  }
+  llvm::Constant *ModuleConstant =
+  llvm::ConstantDataArray::get(M->getContext(), ModuleData);
+  // Use Appending linkage so it doesn't get optimized out.
+  llvm::GlobalVariable *GV = new llvm::GlobalVariable(
+  *M, ModuleConstant->getType(), true, llvm::GlobalValue::AppendingLinkage,
+  ModuleConstant);
+  GV->setSection(getSectionNameForBitcode(T));
+  if (llvm::GlobalVariable *Old =
+  M->getGlobalVariable("llvm.embedded.module")) {
+assert(Old->use_empty() && "llvm.embedded.module must have no uses");
+GV->takeName(Old);
+Old->eraseFromParent();
+  } else {
+GV->setName("llvm.embedded.module");
+  }
+
+  // Return if only bitcode needs to be embedded.

rsmith wrote:
> I see, the "marker" is an empty `llvm.embedded.module` constant. Please add a 
> comment to that effect; that's not obvious.
Sure. 


Comment at: lib/Driver/Tools.cpp:5710-5714
@@ -5709,4 +5709,7 @@
   // by the frontend.
-  if (C.getDriver().isSaveTempsEnabled() && isa(JA))
+  // When -fembed-bitcode is enabled, optimized bitcode is emitted because it
+  // has slightly different breakdown between stages.
+  if (C.getDriver().isSaveTempsEnabled() &&
+  !C.getDriver().embedBitcodeEnabled() && isa(JA))
 CmdArgs.push_back("-disable-llvm-passes");
 

rsmith wrote:
> This means that `-fembed-bitcode -save-temps` will save different 
> intermediate IR than `-save-temps` alone; that seems wrong. I would expect 
> that process to save the unoptimized IR but embed the optimized IR. Getting 
> that right will probably require adding another action to the pipeline for 
> that combination of flags.
That is exactly the case. I will add a FIXME here.


http://reviews.llvm.org/D17392



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

r269202 - Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Wed May 11 11:26:03 2016
New Revision: 269202

URL: http://llvm.org/viewvc/llvm-project?rev=269202&view=rev
Log:
Embed bitcode in object file (clang cc1 part)

Summary:
Teach clang to embed bitcode inside bitcode. When -fembed-bitcode cc1
option is used, clang will embed both the input bitcode and cc1
commandline into the bitcode in special sections before compiling to
the object file.  Using -fembed-bitcode-marker will only introduce a
marker in both sections.

Depends on D17390

Reviewers: rsmith

Subscribers: yaron.keren, vsk, cfe-commits

Differential Revision: http://reviews.llvm.org/D17392

Added:
cfe/trunk/test/Frontend/embed-bitcode.ll
Modified:
cfe/trunk/include/clang/CodeGen/BackendUtil.h
cfe/trunk/include/clang/Driver/Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/include/clang/Frontend/CodeGenOptions.h
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/CodeGen/CodeGenAction.cpp
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/lib/Driver/Tools.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/embed-bitcode.c

Modified: cfe/trunk/include/clang/CodeGen/BackendUtil.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/CodeGen/BackendUtil.h?rev=269202&r1=269201&r2=269202&view=diff
==
--- cfe/trunk/include/clang/CodeGen/BackendUtil.h (original)
+++ cfe/trunk/include/clang/CodeGen/BackendUtil.h Wed May 11 11:26:03 2016
@@ -16,6 +16,7 @@
 
 namespace llvm {
   class Module;
+  class MemoryBufferRef;
 }
 
 namespace clang {
@@ -37,6 +38,9 @@ namespace clang {
  const TargetOptions &TOpts, const LangOptions &LOpts,
  const llvm::DataLayout &TDesc, llvm::Module *M,
  BackendAction Action, raw_pwrite_stream *OS);
+
+  void EmbedBitcode(llvm::Module *M, const CodeGenOptions &CGOpts,
+llvm::MemoryBufferRef Buf);
 }
 
 #endif

Modified: cfe/trunk/include/clang/Driver/Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/Options.td?rev=269202&r1=269201&r2=269202&view=diff
==
--- cfe/trunk/include/clang/Driver/Options.td (original)
+++ cfe/trunk/include/clang/Driver/Options.td Wed May 11 11:26:03 2016
@@ -450,11 +450,14 @@ def fno_autolink : Flag <["-"], "fno-aut
   Flags<[DriverOption, CC1Option]>,
   HelpText<"Disable generation of linker directives for automatic library 
linking">;
 
+def fembed_bitcode_EQ : Joined<["-"], "fembed-bitcode=">,
+Group, Flags<[DriverOption, CC1Option]>, MetaVarName<"">,
+HelpText<"Embed LLVM bitcode (option: off, all, bitcode, marker)">;
 def fembed_bitcode : Flag<["-"], "fembed-bitcode">, Group,
-  Flags<[CC1Option, CC1AsOption]>,
+  Alias, AliasArgs<["all"]>,
   HelpText<"Embed LLVM IR bitcode as data">;
 def fembed_bitcode_marker : Flag<["-"], "fembed-bitcode-marker">,
-  Group, Flags<[CC1Option]>,
+  Alias, AliasArgs<["marker"]>,
   HelpText<"Embed placeholder LLVM IR data as a marker">;
 def fgnu_inline_asm : Flag<["-"], "fgnu-inline-asm">, Group, 
Flags<[DriverOption]>;
 def fno_gnu_inline_asm : Flag<["-"], "fno-gnu-inline-asm">, Group,

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=269202&r1=269201&r2=269202&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Wed May 11 11:26:03 2016
@@ -66,6 +66,8 @@ CODEGENOPT(EmitOpenCLArgMetadata , 1, 0)
 CODEGENOPT(EmulatedTLS   , 1, 0) ///< Set when -femulated-tls is enabled.
 /// \brief FP_CONTRACT mode (on/off/fast).
 ENUM_CODEGENOPT(FPContractMode, FPContractModeKind, 2, FPC_On)
+/// \brief Embed Bitcode mode (off/all/bitcode/marker).
+ENUM_CODEGENOPT(EmbedBitcode, EmbedBitcodeKind, 2, Embed_Off)
 CODEGENOPT(ForbidGuardVariables , 1, 0) ///< Issue errors if C++ guard 
variables
 ///< are required.
 CODEGENOPT(FunctionSections  , 1, 0) ///< Set when -ffunction-sections is 
enabled.

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.h?rev=269202&r1=269201&r2=269202&view=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.h (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.h Wed May 11 11:26:03 2016
@@ -86,6 +86,13 @@ public:
 ProfileIRInstr,// IR level PGO instrumentation in LLVM.
   };
 
+  enum EmbedBitcodeKind {
+Embed_Off,  // No embedded bitcode.
+Embed_All,  // Embed both bitcode and commandline in 

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL269202: Embed bitcode in object file (clang cc1 part) 
(authored by steven_wu).

Changed prior to commit:
  http://reviews.llvm.org/D17392?vs=56371&id=56930#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D17392

Files:
  cfe/trunk/include/clang/CodeGen/BackendUtil.h
  cfe/trunk/include/clang/Driver/Options.td
  cfe/trunk/include/clang/Frontend/CodeGenOptions.def
  cfe/trunk/include/clang/Frontend/CodeGenOptions.h
  cfe/trunk/lib/CodeGen/BackendUtil.cpp
  cfe/trunk/lib/CodeGen/CodeGenAction.cpp
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/lib/Driver/Tools.cpp
  cfe/trunk/lib/Frontend/CompilerInvocation.cpp
  cfe/trunk/test/Driver/embed-bitcode.c
  cfe/trunk/test/Frontend/embed-bitcode.ll

Index: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
===
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp
@@ -634,6 +634,45 @@
   }
 }
   }
+	// Handle -fembed-bitcode option.
+  if (Arg *A = Args.getLastArg(OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();
+unsigned Model = llvm::StringSwitch(Name)
+.Case("off", CodeGenOptions::Embed_Off)
+.Case("all", CodeGenOptions::Embed_All)
+.Case("bitcode", CodeGenOptions::Embed_Bitcode)
+.Case("marker", CodeGenOptions::Embed_Marker)
+.Default(~0U);
+if (Model == ~0U) {
+  Diags.Report(diag::err_drv_invalid_value) << A->getAsString(Args) << Name;
+  Success = false;
+} else
+  Opts.setEmbedBitcode(
+  static_cast(Model));
+  }
+  // FIXME: For backend options that are not yet recorded as function
+  // attributes in the IR, keep track of them so we can embed them in a
+  // separate data section and use them when building the bitcode.
+  if (Opts.getEmbedBitcode() == CodeGenOptions::Embed_All) {
+for (const auto &A : Args) {
+  // Do not encode output and input.
+  if (A->getOption().getID() == options::OPT_o ||
+  A->getOption().getID() == options::OPT_INPUT ||
+  A->getOption().getID() == options::OPT_x ||
+  A->getOption().getID() == options::OPT_fembed_bitcode ||
+  (A->getOption().getGroup().isValid() &&
+   A->getOption().getGroup().getID() == options::OPT_W_Group))
+continue;
+  ArgStringList ASL;
+  A->render(Args, ASL);
+  for (const auto &arg : ASL) {
+StringRef ArgStr(arg);
+Opts.CmdArgs.insert(Opts.CmdArgs.end(), ArgStr.begin(), ArgStr.end());
+// using \00 to seperate each commandline options.
+Opts.CmdArgs.push_back('\0');
+  }
+}
+  }
 
   Opts.InstrumentFunctions = Args.hasArg(OPT_finstrument_functions);
   Opts.InstrumentForProfiling = Args.hasArg(OPT_pg);
Index: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
===
--- cfe/trunk/lib/CodeGen/CodeGenAction.cpp
+++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp
@@ -173,6 +173,8 @@
   return;
   }
 
+  EmbedBitcode(getModule(), CodeGenOpts, llvm::MemoryBufferRef());
+
   EmitBackendOutput(Diags, CodeGenOpts, TargetOpts, LangOpts,
 C.getTargetInfo().getDataLayout(),
 getModule(), Action, AsmOutStream);
@@ -831,9 +833,13 @@
   TheModule->setTargetTriple(TargetOpts.Triple);
 }
 
+EmbedBitcode(TheModule.get(), CI.getCodeGenOpts(),
+ MainFile->getMemBufferRef());
+
 LLVMContext &Ctx = TheModule->getContext();
 Ctx.setInlineAsmDiagnosticHandler(BitcodeInlineAsmDiagHandler,
   &CI.getDiagnostics());
+
 EmitBackendOutput(CI.getDiagnostics(), CI.getCodeGenOpts(), TargetOpts,
   CI.getLangOpts(), CI.getTarget().getDataLayout(),
   TheModule.get(), BA, OS);
Index: cfe/trunk/lib/CodeGen/BackendUtil.cpp
===
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp
@@ -16,9 +16,11 @@
 #include "clang/Frontend/Utils.h"
 #include "llvm/ADT/StringExtras.h"
 #include "llvm/ADT/StringSwitch.h"
+#include "llvm/ADT/Triple.h"
 #include "llvm/Analysis/TargetLibraryInfo.h"
 #include "llvm/Analysis/TargetTransformInfo.h"
 #include "llvm/Bitcode/BitcodeWriterPass.h"
+#include "llvm/Bitcode/ReaderWriter.h"
 #include "llvm/CodeGen/RegAllocRegistry.h"
 #include "llvm/CodeGen/SchedulerRegistry.h"
 #include "llvm/IR/DataLayout.h"
@@ -763,3 +765,91 @@
 }
   }
 }
+
+static const char* getSectionNameForBitcode(const Triple &T) {
+  switch (T.getObjectFormat()) {
+  case Triple::MachO:
+return "__LLVM,__bitcode";
+  case Triple::COFF:
+  case Triple::ELF:
+  case Triple::UnknownObjectFormat:
+return ".llvmbc";
+  }
+}
+
+static const char* getSectionNameForCommandline(const Triple &T) {
+  switch (T.getObjectFormat(

Re: [patch] Don't use appending linkage for embeded bitcode

[Steven Wu via cfe-commits]

Hi Rafael

Thanks for notice this! That would definitely cause duplicated symbol error and 
I should definitely change that. 
Here is some background:
ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but not the 
ones in earlier Xcode. The old ld64 will simply concatenate the bitcode files 
which is not the right thing to do. So there is a symbol generated at the place 
to prevent user to link the bitcode object file with old ld64 because older 
ld64 will fail and report duplicated symbols.
I have a radar tracking to change the linkage type when upstream but I dropped 
the ball on that one. The correct thing to do is to make it internal and add to 
llvm.used. I will come up with a patch.

Steven

> On May 13, 2016, at 9:46 AM, Rafael Espíndola  
> wrote:
> 
> Hi Steven,
> 
> I think there was a mistake when picking this linkage. The appending
> linkage is really just for things that llvm itself special cases. By
> an historical artifact it was codegened just like external.
> 
> The attached patch changes it to external linkage. I tested that the
> produced .o file is bit by bit identical with this change.
> 
> But I have to ask, what is the intended use? I was under the
> impression that the idea was to allow multiple .o files to have their
> IR embedded and have the liker concatenate them.
> 
> Currently, with or without this patch, I expect you to get a
> duplicated symbol error. To implement the above the symbol should be
> internal end the GV added to llvm.used.
> 
> Cheers,
> Rafael
> 

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

Re: r269431 - [OpenCL] Add supported OpenCL extensions to target info.

[Steven Wu via cfe-commits]

Hi Yaxun

You seems missing some override keyword that triggers 
-Winconsistent-missing-override. See:
http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/24442/warnings8Result/new/

Here is a patch to fix them:

diff --git a/lib/Basic/Targets.cpp b/lib/Basic/Targets.cpp
index b1b12e4..20f1e95 100644
--- a/lib/Basic/Targets.cpp
+++ b/lib/Basic/Targets.cpp
@@ -2087,7 +2087,7 @@ public:
 return true;
   }
 
-   void setSupportedOpenCLOpts() {
+   void setSupportedOpenCLOpts() override {
  auto &Opts = getSupportedOpenCLOpts();
  Opts.cl_clang_storage_class_specifiers = 1;
  Opts.cl_khr_gl_sharing = 1;
@@ -2731,7 +2731,7 @@ public:
 return true;
   }
 
-  void setSupportedOpenCLOpts() {
+  void setSupportedOpenCLOpts() override {
 getSupportedOpenCLOpts().setAll();
   }
 };
@@ -7877,7 +7877,7 @@ public:
 return CC_SpirFunction;
   }
 
-  void setSupportedOpenCLOpts() {
+  void setSupportedOpenCLOpts() override {
 // Assume all OpenCL extensions and optional core features are supported
 // for SPIR since it is a generic target.
 getSupportedOpenCLOpts().setAll();

Thanks

Steven

> On May 13, 2016, at 8:44 AM, Yaxun Liu via cfe-commits 
>  wrote:
> 
> Author: yaxunl
> Date: Fri May 13 10:44:37 2016
> New Revision: 269431
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=269431&view=rev
> Log:
> [OpenCL] Add supported OpenCL extensions to target info.
> 
> Add supported OpenCL extensions to target info. It serves as default values 
> to save the users of the burden setting each supported extensions and 
> optional core features in command line.
> 
> Differential Revision: http://reviews.llvm.org/D19484
> 
> Added:
>cfe/trunk/include/clang/Basic/OpenCLOptions.h
>cfe/trunk/test/SemaOpenCL/extensions.cl
> Removed:
>cfe/trunk/test/SemaOpenCL/extension-fp64-cl1.1.cl
>cfe/trunk/test/SemaOpenCL/extension-fp64.cl
>cfe/trunk/test/SemaOpenCL/optional-core-fp64-cl1.2.cl
>cfe/trunk/test/SemaOpenCL/optional-core-fp64-cl2.0.cl
> Modified:
>cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
>cfe/trunk/include/clang/Basic/LangOptions.h
>cfe/trunk/include/clang/Basic/OpenCLExtensions.def
>cfe/trunk/include/clang/Basic/TargetInfo.h
>cfe/trunk/include/clang/Basic/TargetOptions.h
>cfe/trunk/lib/Basic/Targets.cpp
>cfe/trunk/lib/Frontend/InitPreprocessor.cpp
>cfe/trunk/lib/Parse/ParsePragma.cpp
>cfe/trunk/lib/Sema/Sema.cpp
>cfe/trunk/test/CodeGenOpenCL/builtins-r600.cl
>cfe/trunk/test/CodeGenOpenCL/fpmath.cl
>cfe/trunk/test/CodeGenOpenCL/half.cl
>cfe/trunk/test/Lexer/opencl-half-literal.cl
>cfe/trunk/test/Misc/languageOptsOpenCL.cl
>cfe/trunk/test/PCH/opencl-extensions.cl
>cfe/trunk/test/Parser/opencl-astype.cl
>cfe/trunk/test/Parser/opencl-atomics-cl20.cl
>cfe/trunk/test/Parser/opencl-pragma.cl
>cfe/trunk/test/Parser/opencl-storage-class.cl
>cfe/trunk/test/SemaOpenCL/half.cl
>cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl
>cfe/trunk/test/SemaOpenCL/invalid-logical-ops-1.2.cl
> 
> Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td?rev=269431&r1=269430&r2=269431&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
> +++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Fri May 13 10:44:37 
> 2016
> @@ -926,6 +926,10 @@ def warn_pragma_expected_enable_disable
>   "expected 'enable' or 'disable' - ignoring">, InGroup;
> def warn_pragma_unknown_extension : Warning<
>   "unknown OpenCL extension %0 - ignoring">, InGroup;
> +def warn_pragma_unsupported_extension : Warning<
> +  "unsupported OpenCL extension %0 - ignoring">, InGroup;
> +def warn_pragma_extension_is_core : Warning<
> +  "OpenCL extension %0 is core feature or supported optional core feature - 
> ignoring">, InGroup;
> 
> // OpenCL errors.
> def err_opencl_taking_function_address_parser : Error<
> 
> Modified: cfe/trunk/include/clang/Basic/LangOptions.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/LangOptions.h?rev=269431&r1=269430&r2=269431&view=diff
> ==
> --- cfe/trunk/include/clang/Basic/LangOptions.h (original)
> +++ cfe/trunk/include/clang/Basic/LangOptions.h Fri May 13 10:44:37 2016
> @@ -160,18 +160,6 @@ public:
> fp_contract(LangOpts.DefaultFPContract) {}
> };
> 
> -/// \brief OpenCL volatile options
> -class OpenCLOptions {
> -public:
> -#define OPENCLEXT(nm)  unsigned nm : 1;
> -#include "clang/Basic/OpenCLExtensions.def"
> -
> -  OpenCLOptions() {
> -#define OPENCLEXT(nm)   nm = 0;
> -#include "clang/Basic/OpenCLExtensions.def"
> -  }
> -};
> -
> /// \brief Describes the kind of translation unit being processed.
> enum TranslationUnitKind {
>   /// \

Re: r269431 - [OpenCL] Add supported OpenCL extensions to target info.

[Steven Wu via cfe-commits]

It is part of -Wall group and it should be on by default when you building 
clang. That warning is added into clang some time in 2014. Make sure you are 
not using a compiler that is too old.

Steven

> On May 13, 2016, at 10:58 AM, Liu, Yaxun (Sam)  wrote:
> 
> BTW is there a way to turn on this warning with CMake? I could not see this 
> warning in my own build.
> 
> Thanks.
> 
> Sam
> 
> -Original Message-
> From: Liu, Yaxun (Sam) 
> Sent: Friday, May 13, 2016 1:33 PM
> To: 'steve...@apple.com' 
> Cc: cfe-commits@lists.llvm.org
> Subject: RE: r269431 - [OpenCL] Add supported OpenCL extensions to target 
> info.
> 
> Thanks Steven.
> 
> I have reverted my change. I will apply your patch and re-commit.
> 
> Sam
> 
> -Original Message-
> From: steve...@apple.com [mailto:steve...@apple.com]
> Sent: Friday, May 13, 2016 1:27 PM
> To: Liu, Yaxun (Sam) 
> Cc: cfe-commits@lists.llvm.org
> Subject: Re: r269431 - [OpenCL] Add supported OpenCL extensions to target 
> info.
> 
> Hi Yaxun
> 
> You seems missing some override keyword that triggers 
> -Winconsistent-missing-override. See:
> http://lab.llvm.org:8080/green/job/clang-stage1-cmake-RA-incremental_build/24442/warnings8Result/new/
> 
> Here is a patch to fix them:
> 
> diff --git a/lib/Basic/Targets.cpp b/lib/Basic/Targets.cpp index 
> b1b12e4..20f1e95 100644
> --- a/lib/Basic/Targets.cpp
> +++ b/lib/Basic/Targets.cpp
> @@ -2087,7 +2087,7 @@ public:
> return true;
>   }
> 
> -   void setSupportedOpenCLOpts() {
> +   void setSupportedOpenCLOpts() override {
>  auto &Opts = getSupportedOpenCLOpts();
>  Opts.cl_clang_storage_class_specifiers = 1;
>  Opts.cl_khr_gl_sharing = 1;
> @@ -2731,7 +2731,7 @@ public:
> return true;
>   }
> 
> -  void setSupportedOpenCLOpts() {
> +  void setSupportedOpenCLOpts() override {
> getSupportedOpenCLOpts().setAll();
>   }
> };
> @@ -7877,7 +7877,7 @@ public:
> return CC_SpirFunction;
>   }
> 
> -  void setSupportedOpenCLOpts() {
> +  void setSupportedOpenCLOpts() override {
> // Assume all OpenCL extensions and optional core features are supported
> // for SPIR since it is a generic target.
> getSupportedOpenCLOpts().setAll();
> 
> Thanks
> 
> Steven
> 
>> On May 13, 2016, at 8:44 AM, Yaxun Liu via cfe-commits 
>>  wrote:
>> 
>> Author: yaxunl
>> Date: Fri May 13 10:44:37 2016
>> New Revision: 269431
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=269431&view=rev
>> Log:
>> [OpenCL] Add supported OpenCL extensions to target info.
>> 
>> Add supported OpenCL extensions to target info. It serves as default values 
>> to save the users of the burden setting each supported extensions and 
>> optional core features in command line.
>> 
>> Differential Revision: http://reviews.llvm.org/D19484
>> 
>> Added:
>>   cfe/trunk/include/clang/Basic/OpenCLOptions.h
>>   cfe/trunk/test/SemaOpenCL/extensions.cl
>> Removed:
>>   cfe/trunk/test/SemaOpenCL/extension-fp64-cl1.1.cl
>>   cfe/trunk/test/SemaOpenCL/extension-fp64.cl
>>   cfe/trunk/test/SemaOpenCL/optional-core-fp64-cl1.2.cl
>>   cfe/trunk/test/SemaOpenCL/optional-core-fp64-cl2.0.cl
>> Modified:
>>   cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
>>   cfe/trunk/include/clang/Basic/LangOptions.h
>>   cfe/trunk/include/clang/Basic/OpenCLExtensions.def
>>   cfe/trunk/include/clang/Basic/TargetInfo.h
>>   cfe/trunk/include/clang/Basic/TargetOptions.h
>>   cfe/trunk/lib/Basic/Targets.cpp
>>   cfe/trunk/lib/Frontend/InitPreprocessor.cpp
>>   cfe/trunk/lib/Parse/ParsePragma.cpp
>>   cfe/trunk/lib/Sema/Sema.cpp
>>   cfe/trunk/test/CodeGenOpenCL/builtins-r600.cl
>>   cfe/trunk/test/CodeGenOpenCL/fpmath.cl
>>   cfe/trunk/test/CodeGenOpenCL/half.cl
>>   cfe/trunk/test/Lexer/opencl-half-literal.cl
>>   cfe/trunk/test/Misc/languageOptsOpenCL.cl
>>   cfe/trunk/test/PCH/opencl-extensions.cl
>>   cfe/trunk/test/Parser/opencl-astype.cl
>>   cfe/trunk/test/Parser/opencl-atomics-cl20.cl
>>   cfe/trunk/test/Parser/opencl-pragma.cl
>>   cfe/trunk/test/Parser/opencl-storage-class.cl
>>   cfe/trunk/test/SemaOpenCL/half.cl
>>   cfe/trunk/test/SemaOpenCL/invalid-kernel-parameters.cl
>>   cfe/trunk/test/SemaOpenCL/invalid-logical-ops-1.2.cl
>> 
>> Modified: cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/Diag
>> nosticParseKinds.td?rev=269431&r1=269430&r2=269431&view=diff
>> ==
>> 
>> --- cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td (original)
>> +++ cfe/trunk/include/clang/Basic/DiagnosticParseKinds.td Fri May 13
>> +++ 10:44:37 2016
>> @@ -926,6 +926,10 @@ def warn_pragma_expected_enable_disable
>>  "expected 'enable' or 'disable' - ignoring">, 
>> InGroup; def warn_pragma_unknown_extension : Warning<
>>  "unknown OpenCL extension %0 - ignoring">, InGroup;
>> +def warn_pragma_unsupported_extension : Warning<
>> +  "unsupported OpenCL extension %0 - ignoring">, 
>> +InGroup; def 

Re: [patch] Don't use appending linkage for embeded bitcode

[Steven Wu via cfe-commits]

Attach a patch using private linkage type and adding to llvm.used. I have to 
recreate llvm.used when embedding bitcode. I don't really like it but I don't 
have better solutions.
Few other options:
1. Not allowing re-embedded bitcode will simplify the code a bit but not a lot.
2. Create a new "llvm.*.used" variable in llvm.metadata section.
3. Teach optimizer do not optimize away llvm.* variables.   



0001-Fix-embed-bitcode-linkage-type.patch
Description: Binary data


Steven

> On May 13, 2016, at 10:10 AM, Rafael Espíndola  
> wrote:
> 
> On 13 May 2016 at 13:02, Steven Wu  wrote:
>> Hi Rafael
>> 
>> Thanks for notice this! That would definitely cause duplicated symbol error 
>> and I should definitely change that.
>> Here is some background:
>> ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but not 
>> the ones in earlier Xcode. The old ld64 will simply concatenate the bitcode 
>> files which is not the right thing to do. So there is a symbol generated at 
>> the place to prevent user to link the bitcode object file with old ld64 
>> because older ld64 will fail and report duplicated symbols.
>> I have a radar tracking to change the linkage type when upstream but I 
>> dropped the ball on that one. The correct thing to do is to make it internal 
>> and add to llvm.used. I will come up with a patch.
> 
> Thank you so much!
> 
> Cheers,
> Rafael

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

Re: [patch] Don't use appending linkage for embeded bitcode

[Steven Wu via cfe-commits]

> On May 13, 2016, at 3:56 PM, Duncan P. N. Exon Smith  
> wrote:
> 
> Is this something that you need the linker to treat as "used", or just 
> something you don't want the compiler to drop?  If the latter, 
> @llvm.compiler.used seems more appropriate.

Bitcode is actually not really used by the compiler during compilation and 
shouldn't really used by any part of the code. llvm.compiler.used then.

New patch.



0001-Fix-embed-bitcode-linkage-type.patch
Description: Binary data


Steven

> 
>> On 2016-May-13, at 14:01, Steven Wu  wrote:
>> 
>> Attach a patch using private linkage type and adding to llvm.used. I have to 
>> recreate llvm.used when embedding bitcode. I don't really like it but I 
>> don't have better solutions.
>> Few other options:
>> 1. Not allowing re-embedded bitcode will simplify the code a bit but not a 
>> lot.
>> 2. Create a new "llvm.*.used" variable in llvm.metadata section.
>> 3. Teach optimizer do not optimize away llvm.* variables.   
>> 
>> <0001-Fix-embed-bitcode-linkage-type.patch>
>> 
>> Steven
>> 
>>> On May 13, 2016, at 10:10 AM, Rafael Espíndola  
>>> wrote:
>>> 
>>> On 13 May 2016 at 13:02, Steven Wu  wrote:
 Hi Rafael
 
 Thanks for notice this! That would definitely cause duplicated symbol 
 error and I should definitely change that.
 Here is some background:
 ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but 
 not the ones in earlier Xcode. The old ld64 will simply concatenate the 
 bitcode files which is not the right thing to do. So there is a symbol 
 generated at the place to prevent user to link the bitcode object file 
 with old ld64 because older ld64 will fail and report duplicated symbols.
 I have a radar tracking to change the linkage type when upstream but I 
 dropped the ball on that one. The correct thing to do is to make it 
 internal and add to llvm.used. I will come up with a patch.
>>> 
>>> Thank you so much!
>>> 
>>> Cheers,
>>> Rafael
>> 
> 

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

Re: [patch] Don't use appending linkage for embeded bitcode

[Steven Wu via cfe-commits]

> On May 16, 2016, at 6:52 AM, Rafael Espíndola  
> wrote:
> 
> +  auto Used = collectUsedGlobalVariables(*M, UsedGlobals, true);
> 
> Please use an explicit type instead of auto.

Sure.

> 
> You deleted the assert

Are you referring to the assertion that llvm.embedded.module has no uses. I 
added it back to check it has exactly one use.

Attach the final patch with testcase.

Steven



0001-Change-embed-bitcode-linkage-type.patch
Description: Binary data


> 
> I think this is fine otherwise.
> 
> Cheers,
> Rafael
> 
> 
> 
> 
> 
> On 13 May 2016 at 20:00, Steven Wu  wrote:
>> 
>>> On May 13, 2016, at 3:56 PM, Duncan P. N. Exon Smith  
>>> wrote:
>>> 
>>> Is this something that you need the linker to treat as "used", or just 
>>> something you don't want the compiler to drop?  If the latter, 
>>> @llvm.compiler.used seems more appropriate.
>> 
>> Bitcode is actually not really used by the compiler during compilation and 
>> shouldn't really used by any part of the code. llvm.compiler.used then.
>> 
>> New patch.
>> 
>> 
>> 
>> 
>> Steven
>> 
>>> 
 On 2016-May-13, at 14:01, Steven Wu  wrote:
 
 Attach a patch using private linkage type and adding to llvm.used. I have 
 to recreate llvm.used when embedding bitcode. I don't really like it but I 
 don't have better solutions.
 Few other options:
 1. Not allowing re-embedded bitcode will simplify the code a bit but not a 
 lot.
 2. Create a new "llvm.*.used" variable in llvm.metadata section.
 3. Teach optimizer do not optimize away llvm.* variables.
 
 <0001-Fix-embed-bitcode-linkage-type.patch>
 
 Steven
 
> On May 13, 2016, at 10:10 AM, Rafael Espíndola 
>  wrote:
> 
> On 13 May 2016 at 13:02, Steven Wu  wrote:
>> Hi Rafael
>> 
>> Thanks for notice this! That would definitely cause duplicated symbol 
>> error and I should definitely change that.
>> Here is some background:
>> ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly but 
>> not the ones in earlier Xcode. The old ld64 will simply concatenate the 
>> bitcode files which is not the right thing to do. So there is a symbol 
>> generated at the place to prevent user to link the bitcode object file 
>> with old ld64 because older ld64 will fail and report duplicated symbols.
>> I have a radar tracking to change the linkage type when upstream but I 
>> dropped the ball on that one. The correct thing to do is to make it 
>> internal and add to llvm.used. I will come up with a patch.
> 
> Thank you so much!
> 
> Cheers,
> Rafael
 
>>> 
>> 
>> 

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

r269679 - Change embed-bitcode linkage type

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Mon May 16 13:54:58 2016
New Revision: 269679

URL: http://llvm.org/viewvc/llvm-project?rev=269679&view=rev
Log:
Change embed-bitcode linkage type

Embedded bitcode should have private linkage instead of appending or external.
Otherwise, it will cause link failure due to duplicated symbols.
Also add llvm.embedded.module and llvm.cmdline to llvm.compiler.used so they
don't get optimized out.

rdar://problem/21555860

Modified:
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/test/Frontend/embed-bitcode.ll

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=269679&r1=269678&r2=269679&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon May 16 13:54:58 2016
@@ -797,6 +797,20 @@ void clang::EmbedBitcode(llvm::Module *M
   if (CGOpts.getEmbedBitcode() == CodeGenOptions::Embed_Off)
 return;
 
+  // Save llvm.compiler.used and remote it.
+  SmallVector UsedArray;
+  SmallSet UsedGlobals;
+  Type *UsedElementType = Type::getInt8Ty(M->getContext())->getPointerTo(0);
+  GlobalVariable *Used = collectUsedGlobalVariables(*M, UsedGlobals, true);
+  for (auto *GV : UsedGlobals) {
+if (GV->getName() != "llvm.embedded.module" &&
+GV->getName() != "llvm.cmdline")
+  UsedArray.push_back(
+  ConstantExpr::getPointerBitCastOrAddrSpaceCast(GV, UsedElementType));
+  }
+  if (Used)
+Used->eraseFromParent();
+
   // Embed the bitcode for the llvm module.
   std::string Data;
   ArrayRef ModuleData;
@@ -820,38 +834,53 @@ void clang::EmbedBitcode(llvm::Module *M
   }
   llvm::Constant *ModuleConstant =
   llvm::ConstantDataArray::get(M->getContext(), ModuleData);
-  // Use Appending linkage so it doesn't get optimized out.
   llvm::GlobalVariable *GV = new llvm::GlobalVariable(
-  *M, ModuleConstant->getType(), true, llvm::GlobalValue::AppendingLinkage,
+  *M, ModuleConstant->getType(), true, llvm::GlobalValue::PrivateLinkage,
   ModuleConstant);
   GV->setSection(getSectionNameForBitcode(T));
+  UsedArray.push_back(
+  ConstantExpr::getPointerBitCastOrAddrSpaceCast(GV, UsedElementType));
   if (llvm::GlobalVariable *Old =
-  M->getGlobalVariable("llvm.embedded.module")) {
-assert(Old->use_empty() && "llvm.embedded.module must have no uses");
+  M->getGlobalVariable("llvm.embedded.module", true)) {
+assert(Old->hasOneUse() &&
+   "llvm.embedded.module can only be used once in llvm.compiler.used");
 GV->takeName(Old);
 Old->eraseFromParent();
   } else {
 GV->setName("llvm.embedded.module");
   }
 
-  // Return if only bitcode needs to be embedded.
-  if (CGOpts.getEmbedBitcode() == CodeGenOptions::Embed_Bitcode)
+  // Skip if only bitcode needs to be embedded.
+  if (CGOpts.getEmbedBitcode() != CodeGenOptions::Embed_Bitcode) {
+// Embed command-line options.
+ArrayRef CmdData((uint8_t*)CGOpts.CmdArgs.data(),
+  CGOpts.CmdArgs.size());
+llvm::Constant *CmdConstant =
+  llvm::ConstantDataArray::get(M->getContext(), CmdData);
+GV = new llvm::GlobalVariable(*M, CmdConstant->getType(), true,
+  llvm::GlobalValue::PrivateLinkage,
+  CmdConstant);
+GV->setSection(getSectionNameForCommandline(T));
+UsedArray.push_back(
+ConstantExpr::getPointerBitCastOrAddrSpaceCast(GV, UsedElementType));
+if (llvm::GlobalVariable *Old =
+M->getGlobalVariable("llvm.cmdline", true)) {
+  assert(Old->hasOneUse() &&
+ "llvm.cmdline can only be used once in llvm.compiler.used");
+  GV->takeName(Old);
+  Old->eraseFromParent();
+} else {
+  GV->setName("llvm.cmdline");
+}
+  }
+
+  if (UsedArray.empty())
 return;
 
-  // Embed command-line options.
-  ArrayRef CmdData((uint8_t*)CGOpts.CmdArgs.data(),
-CGOpts.CmdArgs.size());
-  llvm::Constant *CmdConstant =
-llvm::ConstantDataArray::get(M->getContext(), CmdData);
-  GV = new llvm::GlobalVariable(*M, CmdConstant->getType(), true,
-llvm::GlobalValue::AppendingLinkage,
-CmdConstant);
-  GV->setSection(getSectionNameForCommandline(T));
-  if (llvm::GlobalVariable *Old = M->getGlobalVariable("llvm.cmdline")) {
-assert(Old->use_empty() && "llvm.cmdline must have no uses");
-GV->takeName(Old);
-Old->eraseFromParent();
-  } else {
-GV->setName("llvm.cmdline");
-  }
+  // Recreate llvm.compiler.used.
+  ArrayType *ATy = ArrayType::get(UsedElementType, UsedArray.size());
+  auto *NewUsed = new GlobalVariable(
+  *M, ATy, false, llvm::GlobalValue::AppendingLinkage,
+  llvm::ConstantArray::get(ATy, UsedArray), "llvm.compiler.used");
+  NewUsed->setSection("llvm.metadata");
 }

Modified: c

Re: [patch] Don't use appending linkage for embeded bitcode

[Steven Wu via cfe-commits]

Thanks! Committed in r269679

Steven

> On May 16, 2016, at 11:54 AM, Rafael Espíndola  
> wrote:
> 
> LGTM
> 
> On 16 May 2016 at 14:03, Steven Wu  wrote:
>> 
>>> On May 16, 2016, at 6:52 AM, Rafael Espíndola  
>>> wrote:
>>> 
>>> +  auto Used = collectUsedGlobalVariables(*M, UsedGlobals, true);
>>> 
>>> Please use an explicit type instead of auto.
>> 
>> Sure.
>> 
>>> 
>>> You deleted the assert
>> 
>> Are you referring to the assertion that llvm.embedded.module has no uses. I 
>> added it back to check it has exactly one use.
>> 
>> Attach the final patch with testcase.
>> 
>> Steven
>> 
>> 
>> 
>> 
>>> 
>>> I think this is fine otherwise.
>>> 
>>> Cheers,
>>> Rafael
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On 13 May 2016 at 20:00, Steven Wu  wrote:
 
> On May 13, 2016, at 3:56 PM, Duncan P. N. Exon Smith 
>  wrote:
> 
> Is this something that you need the linker to treat as "used", or just 
> something you don't want the compiler to drop?  If the latter, 
> @llvm.compiler.used seems more appropriate.
 
 Bitcode is actually not really used by the compiler during compilation and 
 shouldn't really used by any part of the code. llvm.compiler.used then.
 
 New patch.
 
 
 
 
 Steven
 
> 
>> On 2016-May-13, at 14:01, Steven Wu  wrote:
>> 
>> Attach a patch using private linkage type and adding to llvm.used. I 
>> have to recreate llvm.used when embedding bitcode. I don't really like 
>> it but I don't have better solutions.
>> Few other options:
>> 1. Not allowing re-embedded bitcode will simplify the code a bit but not 
>> a lot.
>> 2. Create a new "llvm.*.used" variable in llvm.metadata section.
>> 3. Teach optimizer do not optimize away llvm.* variables.
>> 
>> <0001-Fix-embed-bitcode-linkage-type.patch>
>> 
>> Steven
>> 
>>> On May 13, 2016, at 10:10 AM, Rafael Espíndola 
>>>  wrote:
>>> 
>>> On 13 May 2016 at 13:02, Steven Wu  wrote:
 Hi Rafael
 
 Thanks for notice this! That would definitely cause duplicated symbol 
 error and I should definitely change that.
 Here is some background:
 ld64 in Xcode 7+ knows how to handle the embedded bitcode correctly 
 but not the ones in earlier Xcode. The old ld64 will simply 
 concatenate the bitcode files which is not the right thing to do. So 
 there is a symbol generated at the place to prevent user to link the 
 bitcode object file with old ld64 because older ld64 will fail and 
 report duplicated symbols.
 I have a radar tracking to change the linkage type when upstream but I 
 dropped the ball on that one. The correct thing to do is to make it 
 internal and add to llvm.used. I will come up with a patch.
>>> 
>>> Thank you so much!
>>> 
>>> Cheers,
>>> Rafael
>> 
> 
 
 
>> 
>> 

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

[PATCH] D20374: [Driver] Fix the case when use -fembed-bitcode and -flto= together

[Steven Wu via cfe-commits]

steven_wu created this revision.
steven_wu added a reviewer: joker.eph.
steven_wu added a subscriber: cfe-commits.
Herald added a subscriber: joker.eph.

-fembed-bitcode was only checking for old style LTO flag (-flto) but not
considering the new -flto= style option. That makes clang output bitcode
embedded in bitcode object when using -flto= and -fembed-bitcode= together.
Now clang should output normal bitcode file when using LTO and ignores
-fembed-bitcode option.

http://reviews.llvm.org/D20374

Files:
  lib/Driver/Driver.cpp
  test/Driver/embed-bitcode.c

Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -27,6 +27,8 @@
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=full -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=thin -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: 
'-fembed-bitcode'
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -504,9 +504,11 @@
 .Default(SaveTempsCwd);
   }
 
+  setLTOMode(Args);
+
   // Ignore -fembed-bitcode options with LTO
   // since the output will be bitcode anyway.
-  if (!Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false)) {
+  if (getLTOMode() == LTOK_None) {
 if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
   StringRef Name = A->getValue();
   unsigned Model = llvm::StringSwitch(Name)
@@ -526,8 +528,6 @@
 Args.ClaimAllArgs(options::OPT_fembed_bitcode_EQ);
   }
 
-  setLTOMode(Args);
-
   std::unique_ptr UArgs =
   llvm::make_unique(std::move(Args));
 


Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -27,6 +27,8 @@
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=full -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=thin -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
Index: lib/Driver/Driver.cpp
===
--- lib/Driver/Driver.cpp
+++ lib/Driver/Driver.cpp
@@ -504,9 +504,11 @@
 .Default(SaveTempsCwd);
   }
 
+  setLTOMode(Args);
+
   // Ignore -fembed-bitcode options with LTO
   // since the output will be bitcode anyway.
-  if (!Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false)) {
+  if (getLTOMode() == LTOK_None) {
 if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
   StringRef Name = A->getValue();
   unsigned Model = llvm::StringSwitch(Name)
@@ -526,8 +528,6 @@
 Args.ClaimAllArgs(options::OPT_fembed_bitcode_EQ);
   }
 
-  setLTOMode(Args);
-
   std::unique_ptr UArgs =
   llvm::make_unique(std::move(Args));
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r269961 - [Driver] Fix the case when use -fembed-bitcode and -flto= together

[Steven Wu via cfe-commits]

Author: steven_wu
Date: Wed May 18 12:04:52 2016
New Revision: 269961

URL: http://llvm.org/viewvc/llvm-project?rev=269961&view=rev
Log:
[Driver] Fix the case when use -fembed-bitcode and -flto= together

Summary:
-fembed-bitcode was only checking for old style LTO flag (-flto) but not
considering the new -flto= style option. That makes clang output bitcode
embedded in bitcode object when using -flto= and -fembed-bitcode= together.
Now clang should output normal bitcode file when using LTO and ignores
-fembed-bitcode option.

Reviewers: joker.eph

Subscribers: joker.eph, cfe-commits

Differential Revision: http://reviews.llvm.org/D20374

Modified:
cfe/trunk/lib/Driver/Driver.cpp
cfe/trunk/test/Driver/embed-bitcode.c

Modified: cfe/trunk/lib/Driver/Driver.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Driver.cpp?rev=269961&r1=269960&r2=269961&view=diff
==
--- cfe/trunk/lib/Driver/Driver.cpp (original)
+++ cfe/trunk/lib/Driver/Driver.cpp Wed May 18 12:04:52 2016
@@ -504,9 +504,11 @@ Compilation *Driver::BuildCompilation(Ar
 .Default(SaveTempsCwd);
   }
 
+  setLTOMode(Args);
+
   // Ignore -fembed-bitcode options with LTO
   // since the output will be bitcode anyway.
-  if (!Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false)) {
+  if (getLTOMode() == LTOK_None) {
 if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
   StringRef Name = A->getValue();
   unsigned Model = llvm::StringSwitch(Name)
@@ -526,8 +528,6 @@ Compilation *Driver::BuildCompilation(Ar
 Args.ClaimAllArgs(options::OPT_fembed_bitcode_EQ);
   }
 
-  setLTOMode(Args);
-
   std::unique_ptr UArgs =
   llvm::make_unique(std::move(Args));
 

Modified: cfe/trunk/test/Driver/embed-bitcode.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/embed-bitcode.c?rev=269961&r1=269960&r2=269961&view=diff
==
--- cfe/trunk/test/Driver/embed-bitcode.c (original)
+++ cfe/trunk/test/Driver/embed-bitcode.c Wed May 18 12:04:52 2016
@@ -27,6 +27,8 @@
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=full -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=thin -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: 
'-fembed-bitcode'


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

Re: [PATCH] D20374: [Driver] Fix the case when use -fembed-bitcode and -flto= together

[Steven Wu via cfe-commits]

This revision was automatically updated to reflect the committed changes.
Closed by commit rL269961: [Driver] Fix the case when use -fembed-bitcode and 
-flto= together (authored by steven_wu).

Changed prior to commit:
  http://reviews.llvm.org/D20374?vs=57645&id=57646#toc

Repository:
  rL LLVM

http://reviews.llvm.org/D20374

Files:
  cfe/trunk/lib/Driver/Driver.cpp
  cfe/trunk/test/Driver/embed-bitcode.c

Index: cfe/trunk/test/Driver/embed-bitcode.c
===
--- cfe/trunk/test/Driver/embed-bitcode.c
+++ cfe/trunk/test/Driver/embed-bitcode.c
@@ -27,6 +27,8 @@
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=full -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=thin -fembed-bitcode 2>&1 -### | FileCheck %s 
-check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: 
'-fembed-bitcode'
Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -504,9 +504,11 @@
 .Default(SaveTempsCwd);
   }
 
+  setLTOMode(Args);
+
   // Ignore -fembed-bitcode options with LTO
   // since the output will be bitcode anyway.
-  if (!Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false)) {
+  if (getLTOMode() == LTOK_None) {
 if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
   StringRef Name = A->getValue();
   unsigned Model = llvm::StringSwitch(Name)
@@ -526,8 +528,6 @@
 Args.ClaimAllArgs(options::OPT_fembed_bitcode_EQ);
   }
 
-  setLTOMode(Args);
-
   std::unique_ptr UArgs =
   llvm::make_unique(std::move(Args));
 


Index: cfe/trunk/test/Driver/embed-bitcode.c
===
--- cfe/trunk/test/Driver/embed-bitcode.c
+++ cfe/trunk/test/Driver/embed-bitcode.c
@@ -27,6 +27,8 @@
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=full -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
+// RUN: %clang -c %s -flto=thin -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
Index: cfe/trunk/lib/Driver/Driver.cpp
===
--- cfe/trunk/lib/Driver/Driver.cpp
+++ cfe/trunk/lib/Driver/Driver.cpp
@@ -504,9 +504,11 @@
 .Default(SaveTempsCwd);
   }
 
+  setLTOMode(Args);
+
   // Ignore -fembed-bitcode options with LTO
   // since the output will be bitcode anyway.
-  if (!Args.hasFlag(options::OPT_flto, options::OPT_fno_lto, false)) {
+  if (getLTOMode() == LTOK_None) {
 if (Arg *A = Args.getLastArg(options::OPT_fembed_bitcode_EQ)) {
   StringRef Name = A->getValue();
   unsigned Model = llvm::StringSwitch(Name)
@@ -526,8 +528,6 @@
 Args.ClaimAllArgs(options::OPT_fembed_bitcode_EQ);
   }
 
-  setLTOMode(Args);
-
   std::unique_ptr UArgs =
   llvm::make_unique(std::move(Args));
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: r270047 - [Clang][AVX512][intrinsics] continue completing missing set intrinsics

[Steven Wu via cfe-commits]

Hi Michael

This commit seems break darwin LTO bootstrap bot. 
http://lab.llvm.org:8080/green/job/clang-stage2-configure-Rlto_check/7916/
Also breaks the Asan Ubsan bot:
http://lab.llvm.org:8080/green/job/clang-stage2-cmake-RgSan_check/1742/

Can you talk a look? I don't why the failure doesn't show up in other 
configuration. Let me know if you need any help.

Thanks

Steven


> On May 19, 2016, at 5:07 AM, Michael Zuckerman via cfe-commits 
>  wrote:
> 
> Author: mzuckerm
> Date: Thu May 19 07:07:49 2016
> New Revision: 270047
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=270047&view=rev
> Log:
> [Clang][AVX512][intrinsics] continue completing missing set intrinsics
> 
> Differential Revision: http://reviews.llvm.org/D20160
> 
> 
> Modified:
>cfe/trunk/lib/Headers/avx512fintrin.h
>cfe/trunk/test/CodeGen/avx512f-builtins.c
> 
> Modified: cfe/trunk/lib/Headers/avx512fintrin.h
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Headers/avx512fintrin.h?rev=270047&r1=270046&r2=270047&view=diff
> ==
> --- cfe/trunk/lib/Headers/avx512fintrin.h (original)
> +++ cfe/trunk/lib/Headers/avx512fintrin.h Thu May 19 07:07:49 2016
> @@ -8983,6 +8983,21 @@ _mm512_mask_set1_epi64 (__m512i __O, __m
>  __M);
> }
> 
> +static __inline __m512i __DEFAULT_FN_ATTRS
> +_mm512_set_epi32 (int __A, int __B, int __C, int __D,
> + int __E, int __F, int __G, int __H,
> + int __I, int __J, int __K, int __L,
> + int __M, int __N, int __O, int __P)
> +{
> +  return __extension__ (__m512i)(__v16si)
> +  { __P, __O, __N, __M, __L, __K, __J, __I,
> +__H, __G, __F, __E, __D, __C, __B, __A };
> +}
> +
> +#define _mm512_setr_epi32(e0,e1,e2,e3,e4,e5,e6,e7,   \
> +   e8,e9,e10,e11,e12,e13,e14,e15)  \
> +  _mm512_set_epi32(e15,e14,e13,e12,e11,e10,e9,e8,e7,e6,e5,e4,e3,e2,e1,e0)
> +  
> static __inline__ __m512i __DEFAULT_FN_ATTRS
> _mm512_set_epi64 (long long __A, long long __B, long long __C,
>  long long __D, long long __E, long long __F,
> @@ -8992,6 +9007,9 @@ _mm512_set_epi64 (long long __A, long lo
>   { __H, __G, __F, __E, __D, __C, __B, __A };
> }
> 
> +#define _mm512_setr_epi64(e0,e1,e2,e3,e4,e5,e6,e7)   \
> +  _mm512_set_epi64(e7,e6,e5,e4,e3,e2,e1,e0)
> +
> static __inline__ __m512d __DEFAULT_FN_ATTRS
> _mm512_set_pd (double __A, double __B, double __C, double __D,
> double __E, double __F, double __G, double __H)
> @@ -9000,6 +9018,9 @@ _mm512_set_pd (double __A, double __B, d
>   { __H, __G, __F, __E, __D, __C, __B, __A };
> }
> 
> +#define _mm512_setr_pd(e0,e1,e2,e3,e4,e5,e6,e7)  \
> +  _mm512_set_pd(e7,e6,e5,e4,e3,e2,e1,e0)
> +
> static __inline__ __m512 __DEFAULT_FN_ATTRS
> _mm512_set_ps (float __A, float __B, float __C, float __D,
> float __E, float __F, float __G, float __H,
> @@ -9011,6 +9032,9 @@ _mm512_set_ps (float __A, float __B, flo
> __H, __G, __F, __E, __D, __C, __B, __A };
> }
> 
> +#define 
> _mm512_setr_ps(e0,e1,e2,e3,e4,e5,e6,e7,e8,e9,e10,e11,e12,e13,e14,e15) \
> +  _mm512_set_ps(e15,e14,e13,e12,e11,e10,e9,e8,e7,e6,e5,e4,e3,e2,e1,e0)
> +
> #undef __DEFAULT_FN_ATTRS
> 
> #endif // __AVX512FINTRIN_H
> 
> Modified: cfe/trunk/test/CodeGen/avx512f-builtins.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/avx512f-builtins.c?rev=270047&r1=270046&r2=270047&view=diff
> ==
> --- cfe/trunk/test/CodeGen/avx512f-builtins.c (original)
> +++ cfe/trunk/test/CodeGen/avx512f-builtins.c Thu May 19 07:07:49 2016
> @@ -6521,6 +6521,74 @@ __m512i test_mm512_mask_set1_epi32 (__m5
>   return _mm512_mask_set1_epi32 ( __O, __M, __A);
> }
> 
> +__m512i test_mm512_set_epi32 (int __A, int __B, int __C, int __D,
> +   int __E, int __F, int __G, int __H,
> +   int __I, int __J, int __K, int __L,
> +   int __M, int __N, int __O, int __P)
> +{
> + //CHECK-LABLE: @test_mm512_set_epi32
> + //CHECK: insertelement{{.*}}i32 0
> +//CHECK: insertelement{{.*}}i32 1
> +//CHECK: insertelement{{.*}}i32 2
> +//CHECK: insertelement{{.*}}i32 3
> +//CHECK: insertelement{{.*}}i32 4
> +//CHECK: insertelement{{.*}}i32 5
> +//CHECK: insertelement{{.*}}i32 6
> +//CHECK: insertelement{{.*}}i32 7
> +//CHECK: insertelement{{.*}}i32 8
> +//CHECK: insertelement{{.*}}i32 9
> +//CHECK: insertelement{{.*}}i32 10
> +//CHECK: insertelement{{.*}}i32 11
> +//CHECK: insertelement{{.*}}i32 12
> +//CHECK: insertelement{{.*}}i32 13
> +//CHECK: insertelement{{.*}}i32 14
> +//CHECK: insertelement{{.*}}i32 15
> + return _mm512_set_epi32( __A, __B, __C, __D,__E, __F, __G, __H,
> +  __I, __J, __K, __L,__M, __N, __O, __P);
> +}
> +
> +__m512i test_mm512_setr_epi32 (int __A, int __B, int __C, int __D,
> +   int __E, int __F, int __G, int __H,
> +   int __I, int __J, int __K, int _

Re: r265038 - Diagnostics: remove dodgy handler for bitcode inlineasm diagnostics.

[Steven Wu via cfe-commits]

The original handler is not there to workaround a crash. It is to avoid 
generate a crash report (report_fatal_error) when the input bitcode contains 
invalid assembly. 
It is an oversight to exit(0) even when it failed. Can you make the diagnostic 
handler fatal for Errors kinds instead of removing it? or set the 
gen_crash_diag to false in report_fatal_error in the AsmPrinterInlineAsm.cpp.

Steven

> On Mar 31, 2016, at 12:19 PM, Tim Northover via cfe-commits 
>  wrote:
> 
> Author: tnorthover
> Date: Thu Mar 31 14:19:24 2016
> New Revision: 265038
> 
> URL: http://llvm.org/viewvc/llvm-project?rev=265038&view=rev
> Log:
> Diagnostics: remove dodgy handler for bitcode inlineasm diagnostics.
> 
> Whatever crash it was there to present appears to have been fixed in the
> backend now, and it had the nasty side-effect of causing clang to exit(0) and
> leave a .o containing goodness knows what even when an error hit.
> 
> Modified:
>cfe/trunk/lib/CodeGen/CodeGenAction.cpp
>cfe/trunk/test/CodeGen/asm-errors.c
> 
> Modified: cfe/trunk/lib/CodeGen/CodeGenAction.cpp
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenAction.cpp?rev=265038&r1=265037&r2=265038&view=diff
> ==
> --- cfe/trunk/lib/CodeGen/CodeGenAction.cpp (original)
> +++ cfe/trunk/lib/CodeGen/CodeGenAction.cpp Thu Mar 31 14:19:24 2016
> @@ -756,12 +756,6 @@ CodeGenAction::CreateASTConsumer(Compile
>   return std::move(Result);
> }
> 
> -static void BitcodeInlineAsmDiagHandler(const llvm::SMDiagnostic &SM,
> - void *Context,
> - unsigned LocCookie) {
> -  SM.print(nullptr, llvm::errs());
> -}
> -
> void CodeGenAction::ExecuteAction() {
>   // If this is an IR file, we have to treat it specially.
>   if (getCurrentFileKind() == IK_LLVM_IR) {
> @@ -810,8 +804,6 @@ void CodeGenAction::ExecuteAction() {
>   TheModule->setTargetTriple(TargetOpts.Triple);
> }
> 
> -LLVMContext &Ctx = TheModule->getContext();
> -Ctx.setInlineAsmDiagnosticHandler(BitcodeInlineAsmDiagHandler);
> EmitBackendOutput(CI.getDiagnostics(), CI.getCodeGenOpts(), TargetOpts,
>   CI.getLangOpts(), CI.getTarget().getDataLayout(),
>   TheModule.get(), BA, OS);
> 
> Modified: cfe/trunk/test/CodeGen/asm-errors.c
> URL: 
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/asm-errors.c?rev=265038&r1=265037&r2=265038&view=diff
> ==
> --- cfe/trunk/test/CodeGen/asm-errors.c (original)
> +++ cfe/trunk/test/CodeGen/asm-errors.c Thu Mar 31 14:19:24 2016
> @@ -3,7 +3,7 @@
> // RUN: not %clang_cc1 -triple i386-apple-darwin10 -emit-obj %s -o /dev/null 
> > %t 2>&1
> // RUN: FileCheck %s < %t
> // RUN: %clang_cc1 -triple i386-apple-darwin10 -emit-llvm-bc %s -o %t.bc
> -// RUN: %clang_cc1 -triple i386-apple-darwin10 -emit-obj %t.bc -o /dev/null 
> 2>&1 | \
> +// RUN: not %clang_cc1 -triple i386-apple-darwin10 -emit-obj %t.bc -o 
> /dev/null 2>&1 | \
> // RUN:   FileCheck --check-prefix=CRASH-REPORT %s
> // CRASH-REPORT: :
> // CRASH-REPORT: error: invalid instruction mnemonic 'abc'
> 
> 
> ___
> 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: r265038 - Diagnostics: remove dodgy handler for bitcode inlineasm diagnostics.

[Steven Wu via cfe-commits]

> On Apr 1, 2016, at 12:04 PM, Tim Northover  wrote:
> 
> 
>> On 31 Mar 2016, at 16:51, Steven Wu  wrote:
>> 
>> The original handler is not there to workaround a crash. It is to avoid 
>> generate a crash report (report_fatal_error) when the input bitcode contains 
>> invalid assembly. 
> 
> Ah, I see now. That test needs tweaking too, since it doesn't actually 
> produce the crash report even after my change (probably because it's a 
> %clang_cc1 test).
Probably need assertion build or some cmake setting to actually show the crash 
log. 
> 
> How does the patch attached here look? I originally tried reusing the real 
> InlineAsmDiagHandler but that was disastrous (it needs a real AST I think, 
> which obviously doesn't exist when compiling a .bc file).
Generally good. How about only report error when SM.getKind() == DK_Error?

Steven

> 
> Cheers.
> 
> Tim.
> 
> 

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

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu updated this revision to Diff 52435.
steven_wu added a comment.

Address the feedback from Richard:
Break -fembed-bitcode option into multiple -fembed-bitcode= options.
-fembed-bitcode=all will embed both bitcode and commandline and 
-fembed-bitcode=bitcode will embed only the bitcode in the object file.


http://reviews.llvm.org/D17392

Files:
  include/clang/CodeGen/BackendUtil.h
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/embed-bitcode.c
  test/Frontend/embed-bitcode.ll

Index: test/Frontend/embed-bitcode.ll
===
--- /dev/null
+++ test/Frontend/embed-bitcode.ll
@@ -0,0 +1,57 @@
+; check .ll input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+; RUN: %clang_cc1 -triple aarch64-unknown-linux-gnueabi -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ELF
+
+; check .bc input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-x ir %s -o %t.bc
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %t.bc -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=bitcode -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ONLY-BITCODE
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+
+; run through -fembed-bitcode twice and make sure it doesn't crash
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN: | %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir - -o /dev/null
+
+; check the magic number of bitcode at the beginning of the string
+; CHECK: @llvm.embedded.module
+; CHECK: c"\DE\C0\17\0B
+; CHECK: section "__LLVM,__bitcode"
+; CHECK: @llvm.cmdline
+; CHECK: section "__LLVM,__cmdline"
+
+; CHECK-ELF: @llvm.embedded.module
+; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF: @llvm.cmdline
+; CHECK-ELF: section ".llvmcmd"
+
+; CHECK-ONLY-BITCODE: @llvm.embedded.module
+; CHECK-ONLY-BITCODE: c"\DE\C0\17\0B
+; CHECK-ONLY-BITCODE: section "__LLVM,__bitcode"
+; CHECK-ONLY-BITCODE-NOT: @llvm.cmdline
+; CHECK-ONLY-BITCODE-NOT: section "__LLVM,__cmdline"
+
+; CHECK-MARKER: @llvm.embedded.module
+; CHECK-MARKER: constant [0 x i8] zeroinitializer
+; CHECK-MARKER: section "__LLVM,__bitcode"
+; CHECK-MARKER: @llvm.cmdline
+; CHECK-MARKER: section "__LLVM,__cmdline"
+
+define i32 @f0() {
+  ret i32 0
+}
Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -7,28 +7,35 @@
 // CHECK-CC: -emit-llvm-bc
 // CHECK-CC: -cc1
 // CHECK-CC: -emit-obj
-// CHECK-CC: -fembed-bitcode
+// CHECK-CC: -fembed-bitcode=all
 
+// RUN: %clang %s -c -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-BITCODE
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-llvm-bc
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-obj
+// CHECK-BITCODE: -fembed-bitcode=bitcode
+//
 // RUN: %clang %s -c -save-temps -fembed-bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-SAVE-TEMP
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -E
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -emit-llvm-bc
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -S
-// CHECK-SAVE-TEMP: -fembed-bitcode
+// CHECK-SAVE-TEMP: -fembed-bitcode=all
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
 // CHECK-LTO-NOT: -cc1
-// CHECK-LTO-NOT: -fembed-bitcode
+// CHECK-LTO-NOT: -fembed-bitcode=all
 
 // RUN: %clang -c %s -fembed-bitcode-marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-MARKER
 // CHECK-MARKER: -cc1
 // CHECK-MARKER: -emit-obj
-// CHECK-MARKER: -fembed-bitcode-marker
+// CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -646,6 +646,47 @@
   }
 }
   }
+	// Handle -fembed-bitcode option.
+  if (Arg *A = Args.getLa

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu added a comment.

ping. The currently -fembed-bitcode option is only half working. I don't want 
to leave it like that too long.


http://reviews.llvm.org/D17392



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

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu updated this revision to Diff 54559.
steven_wu added a comment.

Ping.

Rebase the patch over trunk and tweak the testcase.


http://reviews.llvm.org/D17392

Files:
  include/clang/CodeGen/BackendUtil.h
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/embed-bitcode.c
  test/Frontend/embed-bitcode.ll

Index: test/Frontend/embed-bitcode.ll
===
--- /dev/null
+++ test/Frontend/embed-bitcode.ll
@@ -0,0 +1,59 @@
+; REQUIRES: arm-registered-target
+; REQUIRES: aarch64-registered-target
+; check .ll input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+; RUN: %clang_cc1 -triple aarch64-unknown-linux-gnueabi -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ELF
+
+; check .bc input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-x ir %s -o %t.bc
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %t.bc -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=bitcode -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ONLY-BITCODE
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+
+; run through -fembed-bitcode twice and make sure it doesn't crash
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN: | %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir - -o /dev/null
+
+; check the magic number of bitcode at the beginning of the string
+; CHECK: @llvm.embedded.module
+; CHECK: c"\DE\C0\17\0B
+; CHECK: section "__LLVM,__bitcode"
+; CHECK: @llvm.cmdline
+; CHECK: section "__LLVM,__cmdline"
+
+; CHECK-ELF: @llvm.embedded.module
+; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF: @llvm.cmdline
+; CHECK-ELF: section ".llvmcmd"
+
+; CHECK-ONLY-BITCODE: @llvm.embedded.module
+; CHECK-ONLY-BITCODE: c"\DE\C0\17\0B
+; CHECK-ONLY-BITCODE: section "__LLVM,__bitcode"
+; CHECK-ONLY-BITCODE-NOT: @llvm.cmdline
+; CHECK-ONLY-BITCODE-NOT: section "__LLVM,__cmdline"
+
+; CHECK-MARKER: @llvm.embedded.module
+; CHECK-MARKER: constant [0 x i8] zeroinitializer
+; CHECK-MARKER: section "__LLVM,__bitcode"
+; CHECK-MARKER: @llvm.cmdline
+; CHECK-MARKER: section "__LLVM,__cmdline"
+
+define i32 @f0() {
+  ret i32 0
+}
Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -7,28 +7,35 @@
 // CHECK-CC: -emit-llvm-bc
 // CHECK-CC: -cc1
 // CHECK-CC: -emit-obj
-// CHECK-CC: -fembed-bitcode
+// CHECK-CC: -fembed-bitcode=all
 
+// RUN: %clang %s -c -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-BITCODE
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-llvm-bc
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-obj
+// CHECK-BITCODE: -fembed-bitcode=bitcode
+//
 // RUN: %clang %s -c -save-temps -fembed-bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-SAVE-TEMP
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -E
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -emit-llvm-bc
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -S
-// CHECK-SAVE-TEMP: -fembed-bitcode
+// CHECK-SAVE-TEMP: -fembed-bitcode=all
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
 // CHECK-LTO-NOT: -cc1
-// CHECK-LTO-NOT: -fembed-bitcode
+// CHECK-LTO-NOT: -fembed-bitcode=all
 
 // RUN: %clang -c %s -fembed-bitcode-marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-MARKER
 // CHECK-MARKER: -cc1
 // CHECK-MARKER: -emit-obj
-// CHECK-MARKER: -fembed-bitcode-marker
+// CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -635,6 +635,47 @@
   }
 }
   }
+	// Handle -fembed-bitcode option.
+  if (Arg *A = Args.getLastArg(OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();
+unsigned Model = llvm::StringSwitc

Re: [PATCH] D17392: Embed bitcode in object file (clang cc1 part)

[Steven Wu via cfe-commits]

steven_wu updated this revision to Diff 54597.
steven_wu added a comment.

Thanks Vedant!

Address all of your review in this update.


http://reviews.llvm.org/D17392

Files:
  include/clang/CodeGen/BackendUtil.h
  include/clang/Driver/Options.td
  include/clang/Frontend/CodeGenOptions.def
  include/clang/Frontend/CodeGenOptions.h
  lib/CodeGen/BackendUtil.cpp
  lib/CodeGen/CodeGenAction.cpp
  lib/Driver/Driver.cpp
  lib/Driver/Tools.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Driver/embed-bitcode.c
  test/Frontend/embed-bitcode.ll

Index: test/Frontend/embed-bitcode.ll
===
--- /dev/null
+++ test/Frontend/embed-bitcode.ll
@@ -0,0 +1,59 @@
+; REQUIRES: arm-registered-target
+; REQUIRES: aarch64-registered-target
+; check .ll input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+; RUN: %clang_cc1 -triple aarch64-unknown-linux-gnueabi -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ELF
+
+; check .bc input
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-x ir %s -o %t.bc
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir %t.bc -o - \
+; RUN:| FileCheck %s
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=bitcode -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-ONLY-BITCODE
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=marker -x ir %t.bc -o - \
+; RUN:| FileCheck %s -check-prefix=CHECK-MARKER
+
+; run through -fembed-bitcode twice and make sure it doesn't crash
+; RUN: %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm-bc \
+; RUN:-fembed-bitcode=all -x ir %s -o - \
+; RUN: | %clang_cc1 -triple thumbv7-apple-ios8.0.0 -emit-llvm \
+; RUN:-fembed-bitcode=all -x ir - -o /dev/null
+
+; check the magic number of bitcode at the beginning of the string
+; CHECK: @llvm.embedded.module
+; CHECK: c"\DE\C0\17\0B
+; CHECK: section "__LLVM,__bitcode"
+; CHECK: @llvm.cmdline
+; CHECK: section "__LLVM,__cmdline"
+
+; CHECK-ELF: @llvm.embedded.module
+; CHECK-ELF: section ".llvmbc"
+; CHECK-ELF: @llvm.cmdline
+; CHECK-ELF: section ".llvmcmd"
+
+; CHECK-ONLY-BITCODE: @llvm.embedded.module
+; CHECK-ONLY-BITCODE: c"\DE\C0\17\0B
+; CHECK-ONLY-BITCODE: section "__LLVM,__bitcode"
+; CHECK-ONLY-BITCODE-NOT: @llvm.cmdline
+; CHECK-ONLY-BITCODE-NOT: section "__LLVM,__cmdline"
+
+; CHECK-MARKER: @llvm.embedded.module
+; CHECK-MARKER: constant [0 x i8] zeroinitializer
+; CHECK-MARKER: section "__LLVM,__bitcode"
+; CHECK-MARKER: @llvm.cmdline
+; CHECK-MARKER: section "__LLVM,__cmdline"
+
+define i32 @f0() {
+  ret i32 0
+}
Index: test/Driver/embed-bitcode.c
===
--- test/Driver/embed-bitcode.c
+++ test/Driver/embed-bitcode.c
@@ -7,28 +7,35 @@
 // CHECK-CC: -emit-llvm-bc
 // CHECK-CC: -cc1
 // CHECK-CC: -emit-obj
-// CHECK-CC: -fembed-bitcode
+// CHECK-CC: -fembed-bitcode=all
 
+// RUN: %clang %s -c -fembed-bitcode=bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-BITCODE
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-llvm-bc
+// CHECK-BITCODE: -cc1
+// CHECK-BITCODE: -emit-obj
+// CHECK-BITCODE: -fembed-bitcode=bitcode
+//
 // RUN: %clang %s -c -save-temps -fembed-bitcode -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-SAVE-TEMP
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -E
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -emit-llvm-bc
 // CHECK-SAVE-TEMP: -cc1
 // CHECK-SAVE-TEMP: -S
-// CHECK-SAVE-TEMP: -fembed-bitcode
+// CHECK-SAVE-TEMP: -fembed-bitcode=all
 // CHECK-SAVE-TEMP: -cc1as
 
 // RUN: %clang -c %s -flto -fembed-bitcode 2>&1 -### | FileCheck %s -check-prefix=CHECK-LTO
 // CHECK-LTO: -cc1
 // CHECK-LTO: -emit-llvm-bc
 // CHECK-LTO-NOT: warning: argument unused during compilation: '-fembed-bitcode'
 // CHECK-LTO-NOT: -cc1
-// CHECK-LTO-NOT: -fembed-bitcode
+// CHECK-LTO-NOT: -fembed-bitcode=all
 
 // RUN: %clang -c %s -fembed-bitcode-marker -fintegrated-as 2>&1 -### | FileCheck %s -check-prefix=CHECK-MARKER
 // CHECK-MARKER: -cc1
 // CHECK-MARKER: -emit-obj
-// CHECK-MARKER: -fembed-bitcode-marker
+// CHECK-MARKER: -fembed-bitcode=marker
 // CHECK-MARKER-NOT: -cc1
 
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -635,6 +635,45 @@
   }
 }
   }
+	// Handle -fembed-bitcode option.
+  if (Arg *A = Args.getLastArg(OPT_fembed_bitcode_EQ)) {
+StringRef Name = A->getValue();
+unsigned Model = llvm::StringSwitc