[PATCH] D32733: [clang-format] Convert AlignEscapedNewlinesLeft to an enum, adding DontAlign

[Jacob Bandes-Storch via Phabricator via cfe-commits]

jtbandes added inline comments.



Comment at: lib/Format/WhitespaceManager.cpp:523
+  if (C.NewlinesBefore > 0 && C.ContinuesPPDirective)
+C.EscapedNewlineColumn = C.PreviousEndOfTokenColumn + 2;
+return;

djasper wrote:
> I think we should not duplicate this loop. Two alternatives:
> 1. Move this into the other loop. As long as you reset StartOfMacro in each 
> iteration, it should do the right thing.
> 2. Make this work if we just return here. In theory, the "\" should not need 
> any special-casing with this style.
> 
> I'd prefer #2.
I first tried returning here, but the backslashes were butting up against the 
content, as in `int x = foo;\`. I can look around to see if that's fixable.


https://reviews.llvm.org/D32733



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

[PATCH] D32733: [clang-format] Convert AlignEscapedNewlinesLeft to an enum, adding DontAlign

[Daniel Jasper via Phabricator via cfe-commits]

djasper added inline comments.



Comment at: lib/Format/WhitespaceManager.cpp:523
+  if (C.NewlinesBefore > 0 && C.ContinuesPPDirective)
+C.EscapedNewlineColumn = C.PreviousEndOfTokenColumn + 2;
+return;

I think we should not duplicate this loop. Two alternatives:
1. Move this into the other loop. As long as you reset StartOfMacro in each 
iteration, it should do the right thing.
2. Make this work if we just return here. In theory, the "\" should not need 
any special-casing with this style.

I'd prefer #2.


https://reviews.llvm.org/D32733



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

[PATCH] D32646: Fix a bug that -Wmissing-braces fires on system headers

[Yuka Takahashi via Phabricator via cfe-commits]

yamaguchi added inline comments.



Comment at: lib/Sema/SemaInit.cpp:875
 
   if (!VerifyOnly) {
 StructuredSubobjectInitList->setType(T);

ruiu wrote:
> Is it intentional that you run the new code only when !VerifyOnly?
I think VerifyOnly is used to check if it is formal verification mode or not, 
and if VerifyOnly == 1, it is supposed to emit no diagnostics. So I think it is 
OK that this code is here, because this part of is code emits -Wmissing-braces 
if braces are not appropriate.


https://reviews.llvm.org/D32646



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

[PATCH] D32646: Fix a bug that -Wmissing-braces fires on system headers

[Yuka Takahashi via Phabricator via cfe-commits]

yamaguchi updated this revision to Diff 97398.
yamaguchi marked 2 inline comments as done.
yamaguchi added a comment.

Fixed spaces and changed SpellingLoc from two lines to one line.


https://reviews.llvm.org/D32646

Files:
  lib/Sema/SemaInit.cpp
  test/Sema/warn-missing-braces.c


Index: test/Sema/warn-missing-braces.c
===
--- test/Sema/warn-missing-braces.c
+++ test/Sema/warn-missing-braces.c
@@ -1,3 +1,21 @@
 // RUN: %clang_cc1 -fsyntax-only -Wmissing-braces -verify %s
 
+#ifdef BE_THE_HEADER
+#pragma clang system_header
+
+typedef struct _foo {
+unsigned char Data[2];
+} foo;
+
+#define BAR { 0 }
+
+#else
+
+#define BE_THE_HEADER
+#include __FILE__
+
 int a[2][2] = { 0, 1, 2, 3 }; // expected-warning{{suggest braces}} 
expected-warning{{suggest braces}}
+
+foo g = BAR; // should not show warnings
+
+#endif
Index: lib/Sema/SemaInit.cpp
===
--- lib/Sema/SemaInit.cpp
+++ lib/Sema/SemaInit.cpp
@@ -885,8 +885,15 @@
   StructuredSubobjectInitList->setRBraceLoc(EndLoc);
 }
 
-// Complain about missing braces.
-if (T->isArrayType() || T->isRecordType()) {
+// Complain about missing braces when rhs is not a macro from system 
header.
+// getSpellingLoc() isn't cheap, so only call it if the warning is enabled.
+if ((T->isArrayType() || T->isRecordType()) &&
+!SemaRef.Diags.isIgnored(diag::warn_missing_braces,
+ StructuredSubobjectInitList->getLocStart())) {
+  SourceLocation SpellingLoc = 
SemaRef.getSourceManager().getSpellingLoc(StructuredSubobjectInitList->getLocStart());
+  if (SpellingLoc.isValid() &&
+  SemaRef.getSourceManager().isInSystemHeader(SpellingLoc))
+return;
   SemaRef.Diag(StructuredSubobjectInitList->getLocStart(),
diag::warn_missing_braces)
   << StructuredSubobjectInitList->getSourceRange()


Index: test/Sema/warn-missing-braces.c
===
--- test/Sema/warn-missing-braces.c
+++ test/Sema/warn-missing-braces.c
@@ -1,3 +1,21 @@
 // RUN: %clang_cc1 -fsyntax-only -Wmissing-braces -verify %s
 
+#ifdef BE_THE_HEADER
+#pragma clang system_header
+
+typedef struct _foo {
+unsigned char Data[2];
+} foo;
+
+#define BAR { 0 }
+
+#else
+
+#define BE_THE_HEADER
+#include __FILE__
+
 int a[2][2] = { 0, 1, 2, 3 }; // expected-warning{{suggest braces}} expected-warning{{suggest braces}}
+
+foo g = BAR; // should not show warnings
+
+#endif
Index: lib/Sema/SemaInit.cpp
===
--- lib/Sema/SemaInit.cpp
+++ lib/Sema/SemaInit.cpp
@@ -885,8 +885,15 @@
   StructuredSubobjectInitList->setRBraceLoc(EndLoc);
 }
 
-// Complain about missing braces.
-if (T->isArrayType() || T->isRecordType()) {
+// Complain about missing braces when rhs is not a macro from system header.
+// getSpellingLoc() isn't cheap, so only call it if the warning is enabled.
+if ((T->isArrayType() || T->isRecordType()) &&
+!SemaRef.Diags.isIgnored(diag::warn_missing_braces,
+ StructuredSubobjectInitList->getLocStart())) {
+  SourceLocation SpellingLoc = SemaRef.getSourceManager().getSpellingLoc(StructuredSubobjectInitList->getLocStart());
+  if (SpellingLoc.isValid() &&
+  SemaRef.getSourceManager().isInSystemHeader(SpellingLoc))
+return;
   SemaRef.Diag(StructuredSubobjectInitList->getLocStart(),
diag::warn_missing_braces)
   << StructuredSubobjectInitList->getSourceRange()
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32733: [clang-format] Convert AlignEscapedNewlinesLeft to an enum, adding DontAlign

[Jacob Bandes-Storch via Phabricator via cfe-commits]

jtbandes created this revision.
Herald added a subscriber: klimek.

This converts the clang-format option `AlignEscapedNewlinesLeft` from a boolean 
to an enum, named `AlignEscapedNewlines`, with options `Left` (prev. `true`), 
`Right` (prev. `false`), and a new option `DontAlign`.

When set to `DontAlign`, the backslashes are placed just after the last token 
in each line:

  #define EXAMPLE \
  do { \
  int x = a; \
  int b; \
  int dd; \
  } while (0)


https://reviews.llvm.org/D32733

Files:
  include/clang/Format/Format.h
  lib/Format/Format.cpp
  lib/Format/WhitespaceManager.cpp
  unittests/Format/FormatTest.cpp
  unittests/Format/FormatTestSelective.cpp

Index: unittests/Format/FormatTestSelective.cpp
===
--- unittests/Format/FormatTestSelective.cpp
+++ unittests/Format/FormatTestSelective.cpp
@@ -325,7 +325,7 @@
 }
 
 TEST_F(FormatTestSelective, AlwaysFormatsEntireMacroDefinitions) {
-  Style.AlignEscapedNewlinesLeft = true;
+  Style.AlignEscapedNewlines = FormatStyle::ENAS_Left;
   EXPECT_EQ("int  i;\n"
 "#define A \\\n"
 "  int i;  \\\n"
@@ -467,7 +467,7 @@
 TEST_F(FormatTestSelective, UnderstandsTabs) {
   Style.IndentWidth = 8;
   Style.UseTab = FormatStyle::UT_Always;
-  Style.AlignEscapedNewlinesLeft = true;
+  Style.AlignEscapedNewlines = FormatStyle::ENAS_Left;
   EXPECT_EQ("void f() {\n"
 "\tf();\n"
 "\tg();\n"
Index: unittests/Format/FormatTest.cpp
===
--- unittests/Format/FormatTest.cpp
+++ unittests/Format/FormatTest.cpp
@@ -342,7 +342,7 @@
   verifyFormat("if (a)\n  if (b) {\nf();\n  }\ng();");
 
   FormatStyle AllowsMergedIf = getLLVMStyle();
-  AllowsMergedIf.AlignEscapedNewlinesLeft = true;
+  AllowsMergedIf.AlignEscapedNewlines = FormatStyle::ENAS_Left;
   AllowsMergedIf.AllowShortIfStatementsOnASingleLine = true;
   verifyFormat("if (a)\n"
"  // comment\n"
@@ -6423,7 +6423,7 @@
   EXPECT_EQ("\"some text other\";", format("\"some text other\";", Style));
 
   FormatStyle AlignLeft = getLLVMStyleWithColumns(12);
-  AlignLeft.AlignEscapedNewlinesLeft = true;
+  AlignLeft.AlignEscapedNewlines = FormatStyle::ENAS_Left;
   EXPECT_EQ("#define A \\\n"
 "  \"some \" \\\n"
 "  \"text \" \\\n"
@@ -6824,7 +6824,7 @@
   FormatStyle Tab = getLLVMStyleWithColumns(42);
   Tab.IndentWidth = 8;
   Tab.UseTab = FormatStyle::UT_Always;
-  Tab.AlignEscapedNewlinesLeft = true;
+  Tab.AlignEscapedNewlines = FormatStyle::ENAS_Left;
 
   EXPECT_EQ("if ( && // q\n"
 "bb)\t\t// w\n"
@@ -7605,14 +7605,21 @@
"int oneTwoThree = 123;\n"
"int oneTwo = 12;",
Alignment));
-  Alignment.AlignEscapedNewlinesLeft = true;
+  Alignment.AlignEscapedNewlines = FormatStyle::ENAS_DontAlign;
+  verifyFormat("#define A \\\n"
+   "  int    = 12; \\\n"
+   "  int b  = 23; \\\n"
+   "  int ccc= 234; \\\n"
+   "  int dd = 2345;",
+   Alignment);
+  Alignment.AlignEscapedNewlines = FormatStyle::ENAS_Left;
   verifyFormat("#define A   \\\n"
"  int    = 12;  \\\n"
"  int b  = 23;  \\\n"
"  int ccc= 234; \\\n"
"  int dd = 2345;",
Alignment);
-  Alignment.AlignEscapedNewlinesLeft = false;
+  Alignment.AlignEscapedNewlines = FormatStyle::ENAS_Right;
   verifyFormat("#define A  "
"\\\n"
"  int    = 12; "
@@ -7879,14 +7886,21 @@
"}",
Alignment));
   Alignment.AlignConsecutiveAssignments = false;
-  Alignment.AlignEscapedNewlinesLeft = true;
+  Alignment.AlignEscapedNewlines = FormatStyle::ENAS_DontAlign;
+  verifyFormat("#define A \\\n"
+   "  int    = 12; \\\n"
+   "  float b = 23; \\\n"
+   "  const int ccc = 234; \\\n"
+   "  unsigned  dd = 2345;",
+   Alignment);
+  Alignment.AlignEscapedNewlines = FormatStyle::ENAS_Left;
   verifyFormat("#define A  \\\n"
"  int    = 12; \\\n"
"  float b = 23;\\\n"
"  const int ccc = 234; \\\n"
"  unsigned  dd = 2345;",
Alignment);
-  Alignment.AlignEscapedNewlinesLeft = false;
+  Alignment.AlignEscapedNewlines = FormatStyle::ENAS_Right;
   Alignment.ColumnLimit = 30;
   verifyFormat("#define A\\\n"
"  int    = 12;   \\\n"
@@ -8671,7 +8685,6 @@
 TEST_F(FormatTest, ParsesConfigurationBools) {
   FormatStyle Style = {};
   St

[PATCH] D32210: [Sema][ObjC] Add support for attribute "noescape"

[John McCall via Phabricator via cfe-commits]

rjmccall added a comment.

I agree with Aaron, it would be nice if this had some immediate effect.  One 
obvious suggestion: take advantage of it in code generation.  LLVM already has 
a parameter attribute called "nocapture" which conveys exactly the right 
semantics for noescape pointers and references.  For block pointers, nocapture 
is a weaker statement than noescape, because noescape also restricts block 
copies, but it's still correct.




Comment at: include/clang/Basic/AttrDocs.td:120
+compiler that the block cannot escape: that is, no reference to the block
+derived from the parameter value will survive after the function returns.
+

The implementation in Sema allows normal pointers and references in addition to 
block pointers.  Assuming that's intended, it should be documented.

You should also document that *copies* of the block are also not allowed to 
escape.  That's special behavior for block pointers.



Comment at: include/clang/Basic/AttrDocs.td:144
+knowledge. Users are responsible for making sure parameters annotated with
+``noescape`` do not actuallly escape.
+

Typo.



Comment at: lib/Sema/SemaDeclAttr.cpp:1522-1523
+  QualType T = cast(D)->getType();
+  if (!T->isAnyPointerType() && !T->isBlockPointerType() &&
+  !T->isReferenceType() && !T->isArrayType() && !T->isMemberPointerType()) 
{
+S.Diag(Attr.getLoc(), diag::warn_attribute_noescape_non_pointer) << T;

aaron.ballman wrote:
> I don't think the type checking here is correct, at least according to the 
> documentation. For instance, you don't appear to care whether the parameter 
> is an array of block pointers vs an array of ints. Similar for the other 
> composite types.
A member pointer is not really like the others.  Member pointers are always 
global constants, like function pointers; there's no meaningful scope for them 
to escape from.

Also, parameters never have array type.  The type of a ParmVarDecl will be the 
decayed type, i.e. a pointer.

Also, you should check for an invalid decl and avoid checking the type, because 
that's likely a cascading failure.  Test case: make a parameter with a bad type 
specifier.


https://reviews.llvm.org/D32210



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

Re: r301846 - Fix initial diagnostic state setup for an explicit module with no diagnostic pragmas.

[NAKAMURA Takumi via cfe-commits]

It didn't pass for targeting *-win32, since MicrosoftRecordLayoutBuilder
doesn't have ability of -Wpadded.
Tweaked in r301898.

I guess other diag would be available here but I have no good idea.

On Tue, May 2, 2017 at 7:23 AM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Mon May  1 17:10:47 2017
> New Revision: 301846
>
> URL: http://llvm.org/viewvc/llvm-project?rev=301846&view=rev
> Log:
> Fix initial diagnostic state setup for an explicit module with no
> diagnostic pragmas.
>
> If a file has no diagnostic pragmas, we build its diagnostic state lazily,
> but
> in this case we never set up the root state to be the diagnostic state in
> which
> the module was originally built, so the diagnostic flags for files in the
> module with no diagnostic pragmas were incorrectly based on the user of the
> module rather than the diagnostic state when the module was built.
>
> Added:
> cfe/trunk/test/Modules/diag-flags.cpp
> Modified:
> cfe/trunk/lib/Serialization/ASTReader.cpp
> cfe/trunk/test/Modules/Inputs/module.map
>
> Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=301846&r1=301845&r2=301846&view=diff
>
> ==
> --- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
> +++ cfe/trunk/lib/Serialization/ASTReader.cpp Mon May  1 17:10:47 2017
> @@ -3765,6 +3765,13 @@ ASTReader::ASTReadResult ASTReader::Read
>SourceMgr.getLoadedSLocEntryByID(Index);
>  }
>
> +// Map the original source file ID into the ID space of the current
> +// compilation.
> +if (F.OriginalSourceFileID.isValid()) {
> +  F.OriginalSourceFileID = FileID::get(
> +  F.SLocEntryBaseID + F.OriginalSourceFileID.getOpaqueValue() -
> 1);
> +}
> +
>  // Preload all the pending interesting identifiers by marking them
> out of
>  // date.
>  for (auto Offset : F.PreloadIdentifierOffsets) {
> @@ -3873,10 +3880,6 @@ ASTReader::ASTReadResult ASTReader::Read
>
>ModuleFile &PrimaryModule = ModuleMgr.getPrimaryModule();
>if (PrimaryModule.OriginalSourceFileID.isValid()) {
> -PrimaryModule.OriginalSourceFileID
> -  = FileID::get(PrimaryModule.SLocEntryBaseID
> -+ PrimaryModule.OriginalSourceFileID.getOpaqueValue()
> - 1);
> -
>  // If this AST file is a precompiled preamble, then set the
>  // preamble file ID of the source manager to the file source file
>  // from which the preamble was built.
> @@ -5575,6 +5578,13 @@ void ASTReader::ReadPragmaDiagnosticMapp
>FirstState = ReadDiagState(
>F.isModule() ? DiagState() : *Diag.DiagStatesByLoc.CurDiagState,
>SourceLocation(), F.isModule());
> +
> +  // For an explicit module, set up the root buffer of the module to
> start
> +  // with the initial diagnostic state of the module itself, to cover
> files
> +  // that contain no explicit transitions.
> +  if (F.isModule())
> +Diag.DiagStatesByLoc.Files[F.OriginalSourceFileID]
> +.StateTransitions.push_back({FirstState, 0});
>  }
>
>  // Read the state transitions.
>
> Modified: cfe/trunk/test/Modules/Inputs/module.map
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module.map?rev=301846&r1=301845&r2=301846&view=diff
>
> ==
> --- cfe/trunk/test/Modules/Inputs/module.map (original)
> +++ cfe/trunk/test/Modules/Inputs/module.map Mon May  1 17:10:47 2017
> @@ -261,6 +261,10 @@ module config {
>config_macros [exhaustive] WANT_FOO, WANT_BAR
>  }
>
> +module diag_flags {
> +  header "diag_flags.h"
> +}
> +
>  module diag_pragma {
>header "diag_pragma.h"
>  }
>
> Added: cfe/trunk/test/Modules/diag-flags.cpp
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/diag-flags.cpp?rev=301846&view=auto
>
> ==
> --- cfe/trunk/test/Modules/diag-flags.cpp (added)
> +++ cfe/trunk/test/Modules/diag-flags.cpp Mon May  1 17:10:47 2017
> @@ -0,0 +1,22 @@
> +// RUN: rm -rf %t
> +//
> +// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -emit-module
> -fmodules-cache-path=%t -fmodule-name=diag_flags -x c++
> %S/Inputs/module.map -fmodules-ts
> +// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify
> -fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts
> +// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify
> -fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts -DIMPLICIT_FLAG
> -Werror=padded
> +//
> +// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -emit-module
> -fmodule-name=diag_flags -x c++ %S/Inputs/module.map -fmodules-ts -o
> %t/explicit.pcm -Werror=string-plus-int -Wpadded
> +// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify
> -fmodules-cache-path=%t -I %S/Inputs %

r301898 - clang/test/Modules/diag-flags.cpp: Appease targeting *-win32 with explicit triple. Fixes r301846.

[NAKAMURA Takumi via cfe-commits]

Author: chapuni
Date: Tue May  2 00:12:55 2017
New Revision: 301898

URL: http://llvm.org/viewvc/llvm-project?rev=301898&view=rev
Log:
clang/test/Modules/diag-flags.cpp: Appease targeting *-win32 with explicit 
triple. Fixes r301846.

MicrosoftRecordLayoutBuilder doesn't have ability of -Wpadded.

FIXME: Would other diag be available here?

Modified:
cfe/trunk/test/Modules/diag-flags.cpp

Modified: cfe/trunk/test/Modules/diag-flags.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/diag-flags.cpp?rev=301898&r1=301897&r2=301898&view=diff
==
--- cfe/trunk/test/Modules/diag-flags.cpp (original)
+++ cfe/trunk/test/Modules/diag-flags.cpp Tue May  2 00:12:55 2017
@@ -1,12 +1,12 @@
 // RUN: rm -rf %t
 //
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -emit-module 
-fmodules-cache-path=%t -fmodule-name=diag_flags -x c++ %S/Inputs/module.map 
-fmodules-ts
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify 
-fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify 
-fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts -DIMPLICIT_FLAG 
-Werror=padded
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fmodules 
-fimplicit-module-maps -emit-module -fmodules-cache-path=%t 
-fmodule-name=diag_flags -x c++ %S/Inputs/module.map -fmodules-ts
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fmodules 
-fimplicit-module-maps -verify -fmodules-cache-path=%t -I %S/Inputs %s 
-fmodules-ts
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fmodules 
-fimplicit-module-maps -verify -fmodules-cache-path=%t -I %S/Inputs %s 
-fmodules-ts -DIMPLICIT_FLAG -Werror=padded
 //
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -emit-module 
-fmodule-name=diag_flags -x c++ %S/Inputs/module.map -fmodules-ts -o 
%t/explicit.pcm -Werror=string-plus-int -Wpadded
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify 
-fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts -DEXPLICIT_FLAG 
-fmodule-file=%t/explicit.pcm
-// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify 
-fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts -DEXPLICIT_FLAG 
-fmodule-file=%t/explicit.pcm -Werror=padded
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fmodules 
-fimplicit-module-maps -emit-module -fmodule-name=diag_flags -x c++ 
%S/Inputs/module.map -fmodules-ts -o %t/explicit.pcm -Werror=string-plus-int 
-Wpadded
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fmodules 
-fimplicit-module-maps -verify -fmodules-cache-path=%t -I %S/Inputs %s 
-fmodules-ts -DEXPLICIT_FLAG -fmodule-file=%t/explicit.pcm
+// RUN: %clang_cc1 -triple x86_64-unknown-unknown -fmodules 
-fimplicit-module-maps -verify -fmodules-cache-path=%t -I %S/Inputs %s 
-fmodules-ts -DEXPLICIT_FLAG -fmodule-file=%t/explicit.pcm -Werror=padded
 
 import diag_flags;
 


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

[PATCH] D31130: B32239 clang-tidy should not warn about array to pointer decay on system macros

[Breno Rodrigues Guimaraes via Phabricator via cfe-commits]

brenoguim updated this revision to Diff 97385.
brenoguim marked an inline comment as done.
brenoguim added a comment.

Never flag predefinedExpr() types.


https://reviews.llvm.org/D31130

Files:
  clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
  
test/clang-tidy/Inputs/cppcoreguidelines-pro-bounds-array-to-pointer-decay/macro.h
  test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp

Index: test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
===
--- test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
+++ test/clang-tidy/cppcoreguidelines-pro-bounds-array-to-pointer-decay.cpp
@@ -1,5 +1,7 @@
-// RUN: %check_clang_tidy %s cppcoreguidelines-pro-bounds-array-to-pointer-decay %t
+// RUN: %check_clang_tidy %s cppcoreguidelines-pro-bounds-array-to-pointer-decay %t -- -- -isystem%S/Inputs/cppcoreguidelines-pro-bounds-array-to-pointer-decay
+
 #include 
+#include 
 
 namespace gsl {
 template 
@@ -45,3 +47,45 @@
   void *a[2];
   f2(static_cast(a)); // OK, explicit cast
 }
+
+void user_fn_decay_str(const char *);
+void user_fn_decay_int_array(const int *);
+void bug32239() {
+  sys_macro_with_pretty_function_string_decay; // Ok
+  sys_macro_with_sys_string_decay; // Ok
+  sys_macro_with_sys_int_array_decay;  // Ok
+
+  sys_fn_decay_str(__PRETTY_FUNCTION__); // Ok
+
+  sys_fn_decay_str(SYS_STRING);  // Not Ok - should it be ok?
+  // CHECK-MESSAGES: :[[@LINE-1]]:20: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+
+  sys_fn_decay_int_array(SYS_INT_ARRAY); // Not Ok
+  // CHECK-MESSAGES: :[[@LINE-1]]:26: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+
+  user_code_in_sys_macro(sys_fn_decay_str(__PRETTY_FUNCTION__)); // Ok
+
+  user_code_in_sys_macro(sys_fn_decay_str(SYS_STRING));  // Not Ok - should it be ok?
+  // CHECK-MESSAGES: :[[@LINE-1]]:43: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+
+  user_code_in_sys_macro(sys_fn_decay_int_array(SYS_INT_ARRAY)); // Not Ok
+  // CHECK-MESSAGES: :[[@LINE-1]]:49: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+
+  const char UserString[1] = "";
+  decay_to_char_pointer_in_macro(UserString); // Not Ok
+  // CHECK-MESSAGES: :[[@LINE-1]]:34: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+
+  decay_to_char_pointer_in_macro(__PRETTY_FUNCTION__); // Ok
+
+  int a[5];
+  decay_to_int_pointer_in_macro(a); // Not Ok
+  // CHECK-MESSAGES: :[[@LINE-1]]:33: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+
+  user_fn_decay_str(__PRETTY_FUNCTION__); // Ok
+
+  user_fn_decay_str(SYS_STRING); // Not Ok - should it be ok?
+  // CHECK-MESSAGES: :[[@LINE-1]]:21: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+
+  user_fn_decay_int_array(SYS_INT_ARRAY); // Not ok
+  // CHECK-MESSAGES: :[[@LINE-1]]:27: warning: do not implicitly decay an array into a pointer; consider using gsl::array_view or an explicit cast instead [cppcoreguidelines-pro-bounds-array-to-pointer-decay]
+}
Index: test/clang-tidy/Inputs/cppcoreguidelines-pro-bounds-array-to-pointer-decay/macro.h
===
--- /dev/null
+++ test/clang-tidy/Inputs/cppcoreguidelines-pro-bounds-array-to-pointer-decay/macro.h
@@ -0,0 +1,14 @@
+const char SYS_STRING[2]= "s";
+const int  SYS_INT_ARRAY[2] = {0, 0};
+
+void sys_fn_decay_str(const char *);
+void sys_fn_decay_int_array(const int *);
+
+#define sys_macro_with_pretty_function_string_decay sys_fn_decay_str(__PRETTY_FUNCTION__)
+#define sys_macro_with_sys_string_decay sys_fn_decay_str(SYS_STRING)
+#define sys_macro_with_sys_int_array_decay  sys_fn_decay_int_array(SYS_INT_ARRAY)
+
+#define user_code_in_sys_macro(expr) expr;
+
+#define decay_to_char_pointer_in_macro(expr) sys_fn_decay_str(expr)
+#define decay_to_int_pointer_in_macro(expr)  sys_fn_decay_int_array(expr)
Index: clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
===
--- clang-tidy/cppcoreguidelines/ProBoundsArrayToPointerDecayCheck.cpp
+++ cla

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[John McCall via cfe-commits]

On Mon, May 1, 2017 at 7:06 PM, Daniel Berlin  wrote:

> On Mon, May 1, 2017 at 3:58 PM, John McCall  wrote:
>
>> On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin 
>> wrote:
>>
>>> On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin 
>>> wrote:
>>>
 On Mon, May 1, 2017 at 2:07 PM, John McCall  wrote:

> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin 
> wrote:
>
>> So you believe that you can index into an object randomly by pointer
 arithmetic and pull out a different field?

>>>
>>> For starters, this is  illegal because you don't know where the
>>> padding bytes are.
>>> You cannot assume that X.a + 1 == X.b
>>> "Implementation alignment requirements might cause two adjacent
>>> members not to be allocated immediately after each other;"
>>>
>>> See 9.2.14
>>>
>>
>> IE at best you'd have to add
>>
>>  &(struct X*(0))->b - &(struct X*(0))->a
>>
>>
>> I don't believe this is legal either.
>>
>> Let me try to dredge up the long discussions we had about these cases
>> on the gcc mailing lists.
>> The conclusion was, i believe:
>>
>> "if you want to go marching through an object as a char *, that's
>> fine, if you expect to be able to get at fields by playing pointer
>> arithmetic games, from other fields, that is not)
>> I feel like every couple years, a different compiler has the same
>> aliasing discussions :)
>>
>
> With the caveat that, in practice, compilers have to support both:
>   a) "going up a level" by subtracting an offsetof, which is clearly
> officially intended and not otherwise supported,
>

 AFAIK, Vtable accesses were supported by doing this, but pretty much
 nothing else.

>>>
>>> and to be clear, i mean given:
>>>
>>> struct a
>>> {
>>> int a;
>>>  struct b bstruct;
>>> };
>>>
>>> given a pointer to bstruct, subtracting sizeof(int)  is not going to
>>> give you a pointer to a struct a.
>>>
>>
>> If sizeof(int) happens to equal offsetof(struct a, bstruct), it sure
>> should (if you're doing the pointer arithmetic on an appropriate type, of
>> course).
>>
>>
>
>
>
>> It was allowed to work for vtable accesses.
>>>
>>
>> I would like to once again remind you that random mailing list
>> conversations you happened to be in but can't even remember from some
>> completely unnamed
>>
>
> It's not unnamed, it's either gcc@, gcc-patches@ or gcc bugzilla.
> I can even give you approximate dates if you like.
>
> I don't believe calling "the other major compiler's mailing list", which
> treaded exactly this topic, is "a random mailing list conversation", or "an
> unnamed source" or a "different context"
>

>
>> and possibly different context are neither authoritative nor binding on
>> us now. :)
>>
>> John, while i appreciate the smiley, this is kind of rude.
> Without a good reason to be different, we should follow the paths other
> compilers have taken and users have become used to. Both in what we allow,
> and what we disallow.
> So if the plan here is go off and do something that is going to be
> completely different than what users expect from their compilers, that
> doesn't make a lot of sense to me.
> Otherwise, if you really don't want me to tell you what they've done, and
> try to explain why, okay, fine, then i'll bow out of these discussion and
> leave y'all to do whatever.
>
> Just don't expect me to okay patches to llvm that implement the current
> kind of hacks we currently have.
>

Daniel, I have a huge amount of respect for the GCC developers and the work
that they've done, and I'm very interested in hearing what they thought.
If you're willing to present their discussions as prior art and as input
that we should consider in determining Clang's optimization strategy, I
think that would be extremely valuable.  But no, it is not appropriate to
treat those conversations as a sort of binding precedent that can only be
over-ruled with great force; it is completely reasonable for us to discuss
these things and come to different conclusions about both the meaning of
the standard and the proper design of an optimizer.

In particular, GCC has a history — of which this is an instance — of coming
up with a remarkably strict reading of the standard and then telling
anybody who complains to pass a flag to just disable the optimization.  To
my mind, that is not a reasonable way to design an optimizer, especially
when, frankly, that original reading seems pretty questionable and it seems
plausible that a weaker interpretation would still provide almost all of
the real optimization value.

In this case, it seems to me that the vast majority of the power of a
language rule that says that you cannot alias one field from a pointer to
another comes from forbidding out-of-bounds member array accesses from
reaching into earlier or later fields.  Such accesses will overwhelmingly
arise from member access expressions, not explicit pointer 

r301891 - Revert r301785 (and r301787) because they caused PR32864.

[Nick Lewycky via cfe-commits]

Author: nicholas
Date: Mon May  1 20:06:16 2017
New Revision: 301891

URL: http://llvm.org/viewvc/llvm-project?rev=301891&view=rev
Log:
Revert r301785 (and r301787) because they caused PR32864.

The fix is that ExprEvaluatorBase::VisitInitListExpr should handle transparent 
exprs instead of exprs with one element. Fixing that uncovers one testcase 
failure because the AST for "constexpr _Complex float test2 = {1};" is wrong 
(the _Complex prvalue should not be const-qualified), and a number of test 
failures in test/OpenMP where the captured stmt contains an InitListExpr that 
is in syntactic form.

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp
cfe/trunk/test/Sema/integer-overflow.c
cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=301891&r1=301890&r2=301891&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Mon May  1 20:06:16 2017
@@ -2186,9 +2186,6 @@ static bool HandleLValueBase(EvalInfo &I
   if (!Base->isVirtual())
 return HandleLValueDirectBase(Info, E, Obj, DerivedDecl, BaseDecl);
 
-  if (!Obj.checkNullPointer(Info, E, CSK_Base))
-return false;
-
   SubobjectDesignator &D = Obj.Designator;
   if (D.Invalid)
 return false;
@@ -9946,11 +9943,8 @@ static bool EvaluateAsRValue(EvalInfo &I
   if (E->getType().isNull())
 return false;
 
-  if (!CheckLiteralType(Info, E)) {
-if (Info.noteFailure())
-  EvaluateIgnoredValue(Info, E);
+  if (!CheckLiteralType(Info, E))
 return false;
-  }
 
   if (!::Evaluate(Result, Info, E))
 return false;

Modified: cfe/trunk/test/Sema/integer-overflow.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Sema/integer-overflow.c?rev=301891&r1=301890&r2=301891&view=diff
==
--- cfe/trunk/test/Sema/integer-overflow.c (original)
+++ cfe/trunk/test/Sema/integer-overflow.c Mon May  1 20:06:16 2017
@@ -149,16 +149,16 @@ uint64_t check_integer_overflows(int i)
 
 // expected-warning@+2 {{overflow in expression; result is 536870912 with type 
'int'}}
   uint64_t *b;
-  (void)b[4608 * 1024 * 1024];
+  uint64_t b2 = b[4608 * 1024 * 1024] + 1;
 
 // expected-warning@+1 2{{overflow in expression; result is 536870912 with 
type 'int'}}
-  (void)(i ? (4608 * 1024 * 1024) : (4608 * 1024 * 1024));
+  int j1 = i ? (4608 * 1024 * 1024) : (4608 * 1024 * 1024);
 
 // expected-warning@+1 {{overflow in expression; result is 536870912 with type 
'int'}}
-  (void)(-(4608 * 1024 * 1024));
+  int j2 = -(4608 * 1024 * 1024);
 
 // expected-warning@+1 {{overflow in expression; result is 536870912 with type 
'int'}}
-  (void)b[4608 * 1024 * 1024];
+  uint64_t j3 = b[4608 * 1024 * 1024];
 
 // expected-warning@+1 2{{overflow in expression; result is 536870912 with 
type 'int'}}
   return ((4608 * 1024 * 1024) + ((uint64_t)(4608 * 1024 * 1024)));

Modified: cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp?rev=301891&r1=301890&r2=301891&view=diff
==
--- cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp (original)
+++ cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp Mon May  1 20:06:16 
2017
@@ -60,10 +60,6 @@ namespace DerivedToVBaseCast {
   static_assert((U*)&d == w, "");
   static_assert((U*)&d == x, "");
 
-  // expected-error@+2 {{constexpr variable 'a' must be initialized by a 
constant expression}}
-  // expected-warning@+1 {{binding dereferenced null pointer to reference has 
undefined behavior}}
-  constexpr A &a = *((B*)0);  // expected-note {{cannot access base class of 
null pointer}}
-
   struct X {};
   struct Y1 : virtual X {};
   struct Y2 : X {};


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

r301888 - [sanitizer-coverage] update the SanitizerCoverage docs to reflect the current state

[Kostya Serebryany via cfe-commits]

Author: kcc
Date: Mon May  1 19:32:57 2017
New Revision: 301888

URL: http://llvm.org/viewvc/llvm-project?rev=301888&view=rev
Log:
[sanitizer-coverage] update the SanitizerCoverage docs to reflect the current 
state

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=301888&r1=301887&r2=301888&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon May  1 19:32:57 2017
@@ -8,202 +8,12 @@ SanitizerCoverage
 Introduction
 
 
-Sanitizer tools have a very simple code coverage tool built in. It allows to
-get function-level, basic-block-level, and edge-level coverage at a very low
-cost.
-
-How to build and run
-
-
-SanitizerCoverage can be used with :doc:`AddressSanitizer`,
-:doc:`LeakSanitizer`, :doc:`MemorySanitizer`,
-UndefinedBehaviorSanitizer, or without any sanitizer.  Pass one of the
-following compile-time flags:
-
-* ``-fsanitize-coverage=func`` for function-level coverage (very fast).
-* ``-fsanitize-coverage=bb`` for basic-block-level coverage (may add up to 30%
-  **extra** slowdown).
-* ``-fsanitize-coverage=edge`` for edge-level coverage (up to 40% slowdown).
-
-At run time, pass ``coverage=1`` in ``ASAN_OPTIONS``,
-``LSAN_OPTIONS``, ``MSAN_OPTIONS`` or ``UBSAN_OPTIONS``, as
-appropriate. For the standalone coverage mode, use ``UBSAN_OPTIONS``.
-
-Example:
-
-.. code-block:: console
-
-% cat -n cov.cc
- 1  #include 
- 2  __attribute__((noinline))
- 3  void foo() { printf("foo\n"); }
- 4
- 5  int main(int argc, char **argv) {
- 6if (argc == 2)
- 7  foo();
- 8printf("main\n");
- 9  }
-% clang++ -g cov.cc -fsanitize=address -fsanitize-coverage=func
-% ASAN_OPTIONS=coverage=1 ./a.out; ls -l *sancov
-main
--rw-r- 1 kcc eng 4 Nov 27 12:21 a.out.22673.sancov
-% ASAN_OPTIONS=coverage=1 ./a.out foo ; ls -l *sancov
-foo
-main
--rw-r- 1 kcc eng 4 Nov 27 12:21 a.out.22673.sancov
--rw-r- 1 kcc eng 8 Nov 27 12:21 a.out.22679.sancov
-
-Every time you run an executable instrumented with SanitizerCoverage
-one ``*.sancov`` file is created during the process shutdown.
-If the executable is dynamically linked against instrumented DSOs,
-one ``*.sancov`` file will be also created for every DSO.
-
-Postprocessing
-==
-
-The format of ``*.sancov`` files is very simple: the first 8 bytes is the 
magic,
-one of ``0xC0BFFF64`` and ``0xC0BFFF32``. The last byte of the
-magic defines the size of the following offsets. The rest of the data is the
-offsets in the corresponding binary/DSO that were executed during the run.
-
-A simple script
-``$LLVM/projects/compiler-rt/lib/sanitizer_common/scripts/sancov.py`` is
-provided to dump these offsets.
-
-.. code-block:: console
-
-% sancov.py print a.out.22679.sancov a.out.22673.sancov
-sancov.py: read 2 PCs from a.out.22679.sancov
-sancov.py: read 1 PCs from a.out.22673.sancov
-sancov.py: 2 files merged; 2 PCs total
-0x465250
-0x4652a0
-
-You can then filter the output of ``sancov.py`` through ``addr2line --exe
-ObjectFile`` or ``llvm-symbolizer --obj ObjectFile`` to get file names and line
-numbers:
-
-.. code-block:: console
-
-% sancov.py print a.out.22679.sancov a.out.22673.sancov 2> /dev/null | 
llvm-symbolizer --obj a.out
-cov.cc:3
-cov.cc:5
-
-Sancov Tool
-===
-
-A new experimental ``sancov`` tool is developed to process coverage files.
-The tool is part of LLVM project and is currently supported only on Linux.
-It can handle symbolization tasks autonomously without any extra support
-from the environment. You need to pass .sancov files (named 
-``..sancov`` and paths to all corresponding binary elf 
files. 
-Sancov matches these files using module names and binaries file names.
-
-.. code-block:: console
-
-USAGE: sancov [options]  (|<.sancov file>)...
-
-Action (required)
-  -print- Print coverage addresses
-  -covered-functions- Print all covered functions.
-  -not-covered-functions- Print all not covered functions.
-  -symbolize- Symbolizes the report.
-
-Options
-  -blacklist= - Blacklist file (sanitizer blacklist 
format).
-  -demangle   - Print demangled function name.
-  -strip_path_prefix= - Strip this prefix from file paths in 
reports
-
-
-Coverage Reports (Experimental)
-
-
-``.sancov`` files do not contain enough information to generate a source-level 
-coverage report. The missing information is contained
-in debug info of the binary. Thus the ``.sancov`` has to be symbolized
-to produce a ``.symcov`` file first:
-
-.. code-bl

[PATCH] D32727: [libcxx] [test] Be compatible with LWG 2438 "std::iterator inheritance shouldn't be mandated".

[Stephan T. Lavavej via Phabricator via cfe-commits]

STL_MSFT created this revision.

[libcxx] [test] Be compatible with LWG 2438 "std::iterator inheritance 
shouldn't be mandated".

In C++17, these iterators are allowed but not required to inherit from the 
deprecated std::iterator base class.


https://reviews.llvm.org/D32727

Files:
  test/std/iterators/stream.iterators/istream.iterator/types.pass.cpp
  test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
  test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp

Index: test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
===
--- test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
+++ test/std/iterators/stream.iterators/ostreambuf.iterator/types.pass.cpp
@@ -27,16 +27,32 @@
 int main()
 {
 typedef std::ostreambuf_iterator I1;
+#if TEST_STD_VER <= 14
 static_assert((std::is_convertible >::value), "");
+#else
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same >::value), "");
 static_assert((std::is_same::value), "");
 static_assert((std::is_same::value), "");
 
 typedef std::ostreambuf_iterator I2;
+#if TEST_STD_VER <= 14
 static_assert((std::is_convertible >::value), "");
+#else
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same >::value), "");
 static_assert((std::is_same::value), "");
Index: test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
===
--- test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
+++ test/std/iterators/stream.iterators/ostream.iterator/types.pass.cpp
@@ -26,14 +26,30 @@
 int main()
 {
 typedef std::ostream_iterator I1;
+#if TEST_STD_VER <= 14
 static_assert((std::is_convertible >::value), "");
+#else
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same >::value), "");
 static_assert((std::is_same::value), "");
 typedef std::ostream_iterator I2;
+#if TEST_STD_VER <= 14
 static_assert((std::is_convertible >::value), "");
+#else
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same >::value), "");
 static_assert((std::is_same::value), "");
Index: test/std/iterators/stream.iterators/istream.iterator/types.pass.cpp
===
--- test/std/iterators/stream.iterators/istream.iterator/types.pass.cpp
+++ test/std/iterators/stream.iterators/istream.iterator/types.pass.cpp
@@ -43,19 +43,35 @@
 int main()
 {
 typedef std::istream_iterator I1; // double is trivially destructible
+#if TEST_STD_VER <= 14
 static_assert((std::is_convertible >::value), "");
+#else
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same >::value), "");
 static_assert((std::is_same::value), "");
 static_assert( std::is_trivially_copy_constructible::value, "");
 static_assert( std::is_trivially_destructible::value, "");
 
 typedef std::istream_iterator I2; // unsigned is trivially destructible
+#if TEST_STD_VER <= 14
 static_assert((std::is_convertible >::value), "");
+#else
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+static_assert((std::is_same::value), "");
+#endif
 static_assert((std::is_same::value), "");
 static_assert((std::is_same >::value), "");
 static_assert((std::is_same::value), "");
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32726: [libcxx] [test] In msvc_stdlib_force_include.hpp, use _HAS_CXX17 to set TEST_STD_VER.

[Stephan T. Lavavej via Phabricator via cfe-commits]

STL_MSFT created this revision.

[libcxx] [test] In msvc_stdlib_force_include.hpp, use _HAS_CXX17 to set 
TEST_STD_VER.

_HAS_CXX17 indicates whether MSVC's STL is in C++17 mode.


https://reviews.llvm.org/D32726

Files:
  test/support/msvc_stdlib_force_include.hpp


Index: test/support/msvc_stdlib_force_include.hpp
===
--- test/support/msvc_stdlib_force_include.hpp
+++ test/support/msvc_stdlib_force_include.hpp
@@ -40,8 +40,6 @@
 
 // MSVC frontend only configurations
 #if !defined(__clang__)
-#define TEST_STD_VER 17
-
 // Simulate feature-test macros.
 #define __has_feature(X) _MSVC_HAS_FEATURE_ ## X
 #define _MSVC_HAS_FEATURE_cxx_exceptions1
@@ -75,4 +73,12 @@
 // Silence warnings about raw pointers and other unchecked iterators.
 #define _SCL_SECURE_NO_WARNINGS
 
+#include 
+
+#if _HAS_CXX17
+#define TEST_STD_VER 17
+#else // _HAS_CXX17
+#define TEST_STD_VER 14
+#endif // _HAS_CXX17
+
 #endif // SUPPORT_MSVC_STDLIB_FORCE_INCLUDE_HPP


Index: test/support/msvc_stdlib_force_include.hpp
===
--- test/support/msvc_stdlib_force_include.hpp
+++ test/support/msvc_stdlib_force_include.hpp
@@ -40,8 +40,6 @@
 
 // MSVC frontend only configurations
 #if !defined(__clang__)
-#define TEST_STD_VER 17
-
 // Simulate feature-test macros.
 #define __has_feature(X) _MSVC_HAS_FEATURE_ ## X
 #define _MSVC_HAS_FEATURE_cxx_exceptions1
@@ -75,4 +73,12 @@
 // Silence warnings about raw pointers and other unchecked iterators.
 #define _SCL_SECURE_NO_WARNINGS
 
+#include 
+
+#if _HAS_CXX17
+#define TEST_STD_VER 17
+#else // _HAS_CXX17
+#define TEST_STD_VER 14
+#endif // _HAS_CXX17
+
 #endif // SUPPORT_MSVC_STDLIB_FORCE_INCLUDE_HPP
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

[PATCH] D32671: [libcxx] [test] variant: test coverage for P0602 extension

[Casey Carter via Phabricator via cfe-commits]

CaseyCarter updated this revision to Diff 97367.
CaseyCarter added a comment.

Fix missing indent in msvc_stdlib_force_include.hpp


https://reviews.llvm.org/D32671

Files:
  test/std/utilities/variant/variant.variant/variant.assign/copy.pass.cpp
  test/std/utilities/variant/variant.variant/variant.assign/move.pass.cpp
  test/std/utilities/variant/variant.variant/variant.ctor/copy.pass.cpp
  test/std/utilities/variant/variant.variant/variant.ctor/move.pass.cpp
  test/support/msvc_stdlib_force_include.hpp
  test/support/test.workarounds/c1xx_broken_is_trivially_copyable.pass.cpp
  test/support/test_workarounds.h

Index: test/support/test_workarounds.h
===
--- test/support/test_workarounds.h
+++ test/support/test_workarounds.h
@@ -15,6 +15,7 @@
 
 #if defined(TEST_COMPILER_C1XX)
 # define TEST_WORKAROUND_C1XX_BROKEN_NULLPTR_CONVERSION_OPERATOR
+# define TEST_WORKAROUND_C1XX_BROKEN_IS_TRIVIALLY_COPYABLE
 #endif
 
 #endif // SUPPORT_TEST_WORKAROUNDS_H
Index: test/support/test.workarounds/c1xx_broken_is_trivially_copyable.pass.cpp
===
--- /dev/null
+++ test/support/test.workarounds/c1xx_broken_is_trivially_copyable.pass.cpp
@@ -0,0 +1,31 @@
+//===--===//
+//
+// The LLVM Compiler Infrastructure
+//
+// This file is dual licensed under the MIT and the University of Illinois Open
+// Source Licenses. See LICENSE.TXT for details.
+//
+//===--===//
+
+// UNSUPPORTED: c++98, c++03
+
+// Verify TEST_WORKAROUND_C1XX_BROKEN_IS_TRIVIALLY_COPYABLE.
+
+#include 
+
+#include "test_workarounds.h"
+
+struct S {
+  S(S const&) = default;
+  S(S&&) = default;
+  S& operator=(S const&) = delete;
+  S& operator=(S&&) = delete;
+};
+
+int main() {
+#if defined(TEST_WORKAROUND_C1XX_BROKEN_IS_TRIVIALLY_COPYABLE)
+  static_assert(!std::is_trivially_copyable::value, "");
+#else
+  static_assert(std::is_trivially_copyable::value, "");
+#endif
+}
Index: test/support/msvc_stdlib_force_include.hpp
===
--- test/support/msvc_stdlib_force_include.hpp
+++ test/support/msvc_stdlib_force_include.hpp
@@ -26,6 +26,11 @@
 #error This header may not be used when targeting libc++
 #endif
 
+// Indicates that we are using the MSVC standard library.
+#ifndef _MSVC_STL_VER
+#define _MSVC_STL_VER 42
+#endif
+
 struct AssertionDialogAvoider {
 AssertionDialogAvoider() {
 _CrtSetReportMode(_CRT_ASSERT, _CRTDBG_MODE_FILE);
Index: test/std/utilities/variant/variant.variant/variant.ctor/move.pass.cpp
===
--- test/std/utilities/variant/variant.variant/variant.ctor/move.pass.cpp
+++ test/std/utilities/variant/variant.variant/variant.ctor/move.pass.cpp
@@ -22,6 +22,7 @@
 #include 
 
 #include "test_macros.h"
+#include "test_workarounds.h"
 
 struct ThrowsMove {
   ThrowsMove(ThrowsMove &&) noexcept(false) {}
@@ -178,20 +179,48 @@
 }
 
 void test_constexpr_move_ctor_extension() {
-#ifdef _LIBCPP_VERSION
+#if defined(_LIBCPP_VER) || defined(_MSVC_STL_VER)
   using V = std::variant;
+#ifdef TEST_WORKAROUND_C1XX_BROKEN_IS_TRIVIALLY_COPYABLE
+  static_assert(std::is_trivially_destructible::value, "");
+  static_assert(std::is_trivially_copy_constructible::value, "");
+  static_assert(std::is_trivially_move_constructible::value, "");
+  static_assert(!std::is_copy_assignable::value, "");
+  static_assert(!std::is_move_assignable::value, "");
+#else
   static_assert(std::is_trivially_copyable::value, "");
+#endif
   static_assert(std::is_trivially_move_constructible::value, "");
   static_assert(test_constexpr_ctor_extension_imp<0>(V(42l)), "");
   static_assert(test_constexpr_ctor_extension_imp<1>(V(nullptr)), "");
   static_assert(test_constexpr_ctor_extension_imp<2>(V(101)), "");
 #endif
 }
 
+template
+constexpr bool triviality_test =
+  std::is_trivially_move_constructible>::value ==
+std::conjunction...>::value;
+
+void test_triviality_extension() {
+#if defined(_MSVC_STL_VER)
+  static_assert(triviality_test, "");
+  static_assert(triviality_test, "");
+  static_assert(triviality_test, "");
+  static_assert(triviality_test, "");
+  static_assert(triviality_test, "");
+  static_assert(triviality_test, "");
+  static_assert(triviality_test, "");
+  static_assert(triviality_test, "");
+  static_assert(triviality_test, "");
+#endif
+}
+
 int main() {
   test_move_ctor_basic();
   test_move_ctor_valueless_by_exception();
   test_move_noexcept();
   test_move_ctor_sfinae();
   test_constexpr_move_ctor_extension();
+  test_triviality_extension();
 }
Index: test/std/utilities/variant/variant.variant/variant.ctor/copy.pass.cpp
===
--- test/std/utilities/variant/variant.variant/v

[PATCH] D32385: [libcxx] optional: Implement LWG 2900 and P0602

[Casey Carter via Phabricator via cfe-commits]

CaseyCarter updated this revision to Diff 97366.
CaseyCarter added a comment.

Fix a missing indent in the `msvc_stdlib_force_include.hpp` change.


https://reviews.llvm.org/D32385

Files:
  include/optional
  test/libcxx/utilities/optional/optional.object/special_member_gen.pass.cpp
  
test/std/utilities/optional/optional.object/optional.object.assign/copy.pass.cpp
  
test/std/utilities/optional/optional.object/optional.object.assign/move.pass.cpp
  test/std/utilities/optional/optional.object/optional.object.ctor/copy.pass.cpp
  test/std/utilities/optional/optional.object/optional.object.ctor/move.pass.cpp
  test/support/msvc_stdlib_force_include.hpp

Index: test/support/msvc_stdlib_force_include.hpp
===
--- test/support/msvc_stdlib_force_include.hpp
+++ test/support/msvc_stdlib_force_include.hpp
@@ -26,6 +26,11 @@
 #error This header may not be used when targeting libc++
 #endif
 
+// Indicates that we are using the MSVC standard library.
+#ifndef _MSVC_STL_VER
+#define _MSVC_STL_VER 42
+#endif
+
 struct AssertionDialogAvoider {
 AssertionDialogAvoider() {
 _CrtSetReportMode(_CRT_ASSERT, _CRTDBG_MODE_FILE);
Index: test/std/utilities/optional/optional.object/optional.object.ctor/move.pass.cpp
===
--- test/std/utilities/optional/optional.object/optional.object.ctor/move.pass.cpp
+++ test/std/utilities/optional/optional.object/optional.object.ctor/move.pass.cpp
@@ -10,7 +10,10 @@
 // UNSUPPORTED: c++98, c++03, c++11, c++14
 // 
 
-// optional(optional&& rhs);
+// constexpr optional(optional&& rhs);
+//   If is_trivially_move_constructible_v is true,
+//this constructor shall be a constexpr constructor.
+
 
 #include 
 #include 
@@ -36,10 +39,10 @@
 void test_throwing_ctor() {
 #ifndef TEST_HAS_NO_EXCEPTIONS
 struct Z {
-  Z() : count(0) {}
-  Z(Z&& o) : count(o.count + 1)
-  { if (count == 2) throw 6; }
-  int count;
+Z() : count(0) {}
+Z(Z&& o) : count(o.count + 1)
+{ if (count == 2) throw 6; }
+int count;
 };
 Z z;
 optional rhs(std::move(z));
@@ -131,6 +134,48 @@
 #endif
 }
 
+constexpr bool test_constexpr()
+{
+{
+using T = int;
+optional o1{};
+optional o2 = std::move(o1);
+static_cast(o2);
+optional o3{T{42}};
+optional o4 = std::move(o3);
+static_cast(o4);
+}
+{
+struct T {
+constexpr T(int) {}
+T(T&&) = default;
+};
+optional o1{};
+optional o2 = std::move(o1);
+static_cast(o2);
+optional o3{T{42}};
+optional o4 = std::move(o3);
+static_cast(o4);
+}
+return true;
+}
+static_assert(test_constexpr(), "");
+
+template
+constexpr bool triviality_test =
+std::is_trivially_move_constructible>::value ==
+std::is_trivially_move_constructible::value;
+
+void test_triviality_extension() {
+#if defined(_LIBCPP_VER) || defined(_MSVC_STL_VER)
+static_assert(triviality_test, "");
+static_assert(triviality_test>, "");
+static_assert(triviality_test, "");
+static_assert(triviality_test, "");
+static_assert(triviality_test, "");
+static_assert(triviality_test, "");
+#endif
+}
 
 int main()
 {
@@ -178,9 +223,9 @@
 test();
 test(42);
 }
-{
-test_throwing_ctor();
-}
+
+test_throwing_ctor();
+
 {
 struct ThrowsMove {
   ThrowsMove() noexcept(false) {}
@@ -195,7 +240,7 @@
 };
 static_assert(std::is_nothrow_move_constructible>::value, "");
 }
-{
-test_reference_extension();
-}
+
+test_reference_extension();
+test_triviality_extension();
 }
Index: test/std/utilities/optional/optional.object/optional.object.ctor/copy.pass.cpp
===
--- test/std/utilities/optional/optional.object/optional.object.ctor/copy.pass.cpp
+++ test/std/utilities/optional/optional.object/optional.object.ctor/copy.pass.cpp
@@ -10,7 +10,9 @@
 // UNSUPPORTED: c++98, c++03, c++11, c++14
 // 
 
-// optional(const optional& rhs);
+// constexpr optional(const optional& rhs);
+//   If is_trivially_copy_constructible_v is true,
+//this constructor shall be a constexpr constructor.
 
 #include 
 #include 
@@ -35,10 +37,10 @@
 void test_throwing_ctor() {
 #ifndef TEST_HAS_NO_EXCEPTIONS
 struct Z {
-  Z() : count(0) {}
-  Z(Z const& o) : count(o.count + 1)
-  { if (count == 2) throw 6; }
-  int count;
+Z() : count(0) {}
+Z(Z const& o) : count(o.count + 1)
+{ if (count == 2) throw 6; }
+int count;
 };
 const Z z;
 const optional rhs(z);
@@ -104,6 +106,48 @@
 #endif
 }
 
+constexpr bool test_constexpr()
+{
+{
+using T = int;
+optional o1{};
+optional o2 = o1;
+static_cast(o2);
+option

[PATCH] D32724: [Modules] Include the enabled sanitizers in the module hash

[Vedant Kumar via Phabricator via cfe-commits]

vsk created this revision.

When building with implicit modules it's possible to hit a scenario
where modules are built without -fsanitize=address, and are subsequently
imported into CUs with -fsanitize=address enabled. This can cause
strange failures at runtime. One case I've seen affects libcxx, since
its vector implementation behaves differently when ASan is enabled.

Implicit module builds should work even when -fsanitize=X is toggled on
and off across multiple compiler invocations. This patch implements a
fix by including the set of enabled sanitizers in the module hash.

I am not sure if the module hash should change when building with
explicit modules, and would appreciate any input on this.


https://reviews.llvm.org/D32724

Files:
  lib/Basic/LangOptions.cpp
  lib/Frontend/CompilerInvocation.cpp
  test/Modules/Inputs/check-for-sanitizer-feature/check.h
  test/Modules/Inputs/check-for-sanitizer-feature/map
  test/Modules/check-for-sanitizer-feature.cpp


Index: test/Modules/check-for-sanitizer-feature.cpp
===
--- /dev/null
+++ test/Modules/check-for-sanitizer-feature.cpp
@@ -0,0 +1,32 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+
+// Build and use an ASan-enabled module.
+// RUN: %clang_cc1 -fsanitize=address -fmodules -fmodules-cache-path=%t \
+// RUN:   -fmodule-map-file=%S/Inputs/check-for-sanitizer-feature/map \
+// RUN:   -I %S/Inputs/check-for-sanitizer-feature -verify %s
+
+// Force a module rebuild by disabling ASan.
+// RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t \
+// RUN:   -fmodule-map-file=%S/Inputs/check-for-sanitizer-feature/map \
+// RUN:   -I %S/Inputs/check-for-sanitizer-feature -verify %s
+
+// Force another module rebuild by enabling ASan again.
+// RUN: %clang_cc1 -fsanitize=address -fmodules -fmodules-cache-path=%t \
+// RUN:   -fmodule-map-file=%S/Inputs/check-for-sanitizer-feature/map \
+// RUN:   -I %S/Inputs/check-for-sanitizer-feature -verify %s
+
+#include "check.h"
+
+#if __has_feature(address_sanitizer)
+#if HAS_ASAN != 1
+#error Does not have the address_sanitizer feature, but should.
+#endif
+#else
+#if HAS_ASAN != 0
+#error Has the address_sanitizer feature, but shouldn't.
+#endif
+
+#endif
+
+// expected-no-diagnostics
Index: test/Modules/Inputs/check-for-sanitizer-feature/map
===
--- /dev/null
+++ test/Modules/Inputs/check-for-sanitizer-feature/map
@@ -0,0 +1,3 @@
+module check_feature {
+  header "check.h"
+}
Index: test/Modules/Inputs/check-for-sanitizer-feature/check.h
===
--- /dev/null
+++ test/Modules/Inputs/check-for-sanitizer-feature/check.h
@@ -0,0 +1,5 @@
+#if __has_feature(address_sanitizer)
+#define HAS_ASAN 1
+#else
+#define HAS_ASAN 0
+#endif
Index: lib/Frontend/CompilerInvocation.cpp
===
--- lib/Frontend/CompilerInvocation.cpp
+++ lib/Frontend/CompilerInvocation.cpp
@@ -2693,6 +2693,11 @@
 code = ext->hashExtension(code);
   }
 
+  // Extend the signature with the enabled sanitizers, if at least one is
+  // enabled.
+  if (!LangOpts->Sanitize.empty())
+code = hash_combine(code, LangOpts->Sanitize.Mask);
+
   return llvm::APInt(64, code).toString(36, /*Signed=*/false);
 }
 
Index: lib/Basic/LangOptions.cpp
===
--- lib/Basic/LangOptions.cpp
+++ lib/Basic/LangOptions.cpp
@@ -29,9 +29,11 @@
   Name = Default;
 #include "clang/Basic/LangOptions.def"
 
-  // FIXME: This should not be reset; modules can be different with different
-  // sanitizer options (this affects __has_feature(address_sanitizer) etc).
-  Sanitize.clear();
+  // FIXME: Some sanitizers do not expose any information via the preprocessor
+  // (e.g UBSan). We may be able to avoid some module rebuilds by disabling
+  // those sanitizers.
+
+  // These options do not affect AST generation.
   SanitizerBlacklistFiles.clear();
   XRayAlwaysInstrumentFiles.clear();
   XRayNeverInstrumentFiles.clear();


Index: test/Modules/check-for-sanitizer-feature.cpp
===
--- /dev/null
+++ test/Modules/check-for-sanitizer-feature.cpp
@@ -0,0 +1,32 @@
+// RUN: rm -rf %t
+// RUN: mkdir %t
+
+// Build and use an ASan-enabled module.
+// RUN: %clang_cc1 -fsanitize=address -fmodules -fmodules-cache-path=%t \
+// RUN:   -fmodule-map-file=%S/Inputs/check-for-sanitizer-feature/map \
+// RUN:   -I %S/Inputs/check-for-sanitizer-feature -verify %s
+
+// Force a module rebuild by disabling ASan.
+// RUN: %clang_cc1 -fmodules -fmodules-cache-path=%t \
+// RUN:   -fmodule-map-file=%S/Inputs/check-for-sanitizer-feature/map \
+// RUN:   -I %S/Inputs/check-for-sanitizer-feature -verify %s
+
+// Force another module rebuild by enabling ASan again.
+// RUN: %clang_cc1 -fsanitize=address -fmodules -fmodules-cache-path=%t \
+// RUN:   -fmodu

[libcxxabi] r301864 - Creating release candidate rc1 from release_401 branch

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Mon May  1 18:01:07 2017
New Revision: 301864

URL: http://llvm.org/viewvc/llvm-project?rev=301864&view=rev
Log:
Creating release candidate rc1 from release_401 branch

Added:
libcxxabi/tags/RELEASE_401/rc1/   (props changed)
  - copied from r301863, libcxxabi/branches/release_40/

Propchange: libcxxabi/tags/RELEASE_401/rc1/
--
svn:mergeinfo = /libcxxabi/trunk:292135,292418,292638


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

[libunwind] r301876 - Creating release candidate rc1 from release_401 branch

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Mon May  1 18:01:23 2017
New Revision: 301876

URL: http://llvm.org/viewvc/llvm-project?rev=301876&view=rev
Log:
Creating release candidate rc1 from release_401 branch

Added:
libunwind/tags/RELEASE_401/rc1/   (props changed)
  - copied from r301875, libunwind/branches/release_40/

Propchange: libunwind/tags/RELEASE_401/rc1/
--
svn:mergeinfo = /libunwind/trunk:292723,296358-296359


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

[libunwind] r301875 - Creating release directory for release_401.

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Mon May  1 18:01:21 2017
New Revision: 301875

URL: http://llvm.org/viewvc/llvm-project?rev=301875&view=rev
Log:
Creating release directory for release_401.

Added:
libunwind/tags/RELEASE_401/

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

[libcxxabi] r301863 - Creating release directory for release_401.

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Mon May  1 18:01:05 2017
New Revision: 301863

URL: http://llvm.org/viewvc/llvm-project?rev=301863&view=rev
Log:
Creating release directory for release_401.

Added:
libcxxabi/tags/RELEASE_401/

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

[libcxx] r301861 - Creating release directory for release_401.

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Mon May  1 18:01:02 2017
New Revision: 301861

URL: http://llvm.org/viewvc/llvm-project?rev=301861&view=rev
Log:
Creating release directory for release_401.

Added:
libcxx/tags/RELEASE_401/

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

[libcxx] r301862 - Creating release candidate rc1 from release_401 branch

[Tom Stellard via cfe-commits]

Author: tstellar
Date: Mon May  1 18:01:04 2017
New Revision: 301862

URL: http://llvm.org/viewvc/llvm-project?rev=301862&view=rev
Log:
Creating release candidate rc1 from release_401 branch

Added:
libcxx/tags/RELEASE_401/rc1/   (props changed)
  - copied from r301861, libcxx/branches/release_40/

Propchange: libcxx/tags/RELEASE_401/rc1/
--
--- svn:mergeinfo (added)
+++ svn:mergeinfo Mon May  1 18:01:04 2017
@@ -0,0 +1,2 @@
+/libcxx/branches/apple:136569-137939
+/libcxx/trunk:292013,292091,292607,292990,293154,293197,293581,294133,294142,294431


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

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via cfe-commits]

On 05/01/2017 02:35 PM, Krzysztof Parzyszek via cfe-commits wrote:

On 5/1/2017 2:16 PM, Hal Finkel via cfe-commits wrote:


On 05/01/2017 12:49 PM, Daniel Berlin wrote:

On 04/21/2017 06:03 AM, Hal Finkel via Phabricator wrote:

...


   Our struct-path TBAA does the following:

  struct X { int a, b; };
  X x { 50, 100 };
  X *o = (X*) (((int*) &x) + 1);

  int a_is_b = o->a; // This is UB (or so we say)?



This is UB.
A good resource for this stuff is 
http://www.cl.cam.ac.uk/~pes20/cerberus/ 
 which has a long 
document where they exlpore all of these and what various compilers 
do, along with what the standard seems to say.


http://www.cl.cam.ac.uk/~pes20/cerberus/notes30-full.pdf is 172 
pages, and so I may have missed it, but I don't see this case. Also, 
I'd really like to see where the standard says this is UB. I don't 
see it.




The last sentence of 8:


6.5.6 Additive operators


7 For the purposes of these operators, a pointer to an object that is 
not an element of an array behaves the same as a pointer to the first 
element of an array of length one with the type of the object as its 
element type.


8 When an expression that has integer type is added to or subtracted 
from a pointer, the result has the type of the pointer operand. If the 
pointer operand points to an element of an array object, and the array 
is large enough, the result points to an element offset from the 
original element such that the difference of the subscripts of the 
resulting and original array elements equals the integer expression. 
In other words, if the expression P points to the i-th element of an 
array object, the expressions (P)+N (equivalently, N+(P)) and (P)-N 
(where N has the value n) point to, respectively, the i+n-th and 
i−n-th elements of the array object, provided they exist. Moreover, if 
the expression P points to the last element of an array object, the 
expression (P)+1 points one past the last element of the array object, 
and if the expression Q points one past the last element of an array 
object, the expression (Q)-1 points to the last element of the array 
object. If both the pointer operand and the result point to elements 
of the same array object, or one past the last element of the array 
object, the evaluation shall not produce an overflow; otherwise, the 
behavior is undefined. If the result points one past the last element 
of the array object, it shall not be used as the operand of a unary * 
operator that is evaluated.


I certainly see your point, but I'm not sure it helps. It is true that 
((int*) &x), not being a pointer to an array objected, when used as one, 
is an array of length one. Thus, forming (((int*) &x) + 1) is valid, 
being a one-past-the-end pointer, but cannot be used as the operand of a 
unary * that is evaluated. That's not exactly what is going on here, but 
I imagine one could argue some equivalence.


However, the example can also be written as:

  struct X { int a, b; };
  X x { 50, 100 };
  X *o = (X*) &x.b;

  int a_is_b = o->a; // This is UB (or so we say)?

and then the pointer arithmetic considerations don't seem to apply.

Thanks again,
Hal



-Krzysztof



--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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

Re: Hashing the clang resource path

[Argyrios Kyrtzidis via cfe-commits]

> On May 1, 2017, at 7:51 AM, Aaron Ballman  wrote:
> 
> I think we may have stumbled across a bug with
> CIndexer::getClangResourcesPath(), where on POSIX-y systems it uses
> dladdr() to get the path of the shared object. It seems that on some
> systems (in our case, OS X 10.6.8), dladdr() does not return a
> canonicalized path. We're getting a path like
> PATH/TO/CLANG/build/bin/../lib/clang/4.0.0. This resource directory
> path is then used to calculate a hash used by
> CompilerInvocation::getModuleHash(). This, in turn, is causing
> Index/pch-from-libclang.c to fail for us because the module cache
> paths have different names -- the first path is calculated with
> PATH/TO/CLANG/build/lib/clang/4.0.0 and the second path uses
> PATH/TO/CLANG/build/bin/../lib/clang/4.0.0.
> 
> Should CIndexer::getClangResourcePath() always return a canonicalized
> file path, or is it expected that it should return an unnormalized
> path and receivers of that path should be responsible for
> canonicalizing it?

I’d suggest that getClangResourcePath() should return 
'PATH/TO/CLANG/build/lib/clang/4.0.0’ as well.

> 
> Thanks!
> 
> ~Aaron

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

[PATCH] D32332: Add support for transparent overloadable functions in clang

[George Burgess IV via Phabricator via cfe-commits]

george.burgess.iv added a comment.

thanks for the feedback!

fwiw, at a high level, the main problem i'm trying to solve with this is that 
you can't really make a `__overloadable_without_mangling` macro without handing 
it the function name, since you currently need to use 
`__asm__("name-you'd-like-the-function-to-have")` to rename the function. if 
you can think of a better way to go about this, even if it requires that we 
drop the "no `overloadable` required on some redeclarations" feature this adds, 
i'm all ears. :)

> Is there a reason we want the second spelling instead of making the current 
> spelling behave in the manner you describe?

there are two features this is adding, and i'm not sure which you want 
`overloadable` to imply.

1. this new spelling brings with it the promise that we won't mangle function 
names; if we made every `overloadable` act this way, we'd have:

  void foo(int) __attribute__((overloadable)); // emitted as `declare void 
@foo(i32)`
  void foo(long) __attribute__((overloadable)); // emitted as `declare void 
@foo(i64)`. LLVM gets angry, since we have different declarations for @foo.

the only way i can think of to get "no indication of which overloads aren't 
mangled" to work is choosing which overload to mangle based on source order, 
and that seems overly subtle to me. so, i think this behavior needs to be 
spelled out in the source.

2. for the "no overloadable required on redecls" feature this adds: i wasn't 
there for the initial design of the `overloadable` attribute, so i can't say 
for certain, but i think part of the reason that we required `overloadable` to 
be on every redecl was so that people would have an indication of "hey, by the 
way, this name will probably be mangled and there may be other functions you 
end up calling." in C, i can totally see that being valuable. if you're 
suggesting we relax that for all overloads, i'll find who originally 
implemented all of this to figure out what their reasoning was and get back to 
you. :)

---

in any case, whether we actually do this as a new spelling, an optional 
argument to `overloadable`, etc. makes no difference to me. i chose a new 
spelling because AFAICT, we don't currently have a standard way for a user to 
query clang for if it has support for specific features in an attribute. 
(outside of checking clang's version, but that's discouraged AFAIK.) if we 
decide an optional arg would be a better approach than a new spelling, i'm 
happy to add something like `__has_attribute_ext` so you can do 
`__has_attribute_ext(overloadable, transparent_overloads)`.

>   I think that forcing the user to choice which spelling of "overloadable" 
> they want to use is not very user friendly.

yeah. the idea was that users should only need to reach for 
`transparently_overloadable` if they're trying to make a previously 
non-`overloadable` function `overloadable`. like said, if you think there's a 
better way to surface this functionality, i'm all for it.




Comment at: include/clang/Basic/Attr.td:1416
 def Overloadable : Attr {
-  let Spellings = [GNU<"overloadable">];
+  let Spellings = [GNU<"overloadable">, GNU<"transparently_overloadable">];
   let Subjects = SubjectList<[Function], ErrorDiag>;

aaron.ballman wrote:
> I'm not too keen on the name, especially since there's already a 
> "transparent_union" attribute, where the "transparent" means something 
> slightly different than it does here. However, my attempts to dream up a 
> better name are coming up short...
yeah :/

my only other idea was `implicitly_overloadable`. maybe that would be 
preferable? 



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:3259
   "'overloadable' function %0 must have a prototype">;
+def err_attribute_overloadable_too_many_transparent_overloads : Error<
+  "only one 'overloadable' overload may be transparent">;

aaron.ballman wrote:
> Why should this be an error instead of simply an ignored attribute?
if the user asks for us to not mangle two overloads with the same name, i don't 
think we can (sanely) go to CodeGen. see below.



Comment at: test/Sema/overloadable.c:189
+  void to_foo5(int) __attribute__((overloadable)); // expected-note {{previous 
overload}}
+  void to_foo5(int) __attribute__((transparently_overloadable)); // 
expected-error{{mismatched transparency}}
+

aaron.ballman wrote:
> Why should this be a mismatch? Attributes can usually be added to 
> redeclarations without an issue, and it's not unheard of for subsequent 
> redeclarations to gain additional attributes. It seems like the behavior the 
> user would expect from this is for the `transparently_overloadable` attribute 
> to "win" and simply replaces, or silently augments, the `overloadable` 
> attribute.
my issue with this was:

```
// foo.h
void foo(int) __attribute__((overloadable));

// foo.c
void foo(int) __attribute__((overloadable)) {}

// bar.c

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 3:58 PM, John McCall  wrote:

> On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin  wrote:
>
>> On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin 
>> wrote:
>>
>>> On Mon, May 1, 2017 at 2:07 PM, John McCall  wrote:
>>>
 On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin 
 wrote:

> So you believe that you can index into an object randomly by pointer
>>> arithmetic and pull out a different field?
>>>
>>
>> For starters, this is  illegal because you don't know where the
>> padding bytes are.
>> You cannot assume that X.a + 1 == X.b
>> "Implementation alignment requirements might cause two adjacent
>> members not to be allocated immediately after each other;"
>>
>> See 9.2.14
>>
>
> IE at best you'd have to add
>
>  &(struct X*(0))->b - &(struct X*(0))->a
>
>
> I don't believe this is legal either.
>
> Let me try to dredge up the long discussions we had about these cases
> on the gcc mailing lists.
> The conclusion was, i believe:
>
> "if you want to go marching through an object as a char *, that's
> fine, if you expect to be able to get at fields by playing pointer
> arithmetic games, from other fields, that is not)
> I feel like every couple years, a different compiler has the same
> aliasing discussions :)
>

 With the caveat that, in practice, compilers have to support both:
   a) "going up a level" by subtracting an offsetof, which is clearly
 officially intended and not otherwise supported,

>>>
>>> AFAIK, Vtable accesses were supported by doing this, but pretty much
>>> nothing else.
>>>
>>
>> and to be clear, i mean given:
>>
>> struct a
>> {
>> int a;
>>  struct b bstruct;
>> };
>>
>> given a pointer to bstruct, subtracting sizeof(int)  is not going to give
>> you a pointer to a struct a.
>>
>
> If sizeof(int) happens to equal offsetof(struct a, bstruct), it sure
> should (if you're doing the pointer arithmetic on an appropriate type, of
> course).
>
>



> It was allowed to work for vtable accesses.
>>
>
> I would like to once again remind you that random mailing list
> conversations you happened to be in but can't even remember from some
> completely unnamed
>

It's not unnamed, it's either gcc@, gcc-patches@ or gcc bugzilla.
I can even give you approximate dates if you like.

I don't believe calling "the other major compiler's mailing list", which
treaded exactly this topic, is "a random mailing list conversation", or "an
unnamed source" or a "different context".


> and possibly different context are neither authoritative nor binding on us
> now. :)
>
> John, while i appreciate the smiley, this is kind of rude.
Without a good reason to be different, we should follow the paths other
compilers have taken and users have become used to. Both in what we allow,
and what we disallow.
So if the plan here is go off and do something that is going to be
completely different than what users expect from their compilers, that
doesn't make a lot of sense to me.
Otherwise, if you really don't want me to tell you what they've done, and
try to explain why, okay, fine, then i'll bow out of these discussion and
leave y'all to do whatever.

Just don't expect me to okay patches to llvm that implement the current
kind of hacks we currently have.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[John McCall via cfe-commits]

On Mon, May 1, 2017 at 6:40 PM, Daniel Berlin  wrote:

> On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin  wrote:
>
>> On Mon, May 1, 2017 at 2:07 PM, John McCall  wrote:
>>
>>> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin 
>>> wrote:
>>>
 So you believe that you can index into an object randomly by pointer
>> arithmetic and pull out a different field?
>>
>
> For starters, this is  illegal because you don't know where the
> padding bytes are.
> You cannot assume that X.a + 1 == X.b
> "Implementation alignment requirements might cause two adjacent
> members not to be allocated immediately after each other;"
>
> See 9.2.14
>

 IE at best you'd have to add

  &(struct X*(0))->b - &(struct X*(0))->a


 I don't believe this is legal either.

 Let me try to dredge up the long discussions we had about these cases
 on the gcc mailing lists.
 The conclusion was, i believe:

 "if you want to go marching through an object as a char *, that's fine,
 if you expect to be able to get at fields by playing pointer arithmetic
 games, from other fields, that is not)
 I feel like every couple years, a different compiler has the same
 aliasing discussions :)

>>>
>>> With the caveat that, in practice, compilers have to support both:
>>>   a) "going up a level" by subtracting an offsetof, which is clearly
>>> officially intended and not otherwise supported,
>>>
>>
>> AFAIK, Vtable accesses were supported by doing this, but pretty much
>> nothing else.
>>
>
> and to be clear, i mean given:
>
> struct a
> {
> int a;
>  struct b bstruct;
> };
>
> given a pointer to bstruct, subtracting sizeof(int)  is not going to give
> you a pointer to a struct a.
>

If sizeof(int) happens to equal offsetof(struct a, bstruct), it sure should
(if you're doing the pointer arithmetic on an appropriate type, of course).

It was allowed to work for vtable accesses.
>

I would like to once again remind you that random mailing list
conversations you happened to be in but can't even remember from some
completely unnamed and possibly different context are neither authoritative
nor binding on us now. :)

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

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 3:09 PM, Daniel Berlin  wrote:

>
>
> On Mon, May 1, 2017 at 2:07 PM, John McCall  wrote:
>
>> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin 
>> wrote:
>>
>>> So you believe that you can index into an object randomly by pointer
> arithmetic and pull out a different field?
>

 For starters, this is  illegal because you don't know where the padding
 bytes are.
 You cannot assume that X.a + 1 == X.b
 "Implementation alignment requirements might cause two adjacent members
 not to be allocated immediately after each other;"

 See 9.2.14

>>>
>>> IE at best you'd have to add
>>>
>>>  &(struct X*(0))->b - &(struct X*(0))->a
>>>
>>>
>>> I don't believe this is legal either.
>>>
>>> Let me try to dredge up the long discussions we had about these cases on
>>> the gcc mailing lists.
>>> The conclusion was, i believe:
>>>
>>> "if you want to go marching through an object as a char *, that's fine,
>>> if you expect to be able to get at fields by playing pointer arithmetic
>>> games, from other fields, that is not)
>>> I feel like every couple years, a different compiler has the same
>>> aliasing discussions :)
>>>
>>
>> With the caveat that, in practice, compilers have to support both:
>>   a) "going up a level" by subtracting an offsetof, which is clearly
>> officially intended and not otherwise supported,
>>
>
> AFAIK, Vtable accesses were supported by doing this, but pretty much
> nothing else.
>

and to be clear, i mean given:

struct a
{
int a;
 struct b bstruct;
};

given a pointer to bstruct, subtracting sizeof(int)  is not going to give
you a pointer to a struct a.

It was allowed to work for vtable accesses.

everyone else got told to turn off strict aliasing if you wanted it to
work, and they did.

But again, i'll go thread spleunking
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r301847 - New file missed from r301846.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon May  1 17:11:08 2017
New Revision: 301847

URL: http://llvm.org/viewvc/llvm-project?rev=301847&view=rev
Log:
New file missed from r301846.

Added:
cfe/trunk/test/Modules/Inputs/diag_flags.h

Added: cfe/trunk/test/Modules/Inputs/diag_flags.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/diag_flags.h?rev=301847&view=auto
==
--- cfe/trunk/test/Modules/Inputs/diag_flags.h (added)
+++ cfe/trunk/test/Modules/Inputs/diag_flags.h Mon May  1 17:11:08 2017
@@ -0,0 +1 @@
+struct Padded { char x; int y; };


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

r301846 - Fix initial diagnostic state setup for an explicit module with no diagnostic pragmas.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon May  1 17:10:47 2017
New Revision: 301846

URL: http://llvm.org/viewvc/llvm-project?rev=301846&view=rev
Log:
Fix initial diagnostic state setup for an explicit module with no diagnostic 
pragmas.

If a file has no diagnostic pragmas, we build its diagnostic state lazily, but
in this case we never set up the root state to be the diagnostic state in which
the module was originally built, so the diagnostic flags for files in the
module with no diagnostic pragmas were incorrectly based on the user of the
module rather than the diagnostic state when the module was built.

Added:
cfe/trunk/test/Modules/diag-flags.cpp
Modified:
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/test/Modules/Inputs/module.map

Modified: cfe/trunk/lib/Serialization/ASTReader.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Serialization/ASTReader.cpp?rev=301846&r1=301845&r2=301846&view=diff
==
--- cfe/trunk/lib/Serialization/ASTReader.cpp (original)
+++ cfe/trunk/lib/Serialization/ASTReader.cpp Mon May  1 17:10:47 2017
@@ -3765,6 +3765,13 @@ ASTReader::ASTReadResult ASTReader::Read
   SourceMgr.getLoadedSLocEntryByID(Index);
 }
 
+// Map the original source file ID into the ID space of the current
+// compilation.
+if (F.OriginalSourceFileID.isValid()) {
+  F.OriginalSourceFileID = FileID::get(
+  F.SLocEntryBaseID + F.OriginalSourceFileID.getOpaqueValue() - 1);
+}
+
 // Preload all the pending interesting identifiers by marking them out of
 // date.
 for (auto Offset : F.PreloadIdentifierOffsets) {
@@ -3873,10 +3880,6 @@ ASTReader::ASTReadResult ASTReader::Read
 
   ModuleFile &PrimaryModule = ModuleMgr.getPrimaryModule();
   if (PrimaryModule.OriginalSourceFileID.isValid()) {
-PrimaryModule.OriginalSourceFileID
-  = FileID::get(PrimaryModule.SLocEntryBaseID
-+ PrimaryModule.OriginalSourceFileID.getOpaqueValue() - 1);
-
 // If this AST file is a precompiled preamble, then set the
 // preamble file ID of the source manager to the file source file
 // from which the preamble was built.
@@ -5575,6 +5578,13 @@ void ASTReader::ReadPragmaDiagnosticMapp
   FirstState = ReadDiagState(
   F.isModule() ? DiagState() : *Diag.DiagStatesByLoc.CurDiagState,
   SourceLocation(), F.isModule());
+
+  // For an explicit module, set up the root buffer of the module to start
+  // with the initial diagnostic state of the module itself, to cover files
+  // that contain no explicit transitions.
+  if (F.isModule())
+Diag.DiagStatesByLoc.Files[F.OriginalSourceFileID]
+.StateTransitions.push_back({FirstState, 0});
 }
 
 // Read the state transitions.

Modified: cfe/trunk/test/Modules/Inputs/module.map
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/Inputs/module.map?rev=301846&r1=301845&r2=301846&view=diff
==
--- cfe/trunk/test/Modules/Inputs/module.map (original)
+++ cfe/trunk/test/Modules/Inputs/module.map Mon May  1 17:10:47 2017
@@ -261,6 +261,10 @@ module config {
   config_macros [exhaustive] WANT_FOO, WANT_BAR
 }
 
+module diag_flags {
+  header "diag_flags.h"
+}
+
 module diag_pragma {
   header "diag_pragma.h"
 }

Added: cfe/trunk/test/Modules/diag-flags.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/diag-flags.cpp?rev=301846&view=auto
==
--- cfe/trunk/test/Modules/diag-flags.cpp (added)
+++ cfe/trunk/test/Modules/diag-flags.cpp Mon May  1 17:10:47 2017
@@ -0,0 +1,22 @@
+// RUN: rm -rf %t
+//
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -emit-module 
-fmodules-cache-path=%t -fmodule-name=diag_flags -x c++ %S/Inputs/module.map 
-fmodules-ts
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify 
-fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify 
-fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts -DIMPLICIT_FLAG 
-Werror=padded
+//
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -emit-module 
-fmodule-name=diag_flags -x c++ %S/Inputs/module.map -fmodules-ts -o 
%t/explicit.pcm -Werror=string-plus-int -Wpadded
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify 
-fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts -DEXPLICIT_FLAG 
-fmodule-file=%t/explicit.pcm
+// RUN: %clang_cc1 -fmodules -fimplicit-module-maps -verify 
-fmodules-cache-path=%t -I %S/Inputs %s -fmodules-ts -DEXPLICIT_FLAG 
-fmodule-file=%t/explicit.pcm -Werror=padded
+
+import diag_flags;
+
+// Diagnostic flags from the module user make no difference to diagnostics
+// emitted within the module when using an explicitly-loaded module.
+#ifdef IMPLICIT_FLAG
+// expected-error@diag_flags.h:14 {{padding struct}}
+#elif defined(EXPLIC

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 2:07 PM, John McCall  wrote:

> On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin  wrote:
>
>> So you believe that you can index into an object randomly by pointer
 arithmetic and pull out a different field?

>>>
>>> For starters, this is  illegal because you don't know where the padding
>>> bytes are.
>>> You cannot assume that X.a + 1 == X.b
>>> "Implementation alignment requirements might cause two adjacent members
>>> not to be allocated immediately after each other;"
>>>
>>> See 9.2.14
>>>
>>
>> IE at best you'd have to add
>>
>>  &(struct X*(0))->b - &(struct X*(0))->a
>>
>>
>> I don't believe this is legal either.
>>
>> Let me try to dredge up the long discussions we had about these cases on
>> the gcc mailing lists.
>> The conclusion was, i believe:
>>
>> "if you want to go marching through an object as a char *, that's fine,
>> if you expect to be able to get at fields by playing pointer arithmetic
>> games, from other fields, that is not)
>> I feel like every couple years, a different compiler has the same
>> aliasing discussions :)
>>
>
> With the caveat that, in practice, compilers have to support both:
>   a) "going up a level" by subtracting an offsetof, which is clearly
> officially intended and not otherwise supported,
>

AFAIK, Vtable accesses were supported by doing this, but pretty much
nothing else.



> and
>   b) treating a final or flexible array member, possibly at depth > 1, as
> contiguous with a trailing array, because this is an extremely common
> extension and artificial idiom.
>

Yes, anything at the end was treated as magically special.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

r301840 - Put back REQUIRES: system-darwin to fix asan bot.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon May  1 16:49:54 2017
New Revision: 301840

URL: http://llvm.org/viewvc/llvm-project?rev=301840&view=rev
Log:
Put back REQUIRES: system-darwin to fix asan bot.

These tests do not appear to be Darwin-specific, and this REQUIRES: appears to
be hiding a real bug; this change is just restoring the prior state to get the
buildbots happy again while we investigate. (The system-darwin requirement is
covered by PR32851.)

Modified:
cfe/trunk/test/Modules/crash-vfs-headermaps.m
cfe/trunk/test/Modules/crash-vfs-include-pch.m
cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m
cfe/trunk/test/Modules/crash-vfs-relative-incdir.m
cfe/trunk/test/Modules/crash-vfs-run-reproducer.m

Modified: cfe/trunk/test/Modules/crash-vfs-headermaps.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-headermaps.m?rev=301840&r1=301839&r2=301840&view=diff
==
--- cfe/trunk/test/Modules/crash-vfs-headermaps.m (original)
+++ cfe/trunk/test/Modules/crash-vfs-headermaps.m Mon May  1 16:49:54 2017
@@ -1,4 +1,4 @@
-// REQUIRES: crash-recovery, shell
+// REQUIRES: crash-recovery, shell, system-darwin
 
 // This uses a headermap with this entry:
 //   Foo.h -> Foo/Foo.h

Modified: cfe/trunk/test/Modules/crash-vfs-include-pch.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-include-pch.m?rev=301840&r1=301839&r2=301840&view=diff
==
--- cfe/trunk/test/Modules/crash-vfs-include-pch.m (original)
+++ cfe/trunk/test/Modules/crash-vfs-include-pch.m Mon May  1 16:49:54 2017
@@ -1,4 +1,4 @@
-// REQUIRES: crash-recovery, shell
+// REQUIRES: crash-recovery, shell, system-darwin
 //
 // RUN: rm -rf %t
 // RUN: mkdir -p %t/m %t/out

Modified: cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m?rev=301840&r1=301839&r2=301840&view=diff
==
--- cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m (original)
+++ cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m Mon May  1 16:49:54 2017
@@ -1,4 +1,4 @@
-// REQUIRES: crash-recovery, shell
+// REQUIRES: crash-recovery, shell, system-darwin
 
 // RUN: rm -rf %t
 // RUN: mkdir -p %t/m

Modified: cfe/trunk/test/Modules/crash-vfs-relative-incdir.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-relative-incdir.m?rev=301840&r1=301839&r2=301840&view=diff
==
--- cfe/trunk/test/Modules/crash-vfs-relative-incdir.m (original)
+++ cfe/trunk/test/Modules/crash-vfs-relative-incdir.m Mon May  1 16:49:54 2017
@@ -1,4 +1,4 @@
-// REQUIRES: crash-recovery, shell
+// REQUIRES: crash-recovery, shell, system-darwin
 
 // RUN: rm -rf %t
 // RUN: mkdir -p %t/m

Modified: cfe/trunk/test/Modules/crash-vfs-run-reproducer.m
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-run-reproducer.m?rev=301840&r1=301839&r2=301840&view=diff
==
--- cfe/trunk/test/Modules/crash-vfs-run-reproducer.m (original)
+++ cfe/trunk/test/Modules/crash-vfs-run-reproducer.m Mon May  1 16:49:54 2017
@@ -1,4 +1,4 @@
-// REQUIRES: crash-recovery, shell
+// REQUIRES: crash-recovery, shell, system-darwin
 
 // RUN: rm -rf %t
 // RUN: mkdir -p %t/i %t/m %t


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

[PATCH] D32332: Add support for transparent overloadable functions in clang

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a reviewer: rsmith.
aaron.ballman added a comment.

I'm adding Richard to the review because he may have opinions on this 
functionality.

Is there a reason we want the second spelling instead of making the current 
spelling behave in the manner you describe? While the change is fairly 
fundamental, I don't know that it would break code either (but I could be 
wrong). I think that forcing the user to choice which spelling of 
"overloadable" they want to use is not very user friendly.




Comment at: include/clang/Basic/Attr.td:1416
 def Overloadable : Attr {
-  let Spellings = [GNU<"overloadable">];
+  let Spellings = [GNU<"overloadable">, GNU<"transparently_overloadable">];
   let Subjects = SubjectList<[Function], ErrorDiag>;

I'm not too keen on the name, especially since there's already a 
"transparent_union" attribute, where the "transparent" means something slightly 
different than it does here. However, my attempts to dream up a better name are 
coming up short...



Comment at: include/clang/Basic/DiagnosticSemaKinds.td:3259
   "'overloadable' function %0 must have a prototype">;
+def err_attribute_overloadable_too_many_transparent_overloads : Error<
+  "only one 'overloadable' overload may be transparent">;

Why should this be an error instead of simply an ignored attribute?



Comment at: test/Sema/overloadable.c:189
+  void to_foo5(int) __attribute__((overloadable)); // expected-note {{previous 
overload}}
+  void to_foo5(int) __attribute__((transparently_overloadable)); // 
expected-error{{mismatched transparency}}
+

Why should this be a mismatch? Attributes can usually be added to 
redeclarations without an issue, and it's not unheard of for subsequent 
redeclarations to gain additional attributes. It seems like the behavior the 
user would expect from this is for the `transparently_overloadable` attribute 
to "win" and simply replaces, or silently augments, the `overloadable` 
attribute.


https://reviews.llvm.org/D32332



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

[PATCH] D32210: [Sema][ObjC] Add support for attribute "noescape"

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman added a comment.

The attribute is not used anywhere; the initial utility should be part of the 
patch introducing the attribute, unless that utility makes the patch very large.




Comment at: lib/Sema/SemaDeclAttr.cpp:1522-1523
+  QualType T = cast(D)->getType();
+  if (!T->isAnyPointerType() && !T->isBlockPointerType() &&
+  !T->isReferenceType() && !T->isArrayType() && !T->isMemberPointerType()) 
{
+S.Diag(Attr.getLoc(), diag::warn_attribute_noescape_non_pointer) << T;

I don't think the type checking here is correct, at least according to the 
documentation. For instance, you don't appear to care whether the parameter is 
an array of block pointers vs an array of ints. Similar for the other composite 
types.



Comment at: test/SemaObjCXX/noescape.mm:8
+void invalidFunc(int __attribute__((noescape))); // expected-warning 
{{'noescape' attribute ignored on parameter of non-pointer type}}
+int __attribute__((noescape)) g; // expected-warning {{'noescape' attribute 
only applies to parameters}}

You should also have a test ensuring the attribute diagnoses when given an 
argument.


https://reviews.llvm.org/D32210



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

[PATCH] D32064: [asan] Disable ASan global-GC depending on the target and compiler flags

[Evgenii Stepanov via Phabricator via cfe-commits]

eugenis closed this revision.
eugenis added a comment.

r301225


Repository:
  rL LLVM

https://reviews.llvm.org/D32064



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

[PATCH] D32646: Fix a bug that -Wmissing-braces fires on system headers

[Nico Weber via Phabricator via cfe-commits]

thakis added inline comments.



Comment at: test/Sema/warn-missing-braces.c:21
+
+#endif

This looks shorter than the test I pasted on the bug. Does it get the corner 
case right that my patch on that bug didn't get right?


https://reviews.llvm.org/D32646



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

[PATCH] D32332: Add support for transparent overloadable functions in clang

[George Burgess IV via Phabricator via cfe-commits]

george.burgess.iv added a comment.

ping :)


https://reviews.llvm.org/D32332



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

[clang-tools-extra] r301836 - Reorder release notes, fix missing link and a grammar issue.

[Gabor Horvath via cfe-commits]

Author: xazax
Date: Mon May  1 16:02:38 2017
New Revision: 301836

URL: http://llvm.org/viewvc/llvm-project?rev=301836&view=rev
Log:
Reorder release notes, fix missing link and a grammar issue. 

Patch by Réka Nikolett Kovács!

Modified:
clang-tools-extra/trunk/docs/ReleaseNotes.rst

Modified: clang-tools-extra/trunk/docs/ReleaseNotes.rst
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/docs/ReleaseNotes.rst?rev=301836&r1=301835&r2=301836&view=diff
==
--- clang-tools-extra/trunk/docs/ReleaseNotes.rst (original)
+++ clang-tools-extra/trunk/docs/ReleaseNotes.rst Mon May  1 16:02:38 2017
@@ -66,20 +66,11 @@ Improvements to clang-tidy
   
`_
 check
 
   Allow custom memory management functions to be considered as well.
+  
+- New `misc-forwarding-reference-overload
+  
`_
 check
 
-- New `readability-misleading-indentation
-  
`_
 check
-
-  Finds misleading indentation where braces should be introduced or the code 
should be reformatted.
-
-- Added `ParameterThreshold` to `readability-function-size`.
-
-  Finds functions that have more then `ParameterThreshold` parameters and 
emits a warning.
-
-- New `hicpp` module
-
-  Adds checks that implement the `High Integrity C++ Coding Standard 
`_ and other safety
-  standards. Many checks are aliased to other modules.
+  Finds perfect forwarding constructors that can unintentionally hide copy or 
move constructors.
 
 - New `modernize-replace-random-shuffle
   
`_
 check
@@ -92,25 +83,35 @@ Improvements to clang-tidy
   Finds and replaces explicit calls to the constructor in a return statement by
   a braced initializer list so that the return type is not needlessly repeated.
   
-- New `misc-forwarding-reference-overload
-  
`_
 check
-
-  Finds perfect forwarding constructors that can unintentionally hide copy or 
move constructors.
+- Improved `modernize-use-emplace
+  `_ 
check
 
-- Support clang-formatting of the code around applied fixes (``-format-style``
-  command-line option).
+  Removes unnecessary std::make_pair calls in push_back(std::make_pair(a, b)) 
calls and turns them
+  into emplace_back(a, b).
 
 - New `performance-inefficient-vector-operation
   
`_
 check
 
   Finds possible inefficient vector operations in for loops that may cause
   unnecessary memory reallocations.
+  
+- Added `ParameterThreshold` to `readability-function-size
+  
`_
 check
 
-- Improved `modernize-use-emplace
-  `_ 
check
+  Finds functions that have more than `ParameterThreshold` parameters and 
emits a warning.
 
-  Removes unnecessary std::make_pair calls in push_back(std::make_pair(a, b)) 
calls and turns them
-  into emplace_back(a, b).
+- New `readability-misleading-indentation
+  
`_
 check
+
+  Finds misleading indentation where braces should be introduced or the code 
should be reformatted.
+  
+- Support clang-formatting of the code around applied fixes (``-format-style``
+  command-line option).
+  
+- New `hicpp` module
+
+  Adds checks that implement the `High Integrity C++ Coding Standard 
`_ and other safety
+  standards. Many checks are aliased to other modules.
 
 Improvements to include-fixer
 -


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

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[John McCall via cfe-commits]

On Mon, May 1, 2017 at 3:31 PM, Daniel Berlin  wrote:

> So you believe that you can index into an object randomly by pointer
>>> arithmetic and pull out a different field?
>>>
>>
>> For starters, this is  illegal because you don't know where the padding
>> bytes are.
>> You cannot assume that X.a + 1 == X.b
>> "Implementation alignment requirements might cause two adjacent members
>> not to be allocated immediately after each other;"
>>
>> See 9.2.14
>>
>
> IE at best you'd have to add
>
>  &(struct X*(0))->b - &(struct X*(0))->a
>
>
> I don't believe this is legal either.
>
> Let me try to dredge up the long discussions we had about these cases on
> the gcc mailing lists.
> The conclusion was, i believe:
>
> "if you want to go marching through an object as a char *, that's fine, if
> you expect to be able to get at fields by playing pointer arithmetic games,
> from other fields, that is not)
> I feel like every couple years, a different compiler has the same aliasing
> discussions :)
>

With the caveat that, in practice, compilers have to support both:
  a) "going up a level" by subtracting an offsetof, which is clearly
officially intended and not otherwise supported, and
  b) treating a final or flexible array member, possibly at depth > 1, as
contiguous with a trailing array, because this is an extremely common
extension and artificial idiom.

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

r301832 - Object: Remove ModuleSummaryIndexObjectFile class.

[Peter Collingbourne via cfe-commits]

Author: pcc
Date: Mon May  1 15:42:32 2017
New Revision: 301832

URL: http://llvm.org/viewvc/llvm-project?rev=301832&view=rev
Log:
Object: Remove ModuleSummaryIndexObjectFile class.

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

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

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=301832&r1=301831&r2=301832&view=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon May  1 15:42:32 2017
@@ -35,7 +35,6 @@
 #include "llvm/LTO/LTOBackend.h"
 #include "llvm/MC/MCAsmInfo.h"
 #include "llvm/MC/SubtargetFeature.h"
-#include "llvm/Object/ModuleSummaryIndexObjectFile.h"
 #include "llvm/Passes/PassBuilder.h"
 #include "llvm/Support/CommandLine.h"
 #include "llvm/Support/MemoryBuffer.h"


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

Fwd: Missing comma diagnostics patch

[Zaid Alkhishman via cfe-commits]

FYI:

Seems like my confirmation string was expired.

-- Forwarded message --
From: Zaid Alkhishman 
Date: Sat, Apr 29, 2017 at 11:44 PM
Subject: Missing comma diagnostics patch
To: cfe-commits@lists.llvm.org


Hello,

This patch adds missing comma diagnostics to initializer lists.

I'm attaching
the .diff (git),
an input .c
and the compilation output .out

Let me know if there are any required changes.

Regards,

Zaid

zaid.al.khish...@gmail.com

(Note, I tried subscribing to cfe-commits but it said the subscription has
to be confirmed first, so I'm not even sure if this email is gonna go
through, but if it does for now I won't be getting any replies I suppose :/)
diff --git include/clang/Basic/DiagnosticParseKinds.td 
include/clang/Basic/DiagnosticParseKinds.td
index f04ed8ed4c..ef913ce947 100644
--- include/clang/Basic/DiagnosticParseKinds.td
+++ include/clang/Basic/DiagnosticParseKinds.td
@@ -164,6 +164,7 @@ def err_function_declared_typedef : Error<
 def err_at_defs_cxx : Error<"@defs is not supported in Objective-C++">;
 def err_at_in_class : Error<"unexpected '@' in member specification">;
 def err_unexpected_semi : Error<"unexpected ';' before %0">;
+def err_expected_comma : Error<"expected ',' before initializer">;
 
 def err_expected_fn_body : Error<
   "expected function body after function declarator">;
diff --git include/clang/Parse/RAIIObjectsForParser.h 
include/clang/Parse/RAIIObjectsForParser.h
index 0422b038da..938df69b95 100644
--- include/clang/Parse/RAIIObjectsForParser.h
+++ include/clang/Parse/RAIIObjectsForParser.h
@@ -440,6 +440,13 @@ namespace clang {
   
   return diagnoseMissingClose();
 }
+
+bool willClose(){
+  if (P.Tok.is(Close))
+return false;
+  return true;
+}
+
 void skipToEnd();
   };
 
diff --git lib/Parse/ParseInit.cpp lib/Parse/ParseInit.cpp
index f48d01e0f6..2454162b2e 100644
--- lib/Parse/ParseInit.cpp
+++ lib/Parse/ParseInit.cpp
@@ -409,6 +409,8 @@ ExprResult Parser::ParseBraceInitializer() {
   Actions, EnterExpressionEvaluationContext::InitList);
 
   bool InitExprsOk = true;
+  bool maybeMissingComma = false;
+  Token startOfNextIni;
 
   while (1) {
 // Handle Microsoft __if_exists/if_not_exists if necessary.
@@ -427,6 +429,8 @@ ExprResult Parser::ParseBraceInitializer() {
 // If we know that this cannot be a designation, just parse the nested
 // initializer directly.
 ExprResult SubElt;
+startOfNextIni = Tok;
+
 if (MayBeDesignationStart())
   SubElt = ParseInitializerWithPotentialDesignator();
 else
@@ -457,8 +461,24 @@ ExprResult Parser::ParseBraceInitializer() {
   }
 }
 
-// If we don't have a comma continued list, we're done.
-if (Tok.isNot(tok::comma)) break;
+if(maybeMissingComma){
+  //Here we would have checked if InitExprsOk is true,
+  //but it's implied to be ok because of the previous break
+  //Now we know the compilee  very likely forgot the comma
+  Diag(startOfNextIni.getLocation(), diag::err_expected_comma)
+   << 
FixItHint::CreateInsertion(startOfNextIni.getLocation().getLocWithOffset(-1), 
",");
+  maybeMissingComma = false;
+}
+
+// If we don't have a comma continued list, we're done (maybe).
+if (Tok.isNot(tok::comma)){
+  if(!T.willClose()){
+//This is a ok list, no missing commas.
+break;
+  }
+  maybeMissingComma = true;
+  continue;
+}
 
 // TODO: save comma locations if some client cares.
 ConsumeToken();


missingCommasDiag.in
Description: Binary data


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

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via cfe-commits]

On 05/01/2017 02:31 PM, Daniel Berlin wrote:





So you believe that you can index into an object randomly by
pointer arithmetic and pull out a different field?

For starters, this is  illegal because you don't know where the
padding bytes are.
You cannot assume that X.a + 1 == X.b
"Implementation alignment requirements might cause two adjacent
members not to be allocated immediately after each other;"

See 9.2.14


IE at best you'd have to add

 &(struct X*(0))->b - &(struct X*(0))->a


I don't think that helps because the structure offsets are an observable 
part of the model. The code could easily be:


if (offsetof(X, b) == sizeof(int)) {
  // thing we're talking about
} else {
  // something safer
}




I don't believe this is legal either.

Let me try to dredge up the long discussions we had about these cases 
on the gcc mailing lists.

The conclusion was, i believe:

"if you want to go marching through an object as a char *, that's 
fine, if you expect to be able to get at fields by playing pointer 
arithmetic games, from other fields, that is not)
I feel like every couple years, a different compiler has the same 
aliasing discussions :)


I'm sure that's true :-)

 -Hal

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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

r301825 - Silence unused variable warning. NFC.

[Benjamin Kramer via cfe-commits]

Author: d0k
Date: Mon May  1 15:00:23 2017
New Revision: 301825

URL: http://llvm.org/viewvc/llvm-project?rev=301825&view=rev
Log:
Silence unused variable warning. NFC.

Modified:
cfe/trunk/lib/AST/ExprConstant.cpp

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=301825&r1=301824&r2=301825&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Mon May  1 15:00:23 2017
@@ -3042,7 +3042,7 @@ static CompleteObject findCompleteObject
 if (Info.Ctx.getAsIncompleteArrayType(BaseType)) {
   QualType MostRecentType =
  cast(D->getMostRecentDecl())->getType();
-  if (auto CAT = Info.Ctx.getAsConstantArrayType(MostRecentType))
+  if (Info.Ctx.getAsConstantArrayType(MostRecentType))
 BaseType = MostRecentType;
 }
   } else {


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

Re: r301732 - Remove some apparently-unnecessary 'REQUIRES: system-darwin' from tests.

[Vitaly Buka via cfe-commits]

We should file a bug and disable the test. Red bots are inconvenient for
build cop.
I have not notice this on non-asan builds, but I didn't look.

On Mon, May 1, 2017 at 12:14 PM Richard Smith  wrote:

> Looks like this test has found a bug in the compiler. I've not repro'd it
> yet but my guess is that we're hitting an asan error while attempting to
> build the preprocessed source. We can temporarily disable this test to get
> the bot green again if you like. Have you noticed it failing for non-asan'd
> builds of clang?
>
> On 1 May 2017 at 10:54, Vitaly Buka  wrote:
>
>>
>> crash-vfs-ivfsoverlay.m does not work
>>
>>
>> http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/1322/steps/check-clang%20asan/logs/stdio
>>
>>
>> On Fri, Apr 28, 2017 at 6:51 PM Richard Smith via cfe-commits <
>> cfe-commits@lists.llvm.org> wrote:
>>
>>> Author: rsmith
>>> Date: Fri Apr 28 20:38:29 2017
>>> New Revision: 301732
>>>
>>> URL: http://llvm.org/viewvc/llvm-project?rev=301732&view=rev
>>> Log:
>>> Remove some apparently-unnecessary 'REQUIRES: system-darwin' from tests.
>>>
>>> Let's see if any buildbots actually have trouble with these. (They at
>>> least pass on Linux.)
>>>
>>> Modified:
>>> cfe/trunk/test/Modules/crash-vfs-headermaps.m
>>> cfe/trunk/test/Modules/crash-vfs-include-pch.m
>>> cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m
>>>
>>> Modified: cfe/trunk/test/Modules/crash-vfs-headermaps.m
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-headermaps.m?rev=301732&r1=301731&r2=301732&view=diff
>>>
>>> ==
>>> --- cfe/trunk/test/Modules/crash-vfs-headermaps.m (original)
>>> +++ cfe/trunk/test/Modules/crash-vfs-headermaps.m Fri Apr 28 20:38:29
>>> 2017
>>> @@ -1,4 +1,4 @@
>>> -// REQUIRES: crash-recovery, shell, system-darwin
>>> +// REQUIRES: crash-recovery, shell
>>>
>>>  // This uses a headermap with this entry:
>>>  //   Foo.h -> Foo/Foo.h
>>>
>>> Modified: cfe/trunk/test/Modules/crash-vfs-include-pch.m
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-include-pch.m?rev=301732&r1=301731&r2=301732&view=diff
>>>
>>> ==
>>> --- cfe/trunk/test/Modules/crash-vfs-include-pch.m (original)
>>> +++ cfe/trunk/test/Modules/crash-vfs-include-pch.m Fri Apr 28 20:38:29
>>> 2017
>>> @@ -1,4 +1,4 @@
>>> -// REQUIRES: crash-recovery, shell, system-darwin
>>> +// REQUIRES: crash-recovery, shell
>>>  //
>>>  // RUN: rm -rf %t
>>>  // RUN: mkdir -p %t/m %t/out
>>>
>>> Modified: cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m
>>> URL:
>>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m?rev=301732&r1=301731&r2=301732&view=diff
>>>
>>> ==
>>> --- cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m (original)
>>> +++ cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m Fri Apr 28 20:38:29
>>> 2017
>>> @@ -1,4 +1,4 @@
>>> -// REQUIRES: crash-recovery, shell, system-darwin
>>> +// REQUIRES: crash-recovery, shell
>>>
>>>  // RUN: rm -rf %t
>>>  // RUN: mkdir -p %t/m
>>>
>>>
>>> ___
>>> 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

r301824 - [sanitizer-coverage] add a deprecation note to coverage_direct=1

[Kostya Serebryany via cfe-commits]

Author: kcc
Date: Mon May  1 14:52:01 2017
New Revision: 301824

URL: http://llvm.org/viewvc/llvm-project?rev=301824&view=rev
Log:
[sanitizer-coverage] add a deprecation note to coverage_direct=1

Modified:
cfe/trunk/docs/SanitizerCoverage.rst

Modified: cfe/trunk/docs/SanitizerCoverage.rst
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/docs/SanitizerCoverage.rst?rev=301824&r1=301823&r2=301824&view=diff
==
--- cfe/trunk/docs/SanitizerCoverage.rst (original)
+++ cfe/trunk/docs/SanitizerCoverage.rst Mon May  1 14:52:01 2017
@@ -367,6 +367,8 @@ This can be changed with ``ASAN_OPTIONS=
 Sudden death
 
 
+*Deprecated, don't use*
+
 Normally, coverage data is collected in memory and saved to disk when the
 program exits (with an ``atexit()`` handler), when a SIGSEGV is caught, or when
 ``__sanitizer_cov_dump()`` is called.


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

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Krzysztof Parzyszek via cfe-commits]

On 5/1/2017 2:16 PM, Hal Finkel via cfe-commits wrote:


On 05/01/2017 12:49 PM, Daniel Berlin wrote:

On 04/21/2017 06:03 AM, Hal Finkel via Phabricator wrote:

...


   Our struct-path TBAA does the following:

  struct X { int a, b; };
  X x { 50, 100 };
  X *o = (X*) (((int*) &x) + 1);

  int a_is_b = o->a; // This is UB (or so we say)?



This is UB.
A good resource for this stuff is 
http://www.cl.cam.ac.uk/~pes20/cerberus/ 
 which has a long document 
where they exlpore all of these and what various compilers do, along 
with what the standard seems to say.


http://www.cl.cam.ac.uk/~pes20/cerberus/notes30-full.pdf is 172 pages, 
and so I may have missed it, but I don't see this case. Also, I'd really 
like to see where the standard says this is UB. I don't see it.




The last sentence of 8:


6.5.6 Additive operators


7 For the purposes of these operators, a pointer to an object that is 
not an element of an array behaves the same as a pointer to the first 
element of an array of length one with the type of the object as its 
element type.


8 When an expression that has integer type is added to or subtracted 
from a pointer, the result has the type of the pointer operand. If the 
pointer operand points to an element of an array object, and the array 
is large enough, the result points to an element offset from the 
original element such that the difference of the subscripts of the 
resulting and original array elements equals the integer expression. In 
other words, if the expression P points to the i-th element of an array 
object, the expressions (P)+N (equivalently, N+(P)) and (P)-N (where N 
has the value n) point to, respectively, the i+n-th and i−n-th elements 
of the array object, provided they exist. Moreover, if the expression P 
points to the last element of an array object, the expression (P)+1 
points one past the last element of the array object, and if the 
expression Q points one past the last element of an array object, the 
expression (Q)-1 points to the last element of the array object. If both 
the pointer operand and the result point to elements of the same array 
object, or one past the last element of the array object, the evaluation 
shall not produce an overflow; otherwise, the behavior is undefined. If 
the result points one past the last element of the array object, it 
shall not be used as the operand of a unary * operator that is evaluated.


-Krzysztof

--
Qualcomm Innovation Center, Inc. is a member of Code Aurora Forum, 
hosted by The Linux Foundation

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

[PATCH] D29654: [OpenMP] Integrate OpenMP target region cubin into host binary

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea added a comment.

@rnk any further thought on the changes to this patch? Thanks :)


Repository:
  rL LLVM

https://reviews.llvm.org/D29654



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

[PATCH] D29654: [OpenMP] Integrate OpenMP target region cubin into host binary

[Gheorghe-Teodor Bercea via Phabricator via cfe-commits]

gtbercea updated this revision to Diff 97331.
gtbercea added a comment.

Change output of unbundler to produce cubin files when using OpenMP to offload 
to NVIDIA GPUs.


Repository:
  rL LLVM

https://reviews.llvm.org/D29654

Files:
  lib/Driver/Driver.cpp
  lib/Driver/ToolChains/Clang.cpp
  lib/Driver/ToolChains/CommonArgs.cpp
  lib/Driver/ToolChains/CommonArgs.h
  lib/Driver/ToolChains/Cuda.cpp
  lib/Driver/ToolChains/Cuda.h
  lib/Driver/ToolChains/Gnu.cpp
  test/Driver/openmp-offload.c

Index: test/Driver/openmp-offload.c
===
--- test/Driver/openmp-offload.c
+++ test/Driver/openmp-offload.c
@@ -590,6 +590,28 @@
 
 /// ###
 
+/// Check cubin file generation and usage by nvlink
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -save-temps -no-canonical-prefixes %s 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-CUBIN %s
+
+// CHK-CUBIN: clang{{.*}}" "-o" "{{.*}}-openmp-nvptx64-nvidia-cuda.s"
+// CHK-CUBIN-NEXT: ptxas{{.*}}" "--output-file" "{{.*}}-openmp-nvptx64-nvidia-cuda.cubin" "{{.*}}-openmp-nvptx64-nvidia-cuda.s"
+// CHK-CUBIN-NEXT: nvlink" "-o" "{{.*}}-openmp-nvptx64-nvidia-cuda" {{.*}} "openmp-offload-openmp-nvptx64-nvidia-cuda.cubin"
+
+/// ###
+
+/// Check cubin file generation and usage by nvlink
+// RUN:   touch %t1.o
+// RUN:   touch %t2.o
+// RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -save-temps -no-canonical-prefixes %t1.o %t2.o 2>&1 \
+// RUN:   | FileCheck -check-prefix=CHK-TWOCUBIN %s
+
+// CHK-TWOCUBIN: clang-offload-bundler" "-type=o" "{{.*}}inputs={{.*}}tmp1.o" "-outputs={{.*}}.o,{{.*}}tmp1-openmp-nvptx64-nvidia-cuda.cubin" "-unbundle"
+// CHK-TWOCUBIN-NEXT: clang-offload-bundler" "-type=o" "{{.*}}inputs={{.*}}tmp2.o" "-outputs={{.*}}.o,{{.*}}tmp2-openmp-nvptx64-nvidia-cuda.cubin" "-unbundle"
+// CHK-TWOCUBIN-NEXT: nvlink" "-o" "{{.*}}-openmp-nvptx64-nvidia-cuda" {{.*}} "openmp-offload.c.tmp1-openmp-nvptx64-nvidia-cuda.cubin" "openmp-offload.c.tmp2-openmp-nvptx64-nvidia-cuda.cubin"
+
+/// ###
+
 /// Check PTXAS is passed -c flag when offloading to an NVIDIA device using OpenMP.
 // RUN:   %clang -### -fopenmp=libomp -fopenmp-targets=nvptx64-nvidia-cuda -save-temps -no-canonical-prefixes %s 2>&1 \
 // RUN:   | FileCheck -check-prefix=CHK-PTXAS-DEFAULT %s
Index: lib/Driver/ToolChains/Gnu.cpp
===
--- lib/Driver/ToolChains/Gnu.cpp
+++ lib/Driver/ToolChains/Gnu.cpp
@@ -203,131 +203,6 @@
   // The types are (hopefully) good enough.
 }
 
-/// Add OpenMP linker script arguments at the end of the argument list so that
-/// the fat binary is built by embedding each of the device images into the
-/// host. The linker script also defines a few symbols required by the code
-/// generation so that the images can be easily retrieved at runtime by the
-/// offloading library. This should be used only in tool chains that support
-/// linker scripts.
-static void AddOpenMPLinkerScript(const ToolChain &TC, Compilation &C,
-  const InputInfo &Output,
-  const InputInfoList &Inputs,
-  const ArgList &Args, ArgStringList &CmdArgs,
-  const JobAction &JA) {
-
-  // If this is not an OpenMP host toolchain, we don't need to do anything.
-  if (!JA.isHostOffloading(Action::OFK_OpenMP))
-return;
-
-  // Create temporary linker script. Keep it if save-temps is enabled.
-  const char *LKS;
-  SmallString<256> Name = llvm::sys::path::filename(Output.getFilename());
-  if (C.getDriver().isSaveTempsEnabled()) {
-llvm::sys::path::replace_extension(Name, "lk");
-LKS = C.getArgs().MakeArgString(Name.c_str());
-  } else {
-llvm::sys::path::replace_extension(Name, "");
-Name = C.getDriver().GetTemporaryPath(Name, "lk");
-LKS = C.addTempFile(C.getArgs().MakeArgString(Name.c_str()));
-  }
-
-  // Add linker script option to the command.
-  CmdArgs.push_back("-T");
-  CmdArgs.push_back(LKS);
-
-  // Create a buffer to write the contents of the linker script.
-  std::string LksBuffer;
-  llvm::raw_string_ostream LksStream(LksBuffer);
-
-  // Get the OpenMP offload tool chains so that we can extract the triple
-  // associated with each device input.
-  auto OpenMPToolChains = C.getOffloadToolChains();
-  assert(OpenMPToolChains.first != OpenMPToolChains.second &&
- "No OpenMP toolchains??");
-
-  // Track the input file name and device triple in order to build the script,
-  // inserting binaries in the designated sections.
-  SmallVector, 8> InputBinaryInfo;
-
-  // Add commands to embed target binaries. We ensure that each section and
-  // image is 16-byte aligned. This is

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

>
>
>>
>>
> So you believe that you can index into an object randomly by pointer
> arithmetic and pull out a different field?
>
> For starters, this is  illegal because you don't know where the padding
> bytes are.
> You cannot assume that X.a + 1 == X.b
> "Implementation alignment requirements might cause two adjacent members
> not to be allocated immediately after each other;"
>
> See 9.2.14
>

IE at best you'd have to add

 &(struct X*(0))->b - &(struct X*(0))->a


I don't believe this is legal either.

Let me try to dredge up the long discussions we had about these cases on
the gcc mailing lists.
The conclusion was, i believe:

"if you want to go marching through an object as a char *, that's fine, if
you expect to be able to get at fields by playing pointer arithmetic games,
from other fields, that is not)
I feel like every couple years, a different compiler has the same aliasing
discussions :)
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Mon, May 1, 2017 at 12:16 PM, Hal Finkel  wrote:

>
> On 05/01/2017 12:49 PM, Daniel Berlin wrote:
>
>
>
> On Fri, Apr 21, 2017 at 4:03 AM, Hal Finkel via Phabricator <
> revi...@reviews.llvm.org> wrote:
>
>> hfinkel added a comment.
>>
>> In https://reviews.llvm.org/D32199#732737, @rsmith wrote:
>>
>> > In https://reviews.llvm.org/D32199#732189, @hfinkel wrote:
>> >
>> > > In https://reviews.llvm.org/D32199#731472, @rsmith wrote:
>> > >
>> > > > 1. C's "effective type" rule allows writes to set the type pretty
>> much unconditionally, unless the storage is for a variable with a declared
>> type
>> > >
>> > >
>> > > To come back to this point: We don't really implement these rules
>> now, and it is not clear that we will. The problem here is that, if we take
>> the specification literally, then we can't use our current TBAA at all. The
>> problem is that if we have:
>> > >
>> > >   write x, !tbaa "int"
>> > >   read x, !tbaa "int"
>> > >   write x, !tbaa "float"
>> > >
>> > >
>> > > TBAA will currently tell us that the "float" write aliases with
>> neither the preceding read nor the preceding write.
>> >
>> >
>> > Right, C's TBAA rules do not (in general) permit a store to be
>> reordered before a memory operation of a different type, they only allow
>> loads to be moved before stores. (Put another way, they do not tell you
>> that pointers point to distinct memory locations, just that a stored value
>> cannot be observed by a load of a different type.) You get the more general
>> "distinct memory locations" result only for objects of a declared type.
>> >
>> > C++ is similar, except that (because object lifetimes do not currently
>> begin magically due to a store) you /can/ reorder stores past a memory
>> operation of a different type if you know no object's lifetime began in
>> between. (But currently we do not record all lifetime events in IR, so we
>> can't do that today. Also, we may be about to lose the property that you
>> can statically determine a small number of places that might start an
>> object lifetime.)
>> >
>> > > Also, a strict reading of C's access rules seems to rule out the
>> premise underlying our struct-path TBAA entirely. So long as I'm accessing
>> a value using a struct that has some member, including recursively, with
>> that type, then it's fine. The matching of the relative offsets is a
>> sufficient, but not necessary, condition for well-defined access. C++ has
>> essentially the same language (and, thus, potentially the same problem).
>> >
>> > I agree this rule is garbage, but it's not as permissive as I think
>> you're suggesting. The rule says that you can use an lvalue of struct type
>> to access memory of struct field type. In C this happens during struct
>> assignment, for instance. It does *not* permit using an lvalue of struct
>> field type to access unrelated fields of the same struct. So C appears to
>> allow this nonsense:
>> >
>> >   char *p = malloc(8);
>> >   *(int*)p = 0;
>> >   *(int*)(p + 4) = 0;
>> >   struct S {int n; float f;} s = *(struct S*)p; // use lvalue of type
>> `struct S` to access object of effective type `int`, to initialize a `float`
>> >
>> >
>> > but not this nonsense:
>> >
>> >   float q = ((struct S*)p)->f; // ub, cannot use lvalue of type `float`
>> to access object of effective type `int`
>> >
>> >
>> > ... which just means that we can't make much use of TBAA when emitting
>> struct copies in C.
>> >
>> > In C++, on the other hand, the rule is even more garbage, since there
>> is no way to perform a memory access with a glvalue of class type. (The
>> closest you get is that a defaulted union construction/assignment copies
>> the object representation, but that's expressed in terms of copying a
>> sequence of unsigned chars, and in any case those are member functions and
>> so already require an object of the correct type to exist.) See
>> wg21.link/cwg2051
>>
>>
>> Our struct-path TBAA does the following:
>>
>>   struct X { int a, b; };
>>   X x { 50, 100 };
>>   X *o = (X*) (((int*) &x) + 1);
>>
>>   int a_is_b = o->a; // This is UB (or so we say)?
>>
>
> This is UB.
> A good resource for this stuff is http://www.cl.cam.ac.uk/~pes20/cerberus/
> which has a long document where they exlpore all of these and what various
> compilers do, along with what the standard seems to say.
>
>
> http://www.cl.cam.ac.uk/~pes20/cerberus/notes30-full.pdf is 172 pages,
> and so I may have missed it, but I don't see this case.
>

Let me find it for you. it may only be in one of the other versions.


> Also, I'd really like to see where the standard says this is UB. I don't
> see it.
>
>
So you believe that you can index into an object randomly by pointer
arithmetic and pull out a different field?

For starters, this is  illegal because you don't know where the padding
bytes are.
You cannot assume that X.a + 1 == X.b
"Implementation alignment requirements might cause two adjacent members not
to be allocated immediately after each other;"

See 9.2.14
___

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via cfe-commits]

On 05/01/2017 12:49 PM, Daniel Berlin wrote:



On Fri, Apr 21, 2017 at 4:03 AM, Hal Finkel via Phabricator 
mailto:revi...@reviews.llvm.org>> wrote:


hfinkel added a comment.

In https://reviews.llvm.org/D32199#732737
, @rsmith wrote:

> In https://reviews.llvm.org/D32199#732189
, @hfinkel wrote:
>
> > In https://reviews.llvm.org/D32199#731472
, @rsmith wrote:
> >
> > > 1. C's "effective type" rule allows writes to set the type
pretty much unconditionally, unless the storage is for a variable
with a declared type
> >
> >
> > To come back to this point: We don't really implement these
rules now, and it is not clear that we will. The problem here is
that, if we take the specification literally, then we can't use
our current TBAA at all. The problem is that if we have:
> >
> >   write x, !tbaa "int"
> >   read x, !tbaa "int"
> >   write x, !tbaa "float"
> >
> >
> > TBAA will currently tell us that the "float" write aliases
with neither the preceding read nor the preceding write.
>
>
> Right, C's TBAA rules do not (in general) permit a store to be
reordered before a memory operation of a different type, they only
allow loads to be moved before stores. (Put another way, they do
not tell you that pointers point to distinct memory locations,
just that a stored value cannot be observed by a load of a
different type.) You get the more general "distinct memory
locations" result only for objects of a declared type.
>
> C++ is similar, except that (because object lifetimes do not
currently begin magically due to a store) you /can/ reorder stores
past a memory operation of a different type if you know no
object's lifetime began in between. (But currently we do not
record all lifetime events in IR, so we can't do that today. Also,
we may be about to lose the property that you can statically
determine a small number of places that might start an object
lifetime.)
>
> > Also, a strict reading of C's access rules seems to rule out
the premise underlying our struct-path TBAA entirely. So long as
I'm accessing a value using a struct that has some member,
including recursively, with that type, then it's fine. The
matching of the relative offsets is a sufficient, but not
necessary, condition for well-defined access. C++ has essentially
the same language (and, thus, potentially the same problem).
>
> I agree this rule is garbage, but it's not as permissive as I
think you're suggesting. The rule says that you can use an lvalue
of struct type to access memory of struct field type. In C this
happens during struct assignment, for instance. It does *not*
permit using an lvalue of struct field type to access unrelated
fields of the same struct. So C appears to allow this nonsense:
>
>   char *p = malloc(8);
>   *(int*)p = 0;
>   *(int*)(p + 4) = 0;
>   struct S {int n; float f;} s = *(struct S*)p; // use lvalue of
type `struct S` to access object of effective type `int`, to
initialize a `float`
>
>
> but not this nonsense:
>
>   float q = ((struct S*)p)->f; // ub, cannot use lvalue of type
`float` to access object of effective type `int`
>
>
> ... which just means that we can't make much use of TBAA when
emitting struct copies in C.
>
> In C++, on the other hand, the rule is even more garbage, since
there is no way to perform a memory access with a glvalue of class
type. (The closest you get is that a defaulted union
construction/assignment copies the object representation, but
that's expressed in terms of copying a sequence of unsigned chars,
and in any case those are member functions and so already require
an object of the correct type to exist.) See wg21.link/cwg2051


Our struct-path TBAA does the following:

  struct X { int a, b; };
  X x { 50, 100 };
  X *o = (X*) (((int*) &x) + 1);

  int a_is_b = o->a; // This is UB (or so we say)?


This is UB.
A good resource for this stuff is 
http://www.cl.cam.ac.uk/~pes20/cerberus/ 
 which has a long document 
where they exlpore all of these and what various compilers do, along 
with what the standard seems to say.


http://www.cl.cam.ac.uk/~pes20/cerberus/notes30-full.pdf is 172 pages, 
and so I may have missed it, but I don't see this case. Also, I'd really 
like to see where the standard says this is UB. I don't see it.


Thanks again,
Hal

--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://l

Re: r301732 - Remove some apparently-unnecessary 'REQUIRES: system-darwin' from tests.

[Richard Smith via cfe-commits]

Looks like this test has found a bug in the compiler. I've not repro'd it
yet but my guess is that we're hitting an asan error while attempting to
build the preprocessed source. We can temporarily disable this test to get
the bot green again if you like. Have you noticed it failing for non-asan'd
builds of clang?

On 1 May 2017 at 10:54, Vitaly Buka  wrote:

>
> crash-vfs-ivfsoverlay.m does not work
>
> http://lab.llvm.org:8011/builders/sanitizer-x86_64-
> linux-bootstrap/builds/1322/steps/check-clang%20asan/logs/stdio
>
>
> On Fri, Apr 28, 2017 at 6:51 PM Richard Smith via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: rsmith
>> Date: Fri Apr 28 20:38:29 2017
>> New Revision: 301732
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=301732&view=rev
>> Log:
>> Remove some apparently-unnecessary 'REQUIRES: system-darwin' from tests.
>>
>> Let's see if any buildbots actually have trouble with these. (They at
>> least pass on Linux.)
>>
>> Modified:
>> cfe/trunk/test/Modules/crash-vfs-headermaps.m
>> cfe/trunk/test/Modules/crash-vfs-include-pch.m
>> cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m
>>
>> Modified: cfe/trunk/test/Modules/crash-vfs-headermaps.m
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
>> Modules/crash-vfs-headermaps.m?rev=301732&r1=301731&r2=301732&view=diff
>> 
>> ==
>> --- cfe/trunk/test/Modules/crash-vfs-headermaps.m (original)
>> +++ cfe/trunk/test/Modules/crash-vfs-headermaps.m Fri Apr 28 20:38:29
>> 2017
>> @@ -1,4 +1,4 @@
>> -// REQUIRES: crash-recovery, shell, system-darwin
>> +// REQUIRES: crash-recovery, shell
>>
>>  // This uses a headermap with this entry:
>>  //   Foo.h -> Foo/Foo.h
>>
>> Modified: cfe/trunk/test/Modules/crash-vfs-include-pch.m
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
>> Modules/crash-vfs-include-pch.m?rev=301732&r1=301731&r2=301732&view=diff
>> 
>> ==
>> --- cfe/trunk/test/Modules/crash-vfs-include-pch.m (original)
>> +++ cfe/trunk/test/Modules/crash-vfs-include-pch.m Fri Apr 28 20:38:29
>> 2017
>> @@ -1,4 +1,4 @@
>> -// REQUIRES: crash-recovery, shell, system-darwin
>> +// REQUIRES: crash-recovery, shell
>>  //
>>  // RUN: rm -rf %t
>>  // RUN: mkdir -p %t/m %t/out
>>
>> Modified: cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/
>> Modules/crash-vfs-ivfsoverlay.m?rev=301732&r1=301731&r2=301732&view=diff
>> 
>> ==
>> --- cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m (original)
>> +++ cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m Fri Apr 28 20:38:29
>> 2017
>> @@ -1,4 +1,4 @@
>> -// REQUIRES: crash-recovery, shell, system-darwin
>> +// REQUIRES: crash-recovery, shell
>>
>>  // RUN: rm -rf %t
>>  // RUN: mkdir -p %t/m
>>
>>
>> ___
>> 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] D32372: Arrays of unknown bound in constant expressions

[Richard Smith via Phabricator via cfe-commits]

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

Committed as r301822.




Comment at: lib/AST/ExprConstant.cpp:1301
 void addUnsizedArray(EvalInfo &Info, QualType ElemTy) {
-  assert(Designator.Entries.empty() && getType(Base)->isPointerType());
-  assert(isBaseAnAllocSizeCall(Base) &&
- "Only alloc_size bases can have unsized arrays");
-  Designator.FirstEntryIsAnUnsizedArray = true;
   Designator.addUnsizedArrayUnchecked(ElemTy);
 }

rsmith wrote:
> We should call `checkSubobject` here, for cases like:
> 
> ```
> void f(int n) {
>   int arr[2][n];
>   constexpr int *p = &arr[2][0];
> }
> ```
> 
> ... which we should reject because `arr[2]` is a one-past-the-end lvalue, so 
> cannot be indexed (we reject this if `n` is instead a constant).
Turns out this case is already failing before we get here: forming `arr[2]` 
requires determining the size of the array element type `int[n]`, which fails.


https://reviews.llvm.org/D32372



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

r301822 - Improve handling of arrays of unknown bound in constant expressions.

[Richard Smith via cfe-commits]

Author: rsmith
Date: Mon May  1 13:49:04 2017
New Revision: 301822

URL: http://llvm.org/viewvc/llvm-project?rev=301822&view=rev
Log:
Improve handling of arrays of unknown bound in constant expressions.

Do not spuriously reject constexpr functions that access elements of an array
of unknown bound; this may later become valid once the bound is known. Permit
array-to-pointer decay on such arrays, but disallow pointer arithmetic (since
we do not know whether it will have defined behavior).

The standard is not clear on how this should work, but this seems to be a
decent answer.

Patch by Robert Haberlach!

Added:
cfe/trunk/test/SemaCXX/constexpr-array-unknown-bound.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
cfe/trunk/lib/AST/ExprConstant.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td?rev=301822&r1=301821&r2=301822&view=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticASTKinds.td Mon May  1 13:49:04 2017
@@ -154,12 +154,14 @@ def note_constexpr_baa_insufficient_alig
 def note_constexpr_baa_value_insufficient_alignment : Note<
   "value of the aligned pointer (%0) is not a multiple of the asserted %1 "
   "%plural{1:byte|:bytes}1">;
+def note_constexpr_array_unknown_bound_arithmetic : Note<
+  "cannot perform pointer arithmetic on pointer to array without constant 
bound">;
 
 def warn_integer_constant_overflow : Warning<
   "overflow in expression; result is %0 with type %1">,
   InGroup>;
 
-// This is a temporary diagnostic, and shall be removed once our 
+// This is a temporary diagnostic, and shall be removed once our
 // implementation is complete, and like the preceding constexpr notes belongs
 // in Sema.
 def note_unimplemented_constexpr_lambda_feature_ast : Note<

Modified: cfe/trunk/lib/AST/ExprConstant.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/ExprConstant.cpp?rev=301822&r1=301821&r2=301822&view=diff
==
--- cfe/trunk/lib/AST/ExprConstant.cpp (original)
+++ cfe/trunk/lib/AST/ExprConstant.cpp Mon May  1 13:49:04 2017
@@ -148,7 +148,8 @@ namespace {
   static unsigned
   findMostDerivedSubobject(ASTContext &Ctx, APValue::LValueBase Base,
ArrayRef Path,
-   uint64_t &ArraySize, QualType &Type, bool &IsArray) 
{
+   uint64_t &ArraySize, QualType &Type, bool &IsArray,
+   bool &IsUnsizedArray) {
 // This only accepts LValueBases from APValues, and APValues don't support
 // arrays that lack size info.
 assert(!isBaseAnAllocSizeCall(Base) &&
@@ -157,28 +158,34 @@ namespace {
 Type = getType(Base);
 
 for (unsigned I = 0, N = Path.size(); I != N; ++I) {
-  if (Type->isArrayType()) {
-const ConstantArrayType *CAT =
-cast(Ctx.getAsArrayType(Type));
-Type = CAT->getElementType();
-ArraySize = CAT->getSize().getZExtValue();
+  if (auto AT = Ctx.getAsArrayType(Type)) {
 MostDerivedLength = I + 1;
 IsArray = true;
+if (auto CAT = Ctx.getAsConstantArrayType(Type))
+  ArraySize = CAT->getSize().getZExtValue();
+else {
+  ArraySize = 0;
+  IsUnsizedArray = true;
+}
+Type = AT->getElementType();
   } else if (Type->isAnyComplexType()) {
 const ComplexType *CT = Type->castAs();
 Type = CT->getElementType();
 ArraySize = 2;
 MostDerivedLength = I + 1;
 IsArray = true;
+IsUnsizedArray = false;
   } else if (const FieldDecl *FD = getAsField(Path[I])) {
 Type = FD->getType();
 ArraySize = 0;
 MostDerivedLength = I + 1;
 IsArray = false;
+IsUnsizedArray = false;
   } else {
 // Path[I] describes a base class.
 ArraySize = 0;
 IsArray = false;
+IsUnsizedArray = false;
   }
 }
 return MostDerivedLength;
@@ -200,8 +207,9 @@ namespace {
 /// Is this a pointer one past the end of an object?
 unsigned IsOnePastTheEnd : 1;
 
-/// Indicator of whether the first entry is an unsized array.
-unsigned FirstEntryIsAnUnsizedArray : 1;
+/// Indicator of whether the most-derived object is an unsized array (e.g.
+/// of unknown bound).
+unsigned MostDerivedIsAnUnsizedArray : 1;
 
 /// Indicator of whether the most-derived object is an array element.
 unsigned MostDerivedIsArrayElement : 1;
@@ -231,25 +239,28 @@ namespace {
 
 explicit SubobjectDesignator(QualType T)
 : Invalid(false), IsOnePastTheEnd(false),
-  FirstEntryIsAnUnsizedArray(false), MostDerivedIsArrayElement(false),
+  MostDerivedIsAnUnsizedArray(false), 

[PATCH] D30837: [libcxx] Support for shared_ptr

[Erik Pilkington via Phabricator via cfe-commits]

erik.pilkington updated this revision to Diff 97313.
erik.pilkington added a comment.

Rebase n' ping!


https://reviews.llvm.org/D30837

Files:
  include/memory
  
test/libcxx/utilities/memory/util.smartptr/util.smartptr.shared/function_type_default_deleter.fail.cpp
  
test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared.pass.cpp

Index: test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared.pass.cpp
===
--- test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared.pass.cpp
+++ test/std/utilities/memory/util.smartptr/util.smartptr.shared/util.smartptr.shared.create/make_shared.pass.cpp
@@ -45,6 +45,13 @@
 virtual ~Foo() = default;
 };
 
+struct Result {};
+static Result theFunction() { return Result(); }
+static int resultDeletorCount;
+static void resultDeletor(Result (*pf)()) {
+  assert(pf == theFunction);
+  ++resultDeletorCount;
+}
 
 int main()
 {
@@ -65,7 +72,11 @@
 std::shared_ptr p2 = std::make_shared();
 assert(p2.get());
 }
-
+{ // https://bugs.llvm.org/show_bug.cgi?id=27566
+  std::shared_ptr x(&theFunction, &resultDeletor);
+  std::shared_ptr y(theFunction, resultDeletor);
+}
+assert(resultDeletorCount == 2);
 #if TEST_STD_VER >= 11
 nc = globalMemCounter.outstanding_new;
 {
Index: test/libcxx/utilities/memory/util.smartptr/util.smartptr.shared/function_type_default_deleter.fail.cpp
===
--- test/libcxx/utilities/memory/util.smartptr/util.smartptr.shared/function_type_default_deleter.fail.cpp
+++ test/libcxx/utilities/memory/util.smartptr/util.smartptr.shared/function_type_default_deleter.fail.cpp
@@ -0,0 +1,40 @@
+#include 
+
+template  struct Tag {};
+
+template 
+using SPtr = std::shared_ptr)>;
+
+template 
+using FnType = void(Tag);
+
+template 
+void TestFn(Tag) {}
+
+template 
+FnType* getFn() {
+  return &TestFn;
+}
+
+struct Deleter {
+  template 
+  void operator()(Tp) const {
+using RawT = typename std::remove_pointer::type;
+static_assert(std::is_function::value ||
+  std::is_null_pointer::value, "");
+  }
+};
+
+int main() {
+  {
+SPtr<0> s; // OK
+SPtr<1> s1(nullptr); // OK
+SPtr<2> s2(getFn<2>(), Deleter{}); // OK
+SPtr<3> s3(nullptr, Deleter{}); // OK
+  }
+  // expected-error@memory:* 2 {{static_assert failed "default_delete cannot be instantiated for function types"}}
+  {
+SPtr<4> s4(getFn<4>()); // expected-note {{requested here}}
+SPtr<5> s5(getFn<5>(), std::default_delete>{}); // expected-note {{requested here}}
+  }
+}
Index: include/memory
===
--- include/memory
+++ include/memory
@@ -2251,6 +2251,8 @@
 
 template 
 struct _LIBCPP_TEMPLATE_VIS default_delete {
+static_assert(!is_function<_Tp>::value,
+  "default_delete cannot be instantiated for function types");
 #ifndef _LIBCPP_CXX03_LANG
   _LIBCPP_INLINE_VISIBILITY constexpr default_delete() noexcept = default;
 #else
@@ -3653,6 +3655,17 @@
 __a.deallocate(_PTraits::pointer_to(*this), 1);
 }
 
+struct __shared_ptr_dummy_rebind_allocator_type;
+template <>
+class _LIBCPP_TEMPLATE_VIS allocator<__shared_ptr_dummy_rebind_allocator_type>
+{
+template 
+struct rebind
+{
+typedef allocator<_Other> other;
+};
+};
+
 template class _LIBCPP_TEMPLATE_VIS enable_shared_from_this;
 
 template
@@ -3921,6 +3934,17 @@
 #endif  // _LIBCPP_HAS_NO_VARIADICS
 
 private:
+template ::value>
+struct __shared_ptr_default_allocator
+{
+typedef allocator<_Yp> type;
+};
+
+template 
+struct __shared_ptr_default_allocator<_Yp, true>
+{
+typedef allocator<__shared_ptr_dummy_rebind_allocator_type> type;
+};
 
 template 
 _LIBCPP_INLINE_VISIBILITY
@@ -3936,8 +3960,7 @@
 }
 }
 
-_LIBCPP_INLINE_VISIBILITY
-void __enable_weak_this(const volatile void*, const volatile void*) _NOEXCEPT {}
+_LIBCPP_INLINE_VISIBILITY void __enable_weak_this(...) _NOEXCEPT {}
 
 template  friend class _LIBCPP_TEMPLATE_VIS shared_ptr;
 template  friend class _LIBCPP_TEMPLATE_VIS weak_ptr;
@@ -3968,8 +3991,9 @@
 : __ptr_(__p)
 {
 unique_ptr<_Yp> __hold(__p);
-typedef __shared_ptr_pointer<_Yp*, default_delete<_Yp>, allocator<_Yp> > _CntrlBlk;
-__cntrl_ = new _CntrlBlk(__p, default_delete<_Yp>(), allocator<_Yp>());
+typedef typename __shared_ptr_default_allocator<_Yp>::type _AllocT;
+typedef __shared_ptr_pointer<_Yp*, default_delete<_Yp>, _AllocT > _CntrlBlk;
+__cntrl_ = new _CntrlBlk(__p, default_delete<_Yp>(), _AllocT());
 __hold.release();
 __enable_weak_this(__p, __p);
 }
@@ -3984,8 +4008,9 @@
 try
 {
 #endif  // _LIBCPP_NO_EXCEPTIONS
-  

Re: r301732 - Remove some apparently-unnecessary 'REQUIRES: system-darwin' from tests.

[Vitaly Buka via cfe-commits]

crash-vfs-ivfsoverlay.m does not work

http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-bootstrap/builds/1322/steps/check-clang%20asan/logs/stdio

On Fri, Apr 28, 2017 at 6:51 PM Richard Smith via cfe-commits <
cfe-commits@lists.llvm.org> wrote:

> Author: rsmith
> Date: Fri Apr 28 20:38:29 2017
> New Revision: 301732
>
> URL: http://llvm.org/viewvc/llvm-project?rev=301732&view=rev
> Log:
> Remove some apparently-unnecessary 'REQUIRES: system-darwin' from tests.
>
> Let's see if any buildbots actually have trouble with these. (They at
> least pass on Linux.)
>
> Modified:
> cfe/trunk/test/Modules/crash-vfs-headermaps.m
> cfe/trunk/test/Modules/crash-vfs-include-pch.m
> cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m
>
> Modified: cfe/trunk/test/Modules/crash-vfs-headermaps.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-headermaps.m?rev=301732&r1=301731&r2=301732&view=diff
>
> ==
> --- cfe/trunk/test/Modules/crash-vfs-headermaps.m (original)
> +++ cfe/trunk/test/Modules/crash-vfs-headermaps.m Fri Apr 28 20:38:29 2017
> @@ -1,4 +1,4 @@
> -// REQUIRES: crash-recovery, shell, system-darwin
> +// REQUIRES: crash-recovery, shell
>
>  // This uses a headermap with this entry:
>  //   Foo.h -> Foo/Foo.h
>
> Modified: cfe/trunk/test/Modules/crash-vfs-include-pch.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-include-pch.m?rev=301732&r1=301731&r2=301732&view=diff
>
> ==
> --- cfe/trunk/test/Modules/crash-vfs-include-pch.m (original)
> +++ cfe/trunk/test/Modules/crash-vfs-include-pch.m Fri Apr 28 20:38:29 2017
> @@ -1,4 +1,4 @@
> -// REQUIRES: crash-recovery, shell, system-darwin
> +// REQUIRES: crash-recovery, shell
>  //
>  // RUN: rm -rf %t
>  // RUN: mkdir -p %t/m %t/out
>
> Modified: cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m
> URL:
> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m?rev=301732&r1=301731&r2=301732&view=diff
>
> ==
> --- cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m (original)
> +++ cfe/trunk/test/Modules/crash-vfs-ivfsoverlay.m Fri Apr 28 20:38:29 2017
> @@ -1,4 +1,4 @@
> -// REQUIRES: crash-recovery, shell, system-darwin
> +// REQUIRES: crash-recovery, shell
>
>  // RUN: rm -rf %t
>  // RUN: mkdir -p %t/m
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Daniel Berlin via cfe-commits]

On Fri, Apr 21, 2017 at 4:03 AM, Hal Finkel via Phabricator <
revi...@reviews.llvm.org> wrote:

> hfinkel added a comment.
>
> In https://reviews.llvm.org/D32199#732737, @rsmith wrote:
>
> > In https://reviews.llvm.org/D32199#732189, @hfinkel wrote:
> >
> > > In https://reviews.llvm.org/D32199#731472, @rsmith wrote:
> > >
> > > > 1. C's "effective type" rule allows writes to set the type pretty
> much unconditionally, unless the storage is for a variable with a declared
> type
> > >
> > >
> > > To come back to this point: We don't really implement these rules now,
> and it is not clear that we will. The problem here is that, if we take the
> specification literally, then we can't use our current TBAA at all. The
> problem is that if we have:
> > >
> > >   write x, !tbaa "int"
> > >   read x, !tbaa "int"
> > >   write x, !tbaa "float"
> > >
> > >
> > > TBAA will currently tell us that the "float" write aliases with
> neither the preceding read nor the preceding write.
> >
> >
> > Right, C's TBAA rules do not (in general) permit a store to be reordered
> before a memory operation of a different type, they only allow loads to be
> moved before stores. (Put another way, they do not tell you that pointers
> point to distinct memory locations, just that a stored value cannot be
> observed by a load of a different type.) You get the more general "distinct
> memory locations" result only for objects of a declared type.
> >
> > C++ is similar, except that (because object lifetimes do not currently
> begin magically due to a store) you /can/ reorder stores past a memory
> operation of a different type if you know no object's lifetime began in
> between. (But currently we do not record all lifetime events in IR, so we
> can't do that today. Also, we may be about to lose the property that you
> can statically determine a small number of places that might start an
> object lifetime.)
> >
> > > Also, a strict reading of C's access rules seems to rule out the
> premise underlying our struct-path TBAA entirely. So long as I'm accessing
> a value using a struct that has some member, including recursively, with
> that type, then it's fine. The matching of the relative offsets is a
> sufficient, but not necessary, condition for well-defined access. C++ has
> essentially the same language (and, thus, potentially the same problem).
> >
> > I agree this rule is garbage, but it's not as permissive as I think
> you're suggesting. The rule says that you can use an lvalue of struct type
> to access memory of struct field type. In C this happens during struct
> assignment, for instance. It does *not* permit using an lvalue of struct
> field type to access unrelated fields of the same struct. So C appears to
> allow this nonsense:
> >
> >   char *p = malloc(8);
> >   *(int*)p = 0;
> >   *(int*)(p + 4) = 0;
> >   struct S {int n; float f;} s = *(struct S*)p; // use lvalue of type
> `struct S` to access object of effective type `int`, to initialize a `float`
> >
> >
> > but not this nonsense:
> >
> >   float q = ((struct S*)p)->f; // ub, cannot use lvalue of type `float`
> to access object of effective type `int`
> >
> >
> > ... which just means that we can't make much use of TBAA when emitting
> struct copies in C.
> >
> > In C++, on the other hand, the rule is even more garbage, since there is
> no way to perform a memory access with a glvalue of class type. (The
> closest you get is that a defaulted union construction/assignment copies
> the object representation, but that's expressed in terms of copying a
> sequence of unsigned chars, and in any case those are member functions and
> so already require an object of the correct type to exist.) See
> wg21.link/cwg2051
>
>
> Our struct-path TBAA does the following:
>
>   struct X { int a, b; };
>   X x { 50, 100 };
>   X *o = (X*) (((int*) &x) + 1);
>
>   int a_is_b = o->a; // This is UB (or so we say)?
>

This is UB.
A good resource for this stuff is http://www.cl.cam.ac.uk/~pes20/cerberus/
which has a long document where they exlpore all of these and what various
compilers do, along with what the standard seems to say.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [PATCH] D32199: [TBAASan] A TBAA Sanitizer (Clang)

[Hal Finkel via cfe-commits]

Richard, et al.,

Any feedback on my comments below on what C/C++ allows? I'd like to just 
be missing something ;)


Thanks again,

Hal


On 04/21/2017 06:03 AM, Hal Finkel via Phabricator wrote:

...

Our struct-path TBAA does the following:

   struct X { int a, b; };
   X x { 50, 100 };
   X *o = (X*) (((int*) &x) + 1);
   
   int a_is_b = o->a; // This is UB (or so we say)?



Because we assume that the (type, offset) tuples are identified entities in the 
type-aliasing tree. Practically speaking, this certainly makes sense to me. 
However, I don't see anything in the language that actually forbids this 
behavior. In case it matters, because in the above case the type of the struct 
actually matches, we similarly forbid:

   struct X { int a, b; };
   struct Y { int a; float b; };
   X x { 50, 100 };
   Y *o = (X*) (((int*) &x) + 1);
   
   int a_is_b = o->a; // This is UB (or so we say)?


as is this:

   struct X { int a, b; };
   struct Y { int a; float b; X h; /* in case this matters for the aggregate 
members thing */ };
   X x { 50, 100 };
   Y *o = (X*) (((int*) &x) + 1);
   
   int a_is_b = o->a; // This is UB (or so we say)?


(although, as you say, this shouldn't matter in C++ because we don't have 
struct glvalues)

In any case, am I missing something?



...
As I recall, "store can create an object" is the broad direction that SG12 
agreed on for the cases where you have a pointer into a raw storage buffer (that is, a 
char array), and we want the low-level storage allocation functions to give us such a 
buffer.

What about a read after a calloc (or memset)?


https://reviews.llvm.org/D32199





--
Hal Finkel
Lead, Compiler Technology and Programming Languages
Leadership Computing Facility
Argonne National Laboratory

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

[PATCH] D32700: [clang-tidy] Add misc-suspicious-memset-usage check.

[Eugene Zelenko via Phabricator via cfe-commits]

Eugene.Zelenko added a comment.

Please mention this check in docs/ReleaseNotes.rst (in alphabetical order).




Comment at: docs/clang-tidy/checks/misc-suspicious-memset-usage.rst:6
+
+This check finds memset calls with potential mistakes in their arguments.
+Considering the function as ``void* memset(void* destination, int fill_value,

Please enclose memset on `` and add ().



Comment at: docs/clang-tidy/checks/misc-suspicious-memset-usage.rst:25
+
+If the class containing the memset call has a virtual function, using
+memset on the ``this`` pointer might corrupt the virtual method table.

Please enclose memset on `` and add ().


https://reviews.llvm.org/D32700



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

r301815 - Adapt to LLVM's rename of WeakVH to WeakTrackingVH; NFC

[Sanjoy Das via cfe-commits]

Author: sanjoy
Date: Mon May  1 12:08:00 2017
New Revision: 301815

URL: http://llvm.org/viewvc/llvm-project?rev=301815&view=rev
Log:
Adapt to LLVM's rename of WeakVH to WeakTrackingVH; NFC

Modified:
cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
cfe/trunk/lib/CodeGen/CGObjCMac.cpp
cfe/trunk/lib/CodeGen/CodeGenFunction.h
cfe/trunk/lib/CodeGen/CodeGenModule.cpp
cfe/trunk/lib/CodeGen/CodeGenModule.h

Modified: cfe/trunk/lib/CodeGen/CGDeclCXX.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDeclCXX.cpp?rev=301815&r1=301814&r2=301815&view=diff
==
--- cfe/trunk/lib/CodeGen/CGDeclCXX.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDeclCXX.cpp Mon May  1 12:08:00 2017
@@ -571,9 +571,10 @@ CodeGenFunction::GenerateCXXGlobalInitFu
   FinishFunction();
 }
 
-void CodeGenFunction::GenerateCXXGlobalDtorsFunc(llvm::Function *Fn,
-  const std::vector >
-&DtorsAndObjects) {
+void CodeGenFunction::GenerateCXXGlobalDtorsFunc(
+llvm::Function *Fn,
+const std::vector>
+&DtorsAndObjects) {
   {
 auto NL = ApplyDebugLocation::CreateEmpty(*this);
 StartFunction(GlobalDecl(), getContext().VoidTy, Fn,

Modified: cfe/trunk/lib/CodeGen/CGObjCMac.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGObjCMac.cpp?rev=301815&r1=301814&r2=301815&view=diff
==
--- cfe/trunk/lib/CodeGen/CGObjCMac.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGObjCMac.cpp Mon May  1 12:08:00 2017
@@ -886,7 +886,7 @@ protected:
 
   /// Cached reference to the class for constant strings. This value has type
   /// int * but is actually an Obj-C class pointer.
-  llvm::WeakVH ConstantStringClassRef;
+  llvm::WeakTrackingVH ConstantStringClassRef;
 
   /// \brief The LLVM type corresponding to NSConstantString.
   llvm::StructType *NSConstantStringType = nullptr;

Modified: cfe/trunk/lib/CodeGen/CodeGenFunction.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenFunction.h?rev=301815&r1=301814&r2=301815&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenFunction.h (original)
+++ cfe/trunk/lib/CodeGen/CodeGenFunction.h Mon May  1 12:08:00 2017
@@ -3471,9 +3471,10 @@ public:
 
   /// GenerateCXXGlobalDtorsFunc - Generates code for destroying global
   /// variables.
-  void GenerateCXXGlobalDtorsFunc(llvm::Function *Fn,
-  const std::vector > &DtorsAndObjects);
+  void GenerateCXXGlobalDtorsFunc(
+  llvm::Function *Fn,
+  const std::vector>
+  &DtorsAndObjects);
 
   void GenerateCXXGlobalVarDeclInitFunc(llvm::Function *Fn,
 const VarDecl *D,

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.cpp?rev=301815&r1=301814&r2=301815&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.cpp (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.cpp Mon May  1 12:08:00 2017
@@ -1154,7 +1154,7 @@ void CodeGenModule::addCompilerUsedGloba
 }
 
 static void emitUsed(CodeGenModule &CGM, StringRef Name,
- std::vector &List) {
+ std::vector &List) {
   // Don't create llvm.used if there is no need.
   if (List.empty())
 return;

Modified: cfe/trunk/lib/CodeGen/CodeGenModule.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CodeGenModule.h?rev=301815&r1=301814&r2=301815&view=diff
==
--- cfe/trunk/lib/CodeGen/CodeGenModule.h (original)
+++ cfe/trunk/lib/CodeGen/CodeGenModule.h Mon May  1 12:08:00 2017
@@ -344,8 +344,8 @@ private:
   /// List of global values which are required to be present in the object 
file;
   /// bitcast to i8*. This is used for forcing visibility of symbols which may
   /// otherwise be optimized out.
-  std::vector LLVMUsed;
-  std::vector LLVMCompilerUsed;
+  std::vector LLVMUsed;
+  std::vector LLVMCompilerUsed;
 
   /// Store the list of global constructors and their respective priorities to
   /// be emitted when the translation unit is complete.
@@ -416,7 +416,7 @@ private:
   SmallVector PrioritizedCXXGlobalInits;
 
   /// Global destructor functions and arguments that need to run on 
termination.
-  std::vector > CXXGlobalDtors;
+  std::vector> 
CXXGlobalDtors;
 
   /// \brief The complete set of modules that has been imported.
   llvm::SetVector ImportedModules;
@@ -433,7 +433,7 @@ private:
 
   /// Cached reference to the class for constant strings. This value has type
   /// int * but is actually an Obj-C class pointer.
-  llvm::WeakVH CFConstantStringClassRef;
+  llvm::WeakTrackingVH CFConstantStringClassRef;
 
   /

[PATCH] D32702: [analyzer] Fix 'Memory Error' bugtype capitalization.

[Anna Zaks via Phabricator via cfe-commits]

zaks.anna accepted this revision.
zaks.anna added a comment.

Thanks!


https://reviews.llvm.org/D32702



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

[PATCH] D32702: [analyzer] Fix 'Memory Error' bugtype capitalization.

[Aleksei Sidorin via Phabricator via cfe-commits]

a.sidorin added a comment.

Hi Artem. It is a good point but I think we should have a literal for this 
instead.


https://reviews.llvm.org/D32702



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

[PATCH] D32690: [clang-tidy] modernize-use-emplace: Remove unnecessary make_tuple calls

[Jakub Kuderski via Phabricator via cfe-commits]

kuhar updated this revision to Diff 97299.
kuhar edited the summary of this revision.
kuhar added a comment.

I went ahead and generalized the patch to support custom tuple-like types and 
custom make_ functions.
I added a bunch of tests and updated the docs.

Let me know what you think.


https://reviews.llvm.org/D32690

Files:
  clang-tidy/modernize/UseEmplaceCheck.cpp
  clang-tidy/modernize/UseEmplaceCheck.h
  docs/ReleaseNotes.rst
  docs/clang-tidy/checks/modernize-use-emplace.rst
  test/clang-tidy/modernize-use-emplace.cpp

Index: test/clang-tidy/modernize-use-emplace.cpp
===
--- test/clang-tidy/modernize-use-emplace.cpp
+++ test/clang-tidy/modernize-use-emplace.cpp
@@ -1,7 +1,12 @@
 // RUN: %check_clang_tidy %s modernize-use-emplace %t -- \
 // RUN:   -config="{CheckOptions: \
 // RUN: [{key: modernize-use-emplace.ContainersWithPushBack, \
-// RUN:   value: '::std::vector; ::std::list; ::std::deque; llvm::LikeASmallVector'}]}" -- -std=c++11
+// RUN:   value: '::std::vector; ::std::list; ::std::deque; llvm::LikeASmallVector'}, \
+// RUN:  {key: modernize-use-emplace.TupleTypes, \
+// RUN:   value: '::std::pair; std::tuple; ::test::Single'}, \
+// RUN:  {key: modernize-use-emplace.TupleMakeFunctions, \
+// RUN:   value: '::std::make_pair; ::std::make_tuple; ::test::MakeSingle'}] \
+// RUN: }" -- -std=c++11
 
 namespace std {
 template 
@@ -36,27 +41,54 @@
   ~deque();
 };
 
-template 
-class pair {
+template  struct remove_reference { using type = T; };
+template  struct remove_reference { using type = T; };
+template  struct remove_reference { using type = T; };
+
+template  class pair {
 public:
   pair() = default;
   pair(const pair &) = default;
   pair(pair &&) = default;
 
   pair(const T1 &, const T2 &) {}
   pair(T1 &&, T2 &&) {}
 
-  template 
-  pair(const pair &p){};
-  template 
-  pair(pair &&p){};
+  template  pair(const pair &){};
+  template  pair(pair &&){};
 };
 
 template 
-pair make_pair(T1&&, T2&&) {
+pair::type, typename remove_reference::type>
+make_pair(T1 &&, T2 &&) {
   return {};
 };
 
+template  class tuple {
+public:
+  tuple() = default;
+  tuple(const tuple &) = default;
+  tuple(tuple &&) = default;
+
+  tuple(const Ts &...) {}
+  tuple(Ts &&...) {}
+
+  template  tuple(const tuple &){};
+  template  tuple(tuple &&) {}
+
+  template  tuple(const pair &) {
+static_assert(sizeof...(Ts) == 2, "Wrong tuple size");
+  };
+  template  tuple(pair &&) {
+static_assert(sizeof...(Ts) == 2, "Wrong tuple size");
+  };
+};
+
+template 
+tuple::type...> make_tuple(Ts &&...) {
+  return {};
+}
+
 template 
 class unique_ptr {
 public:
@@ -197,6 +229,30 @@
   // CHECK-FIXES: v2.emplace_back(Something(42, 42), Zoz(Something(21, 37)));
 }
 
+void testTuple() {
+  std::vector> v;
+  v.push_back(std::tuple(false, 'x', 1));
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(false, 'x', 1);
+
+  v.push_back(std::tuple{false, 'y', 2});
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(false, 'y', 2);
+
+  v.push_back({true, 'z', 3});
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(true, 'z', 3);
+
+  std::vector> x;
+  x.push_back(std::make_pair(1, false));
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: x.emplace_back(1, false);
+
+  x.push_back(std::make_pair(2LL, 1));
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: x.emplace_back(2LL, 1);
+}
+
 struct Base {
   Base(int, int *, int = 42);
 };
@@ -318,6 +374,77 @@
   // make_pair cannot be removed here, as Y is not constructible with two ints.
 }
 
+void testMakeTuple() {
+  std::vector> v;
+  v.push_back(std::make_tuple(1, true, 'v'));
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(1, true, 'v');
+
+  v.push_back(std::make_tuple(2ULL, 1, 0));
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(2ULL, 1, 0);
+
+  v.push_back(std::make_tuple(3LL, 1, 0));
+  // CHECK-MESSAGES: :[[@LINE-1]]:5: warning: use emplace_back
+  // CHECK-FIXES: v.emplace_back(std::make_tuple(3LL, 1, 0));
+  // make_tuple is not removed when there are explicit template
+  // arguments provided.
+}
+
+namespace test {
+template  struct Single {
+  Single() = default;
+  Single(const Single &) = default;
+  Single(Single &&) = default;
+
+  Single(const T &) {}
+  Single(T &&) {}
+
+  template  Single(const Single &) {}
+  template  Single(Single &&) {}
+
+  template  Single(const std::tuple &) {}
+  template  Single(std::tuple &&) {}
+};
+
+template 
+Single::type> MakeSingle(T &&) {
+  return {};
+}
+} // namespace test
+
+void testOtherTuples() {
+  std::vector> v;
+  v.push_back(test::Single(1));

[PATCH] D32702: [analyzer] Fix 'Memory Error' bugtype capitalization.

[Gábor Horváth via Phabricator via cfe-commits]

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

LGTM!


https://reviews.llvm.org/D32702



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

[PATCH] D32702: [analyzer] Fix 'Memory Error' bugtype capitalization.

[Artem Dergachev via Phabricator via cfe-commits]

NoQ created this revision.

It seems that we're not capitalizing every word in our bug type descriptions, 
however `Memory Error` is an exception from this rule. Additionally, one of the 
nullability checkers actually does spell it as `Memory error`. So i guess it's 
better to keep everything consistent.


https://reviews.llvm.org/D32702

Files:
  lib/StaticAnalyzer/Checkers/MallocChecker.cpp
  lib/StaticAnalyzer/Checkers/ValistChecker.cpp
  test/Analysis/MismatchedDeallocator-path-notes.cpp
  test/Analysis/NewDelete-path-notes.cpp
  test/Analysis/diagnostics/report-issues-within-main-file.cpp
  test/Analysis/edges-new.mm
  test/Analysis/malloc-plist.c
  test/Analysis/plist-macros.cpp

Index: test/Analysis/plist-macros.cpp
===
--- test/Analysis/plist-macros.cpp
+++ test/Analysis/plist-macros.cpp
@@ -218,7 +218,7 @@
 // CHECK-NEXT: 
 // CHECK-NEXT:
 // CHECK-NEXT:descriptionMemory allocated by malloc() should be deallocated by free(), not 'delete'
-// CHECK-NEXT:categoryMemory Error
+// CHECK-NEXT:categoryMemory error
 // CHECK-NEXT:typeBad deallocator
 // CHECK-NEXT:check_nameunix.MismatchedDeallocator
 // CHECK-NEXT:
@@ -315,7 +315,7 @@
 // CHECK-NEXT: 
 // CHECK-NEXT:
 // CHECK-NEXT:descriptionPotential leak of memory pointed to by 'x'
-// CHECK-NEXT:categoryMemory Error
+// CHECK-NEXT:categoryMemory error
 // CHECK-NEXT:typeMemory leak
 // CHECK-NEXT:check_nameunix.Malloc
 // CHECK-NEXT:
Index: test/Analysis/malloc-plist.c
===
--- test/Analysis/malloc-plist.c
+++ test/Analysis/malloc-plist.c
@@ -421,7 +421,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotential leak of memory pointed to by 'p'
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeMemory leak
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -586,7 +586,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotential leak of memory pointed to by 'A'
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeMemory leak
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -974,7 +974,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotential leak of memory pointed to by 'buf'
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeMemory leak
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -1376,7 +1376,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotential leak of memory pointed to by 'buf'
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeMemory leak
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -1962,7 +1962,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionUse of memory after it is freed
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeUse-after-free
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -2524,7 +2524,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotential leak of memory pointed to by 'buf'
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeMemory leak
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -2795,7 +2795,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotential leak of memory pointed to by 'v'
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeMemory leak
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -3144,7 +3144,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionUse of memory after it is freed
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeUse-after-free
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -3309,7 +3309,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotential leak of memory pointed to by 'm'
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeMemory leak
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -3517,7 +3517,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotential leak of memory pointed to by 'x'
-// CHECK-NEXT: categoryMemory Error
+// CHECK-NEXT: categoryMemory error
 // CHECK-NEXT: typeMemory leak
 // CHECK-NEXT: check_nameunix.Malloc
 // CHECK-NEXT: 
@@ -3725,7 +3725,7 @@
 // CHECK-NEXT:  
 // CHECK-NEXT: 
 // CHECK-NEXT: descriptionPotenti

[PATCH] D30268: Avoid copy of __atoms when char_type is char

[Aditya Kumar via Phabricator via cfe-commits]

hiraditya added a comment.
This revision now requires changes to proceed.

Ping


https://reviews.llvm.org/D30268



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

r301805 - Relax testcase to fix a PS4 buildbot failure.

[Adrian Prantl via cfe-commits]

Author: adrian
Date: Mon May  1 10:49:40 2017
New Revision: 301805

URL: http://llvm.org/viewvc/llvm-project?rev=301805&view=rev
Log:
Relax testcase to fix a PS4 buildbot failure.

Modified:
cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp

Modified: cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp?rev=301805&r1=301804&r2=301805&view=diff
==
--- cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp (original)
+++ cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp Mon May  1 10:49:40 2017
@@ -76,7 +76,7 @@ void B::func_fwd() {
 // CHECK: !DINamespace(scope: null)
 // CHECK: [[CU:![0-9]+]] = distinct !DICompileUnit(
 // CHECK-SAME:imports: [[MODULES:![0-9]*]]
-// CHECK: [[MODULES]] = !{[[M1:![0-9]+]], [[M2:![0-9]+]], [[M3:![0-9]+]], 
[[M4:![0-9]+]], [[M5:![0-9]+]], [[M6:![0-9]+]], [[M7:![0-9]+]], [[M8:![0-9]+]], 
[[M9:![0-9]+]], [[M10:![0-9]+]], [[M11:![0-9]+]], [[M12:![0-9]+]], 
[[M13:![0-9]+]], [[M14:![0-9]+]], [[M15:![0-9]+]], [[M16:![0-9]+]], 
[[M17:![0-9]+]]}
+// CHECK: [[MODULES]] = !{[[M1:![0-9]+]], [[M2:![0-9]+]], [[M3:![0-9]+]], 
[[M4:![0-9]+]], [[M5:![0-9]+]], [[M6:![0-9]+]], [[M7:![0-9]+]], [[M8:![0-9]+]], 
[[M9:![0-9]+]], [[M10:![0-9]+]], [[M11:![0-9]+]], [[M12:![0-9]+]], 
[[M13:![0-9]+]], [[M14:![0-9]+]], [[M15:![0-9]+]], [[M16:![0-9]+]], 
[[M17:![0-9]+]]
 // CHECK: [[M1]] = !DIImportedEntity(tag: DW_TAG_imported_module, scope: 
[[CTXT]], entity: [[NS]], line: 15)
 
 // CHECK: [[M2]] = !DIImportedEntity(tag: DW_TAG_imported_module, scope: 
[[CU]], entity: [[CTXT]],


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

Re: r301707 - Adapt to LLVM API change (DINamespace no longer takes line/file info).

[Adrian Prantl via cfe-commits]

I relaxed the testcase to allow for the extra import in r301805. The extra 
import is for the anonymous namespace that I added to the testcase, which is 
the intended behavior on the PS4 platform (DebugExplicitImport).

-- adrian

> On Apr 28, 2017, at 9:37 PM, Yung, Douglas  wrote:
> 
> Hi Adrian,
> 
> This commit, or the previous one you made seems to be causing a failure in 
> the clang test CodeGenCXX\debug-info-namespace.cpp on the ps4 Windows and 
> Linux bots. It's failing when trying to match the CHECK line on line 79 of 
> the test because the line it matches seems to have one extra import on the 
> PS4 target. Can you take a look?
> 
> Douglas Yung
> 
>> -Original Message-
>> From: cfe-commits [mailto:cfe-commits-boun...@lists.llvm.org] On Behalf Of
>> Adrian Prantl via cfe-commits
>> Sent: Friday, April 28, 2017 15:26
>> To: cfe-commits@lists.llvm.org
>> Subject: r301707 - Adapt to LLVM API change (DINamespace no longer takes
>> line/file info).
>> 
>> Author: adrian
>> Date: Fri Apr 28 17:25:53 2017
>> New Revision: 301707
>> 
>> URL: http://llvm.org/viewvc/llvm-project?rev=301707&view=rev
>> Log:
>> Adapt to LLVM API change (DINamespace no longer takes line/file info).
>> 
>> rdar://problem/17484998
>> https://reviews.llvm.org/D32648
>> 
>> Modified:
>>cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>>cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
>>cfe/trunk/test/Modules/ExtDebugInfo.cpp
>> 
>> Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
>> URL: http://llvm.org/viewvc/llvm-
>> project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=301707&r1=301706&r2=301707&v
>> iew=diff
>> ==
>> --- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
>> +++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Fri Apr 28 17:25:53 2017
>> @@ -4034,11 +4034,9 @@ CGDebugInfo::getOrCreateNameSpace(const
>>   if (I != NameSpaceCache.end())
>> return cast(I->second);
>> 
>> -  unsigned LineNo = getLineNumber(NSDecl->getLocation());
>> -  llvm::DIFile *FileD = getOrCreateFile(NSDecl->getLocation());
>>   llvm::DIScope *Context = getDeclContextDescriptor(NSDecl);
>> -  llvm::DINamespace *NS = DBuilder.createNameSpace(
>> -  Context, NSDecl->getName(), FileD, LineNo, NSDecl->isInline());
>> +  llvm::DINamespace *NS =
>> +  DBuilder.createNameSpace(Context, NSDecl->getName(),
>> + NSDecl->isInline());
>>   NameSpaceCache[NSDecl].reset(NS);
>>   return NS;
>> }
>> 
>> Modified: cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp
>> URL: 
>> http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGenCXX/debug-info-
>> namespace.cpp?rev=301707&r1=301706&r2=301707&view=diff
>> ==
>> --- cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp (original)
>> +++ cfe/trunk/test/CodeGenCXX/debug-info-namespace.cpp Fri Apr 28
>> +++ 17:25:53 2017
>> @@ -53,21 +53,27 @@ inline namespace I {  int var_i;  }  } -void 
>> B::func_fwd()
>> {}
>> +namespace {
>> +int anonymous;
>> +}
>> +void B::func_fwd() {
>> +  anonymous = 0;
>> +}
>> +
>> 
>> // This should work even if 'i' and 'func' were declarations & not
>> definitions,  // but it doesn't yet.
>> 
>> // CHECK: [[I:![0-9]+]] = distinct !DIGlobalVariable(name: "i",{{.*}} scope:
>> [[NS:![0-9]+]], -// CHECK: [[NS]] = !DINamespace(name: "B", scope: 
>> [[CTXT:![0-
>> 9]+]], file: [[FOOCPP:![0-9]+]], line: 1) -// CHECK: [[FOOCPP]] =
>> !DIFile(filename: "foo.cpp"
>> -// CHECK: [[CTXT]] = !DINamespace(name: "A", scope: null, file: [[FILE:![0-
>> 9]+]], line: 5) -// CHECK: [[FILE]] = !DIFile(filename: "{{.*}}debug-info-
>> namespace.cpp",
>> +// CHECK: [[NS]] = !DINamespace(name: "B", scope: [[CTXT:![0-9]+]]) //
>> +CHECK: [[CTXT]] = !DINamespace(name: "A", scope: null) // CHECK:
>> +[[FOOCPP:.*]] = !DIFile(filename: "foo.cpp"
>> // CHECK: [[VAR_FWD:![0-9]+]] = distinct !DIGlobalVariable(name:
>> "var_fwd",{{.*}} scope: [[NS]],
>> // CHECK-SAME: line: 44
>> // CHECK-SAME: isDefinition: true
>> // CHECK: distinct !DIGlobalVariable(name: "var_i",{{.*}} scope:
>> [[INLINE:![0-9]+]], -// CHECK: [[INLINE]] = !DINamespace(name: "I", scope:
>> [[CTXT]], file: [[FOOCPP]], line: 46, exportSymbols: true)
>> +// CHECK: [[INLINE]] = !DINamespace(name: "I", scope: [[CTXT]],
>> +exportSymbols: true) // CHECK: !DINamespace(scope: null)
>> // CHECK: [[CU:![0-9]+]] = distinct !DICompileUnit(
>> // CHECK-SAME:imports: [[MODULES:![0-9]*]]
>> // CHECK: [[MODULES]] = !{[[M1:![0-9]+]], [[M2:![0-9]+]], [[M3:![0-9]+]],
>> [[M4:![0-9]+]], [[M5:![0-9]+]], [[M6:![0-9]+]], [[M7:![0-9]+]], [[M8:![0-
>> 9]+]], [[M9:![0-9]+]], [[M10:![0-9]+]], [[M11:![0-9]+]], [[M12:![0-9]+]],
>> [[M13:![0-9]+]], [[M14:![0-9]+]], [[M15:![0-9]+]], [[M16:![0-9]+]], 
>> [[M17:![0-
>> 9]+]]} @@ -106,7 +112,7 @@ void B::func_fwd() {}
>> // CHECK-SAME:   

Hashing the clang resource path

[Aaron Ballman via cfe-commits]

I think we may have stumbled across a bug with
CIndexer::getClangResourcesPath(), where on POSIX-y systems it uses
dladdr() to get the path of the shared object. It seems that on some
systems (in our case, OS X 10.6.8), dladdr() does not return a
canonicalized path. We're getting a path like
PATH/TO/CLANG/build/bin/../lib/clang/4.0.0. This resource directory
path is then used to calculate a hash used by
CompilerInvocation::getModuleHash(). This, in turn, is causing
Index/pch-from-libclang.c to fail for us because the module cache
paths have different names -- the first path is calculated with
PATH/TO/CLANG/build/lib/clang/4.0.0 and the second path uses
PATH/TO/CLANG/build/bin/../lib/clang/4.0.0.

Should CIndexer::getClangResourcePath() always return a canonicalized
file path, or is it expected that it should return an unnormalized
path and receivers of that path should be responsible for
canonicalizing it?

Thanks!

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

[PATCH] D32181: Remove use of coverage-file flag

[Aaron Ballman via Phabricator via cfe-commits]

aaron.ballman abandoned this revision.
aaron.ballman added a comment.

I've commit in r301796. Rather than accept my own review and then close it, I 
am marking it as abandoned.


https://reviews.llvm.org/D32181



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

r301796 - The -coverage-file flag was removed in r280306, and this piece was missed; NFC.

[Aaron Ballman via cfe-commits]

Author: aaronballman
Date: Mon May  1 08:05:04 2017
New Revision: 301796

URL: http://llvm.org/viewvc/llvm-project?rev=301796&view=rev
Log:
The -coverage-file flag was removed in r280306, and this piece was missed; NFC.

Modified:
cfe/trunk/lib/Driver/Job.cpp

Modified: cfe/trunk/lib/Driver/Job.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Job.cpp?rev=301796&r1=301795&r2=301796&view=diff
==
--- cfe/trunk/lib/Driver/Job.cpp (original)
+++ cfe/trunk/lib/Driver/Job.cpp Mon May  1 08:05:04 2017
@@ -49,7 +49,7 @@ static bool skipArgs(const char *Flag, b
   // arguments.  Therefore, we need to skip the flag and the next argument.
   bool ShouldSkip = llvm::StringSwitch(Flag)
 .Cases("-MF", "-MT", "-MQ", "-serialize-diagnostic-file", true)
-.Cases("-o", "-coverage-file", "-dependency-file", true)
+.Cases("-o", "-dependency-file", true)
 .Cases("-fdebug-compilation-dir", "-diagnostic-log-file", true)
 .Cases("-dwarf-debug-flags", "-ivfsoverlay", true)
 .Default(false);


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

[PATCH] D31608: [coroutines] Add emission of initial and final suspends

[Gor Nishanov via Phabricator via cfe-commits]

GorNishanov added a comment.

Weakly (sp) ping


https://reviews.llvm.org/D31608



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

[PATCH] D31646: [coroutines] Build GRO declaration and return GRO statement

[Gor Nishanov via Phabricator via cfe-commits]

GorNishanov added a comment.

Traditional weekly ping


https://reviews.llvm.org/D31646



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

[PATCH] D32700: [clang-tidy] Add misc-suspicious-memset-usage check.

[Reka Kovacs via Phabricator via cfe-commits]

rnkovacs created this revision.
Herald added a subscriber: mgorny.

This check finds memset calls with potential mistakes in their arguments.
Cases covered:

- Fill value is a character '0'. Integer 0 might have been intended.
- Fill value is out of character range and gets truncated.
- The destination is a this pointer within a class that has a virtual function. 
It might reset the virtual pointer.

The existing google-runtime-memset-zero-length check is related. It finds cases 
when the byte count parameter is zero and offers to swap that with the fill 
value argument. Perhaps the two could be merged while maintaining backward 
compatibility through an alias. When turned on using the alias name, the check 
would only examine the count parameter as in the google check.

Any suggestions are appreciated.


https://reviews.llvm.org/D32700

Files:
  clang-tidy/misc/CMakeLists.txt
  clang-tidy/misc/MiscTidyModule.cpp
  clang-tidy/misc/SuspiciousMemsetUsageCheck.cpp
  clang-tidy/misc/SuspiciousMemsetUsageCheck.h
  docs/clang-tidy/checks/list.rst
  docs/clang-tidy/checks/misc-suspicious-memset-usage.rst
  test/clang-tidy/misc-suspicious-memset-usage.cpp

Index: test/clang-tidy/misc-suspicious-memset-usage.cpp
===
--- /dev/null
+++ test/clang-tidy/misc-suspicious-memset-usage.cpp
@@ -0,0 +1,101 @@
+// RUN: %check_clang_tidy %s misc-suspicious-memset-usage %t
+
+void *memset(void *, int, __SIZE_TYPE__);
+
+template 
+void mtempl() {
+  memset(0, '0', sizeof(T));
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: memset fill value is char '0', potentially mistaken for int 0 [misc-suspicious-memset-usage]
+  // CHECK-FIXES: memset(0, 0, sizeof(T));
+  memset(0, 256, sizeof(T));
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: memset fill value is out of unsigned character range, gets truncated [misc-suspicious-memset-usage]
+}
+
+void BadFillValue() {
+
+  int i[5] = {1, 2, 3, 4, 5};
+  int *p = i;
+  int l = 5;
+  char z = '1';
+  char *c = &z;
+
+  memset(p, '0', l);
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: memset fill value is char '0', potentially mistaken for int 0 [misc-suspicious-memset-usage]
+  // CHECK-FIXES: memset(p, 0, l);
+#define M memset(p, '0', l);
+  M
+  // CHECK-MESSAGES: :[[@LINE-1]]:3: warning: memset fill value is char '0', potentially mistaken for int 0 [misc-suspicious-memset-usage]
+
+  // Valid expressions:
+  memset(p, '2', l);
+  memset(p, 0, l);
+  memset(c, '0', 1);
+
+  memset(p, 0xabcd, l);
+  // CHECK-MESSAGES: :[[@LINE-1]]:13: warning: memset fill value is out of unsigned character range, gets truncated [misc-suspicious-memset-usage]
+
+  // Valid expressions:
+  memset(p, 0x00, l);
+  mtempl();
+}
+
+class A {
+  virtual void a1() {}
+  void a2() {
+memset(this, 0, sizeof(*this));
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: memset used on this pointer potentially corrupts virtual method table [misc-suspicious-memset-usage]
+  }
+  A() {
+memset(this, 0, sizeof(*this));
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: memset used on this pointer potentially corrupts virtual method table [misc-suspicious-memset-usage]
+  }
+};
+
+class B : public A {
+  void b1() {}
+  void b2() {
+memset(this, 0, sizeof(*this));
+// CHECK-MESSAGES: :[[@LINE-1]]:12: warning: memset used on this pointer potentially corrupts virtual method table [misc-suspicious-memset-usage]
+  }
+};
+
+// Valid expressions:
+class C {
+  void c1() {}
+  void c2() {
+memset(this, 0, sizeof(*this));
+  }
+  C() {
+memset(this, 0, sizeof(*this));
+  }
+};
+
+class D {
+  virtual void d1() {}
+  void d2() {
+[this] { memset(this, 0, sizeof(*this)); };
+// CHECK-MESSAGES: :[[@LINE-1]]:21: warning: memset used on this pointer potentially corrupts virtual method table [misc-suspicious-memset-usage]
+  }
+  D() {
+[this] { memset(this, 0, sizeof(*this)); };
+// CHECK-MESSAGES: :[[@LINE-1]]:21: warning: memset used on this pointer potentially corrupts virtual method table [misc-suspicious-memset-usage]
+  }
+};
+
+// Valid expressions:
+class E {
+  virtual void e1() {}
+  E() {
+struct S1 {
+  void s1() { memset(this, 0, sizeof(*this)); }
+};
+  }
+  struct S2 {
+void s2() { memset(this, 0, sizeof(*this)); }
+  };
+  void e2() {
+struct S3 {
+  void s3() { memset(this, 0, sizeof(*this)); }
+};
+  }
+};
Index: docs/clang-tidy/checks/misc-suspicious-memset-usage.rst
===
--- /dev/null
+++ docs/clang-tidy/checks/misc-suspicious-memset-usage.rst
@@ -0,0 +1,57 @@
+.. title:: clang-tidy - misc-suspicious-memset-usage
+
+misc-suspicious-memset-usage
+
+
+This check finds memset calls with potential mistakes in their arguments.
+Considering the function as ``void* memset(void* destination, int fill_value,
+size_t byte_count)``, the following cases are covered:
+
+**Case 1: Fill value is a character '0'*

[PATCH] D32696: More detailed docs for UsingShadowDecl

[Kim Gräsman via Phabricator via cfe-commits]

kimgr created this revision.

I couldn't make sense of the docs before, so I sent a question to cfe-dev. 
Richard was gracious enough to fill in the blanks:
http://lists.llvm.org/pipermail/cfe-dev/2017-April/053687.html

I've tried to transfer some of his response to the Doxygen for UsingShadowDecl. 
Here's to hoping I captured everything correctly.


Repository:
  rL LLVM

https://reviews.llvm.org/D32696

Files:
  include/clang/AST/DeclCXX.h


Index: include/clang/AST/DeclCXX.h
===
--- include/clang/AST/DeclCXX.h
+++ include/clang/AST/DeclCXX.h
@@ -2856,18 +2856,34 @@
 };
 
 /// \brief Represents a shadow declaration introduced into a scope by a
-/// (resolved) using declaration.
+/// (resolved) using declaration, whose target is made visible for name lookup.
 ///
 /// For example,
 /// \code
 /// namespace A {
-///   void foo();
+///   void foo(int);
+///   void foo(double);
 /// }
 /// namespace B {
 ///   using A::foo; // <- a UsingDecl
-/// // Also creates a UsingShadowDecl for A::foo() in B
+/// // Also creates UsingShadowDecls for both A::foo(int) and
+/// // A::foo(double) in B
 /// }
 /// \endcode
+///
+/// Derived class member declarations can hide any shadow declarations brought
+/// in by a class-scope UsingDecl;
+/// \code
+/// class Base {
+/// public:
+///   void foo();
+/// };
+/// class Derived : public Base {
+/// public:
+///   using Base::foo; // <- a UsingDecl
+///   void foo();  // Hides Base::foo and suppresses its UsingShadowDecl.
+/// };
+/// \endcode
 class UsingShadowDecl : public NamedDecl, public Redeclarable 
{
   void anchor() override;
 


Index: include/clang/AST/DeclCXX.h
===
--- include/clang/AST/DeclCXX.h
+++ include/clang/AST/DeclCXX.h
@@ -2856,18 +2856,34 @@
 };
 
 /// \brief Represents a shadow declaration introduced into a scope by a
-/// (resolved) using declaration.
+/// (resolved) using declaration, whose target is made visible for name lookup.
 ///
 /// For example,
 /// \code
 /// namespace A {
-///   void foo();
+///   void foo(int);
+///   void foo(double);
 /// }
 /// namespace B {
 ///   using A::foo; // <- a UsingDecl
-/// // Also creates a UsingShadowDecl for A::foo() in B
+/// // Also creates UsingShadowDecls for both A::foo(int) and
+/// // A::foo(double) in B
 /// }
 /// \endcode
+///
+/// Derived class member declarations can hide any shadow declarations brought
+/// in by a class-scope UsingDecl;
+/// \code
+/// class Base {
+/// public:
+///   void foo();
+/// };
+/// class Derived : public Base {
+/// public:
+///   using Base::foo; // <- a UsingDecl
+///   void foo();  // Hides Base::foo and suppresses its UsingShadowDecl.
+/// };
+/// \endcode
 class UsingShadowDecl : public NamedDecl, public Redeclarable {
   void anchor() override;
 
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits