[flang] [clang] [flang][driver] Rename `flang-new` as `flang` (PR #74377)

2023-12-07 Thread Renato Golin via cfe-commits

rengolin wrote:

The CI errors are Flang specific on Windows... Do we care about those?

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


[clang] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)

2023-09-25 Thread Renato Golin via cfe-commits

rengolin wrote:

> @tru I'd ask @AaronBallman. My vote would be to reformat.

Not as a requirement for this patch, I imagine?

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


[clang] [llvm][tblgen] Add `SourcePath` for `emitSourceFileHeader` (PR #65744)

2023-09-25 Thread Renato Golin via cfe-commits

rengolin wrote:

> Is this suggestion correct?

Doesn't look right to me. I seems it's suggesting 4 spaces tabs, which isn't 
what we normally use. Something wrong with the clang-format job, maybe?

@tru @tstellar 

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


[clang-tools-extra] [MLIR] Enabling Intel GPU Integration. (PR #65539)

2023-09-07 Thread Renato Golin via cfe-commits

rengolin wrote:

CI failure looks like Buildkite issue?
```
$ /etc/buildkite-agent/hooks/pre-checkout
--
  | BUILDKITE_REPO: https://github.com/llvm/llvm-project.git
  | fatal: not a git repository (or any parent up to mount point /var/lib)
  | Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
  |  Error: The global pre-checkout hook exited with status 128
```

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


[clang] [MLIR] Enabling Intel GPU Integration. (PR #65539)

2023-09-07 Thread Renato Golin via cfe-commits

rengolin wrote:

CI failure looks like Buildkite issue?
```
$ /etc/buildkite-agent/hooks/pre-checkout
--
  | BUILDKITE_REPO: https://github.com/llvm/llvm-project.git
  | fatal: not a git repository (or any parent up to mount point /var/lib)
  | Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
  |  Error: The global pre-checkout hook exited with status 128
```

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


[clang-tools-extra] [MLIR] Enabling Intel GPU Integration. (PR #65539)

2023-09-07 Thread Renato Golin via cfe-commits

rengolin wrote:

> At some point it would be nice to have some design document or documentation 
> somewhere explaining how all these MLIR runners works, including this one.

The idea is to eventually consolidate all runners into one. This PR is just 
another piece of the puzzle.

Once we're all happy with how the runners work, we should common them up using 
command line options to select the "type" and CMake options to enable 
particular runner types (depending on the runtimes and hardware available).

> Globally this PR add a SYCL runner, but it is very specific for Intel Level 
> 0. It would be nice to have in the future some generalization, like SYCL 
> using OpenCL interoperability interface to run the SPIR-V kernels or even 
> native kernels.

Agreed! The SYCL runtime here is just being used to abstract the LevelZero 
calls, but this work will be helpful when adding a full SYCL runner (actual 
language extensions and libraries) to other CPUs/GPUs later. 

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


[clang] [MLIR] Enabling Intel GPU Integration. (PR #65539)

2023-09-07 Thread Renato Golin via cfe-commits

rengolin wrote:

> At some point it would be nice to have some design document or documentation 
> somewhere explaining how all these MLIR runners works, including this one.

The idea is to eventually consolidate all runners into one. This PR is just 
another piece of the puzzle.

Once we're all happy with how the runners work, we should common them up using 
command line options to select the "type" and CMake options to enable 
particular runner types (depending on the runtimes and hardware available).

> Globally this PR add a SYCL runner, but it is very specific for Intel Level 
> 0. It would be nice to have in the future some generalization, like SYCL 
> using OpenCL interoperability interface to run the SPIR-V kernels or even 
> native kernels.

Agreed! The SYCL runtime here is just being used to abstract the LevelZero 
calls, but this work will be helpful when adding a full SYCL runner (actual 
language extensions and libraries) to other CPUs/GPUs later. 

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


Re: [llvm-dev] Phabricator Creator Pulling the Plug

2021-08-24 Thread Renato Golin via cfe-commits
On Tue, 24 Aug 2021 at 17:30, James Y Knight  wrote:

> Yes, the Gerrit hosting which Go uses ("googlesource.com") only permits a
> google-account login as a matter of policy. But that's not a restriction of
> Gerrit itself -- it can perfectly well be configured to use a github login.
>

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


Re: [llvm-dev] Phabricator Creator Pulling the Plug

2021-08-24 Thread Renato Golin via cfe-commits
On Tue, 24 Aug 2021 at 12:49, Aaron Ballman  wrote:

> > A minor issue is that the messages Gerrit sends to Github are a bit
> pointless "Message from PersonA: (1 comment)". It would be better if the
> integration either works (like adding comments to a specific line or
> updating the commits) or not pollute.
>
> Also, the Gerrit review process uses a different workflow than the
> Phabricator review process, and we should make sure we're comfortable
> with that. My uses of Gerrit (which have been purely corporate in
> nature, so my experience may be with an older version of the tool)
> have run into some pretty big usability concerns -- like the fact that
> it only shows you the diff contents of one file at a time, lacks the
> ability to "stack" related patches, comments are easier to lose track
> of when updating a review, there's no way to mark comments as "done"
> or not, etc.


Right, my comment was about the integration, not Gerrit vs Phab vs Github.

Whatever integrates with Github should be more succinct, clearer and re-use
Github's ID.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
https://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [llvm-dev] Phabricator Creator Pulling the Plug

2021-08-24 Thread Renato Golin via cfe-commits
On Mon, 23 Aug 2021 at 18:56, James Y Knight  wrote:

> If phabricator/phorge do turn out to be non-viable in the future, I think
> we may want to reopen the option of moving to Gerrit for the primary
> code-review platform.
>
> I'll note that the Golang folks are using Gerrit as their review platform,
> and they have a GitHub bot setup to translate GH pull-requests into a
> gerrit review, so as to be friendly to first-time or drive-by contributors.
> See e.g. https://github.com/golang/go/pull/47766 for an example.
>

Honestly, this is a thing we can do regardless of which tool we use.

There are other tools that integrate with Github more closely that Anton
was looking at, but I think none of them had the functionality we needed
(which both Phab and Gerrit do).

The main problem with that (Go) solution is that the Gerrit install doesn't
single-sign-on with Github accounts, it asked me for my Google account. We
shouldn't ask people to create more accounts if we want integration with
Github. I guess this is just a configuration issue, right?

A minor issue is that the messages Gerrit sends to Github are a bit
pointless "Message from PersonA: (1 comment)". It would be better if the
integration either works (like adding comments to a specific line or
updating the commits) or not pollute.

Same goes for bug tracker...

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


Re: [llvm-dev] Phabricator Creator Pulling the Plug

2021-08-23 Thread Renato Golin via cfe-commits
On Wed, 18 Aug 2021 at 18:17, MyDeveloper Day via llvm-dev <
llvm-...@lists.llvm.org> wrote:

> But unless I missed this, was there any discussion regarding the recent
> "Winding Down" announcement of Phabricator? and what it might mean for us
> in LLVM
>

I think we have our own self-hosted version and enough local people that
has hacked on it to "maintain" it, but we'd stop getting the updated from
upstream, which have been substantial over the years.

I don't think this should be a rush to replace with an alternative, as
there is no imminent peril, but it is an additional important point for the
ongoing discussion of potential transition.

Personally I'm excited by the concept of a community driven replacement (
> https://we.phorge.it/) .
> epriestley did a truly amazing job, it wasn't open to public
> contributions. Perhaps more open development could lead to closing some of
> the github gaps that were of concern.
>

IMO, it would have to be seriously active upstream, understand our existing
database "as is" and import without problems, and interface with Github
more closely to be worth the hassle of migration.

Github pull requests don't seem to be improving a lot, so "phorge" may be
the right answer sooner than they catch up...

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


r348364 - Revert: Honor -fdebug-prefix-map when creating function names for the debug info.

2018-12-05 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Wed Dec  5 05:56:26 2018
New Revision: 348364

URL: http://llvm.org/viewvc/llvm-project?rev=348364=rev
Log:
Revert: Honor -fdebug-prefix-map when creating function names for the debug 
info.

This commit reverts r348060 and r348062 due to it breaking the AArch64 Full
buildbot: https://bugs.llvm.org/show_bug.cgi?id=39892

Removed:
cfe/trunk/test/CodeGenCXX/debug-prefix-map-lambda.cpp
Modified:
cfe/trunk/include/clang/AST/PrettyPrinter.h
cfe/trunk/lib/AST/TypePrinter.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
cfe/trunk/lib/CodeGen/CGDebugInfo.h

Modified: cfe/trunk/include/clang/AST/PrettyPrinter.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/PrettyPrinter.h?rev=348364=348363=348364=diff
==
--- cfe/trunk/include/clang/AST/PrettyPrinter.h (original)
+++ cfe/trunk/include/clang/AST/PrettyPrinter.h Wed Dec  5 05:56:26 2018
@@ -38,20 +38,21 @@ public:
 struct PrintingPolicy {
   /// Create a default printing policy for the specified language.
   PrintingPolicy(const LangOptions )
-  : Indentation(2), SuppressSpecifiers(false),
-SuppressTagKeyword(LO.CPlusPlus), IncludeTagDefinition(false),
-SuppressScope(false), SuppressUnwrittenScope(false),
-SuppressInitializers(false), ConstantArraySizeAsWritten(false),
-AnonymousTagLocations(true), SuppressStrongLifetime(false),
-SuppressLifetimeQualifiers(false),
-SuppressTemplateArgsInCXXConstructors(false), Bool(LO.Bool),
-Restrict(LO.C99), Alignof(LO.CPlusPlus11), UnderscoreAlignof(LO.C11),
-UseVoidForZeroParams(!LO.CPlusPlus), TerseOutput(false),
-PolishForDeclaration(false), Half(LO.Half),
-MSWChar(LO.MicrosoftExt && !LO.WChar), IncludeNewlines(true),
-MSVCFormatting(false), ConstantsAsWritten(false),
-SuppressImplicitBase(false), FullyQualifiedName(false),
-RemapFilePaths(false) {}
+: Indentation(2), SuppressSpecifiers(false),
+  SuppressTagKeyword(LO.CPlusPlus),
+  IncludeTagDefinition(false), SuppressScope(false),
+  SuppressUnwrittenScope(false), SuppressInitializers(false),
+  ConstantArraySizeAsWritten(false), AnonymousTagLocations(true),
+  SuppressStrongLifetime(false), SuppressLifetimeQualifiers(false),
+  SuppressTemplateArgsInCXXConstructors(false),
+  Bool(LO.Bool), Restrict(LO.C99),
+  Alignof(LO.CPlusPlus11), UnderscoreAlignof(LO.C11),
+  UseVoidForZeroParams(!LO.CPlusPlus),
+  TerseOutput(false), PolishForDeclaration(false),
+  Half(LO.Half), MSWChar(LO.MicrosoftExt && !LO.WChar),
+  IncludeNewlines(true), MSVCFormatting(false),
+  ConstantsAsWritten(false), SuppressImplicitBase(false),
+  FullyQualifiedName(false) { }
 
   /// Adjust this printing policy for cases where it's known that we're
   /// printing C++ code (for instance, if AST dumping reaches a C++-only
@@ -224,12 +225,6 @@ struct PrintingPolicy {
   /// When true, print the fully qualified name of function declarations.
   /// This is the opposite of SuppressScope and thus overrules it.
   unsigned FullyQualifiedName : 1;
-
-  /// Whether to apply -fdebug-prefix-map to any file paths.
-  unsigned RemapFilePaths : 1;
-
-  /// When RemapFilePaths is true, this function performs the action.
-  std::function remapPath;
 };
 
 } // end namespace clang

Modified: cfe/trunk/lib/AST/TypePrinter.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/AST/TypePrinter.cpp?rev=348364=348363=348364=diff
==
--- cfe/trunk/lib/AST/TypePrinter.cpp (original)
+++ cfe/trunk/lib/AST/TypePrinter.cpp Wed Dec  5 05:56:26 2018
@@ -1157,13 +1157,9 @@ void TypePrinter::printTag(TagDecl *D, r
   PresumedLoc PLoc = D->getASTContext().getSourceManager().getPresumedLoc(
   D->getLocation());
   if (PLoc.isValid()) {
-OS << " at ";
-StringRef File = PLoc.getFilename();
-if (Policy.RemapFilePaths)
-  OS << Policy.remapPath(File);
-else
-  OS << File;
-OS << ':' << PLoc.getLine() << ':' << PLoc.getColumn();
+OS << " at " << PLoc.getFilename()
+   << ':' << PLoc.getLine()
+   << ':' << PLoc.getColumn();
   }
 }
 

Modified: cfe/trunk/lib/CodeGen/CGDebugInfo.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/CGDebugInfo.cpp?rev=348364=348363=348364=diff
==
--- cfe/trunk/lib/CodeGen/CGDebugInfo.cpp (original)
+++ cfe/trunk/lib/CodeGen/CGDebugInfo.cpp Wed Dec  5 05:56:26 2018
@@ -235,9 +235,6 @@ PrintingPolicy CGDebugInfo::getPrintingP
   if (CGM.getCodeGenOpts().EmitCodeView)
 PP.MSVCFormatting = true;
 
-  // Apply -fdebug-prefix-map.
-  PP.RemapFilePaths = true;
-  PP.remapPath = [this](StringRef Path) { return remapDIPath(Path); };
   return 

[libunwind] r316991 - Merge r311574: ARM: explicitly specify the 8-byte alignment

2017-10-31 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Tue Oct 31 05:21:32 2017
New Revision: 316991

URL: http://llvm.org/viewvc/llvm-project?rev=316991=rev
Log:
Merge r311574: ARM: explicitly specify the 8-byte alignment

Fixing the last libunwind failure on ARM.



Modified:
libunwind/branches/release_50/include/unwind.h
libunwind/branches/release_50/test/alignment.pass.cpp

Modified: libunwind/branches/release_50/include/unwind.h
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_50/include/unwind.h?rev=316991=316990=316991=diff
==
--- libunwind/branches/release_50/include/unwind.h (original)
+++ libunwind/branches/release_50/include/unwind.h Tue Oct 31 05:21:32 2017
@@ -100,7 +100,7 @@ struct _Unwind_Control_Block {
   } pr_cache;
 
   long long int :0; /* Enforce the 8-byte alignment */
-};
+} __attribute__((__aligned__(8)));
 
 typedef _Unwind_Reason_Code (*_Unwind_Stop_Fn)
   (_Unwind_State state,

Modified: libunwind/branches/release_50/test/alignment.pass.cpp
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_50/test/alignment.pass.cpp?rev=316991=316990=316991=diff
==
--- libunwind/branches/release_50/test/alignment.pass.cpp (original)
+++ libunwind/branches/release_50/test/alignment.pass.cpp Tue Oct 31 05:21:32 
2017
@@ -13,8 +13,16 @@
 
 #include 
 
-struct MaxAligned {} __attribute__((aligned));
-static_assert(alignof(_Unwind_Exception) == alignof(MaxAligned), "");
+// EHABI  : 8-byte aligned
+// itanium: largest supported alignment for the system
+#if defined(_LIBUNWIND_ARM_EHABI)
+static_assert(alignof(_Unwind_Control_Block) == 8,
+  "_Unwind_Control_Block must be double-word aligned");
+#else
+struct MaxAligned {} __attribute__((__aligned__));
+static_assert(alignof(_Unwind_Exception) == alignof(MaxAligned),
+  "_Unwind_Exception must be maximally aligned");
+#endif
 
 int main()
 {


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


[libunwind] r316664 - Merging r316657: fixing libunwind tests

2017-10-26 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Thu Oct 26 06:53:36 2017
New Revision: 316664

URL: http://llvm.org/viewvc/llvm-project?rev=316664=rev
Log:
Merging r316657: fixing libunwind tests

Modified:
libunwind/branches/release_50/test/libunwind/test/config.py

Modified: libunwind/branches/release_50/test/libunwind/test/config.py
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_50/test/libunwind/test/config.py?rev=316664=316663=316664=diff
==
--- libunwind/branches/release_50/test/libunwind/test/config.py (original)
+++ libunwind/branches/release_50/test/libunwind/test/config.py Thu Oct 26 
06:53:36 2017
@@ -43,10 +43,11 @@ class Configuration(LibcxxConfiguration)
 
 def configure_compile_flags(self):
 self.cxx.compile_flags += ['-DLIBUNWIND_NO_TIMER']
-if self.get_lit_bool('enable_exceptions', True):
-self.cxx.compile_flags += ['-funwind-tables']
-else:
+if not self.get_lit_bool('enable_exceptions', True):
 self.cxx.compile_flags += ['-fno-exceptions', 
'-DLIBUNWIND_HAS_NO_EXCEPTIONS']
+# Stack unwinding tests need unwinding tables and these are not
+# generated by default on all Targets.
+self.cxx.compile_flags += ['-funwind-tables']
 if not self.get_lit_bool('enable_threads', True):
 self.cxx.compile_flags += ['-D_LIBUNWIND_HAS_NO_THREADS']
 self.config.available_features.add('libunwind-no-threads')


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


r304697 - Revert "[sanitizer-coverage] one more flavor of coverage: -fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting yet. (clang part)"

2017-06-05 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Mon Jun  5 02:35:45 2017
New Revision: 304697

URL: http://llvm.org/viewvc/llvm-project?rev=304697=rev
Log:
Revert "[sanitizer-coverage] one more flavor of coverage: 
-fsanitize-coverage=inline-8bit-counters. Experimental so far, not documenting 
yet. (clang part)"

This reverts commit r304631, as it broke ARM/AArch64 bots for 2 days.

Modified:
cfe/trunk/include/clang/Driver/CC1Options.td
cfe/trunk/include/clang/Frontend/CodeGenOptions.def
cfe/trunk/lib/CodeGen/BackendUtil.cpp
cfe/trunk/lib/Driver/SanitizerArgs.cpp
cfe/trunk/lib/Frontend/CompilerInvocation.cpp
cfe/trunk/test/Driver/fsanitize-coverage.c

Modified: cfe/trunk/include/clang/Driver/CC1Options.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Driver/CC1Options.td?rev=304697=304696=304697=diff
==
--- cfe/trunk/include/clang/Driver/CC1Options.td (original)
+++ cfe/trunk/include/clang/Driver/CC1Options.td Mon Jun  5 02:35:45 2017
@@ -293,9 +293,6 @@ def fsanitize_coverage_trace_gep
 def fsanitize_coverage_8bit_counters
 : Flag<["-"], "fsanitize-coverage-8bit-counters">,
   HelpText<"Enable frequency counters in sanitizer coverage">;
-def fsanitize_coverage_inline_8bit_counters
-: Flag<["-"], "fsanitize-coverage-inline-8bit-counters">,
-  HelpText<"Enable inline 8-bit counters in sanitizer coverage">;
 def fsanitize_coverage_trace_pc
 : Flag<["-"], "fsanitize-coverage-trace-pc">,
   HelpText<"Enable PC tracing in sanitizer coverage">;

Modified: cfe/trunk/include/clang/Frontend/CodeGenOptions.def
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CodeGenOptions.def?rev=304697=304696=304697=diff
==
--- cfe/trunk/include/clang/Frontend/CodeGenOptions.def (original)
+++ cfe/trunk/include/clang/Frontend/CodeGenOptions.def Mon Jun  5 02:35:45 2017
@@ -163,7 +163,6 @@ CODEGENOPT(SanitizeCoverageTracePC, 1, 0
   ///< in sanitizer coverage.
 CODEGENOPT(SanitizeCoverageTracePCGuard, 1, 0) ///< Enable PC tracing with 
guard
///< in sanitizer coverage.
-CODEGENOPT(SanitizeCoverageInline8bitCounters, 1, 0) ///< Use inline 8bit 
counters.
 CODEGENOPT(SanitizeCoverageNoPrune, 1, 0) ///< Disable coverage pruning.
 CODEGENOPT(SanitizeStats , 1, 0) ///< Collect statistics for sanitizers.
 CODEGENOPT(SimplifyLibCalls  , 1, 1) ///< Set when -fbuiltin is enabled.

Modified: cfe/trunk/lib/CodeGen/BackendUtil.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/CodeGen/BackendUtil.cpp?rev=304697=304696=304697=diff
==
--- cfe/trunk/lib/CodeGen/BackendUtil.cpp (original)
+++ cfe/trunk/lib/CodeGen/BackendUtil.cpp Mon Jun  5 02:35:45 2017
@@ -187,7 +187,6 @@ static void addSanitizerCoveragePass(con
   Opts.TracePC = CGOpts.SanitizeCoverageTracePC;
   Opts.TracePCGuard = CGOpts.SanitizeCoverageTracePCGuard;
   Opts.NoPrune = CGOpts.SanitizeCoverageNoPrune;
-  Opts.Inline8bitCounters = CGOpts.SanitizeCoverageInline8bitCounters;
   PM.add(createSanitizerCoverageModulePass(Opts));
 }
 

Modified: cfe/trunk/lib/Driver/SanitizerArgs.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/SanitizerArgs.cpp?rev=304697=304696=304697=diff
==
--- cfe/trunk/lib/Driver/SanitizerArgs.cpp (original)
+++ cfe/trunk/lib/Driver/SanitizerArgs.cpp Mon Jun  5 02:35:45 2017
@@ -48,14 +48,13 @@ enum CoverageFeature {
   CoverageBB = 1 << 1,
   CoverageEdge = 1 << 2,
   CoverageIndirCall = 1 << 3,
-  CoverageTraceBB = 1 << 4,  // Deprecated.
+  CoverageTraceBB = 1 << 4,
   CoverageTraceCmp = 1 << 5,
   CoverageTraceDiv = 1 << 6,
   CoverageTraceGep = 1 << 7,
-  Coverage8bitCounters = 1 << 8,  // Deprecated.
+  Coverage8bitCounters = 1 << 8,
   CoverageTracePC = 1 << 9,
   CoverageTracePCGuard = 1 << 10,
-  CoverageInline8bitCounters = 1 << 12,
   CoverageNoPrune = 1 << 11,
 };
 
@@ -531,8 +530,7 @@ SanitizerArgs::SanitizerArgs(const ToolC
   }
 
   // trace-pc w/o func/bb/edge implies edge.
-  if ((CoverageFeatures &
-   (CoverageTracePC | CoverageTracePCGuard | CoverageInline8bitCounters)) 
&&
+  if ((CoverageFeatures & (CoverageTracePC | CoverageTracePCGuard)) &&
   !(CoverageFeatures & InsertionPointTypes))
 CoverageFeatures |= CoverageEdge;
 
@@ -639,7 +637,6 @@ void SanitizerArgs::addArgs(const ToolCh
 std::make_pair(Coverage8bitCounters, "-fsanitize-coverage-8bit-counters"),
 std::make_pair(CoverageTracePC, "-fsanitize-coverage-trace-pc"),
 std::make_pair(CoverageTracePCGuard, "-fsanitize-coverage-trace-pc-guard"),
-std::make_pair(CoverageInline8bitCounters, 
"-fsanitize-coverage-inline-8bit-counters"),
 std::make_pair(CoverageNoPrune, 

r303996 - Revert "[OpenCL] An error shall occur if any scalar operand has greater rank than the type of the vector element"

2017-05-26 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Fri May 26 10:32:45 2017
New Revision: 303996

URL: http://llvm.org/viewvc/llvm-project?rev=303996=rev
Log:
Revert "[OpenCL] An error shall occur if any scalar operand has greater rank 
than the type of the vector element"

This reverts commit r303986 as it broke all ARM and AArch64 buildbots...

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-39vma/builds/7007
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/6705
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/7509
etc.

Removed:
cfe/trunk/test/SemaOpenCL/arithmetic-conversions.cl
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/test/SemaOpenCL/cond.cl

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=303996=303995=303996=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri May 26 10:32:45 
2017
@@ -8314,9 +8314,6 @@ def err_opencl_bitfields : Error<
   "bit-fields are not supported in OpenCL">;
 def err_opencl_vla : Error<
   "variable length arrays are not supported in OpenCL">;
-def err_opencl_scalar_type_rank_greater_than_vector_type : Error<
-"scalar operand type has greater rank than the type of the vector "
-"element. (%0 and %1)">;
 def err_bad_kernel_param_type : Error<
   "%0 cannot be used as the type of a kernel parameter">;
 def err_record_with_pointers_kernel_param : Error<

Modified: cfe/trunk/lib/Sema/SemaExpr.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaExpr.cpp?rev=303996=303995=303996=diff
==
--- cfe/trunk/lib/Sema/SemaExpr.cpp (original)
+++ cfe/trunk/lib/Sema/SemaExpr.cpp Fri May 26 10:32:45 2017
@@ -8074,38 +8074,28 @@ QualType Sema::InvalidLogicalVectorOpera
 /// rank; for C, Obj-C, and C++ we allow any real scalar conversion except
 /// for float->int.
 ///
-/// OpenCL V2.0 6.2.6.p2:
-/// An error shall occur if any scalar operand type has greater rank
-/// than the type of the vector element.
-///
 /// \param scalar - if non-null, actually perform the conversions
 /// \return true if the operation fails (but without diagnosing the failure)
 static bool tryVectorConvertAndSplat(Sema , ExprResult *scalar,
  QualType scalarTy,
  QualType vectorEltTy,
- QualType vectorTy,
- unsigned ) {
+ QualType vectorTy) {
   // The conversion to apply to the scalar before splatting it,
   // if necessary.
   CastKind scalarCast = CK_Invalid;
   
   if (vectorEltTy->isIntegralType(S.Context)) {
-if (S.getLangOpts().OpenCL && (scalarTy->isRealFloatingType() ||
-(scalarTy->isIntegerType() &&
- S.Context.getIntegerTypeOrder(vectorEltTy, scalarTy) < 0))) {
-  DiagID = diag::err_opencl_scalar_type_rank_greater_than_vector_type;
-  return true;
-}
 if (!scalarTy->isIntegralType(S.Context))
   return true;
+if (S.getLangOpts().OpenCL &&
+S.Context.getIntegerTypeOrder(vectorEltTy, scalarTy) < 0)
+  return true;
 scalarCast = CK_IntegralCast;
   } else if (vectorEltTy->isRealFloatingType()) {
 if (scalarTy->isRealFloatingType()) {
   if (S.getLangOpts().OpenCL &&
-  S.Context.getFloatingTypeOrder(vectorEltTy, scalarTy) < 0) {
-DiagID = diag::err_opencl_scalar_type_rank_greater_than_vector_type;
+  S.Context.getFloatingTypeOrder(vectorEltTy, scalarTy) < 0)
 return true;
-  }
   scalarCast = CK_FloatingCast;
 }
 else if (scalarTy->isIntegralType(S.Context))
@@ -8351,12 +8341,10 @@ QualType Sema::CheckVectorOperands(ExprR
 
   // If there's a vector type and a scalar, try to convert the scalar to
   // the vector element type and splat.
-  unsigned DiagID = diag::err_typecheck_vector_not_convertable;
   if (!RHSVecType) {
 if (isa(LHSVecType)) {
   if (!tryVectorConvertAndSplat(*this, , RHSType,
-LHSVecType->getElementType(), LHSType,
-DiagID))
+LHSVecType->getElementType(), LHSType))
 return LHSType;
 } else {
   if (!tryGCCVectorConvertAndSplat(*this, , ))
@@ -8367,7 +8355,7 @@ QualType Sema::CheckVectorOperands(ExprR
 if (isa(RHSVecType)) {
   if (!tryVectorConvertAndSplat(*this, (IsCompAssign ? nullptr : ),
 LHSType, RHSVecType->getElementType(),
-RHSType, DiagID))
+RHSType))
 return RHSType;
 } else {
   

Re: Potential self-hosting failure

2017-05-17 Thread Renato Golin via cfe-commits
On 17 May 2017 at 18:07, John Brawn  wrote:
> I've now tracked this down to a problem with LEApcrel rematerialization
> where the rematerialized LEApcrel can address a different literal pool
> to the original. I've raised https://bugs.llvm.org/show_bug.cgi?id=33074

Sounds nasty!


> This is actually a bug that already existed before my patches, but because
> my patches made LEApcrel be rematerialized in more situations they made it
> more likely to trigger the bug. I'll continue looking into this to see if
> I can figure out how to fix it.

Thanks John!

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


Re: Potential self-hosting failure

2017-05-16 Thread Renato Golin via cfe-commits
On 16 May 2017 at 18:26, John Brawn  wrote:
> I've managed to reproduce this, but no luck so far in figuring out
> what exactly is going wrong. I'll continue looking into it tomorrow.

Thanks John,

I have reverted it for now on r303193, to get the bots green.

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


Potential self-hosting failure

2017-05-16 Thread Renato Golin via cfe-commits
Hi John,

It seems the LEApcrel patches have broken our self-hosting:

http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15-full-sh/builds/1550

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost-neon/builds/1349

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/1845

The range in each is big, but the overlapping range is actually just
303051 ~ 303054.

Since two of those patches are yours and since this is a self-hosting
issue, my money is on your patches, not the Dwarf one. :)

The tests don't help much, unfortunately.

I have had problems like this in Clang, where the code assumed some
ABI that wasn't as generic as initially assumed, and changes in
relocation are normally the ones that expose those wrong assumptions.

Can you have a look on your side, while we're testing on our side, too?

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


Re: r302750 - PR22877: When constructing an array via a constructor with a default argument

2017-05-12 Thread Renato Golin via cfe-commits
On 12 May 2017 at 20:46, Diana Picus  wrote:
> On 11 May 2017 at 21:14, Richard Smith  wrote:
>> Thanks for the revert, fixed up and recommitted in r302817.
>>
>> Any idea why not a single buildbot sent me any email about this? :( (A
>> couple of them were red at the previous change too, but some of them were
>> not (eg. clang-cmake-armv7-a15).
>
> Hm, I have no idea... @Renato, thoughts?

This seems to be the one:
http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/6961

First red in a long line of greens.

I have received breakage emails this week, so if you didn't get the
email it could be some outage in the bots (Galina?) or some filters?

I really have no better idea. :(

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


r298185 - Revert "Modules: Cache PCMs in memory and avoid a use-after-free"

2017-03-18 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Sat Mar 18 07:31:32 2017
New Revision: 298185

URL: http://llvm.org/viewvc/llvm-project?rev=298185=rev
Log:
Revert "Modules: Cache PCMs in memory and avoid a use-after-free"

This reverts commit r298165, as it broke the ARM builds.

Removed:
cfe/trunk/include/clang/Basic/MemoryBufferCache.h
cfe/trunk/lib/Basic/MemoryBufferCache.cpp
cfe/trunk/test/Modules/Inputs/system-out-of-date/X.h
cfe/trunk/test/Modules/Inputs/system-out-of-date/Y.h
cfe/trunk/test/Modules/Inputs/system-out-of-date/Z.h
cfe/trunk/test/Modules/Inputs/system-out-of-date/module.map
cfe/trunk/test/Modules/Inputs/warning-mismatch/Mismatch.h
cfe/trunk/test/Modules/Inputs/warning-mismatch/System.h
cfe/trunk/test/Modules/Inputs/warning-mismatch/module.modulemap
cfe/trunk/test/Modules/outofdate-rebuild.m
cfe/trunk/test/Modules/system-out-of-date-test.m
cfe/trunk/test/Modules/warning-mismatch.m
cfe/trunk/unittests/Basic/MemoryBufferCacheTest.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td
cfe/trunk/include/clang/Frontend/ASTUnit.h
cfe/trunk/include/clang/Frontend/CompilerInstance.h
cfe/trunk/include/clang/Lex/Preprocessor.h
cfe/trunk/include/clang/Serialization/ASTReader.h
cfe/trunk/include/clang/Serialization/ASTWriter.h
cfe/trunk/include/clang/Serialization/Module.h
cfe/trunk/include/clang/Serialization/ModuleManager.h
cfe/trunk/lib/Basic/CMakeLists.txt
cfe/trunk/lib/Frontend/ASTUnit.cpp
cfe/trunk/lib/Frontend/CompilerInstance.cpp
cfe/trunk/lib/Lex/Preprocessor.cpp
cfe/trunk/lib/Serialization/ASTReader.cpp
cfe/trunk/lib/Serialization/ASTWriter.cpp
cfe/trunk/lib/Serialization/GeneratePCH.cpp
cfe/trunk/lib/Serialization/ModuleManager.cpp
cfe/trunk/unittests/Basic/CMakeLists.txt
cfe/trunk/unittests/Basic/SourceManagerTest.cpp
cfe/trunk/unittests/Lex/LexerTest.cpp
cfe/trunk/unittests/Lex/PPCallbacksTest.cpp
cfe/trunk/unittests/Lex/PPConditionalDirectiveRecordTest.cpp

Modified: cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td?rev=298185=298184=298185=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSerializationKinds.td Sat Mar 18 
07:31:32 2017
@@ -176,11 +176,6 @@ def warn_duplicate_module_file_extension
   "duplicate module file extension block name '%0'">,
   InGroup;
 
-def warn_module_system_bit_conflict : Warning<
-  "module file '%0' was validated as a system module and is now being imported 
"
-  "as a non-system module; any difference in diagnostic options will be 
ignored">,
-  InGroup;
-
 } // let CategoryName
 } // let Component
 

Removed: cfe/trunk/include/clang/Basic/MemoryBufferCache.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/MemoryBufferCache.h?rev=298184=auto
==
--- cfe/trunk/include/clang/Basic/MemoryBufferCache.h (original)
+++ cfe/trunk/include/clang/Basic/MemoryBufferCache.h (removed)
@@ -1,80 +0,0 @@
-//===- MemoryBufferCache.h - Cache for loaded memory buffers *- C++ 
-*-===//
-//
-// The LLVM Compiler Infrastructure
-//
-// This file is distributed under the University of Illinois Open Source
-// License. See LICENSE.TXT for details.
-//
-//===--===//
-
-#ifndef LLVM_CLANG_BASIC_MEMORYBUFFERCACHE_H
-#define LLVM_CLANG_BASIC_MEMORYBUFFERCACHE_H
-
-#include "llvm/ADT/IntrusiveRefCntPtr.h"
-#include "llvm/ADT/StringMap.h"
-#include 
-
-namespace llvm {
-class MemoryBuffer;
-} // end namespace llvm
-
-namespace clang {
-
-/// Manage memory buffers across multiple users.
-///
-/// Ensures that multiple users have a consistent view of each buffer.  This is
-/// used by \a CompilerInstance when building PCMs to ensure that each \a
-/// ModuleManager sees the same files.
-///
-/// \a finalizeCurrentBuffers() should be called before creating a new user.
-/// This locks in the current buffers, ensuring that no buffer that has already
-/// been accessed can be purged, preventing use-after-frees.
-class MemoryBufferCache : public llvm::RefCountedBase {
-  struct BufferEntry {
-std::unique_ptr Buffer;
-
-/// Track the timeline of when this was added to the cache.
-unsigned Index;
-  };
-
-  /// Cache of buffers.
-  llvm::StringMap Buffers;
-
-  /// Monotonically increasing index.
-  unsigned NextIndex = 0;
-
-  /// Bumped to prevent "older" buffers from being removed.
-  unsigned FirstRemovableIndex = 0;
-
-public:
-  /// Store the Buffer under the Filename.
-  ///
-  /// \pre There is not already buffer is not already in the cache.
-  /// \return a reference to the buffer as a 

Re: r296166 - clang-format: Don't leave behind temp files in -i mode on Windows, PR26125

2017-02-24 Thread Renato Golin via cfe-commits
On 24 February 2017 at 20:49, Nico Weber via cfe-commits
 wrote:
> Author: nico
> Date: Fri Feb 24 14:49:00 2017
> New Revision: 296166
>
> URL: http://llvm.org/viewvc/llvm-project?rev=296166=rev
> Log:
> clang-format: Don't leave behind temp files in -i mode on Windows, PR26125
>
> Fix and analysis by Wei Mao  (see bug), test by me.

Hi Nico,

This one looks yours:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/5005

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/4075

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/4386

http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/4439

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/4450

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


Re: r294862 - Hopefully fixes a compile error introduced by r294861.

2017-02-12 Thread Renato Golin via cfe-commits
On 12 February 2017 at 19:24, Aaron Ballman  wrote:
> Did, just that the test also needs a triple. I guess I'll do the dance
> to add it and re-commit.

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


Re: r294862 - Hopefully fixes a compile error introduced by r294861.

2017-02-12 Thread Renato Golin via cfe-commits
On 11 February 2017 at 18:00, Aaron Ballman via cfe-commits
 wrote:
> Author: aaronballman
> Date: Sat Feb 11 12:00:32 2017
> New Revision: 294862
>
> URL: http://llvm.org/viewvc/llvm-project?rev=294862=rev
> Log:
> Hopefully fixes a compile error introduced by r294861.

Didn't... :)

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/3873 (and others)

Reverted both in r294910.

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


r294910 - Revert "Attributes on K C functions should not cause incompatible..."

2017-02-12 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Sun Feb 12 13:08:02 2017
New Revision: 294910

URL: http://llvm.org/viewvc/llvm-project?rev=294910=rev
Log:
Revert "Attributes on K C functions should not cause incompatible..."

...function type with a redeclaration having the same attribute. Fixing this
introduced a secondary problem where we were assuming that K functions
could not be attributed types when reporting old-style function definitions
that are not preceded by a prototype."

Also Revert "Hopefully fixes a compile error introduced by r294861."

This reverts commit r294862, r294861, as they bork the ARM builds and
haven't fix it back.

Also, please, short commit titles, long commit decsriptions...

Modified:
cfe/trunk/include/clang/AST/Type.h
cfe/trunk/include/clang/AST/TypeLoc.h
cfe/trunk/lib/Sema/SemaDecl.cpp
cfe/trunk/test/Sema/knr-def-call.c
cfe/trunk/test/Sema/warn-strict-prototypes.c

Modified: cfe/trunk/include/clang/AST/Type.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/Type.h?rev=294910=294909=294910=diff
==
--- cfe/trunk/include/clang/AST/Type.h (original)
+++ cfe/trunk/include/clang/AST/Type.h Sun Feb 12 13:08:02 2017
@@ -1888,13 +1888,6 @@ public:
   /// immediately following this class.
   template  const T *getAs() const;
 
-  /// Member-template getAsAdjusted. Look through specific kinds
-  /// of sugar (parens, attributes, etc) for an instance of \.
-  /// This is used when you need to walk over sugar nodes that represent some
-  /// kind of type adjustment from a type that was written as a \
-  /// to another type that is still canonically a \.
-  template  const T *getAsAdjusted() const;
-
   /// A variant of getAs<> for array types which silently discards
   /// qualifiers from the outermost type.
   const ArrayType *getAsArrayTypeUnsafe() const;
@@ -6015,38 +6008,6 @@ template  const T *Type::get
   return cast(getUnqualifiedDesugaredType());
 }
 
-template  const T *Type::getAsAdjusted() const {
-  static_assert(!TypeIsArrayType::value, "ArrayType cannot be used with 
getAsAdjusted!");
-
-  // If this is directly a T type, return it.
-  if (const T *Ty = dyn_cast(this))
-return Ty;
-
-  // If the canonical form of this type isn't the right kind, reject it.
-  if (!isa(CanonicalType))
-return nullptr;
-
-  // Strip off type adjustments that do not modify the underlying nature of the
-  // type.
-  const Type *Ty = this;
-  while (Ty) {
-if (const auto *A = dyn_cast(Ty))
-  Ty = A->getModifiedType().getTypePtr();
-else if (const auto *E = dyn_cast(Ty))
-  Ty = E->desugar().getTypePtr();
-else if (const auto *P = dyn_cast(Ty))
-  Ty = P->desugar().getTypePtr();
-else if (const auto *A = dyn_cast(Ty))
-  Ty = A->desugar().getTypePtr();
-else
-  break;
-  }
-
-  // Just because the canonical type is correct does not mean we can use 
cast<>,
-  // since we may not have stripped off all the sugar down to the base type.
-  return dyn_cast(Ty);
-}
-
 inline const ArrayType *Type::getAsArrayTypeUnsafe() const {
   // If this is directly an array type, return it.
   if (const ArrayType *arr = dyn_cast(this))

Modified: cfe/trunk/include/clang/AST/TypeLoc.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/AST/TypeLoc.h?rev=294910=294909=294910=diff
==
--- cfe/trunk/include/clang/AST/TypeLoc.h (original)
+++ cfe/trunk/include/clang/AST/TypeLoc.h Sun Feb 12 13:08:02 2017
@@ -70,13 +70,6 @@ public:
 return t;
   }
 
-  /// \brief Convert to the specified TypeLoc type, returning a null TypeLoc if
-  /// this TypeLock is not of the desired type. It will consider type
-  /// adjustments from a type that wad written as a T to another type that is
-  /// still canonically a T (ignores parens, attributes, elaborated types, 
etc).
-  template 
-  T getAsAdjusted() const;
-
   /// The kinds of TypeLocs.  Equivalent to the Type::TypeClass enum,
   /// except it also defines a Qualified enum that corresponds to the
   /// QualifiedLoc class.
@@ -2195,24 +2188,6 @@ public:
 
   QualType getInnerType() const { return this->getTypePtr()->getElementType(); 
}
 };
-
-template 
-inline T TypeLoc::getAsAdjusted() const {
-  TypeLoc Cur = *this;
-  while (!T::isKind(Cur)) {
-if (auto PTL = Cur.getAs())
-  Cur = PTL.getInnerLoc();
-else if (auto ATL = Cur.getAs())
-  Cur = ATL.getModifiedLoc();
-else if (auto ETL = Cur.getAs())
-  Cur = ETL.getNamedTypeLoc();
-else if (auto ATL = Cur.getAs())
-  Cur = ATL.getOriginalLoc();
-else
-  break;
-  }
-  return Cur.getAs();
-}
 }
 
 #endif

Modified: cfe/trunk/lib/Sema/SemaDecl.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Sema/SemaDecl.cpp?rev=294910=294909=294910=diff
==
--- 

Re: [libcxxabi] r292638 - Fix catch_reference_nullptr.pass.cpp test for GCC.

2017-02-01 Thread Renato Golin via cfe-commits
Right, the other one was 292607 and has already been merged. Sorry for
the confusion. We just need to merge this one and we're done.

--renato

On 1 February 2017 at 21:14, Renato Golin  wrote:
> On 1 February 2017 at 19:33, Hans Wennborg  wrote:
>> Also I'm confused, since I haven't seen anything besides r292638
>> mentioned. Are there other changes besides that up for merging?
>
> I think the other commits were back-ported by other means (other PRs).
>
> Regardless, this is an important commit that fixes a number of
> problems building libc++ and should go in 4.0.
>
> I'll see if I can find the others and will let you know.
>
> cheers,
> --renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [libcxxabi] r292638 - Fix catch_reference_nullptr.pass.cpp test for GCC.

2017-02-01 Thread Renato Golin via cfe-commits
On 1 February 2017 at 19:33, Hans Wennborg  wrote:
> Also I'm confused, since I haven't seen anything besides r292638
> mentioned. Are there other changes besides that up for merging?

I think the other commits were back-ported by other means (other PRs).

Regardless, this is an important commit that fixes a number of
problems building libc++ and should go in 4.0.

I'll see if I can find the others and will let you know.

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


Re: [libcxx] r292607 - Don't default older GCC's to C++17, but C++14 or C++11 instead

2017-01-26 Thread Renato Golin via cfe-commits
On 26 January 2017 at 18:22, Hans Wennborg  wrote:
> What's the status here? Waiting for Marshall?

Possibly. I can confirm this made all the problem on ARM go away with
GCC 5.3 and 6.3.
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [libcxxabi] r292638 - Fix catch_reference_nullptr.pass.cpp test for GCC.

2017-01-20 Thread Renato Golin via cfe-commits
On 20 January 2017 at 19:46, Eric Fiselier  wrote:
> This patch fixes a libc++abi test failure when compiled with GCC 5, 6, or 7.
> We should merge this into 4.0 to help get `check-all` clean.

Hi Eric,

All good on my side, pass with GCC 5.4 and 6.3.

Can you attach all commits that need to be backported into a bug
against PR31622?

We should probably squash them all before merge.

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


r292355 - Revert "[xray] try to fix thumb buildbot"

2017-01-18 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Wed Jan 18 03:05:32 2017
New Revision: 292355

URL: http://llvm.org/viewvc/llvm-project?rev=292355=rev
Log:
Revert "[xray] try to fix thumb buildbot"

This reverts commit r292268, as it didn't fix the buildbots.

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

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=292355=292354=292355=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Wed Jan 18 03:05:32 2017
@@ -4996,7 +4996,6 @@ void Clang::ConstructJob(Compilation ,
   switch (Triple.getArch()) {
   case llvm::Triple::x86_64:
   case llvm::Triple::arm:
-  case llvm::Triple::thumb:
   case llvm::Triple::aarch64:
 // Supported.
 break;


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


r292268 - [xray] try to fix thumb buildbot

2017-01-17 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Tue Jan 17 15:37:24 2017
New Revision: 292268

URL: http://llvm.org/viewvc/llvm-project?rev=292268=rev
Log:
[xray] try to fix thumb buildbot

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

Modified: cfe/trunk/lib/Driver/Tools.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Driver/Tools.cpp?rev=292268=292267=292268=diff
==
--- cfe/trunk/lib/Driver/Tools.cpp (original)
+++ cfe/trunk/lib/Driver/Tools.cpp Tue Jan 17 15:37:24 2017
@@ -4996,6 +4996,7 @@ void Clang::ConstructJob(Compilation ,
   switch (Triple.getArch()) {
   case llvm::Triple::x86_64:
   case llvm::Triple::arm:
+  case llvm::Triple::thumb:
   case llvm::Triple::aarch64:
 // Supported.
 break;


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


Re: LLVM buildmaster will be unavailable on 1/13/17

2017-01-13 Thread Renato Golin via cfe-commits
Should we slow down, or block commits for the time being?

It could be a total chaos when they get back...

On 13 January 2017 at 19:16, Galina Kistanova via cfe-commits
 wrote:
> Just a remainder.
>
> LLVM buildmaster will be offline today hopefully for short time due for
> replacing network hardware.
> Thank you for understanding.
>
> Thanks
>
> Galina
>
>
>
> On Thu, Jan 12, 2017 at 8:29 PM, Galina Kistanova 
> wrote:
>>
>> Hello everyone,
>>
>> LLVM buildmaster will be offline on 1/13/17 hopefully for short time due
>> for replacing network hardware.
>> Thank you for understanding.
>>
>> Thanks
>>
>> Galina
>
>
>
> ___
> 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: r290808 - DR1391: Check for implicit conversion sequences for non-dependent function

2017-01-02 Thread Renato Golin via cfe-commits
On 2 January 2017 at 02:42, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Sun Jan  1 20:42:17 2017
> New Revision: 290808
>
> URL: http://llvm.org/viewvc/llvm-project?rev=290808=rev
> Log:
> DR1391: Check for implicit conversion sequences for non-dependent function
> template parameters between deduction and substitution. The idea is to accept
> as many cases as possible, on the basis that substitution failure outside
> the immediate context is much more common during substitution than during
> implicit conversion sequence formation.

Hi Richard,

This commit has broken *all* our test-suite bots:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/2162

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/772

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-lld/builds/301

http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/1634

Are you not receiving emails? It's not the first time that you break
our bots and leave them to dry.

Next time you break a bot, please either revert the commit or contact
the bot owner ASAP to remediate the problem.

If you're having email problems, please contact Galina, copying the
llvm-admin@ mailing list.

I have reverted in r290811.

Also, please, next time, try to write a commit message in according to
our guidelines:

http://llvm.org/docs/DeveloperPolicy.html#commit-messages

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


r290811 - Revert "DR1391: Check for implicit conversion sequences for non-dependent function template parameters between deduction and substitution. The idea is to accept as many cases as possible, on

2017-01-02 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Mon Jan  2 05:15:42 2017
New Revision: 290811

URL: http://llvm.org/viewvc/llvm-project?rev=290811=rev
Log:
Revert "DR1391: Check for implicit conversion sequences for non-dependent 
function template parameters between deduction and substitution. The idea is to 
accept as many cases as possible, on the basis that substitution failure 
outside the immediate context is much more common during substitution than 
during implicit conversion sequence formation."

This reverts commit r290808, as it broken all ARM and AArch64 test-suite
test: MultiSource/UnitTests/C++11/frame_layout

Also, please, next time, try to write a commit message in according to
our guidelines:

http://llvm.org/docs/DeveloperPolicy.html#commit-messages

Modified:
cfe/trunk/include/clang/Sema/Overload.h
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/lib/Sema/SemaTemplateDeduction.cpp
cfe/trunk/test/CXX/drs/dr13xx.cpp
cfe/trunk/test/Misc/diag-template-diffing.cpp
cfe/trunk/test/SemaCXX/overload-call.cpp
cfe/trunk/test/SemaCXX/overload-member-call.cpp
cfe/trunk/www/cxx_dr_status.html

Modified: cfe/trunk/include/clang/Sema/Overload.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Overload.h?rev=290811=290810=290811=diff
==
--- cfe/trunk/include/clang/Sema/Overload.h (original)
+++ cfe/trunk/include/clang/Sema/Overload.h Mon Jan  2 05:15:42 2017
@@ -531,13 +531,6 @@ namespace clang {
   Ambiguous.construct();
 }
 
-void setAsIdentityConversion(QualType T) {
-  setStandard();
-  Standard.setAsIdentityConversion();
-  Standard.setFromType(T);
-  Standard.setAllToTypes(T);
-}
-
 /// \brief Whether the target is really a std::initializer_list, and the
 /// sequence only represents the worst element conversion.
 bool isStdInitializerListElement() const {
@@ -610,11 +603,6 @@ namespace clang {
 ovl_fail_ext_disabled,
   };
 
-  /// A list of implicit conversion sequences for the arguments of an
-  /// OverloadCandidate.
-  typedef llvm::MutableArrayRef
-  ConversionSequenceList;
-
   /// OverloadCandidate - A single candidate in an overload set (C++ 13.3).
   struct OverloadCandidate {
 /// Function - The actual function that this candidate
@@ -639,13 +627,18 @@ namespace clang {
 /// is a surrogate, but only if IsSurrogate is true.
 CXXConversionDecl *Surrogate;
 
-/// The conversion sequences used to convert the function arguments
-/// to the function parameters.
-ConversionSequenceList Conversions;
+/// Conversions - The conversion sequences used to convert the
+/// function arguments to the function parameters, the pointer points to a
+/// fixed size array with NumConversions elements. The memory is owned by
+/// the OverloadCandidateSet.
+ImplicitConversionSequence *Conversions;
 
 /// The FixIt hints which can be used to fix the Bad candidate.
 ConversionFixItGenerator Fix;
 
+/// NumConversions - The number of elements in the Conversions array.
+unsigned NumConversions;
+
 /// Viable - True to indicate that this overload candidate is viable.
 bool Viable;
 
@@ -684,9 +677,9 @@ namespace clang {
 /// hasAmbiguousConversion - Returns whether this overload
 /// candidate requires an ambiguous conversion or not.
 bool hasAmbiguousConversion() const {
-  for (auto  : Conversions) {
-if (!C.isInitialized()) return false;
-if (C.isAmbiguous()) return true;
+  for (unsigned i = 0, e = NumConversions; i != e; ++i) {
+if (!Conversions[i].isInitialized()) return false;
+if (Conversions[i].isAmbiguous()) return true;
   }
   return false;
 }
@@ -735,7 +728,7 @@ namespace clang {
 SmallVector Candidates;
 llvm::SmallPtrSet Functions;
 
-// Allocator for ConversionSequenceLists. We store the first few
+// Allocator for OverloadCandidate::Conversions. We store the first few
 // elements inline to avoid allocation for small sets.
 llvm::BumpPtrAllocator ConversionSequenceAllocator;
 
@@ -776,45 +769,30 @@ namespace clang {
 size_t size() const { return Candidates.size(); }
 bool empty() const { return Candidates.empty(); }
 
-/// \brief Allocate storage for conversion sequences for NumConversions
-/// conversions.
-ConversionSequenceList
-allocateConversionSequences(unsigned NumConversions) {
-  ImplicitConversionSequence *Conversions;
+/// \brief Add a new candidate with NumConversions conversion sequence 
slots
+/// to the overload set.
+OverloadCandidate (unsigned NumConversions = 0) {
+  Candidates.push_back(OverloadCandidate());
+  OverloadCandidate  = Candidates.back();
 
   // Assign space from the inline array if there are enough free slots
   // available.
   if 

Re: r290080 - [c++1z] P0195R2: Support pack-expansion of using-declarations.

2016-12-19 Thread Renato Golin via cfe-commits
On 19 December 2016 at 12:39, Daniel Jasper  wrote:
> Oh, I completely understand, I am doing the same here :)

Btw, this also happened:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/582

It seems Clang lost the ability to find the libstdc++:

CMake Error at cmake/modules/CheckCompilerVersion.cmake:38 (message):
  Host Clang must be able to find libstdc++4.8 or newer!

Your revert did fix the issue:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-selfhost/builds/587

So when this comes back, it needs to also fix this problem.

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


Re: r290080 - [c++1z] P0195R2: Support pack-expansion of using-declarations.

2016-12-19 Thread Renato Golin via cfe-commits
On 19 December 2016 at 12:27, Daniel Jasper  wrote:
> I don't understand. This *is* a revert of the whole patch.

My bad, your revert hadn't gone through:

http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/1361

Now it's green.

Sorry, we're dealing with 4 different cluster-plucks today.

I hate Mondays.

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


Re: r290080 - [c++1z] P0195R2: Support pack-expansion of using-declarations.

2016-12-19 Thread Renato Golin via cfe-commits
On 19 December 2016 at 11:28, Daniel Jasper via cfe-commits
 wrote:
> I have reverted this in r290092 as it was leading to Clang crashes on the
> bots and elsewhere, e.g.:
> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/1814

Hi Daniel, Richard,

This is will red on our LNT bot, which started with this commit:

http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/1354

and still has the same failures on the last build:

http://lab.llvm.org:8011/builders/clang-native-arm-lnt/builds/1360

this is one of the 5 different failures we have in all our bots...
After so many fix-patches and reverts, I'm not surprised we got into
this corner of mayhem.

I'd like to ask people a bit more care and worry about the bots.

Most of the time, reverting the whole patch and talking to the bot
owners is a much better strategy than push-fix a bunch of trail and
errors.

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


Re: [libcxxabi] r288457 - Update implementation of ABI support for throwing noexcept function pointers

2016-12-02 Thread Renato Golin via cfe-commits
It's been a while, and new patches are coming. Should we just revert
this for now?

--renato

On 2 December 2016 at 10:13, Renato Golin  wrote:
> On 2 December 2016 at 02:06, Richard Smith via cfe-commits
>  wrote:
>> Author: rsmith
>> Date: Thu Dec  1 20:06:53 2016
>> New Revision: 288457
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=288457=rev
>> Log:
>> Update implementation of ABI support for throwing noexcept function pointers
>> and catching as non-noexcept to match the final design per discusson on
>> cxx-abi-dev.
>
> Hi Richard,
>
> I hope you've seen this:
>
> http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/4
>
> http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions/builds/6
>
> http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux/builds/97
>
> http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux-noexceptions/builds/109
>
> error: exception specifications are not allowed in type aliases
> template using FnType = void() noexcept(Noexcept);
>
> error: exception specifications are not allowed in type aliases
> template using FnType = void (X::*)() noexcept(Noexcept);
>
> cheers,
> --renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [libcxxabi] r288457 - Update implementation of ABI support for throwing noexcept function pointers

2016-12-02 Thread Renato Golin via cfe-commits
On 2 December 2016 at 02:06, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Thu Dec  1 20:06:53 2016
> New Revision: 288457
>
> URL: http://llvm.org/viewvc/llvm-project?rev=288457=rev
> Log:
> Update implementation of ABI support for throwing noexcept function pointers
> and catching as non-noexcept to match the final design per discusson on
> cxx-abi-dev.

Hi Richard,

I hope you've seen this:

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux/builds/4

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-aarch64-linux-noexceptions/builds/6

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux/builds/97

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux-noexceptions/builds/109

error: exception specifications are not allowed in type aliases
template using FnType = void() noexcept(Noexcept);

error: exception specifications are not allowed in type aliases
template using FnType = void (X::*)() noexcept(Noexcept);

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


[PATCH] D26968: [ARM] Add Driver support for emitting the missing Tag_ABI_enum_size build attribute values

2016-11-22 Thread Renato Golin via cfe-commits
rengolin added a comment.

How does GCC behave with those arguments?

Thinking back now, we may be required to follow, as the principle of least 
surprise has to hold.


https://reviews.llvm.org/D26968



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


[PATCH] D26968: [ARM] Add Driver support for emitting the missing Tag_ABI_enum_size build attribute values

2016-11-22 Thread Renato Golin via cfe-commits
rengolin added inline comments.



Comment at: lib/Basic/Targets.cpp:5407
+  Builder.defineMacro("__ARM_SIZEOF_MINIMAL_ENUM",
+  Opts.ShortEnums || Opts.ABIEnums ? "1" : "4");
 

labrinea wrote:
> rengolin wrote:
> > Isn't ABIEnums 4? Shouldn't this be:
> > 
> > Opts.ShortEnums || !Opts.ABIEnums
> > 
> > Is it even valid to have ABIEnums && ShortEnums at the same time?
> My understanding is that ABIEnums requires 32-bit enums across an 
> ABI-complying interface, but allows short enums outside of it. Therefore 
> __ARM_SIZEOF_MINIMAL_ENUM could be any of 1 or 4.
> 
> ABIEnums && ShortEnums cannot be both set at the same time.
If all four options are mutually exclusive, than they should be a single 
integer option, not multiple boolean ones.



Comment at: lib/Driver/Tools.cpp:5731
+
+  // The last of -fno-enums, -fshort-enums, -fabi-enums wins.
+  Arg *Enum;

labrinea wrote:
> rengolin wrote:
> > If this is true, why go the extra complexity of mapping all possible 
> > states? Why not just use one line:
> > 
> > Enum = Args.getLastArg(options::OPT_fno_enums, 
> > options::OPT_fshort_enums, options::OPT_fabi_enums);
> > 
> > and be done with it? Short and ABI are not compatible, it's either one or 
> > the other.
> I don't like this complicated logic either but it can handle cases like:
> -fshort-enums -fno-enums -fabi-enums -fno-abi-enums
> where -fno-enums should win. I've added a test for this sequence 
> (test/Driver/clang_f_opts.c, line 459)
> The suggested logic would ignore '-fno-abi-enums', which is the last 
> argument. If we are happy with rejecting all the preceding flags and keeping 
> just the last one this would work:
> ```
> Args.getLastArg(options::OPT_fno_enums, options::OPT_fshort_enums, 
> options::OPT_fno_short_enums,
> options::OPT_fabi_enums, options::OPT_fno_abi_enums);
> ```
> Alternatively an equally ugly logic that handles complicated sequences is:
> ```
> if (Arg *Enum = Args.getLastArg(options::OPT_fno_enums,
>  ShortEnums ? options::OPT_fshort_enums : options::OPT_INVALID,
>ABIEnums ? options::OPT_fabi_enums   : options::OPT_INVALID)) {
> ```
I disagree. These are different flags controlling the same thing, so the 
last-option wins.

How does -ffast-math vs its internal options are handled? How is -O handled? Or 
the other ABI flags like vfp, hard-float?

Easier still, have a look at unsigned/signed char below. Last arg wins.


https://reviews.llvm.org/D26968



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


[PATCH] D26968: [ARM] Add Driver support for emitting the missing Tag_ABI_enum_size build attribute values

2016-11-22 Thread Renato Golin via cfe-commits
rengolin added a comment.

Hi Alexandros,

My interpretation of `Tag_ABI_enum_size` is that value 3 is that **all** enums 
are 32-bit and value 4 is that only those ABI-visible (ie. public interfaces) 
have to be 32-bits. This is similar to the other PCS tags.

So, the table is:

- 0: no enums
- 1: short enums
- 2: all 32-bit
- 3: public 32-bit

With the default being 2 in GCC.

My reading of your code here is that you assume short|abi = short, which 
doesn't match the table in the ABI.




Comment at: lib/Basic/Targets.cpp:5407
+  Builder.defineMacro("__ARM_SIZEOF_MINIMAL_ENUM",
+  Opts.ShortEnums || Opts.ABIEnums ? "1" : "4");
 

Isn't ABIEnums 4? Shouldn't this be:

Opts.ShortEnums || !Opts.ABIEnums

Is it even valid to have ABIEnums && ShortEnums at the same time?



Comment at: lib/Driver/Tools.cpp:5731
+
+  // The last of -fno-enums, -fshort-enums, -fabi-enums wins.
+  Arg *Enum;

If this is true, why go the extra complexity of mapping all possible states? 
Why not just use one line:

Enum = Args.getLastArg(options::OPT_fno_enums, options::OPT_fshort_enums, 
options::OPT_fabi_enums);

and be done with it? Short and ABI are not compatible, it's either one or the 
other.



Comment at: lib/Driver/Tools.cpp:5741
+  else
+Enum = Args.getLastArg(options::OPT_fno_enums);
+  if (Enum) {

This code is confusing and merging with each other. Please add some empty lines 
between them.


https://reviews.llvm.org/D26968



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


Re: [clang-tools-extra] r287540 - readability-redundant-declaration: Fix crash

2016-11-21 Thread Renato Golin via cfe-commits
On 21 November 2016 at 14:29, Daniel Marjamaki via cfe-commits
 wrote:
> Author: danielmarjamaki
> Date: Mon Nov 21 08:29:53 2016
> New Revision: 287540
>
> URL: http://llvm.org/viewvc/llvm-project?rev=287540=rev
> Log:
> readability-redundant-declaration: Fix crash

Introduced another... :)

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/728

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


[PATCH] D26464: [ARM] Fix sema check of ARM special register names

2016-11-15 Thread Renato Golin via cfe-commits
rengolin accepted this revision.
rengolin added a reviewer: rengolin.
rengolin added a comment.
This revision is now accepted and ready to land.

LGTM. Thanks!


Repository:
  rL LLVM

https://reviews.llvm.org/D26464



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


[PATCH] D26464: [ARM] Fix sema check of ARM special register names

2016-11-14 Thread Renato Golin via cfe-commits
rengolin added a comment.

Looks like an oversight. Aren't there any tests for this? Maybe there should be 
one.


Repository:
  rL LLVM

https://reviews.llvm.org/D26464



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


Re: r286815 - Improve handling of floating point literals in OpenCL to only use double precision if the target supports fp64.

2016-11-14 Thread Renato Golin via cfe-commits
On 14 November 2016 at 11:15, Neil Hickey via cfe-commits
 wrote:
> Author: neil.hickey
> Date: Mon Nov 14 05:15:51 2016
> New Revision: 286815
>
> URL: http://llvm.org/viewvc/llvm-project?rev=286815=rev
> Log:
> Improve handling of floating point literals in OpenCL to only use double 
> precision if the target supports fp64.

Major breakages on all ARM and AArch64 bots, with unreachable on Sema.cpp:

UNREACHABLE executed at
/home/buildslave/buildslave/clang-cmake-aarch64-quick/llvm/tools/clang/lib/Sema/Sema.cpp:375!

Examples:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/473

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-39vma/builds/613

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/718

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/871

etc...

Reverted in r286818.

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


[PATCH] D24998: Add a new optimization option -Og

2016-11-11 Thread Renato Golin via cfe-commits
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.

I agree with Keith. This is a starting point, not a final destination.

As we evolve this, we can start looking at better ways to improve the debug 
illusion, but right now, `O1` is probably the best thing to do.

LGTM, thanks!


https://reviews.llvm.org/D24998



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


Re: r285604 - [x86][inline-asm][AVX512][clang][PART-1] Introducing "k" and "Yk" constraints for extended inline assembly, enabling use of AVX512 masked vectorized instructions.

2016-10-31 Thread Renato Golin via cfe-commits
On 31 October 2016 at 17:23, Michael Zuckerman via cfe-commits
 wrote:
> Author: mzuckerm
> Date: Mon Oct 31 12:23:52 2016
> New Revision: 285604
>
> URL: http://llvm.org/viewvc/llvm-project?rev=285604=rev
> Log:
> [x86][inline-asm][AVX512][clang][PART-1] Introducing "k" and "Yk" constraints 
> for extended inline assembly, enabling use of AVX512 masked vectorized 
> instructions.

Hi Michael,

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-39vma/builds/90
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/311
http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/271

'No available targets are compatible with this triple.'

I'm not sure why this one fails and the other similar ones don't.

This is breaking all bots that don't build x86.

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


Re: r285027 - Fix test on non-X86 platforms

2016-10-24 Thread Renato Golin via cfe-commits
Hi Mehdi, it's also failing on aarch64:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/47

And current build was still red. Not to mention all arm bots. Maybe
reverting and trying offline next time.

I can help you with arm environments, if you need.

Cheers,
Renato

On 24 Oct 2016 23:53, "Mehdi Amini via cfe-commits" <
cfe-commits@lists.llvm.org> wrote:

> The test is validating pointer size as well, so it is failing on 32 bits
> right now.
>
> I could try to differentiate some of the check and have them work on both
> size, but I can’t verify that the runtime works (I don’t have a 32 bits
> runtime).
>
> —
> Mehdi
>
>
> On Oct 24, 2016, at 2:48 PM, Craig Topper  wrote:
>
> Doesn't this exclude 32-bit x86?
>
> ~Craig
>
> On Mon, Oct 24, 2016 at 2:22 PM, Mehdi Amini via cfe-commits <
> cfe-commits@lists.llvm.org> wrote:
>
>> Author: mehdi_amini
>> Date: Mon Oct 24 16:22:01 2016
>> New Revision: 285027
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=285027=rev
>> Log:
>> Fix test on non-X86 platforms
>>
>> This is a fixup for r285019, adding an `#ifdef __x86_64__` since
>> the os_log builtin is platform specific.
>>
>> Modified:
>> cfe/trunk/test/CodeGen/builtins.c
>>
>> Modified: cfe/trunk/test/CodeGen/builtins.c
>> URL: http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/
>> builtins.c?rev=285027=285026=285027=diff
>> 
>> ==
>> --- cfe/trunk/test/CodeGen/builtins.c (original)
>> +++ cfe/trunk/test/CodeGen/builtins.c Mon Oct 24 16:22:01 2016
>> @@ -369,6 +369,9 @@ long long test_builtin_readcyclecounter(
>>return __builtin_readcyclecounter();
>>  }
>>
>> +// Behavior of __builtin_os_log differs between platforms, so only test
>> on X86
>> +#ifdef __x86_64__
>> +
>>  // CHECK-LABEL: define void @test_builtin_os_log
>>  // CHECK: (i8* [[BUF:%.*]], i32 [[I:%.*]], i8* [[DATA:%.*]])
>>  void test_builtin_os_log(void *buf, int i, const char *data) {
>> @@ -506,3 +509,5 @@ void test_builtin_os_log_percent(void *b
>>// CHECK: store i8* [[DATA2]], i8** [[ARG1_PTR]]
>>__builtin_os_log_format(buf, "%s %%", data);
>>  }
>> +
>> +#endif
>> \ No newline at end of file
>>
>>
>> ___
>> cfe-commits mailing list
>> cfe-commits@lists.llvm.org
>> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>>
>
>
>
> ___
> cfe-commits mailing list
> cfe-commits@lists.llvm.org
> http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r284960 - [analyzer] Add StdLibraryFunctions checker.

2016-10-24 Thread Renato Golin via cfe-commits
On 24 October 2016 at 14:09, Artem Dergachev  wrote:
> Strange, i'm not receiving any buildbot emails again. Will look through bots
> manually next time, that doesn't sound too hard. Pushed a hotfix in r284969.

The buildmaster was restarted this weekend and got all old builds data wiped.

I only know because I have a monitoring page.

Galina,

Any info on the server migration and the email configuration?

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


Re: r284960 - [analyzer] Add StdLibraryFunctions checker.

2016-10-24 Thread Renato Golin via cfe-commits
On 24 October 2016 at 10:41, Artem Dergachev via cfe-commits
 wrote:
> Author: dergachev
> Date: Mon Oct 24 04:41:38 2016
> New Revision: 284960
>
> URL: http://llvm.org/viewvc/llvm-project?rev=284960=rev
> Log:
> [analyzer] Add StdLibraryFunctions checker.

Hi Artem,

I'm not sure what you're checking, but this failed on the ARM bots:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/14
http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/14

error: 'warning' diagnostics expected but not seen:
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 35: TRUE
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 38: TRUE
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 44: TRUE
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 52: TRUE
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 54: TRUE
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 66: FALSE
error: 'warning' diagnostics seen but not expected:
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 35: UNKNOWN
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 38: UNKNOWN
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 44: UNKNOWN
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 52: UNKNOWN
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 54: UNKNOWN
  File 
/home/linaro/buildbot/clang-cmake-armv7-a15/llvm/tools/clang/test/Analysis/std-c-library-functions.c
Line 66: UNKNOWN
12 errors generated.

If it's not trivial to fix, let's revert and try to find it offline.

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


[PATCH] D25842: [clang] Limit clang test to ARM and AArch64 only

2016-10-22 Thread Renato Golin via cfe-commits
rengolin accepted this revision.
rengolin added a reviewer: rengolin.
rengolin added a comment.
This revision is now accepted and ready to land.

I haven't tested with ARM and not AArch64 or vice-versa. I'm assuming you have. 
If so, LGTM. Thanks.


https://reviews.llvm.org/D25842



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


Re: r284800 - DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.

2016-10-21 Thread Renato Golin via cfe-commits
On 21 October 2016 at 03:36, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Thu Oct 20 21:36:37 2016
> New Revision: 284800
>
> URL: http://llvm.org/viewvc/llvm-project?rev=284800=rev
> Log:
> DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules.

Hi Richard,

This failed all our bots:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/13274

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/11260

http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/16281

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15/builds/15991

I've reverted in r284811.

Let me know if you need help testing.

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


r284811 - Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' rules."

2016-10-21 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Fri Oct 21 03:03:49 2016
New Revision: 284811

URL: http://llvm.org/viewvc/llvm-project?rev=284811=rev
Log:
Revert "DR583, DR1512: Implement a rewrite to C++'s 'composite pointer type' 
rules."

This reverts commit r284800, as it failed all ARM/AArch64 bots.

Removed:
cfe/trunk/test/CXX/over/over.built/p15.cpp
cfe/trunk/test/CXX/over/over.built/p16.cpp
cfe/trunk/test/SemaCXX/libstdcxx_libcxx_less_hack.cpp
Modified:
cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
cfe/trunk/include/clang/Sema/Sema.h
cfe/trunk/lib/Sema/SemaExpr.cpp
cfe/trunk/lib/Sema/SemaExprCXX.cpp
cfe/trunk/lib/Sema/SemaOverload.cpp
cfe/trunk/test/CXX/drs/dr15xx.cpp
cfe/trunk/test/CXX/drs/dr5xx.cpp
cfe/trunk/test/CXX/expr/expr.const/p2-0x.cpp
cfe/trunk/test/Misc/warning-flags.c
cfe/trunk/test/OpenMP/distribute_parallel_for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/distribute_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/parallel_for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/target_parallel_for_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/target_simd_aligned_messages.cpp
cfe/trunk/test/OpenMP/taskloop_simd_aligned_messages.cpp
cfe/trunk/test/SemaCXX/compare.cpp
cfe/trunk/test/SemaCXX/composite-pointer-type.cpp
cfe/trunk/test/SemaCXX/constant-expression-cxx11.cpp
cfe/trunk/test/SemaCXX/null_in_arithmetic_ops.cpp
cfe/trunk/test/SemaCXX/nullptr.cpp
cfe/trunk/test/SemaCXX/nullptr_in_arithmetic_ops.cpp
cfe/trunk/test/SemaCXX/warn-memsize-comparison.cpp
cfe/trunk/test/SemaObjCXX/null_objc_pointer.mm
cfe/trunk/www/cxx_dr_status.html

Modified: cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td?rev=284811=284810=284811=diff
==
--- cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td (original)
+++ cfe/trunk/include/clang/Basic/DiagnosticSemaKinds.td Fri Oct 21 03:03:49 
2016
@@ -5536,8 +5536,6 @@ def ext_typecheck_ordered_comparison_of_
   "ordered comparison between pointer and integer (%0 and %1)">;
 def ext_typecheck_ordered_comparison_of_pointer_and_zero : Extension<
   "ordered comparison between pointer and zero (%0 and %1) is an extension">;
-def err_typecheck_ordered_comparison_of_pointer_and_zero : Error<
-  "ordered comparison between pointer and zero (%0 and %1)">;
 def ext_typecheck_ordered_comparison_of_function_pointers : ExtWarn<
   "ordered comparison of function pointers (%0 and %1)">;
 def ext_typecheck_comparison_of_fptr_to_void : Extension<
@@ -5558,6 +5556,9 @@ def err_cond_voidptr_arc : Error <
   "in ARC mode">;
 def err_typecheck_comparison_of_distinct_pointers : Error<
   "comparison of distinct pointer types%diff{ ($ and $)|}0,1">;
+def ext_typecheck_comparison_of_distinct_pointers_nonstandard : ExtWarn<
+  "comparison of distinct pointer types (%0 and %1) uses non-standard "
+  "composite pointer type %2">, InGroup;
 def err_typecheck_op_on_nonoverlapping_address_space_pointers : Error<
   "%select{comparison between %diff{ ($ and $)|}0,1"
   "|arithmetic operation with operands of type %diff{ ($ and $)|}0,1"
@@ -6836,6 +6837,9 @@ def err_typecheck_expect_scalar_operand
   "operand of type %0 where arithmetic or pointer type is required">;
 def err_typecheck_cond_incompatible_operands : Error<
   "incompatible operand types%diff{ ($ and $)|}0,1">;
+def ext_typecheck_cond_incompatible_operands_nonstandard : ExtWarn<
+  "incompatible operand types%diff{ ($ and $)|}0,1 use non-standard composite "
+  "pointer type %2">;
 def err_cast_selector_expr : Error<
   "cannot type cast @selector expression">;
 def ext_typecheck_cond_incompatible_pointers : ExtWarn<

Modified: cfe/trunk/include/clang/Sema/Sema.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Sema/Sema.h?rev=284811=284810=284811=diff
==
--- cfe/trunk/include/clang/Sema/Sema.h (original)
+++ cfe/trunk/include/clang/Sema/Sema.h Fri Oct 21 03:03:49 2016
@@ -8954,13 +8954,15 @@ public:
 ExprResult , ExprResult , ExprResult ,
 ExprValueKind , ExprObjectKind , SourceLocation questionLoc);
   QualType FindCompositePointerType(SourceLocation Loc, Expr *, Expr *,
+bool *NonStandardCompositeType = nullptr,
 bool ConvertArgs = true);
   QualType FindCompositePointerType(SourceLocation Loc,
 ExprResult , ExprResult ,
+bool *NonStandardCompositeType = nullptr,
 bool ConvertArgs = true) {
 Expr *E1Tmp = E1.get(), *E2Tmp = E2.get();
-QualType Composite =
-

[PATCH] D25842: [clang] Limit clang test to ARM only

2016-10-20 Thread Renato Golin via cfe-commits
rengolin added inline comments.



Comment at: test/Frontend/gnu-mcount.c:1
+// REQUIRES: arm-registered-target
+

If you have ARM but not AArch64, this test will also fail. Can you use AND on 
REQUIRES?


https://reviews.llvm.org/D25842



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


r284749 - [clang-cl] Fix test that shouldn't be running on non-x86

2016-10-20 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Thu Oct 20 12:41:08 2016
New Revision: 284749

URL: http://llvm.org/viewvc/llvm-project?rev=284749=rev
Log:
[clang-cl] Fix test that shouldn't be running on non-x86

The clang-cl test required x86-registered-target but it defaulted to the
host's triple and AArch64 still doesn't support COFF, so the test failed.

The triple was "aarch64-pc-windows-msvc18.0.0" with ObjectFormat equals
llvm::Triple::COFF, failing assertion:

Assertion `(TT.isOSBinFormatELF() || TT.isOSBinFormatMachO()) &&
  "Only expect Darwin and ELF targets"

in AArch64MCTargetDesc.cpp:78.

Making the test only run on Windows hosts obviously fixes the problem.

Modified:
cfe/trunk/test/Driver/cl-pch.c

Modified: cfe/trunk/test/Driver/cl-pch.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/cl-pch.c?rev=284749=284748=284749=diff
==
--- cfe/trunk/test/Driver/cl-pch.c (original)
+++ cfe/trunk/test/Driver/cl-pch.c Thu Oct 20 12:41:08 2016
@@ -1,4 +1,4 @@
-// REQUIRES: x86-registered-target
+// REQUIRES: system-windows
 //
 // RUN: rm -rf %t
 // RUN: mkdir %t


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


[PATCH] D25761: Use linker flag --fix-cortex-a53-843419 on Android ARM64 compilation.

2016-10-19 Thread Renato Golin via cfe-commits
rengolin added a comment.

In https://reviews.llvm.org/D25761#573903, @srhines wrote:

> > I think "clang -v" will show the linker invocation, with all its flags.
>
> But is there a way to get a dry-run of the linker? I don't want to run 
> /usr/bin/ld for ARM targets. It seems like all of the other linker 
> flag-related tests in tests/Driver/ only work for x86.


I think the combination of -v and -### does that, no?


https://reviews.llvm.org/D25761



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


[PATCH] D25761: Use linker flag --fix-cortex-a53-843419 on Android ARM64 compilation.

2016-10-19 Thread Renato Golin via cfe-commits
rengolin added a comment.

In https://reviews.llvm.org/D25761#573892, @srhines wrote:

> From what I can tell, there is no nice way to generate tests for Clang's 
> driver when producing linker flags. -### only works for the -cc1 command line 
> (which won't see this flag, since it is only for linking, and not 
> compilation). If there is a suggestion for how to automatically test this, I 
> am listening, but all my local tests looked fine (for generating/suppressing 
> the flag). :)


I think "clang -v" will show the linker invocation, with all its flags.


https://reviews.llvm.org/D25761



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


Re: r284335 - [analyzer] Make MallocChecker more robust against custom redeclarations

2016-10-16 Thread Renato Golin via cfe-commits
On 16 October 2016 at 20:36, Devin Coughlin  wrote:
> Reverted in r284340.

Hi Devin,

Sometimes Clang patches break on stage 2 or test-suite, but this is
not the case. I dug deeper and found that there was another commit,
not showing on that range (it should have, but that's nothing to do
with this patch), that broke the bot.

Please, re-commit your patch, and sorry for the noise.

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


Re: r284335 - [analyzer] Make MallocChecker more robust against custom redeclarations

2016-10-16 Thread Renato Golin via cfe-commits
On 16 October 2016 at 18:26, Devin Coughlin via cfe-commits
 wrote:
> Author: dcoughlin
> Date: Sun Oct 16 12:26:06 2016
> New Revision: 284335
>
> URL: http://llvm.org/viewvc/llvm-project?rev=284335=rev
> Log:
> [analyzer] Make MallocChecker more robust against custom redeclarations
>
> Add additional checking to MallocChecker to avoid crashing when memory
> routines have unexpected numbers of arguments. You wouldn't expect to see much
> of this in normal code (-Wincompatible-library-redeclaration warns on this),
> but, for example, CMake tests can generate these.

Hi Devin,

Sounds like yours:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/11121

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


[PATCH] D25479: Guard flag –fdenormal-fp-math with –fno-fast-math

2016-10-13 Thread Renato Golin via cfe-commits
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.

LGTM, thanks!


https://reviews.llvm.org/D25479



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


[PATCH] D25479: Guard flag –fdenormal-fp-math with –fno-fast-math

2016-10-12 Thread Renato Golin via cfe-commits
rengolin added inline comments.



Comment at: test/Driver/denormal-fp-math.c:4
 // RUN: %clang -### -target arm-unknown-linux-gnu -c %s 
-fdenormal-fp-math=positive-zero -v 2>&1 | FileCheck -check-prefix=CHECK-PZ %s
+// RUN: %clang -### -target arm-unknown-linux-gnu -c %s 
-fdenormal-fp-math=ieee -fno-fast-math -v 2>&1 | FileCheck 
-check-prefix=CHECK-NO-UNSAFE %s
 // RUN: not %clang -target arm-unknown-linux-gnu -c %s -fdenormal-fp-math=foo 
-v 2>&1 | FileCheck -check-prefix=CHECK-INVALID %s

Please add all tests that the change is covering.


https://reviews.llvm.org/D25479



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


Re: [clang-tools-extra] r283981 - [ClangTidy] Add UsingInserter and NamespaceAliaser

2016-10-12 Thread Renato Golin via cfe-commits
On 12 October 2016 at 08:59, Haojian Wu via cfe-commits
 wrote:
> Author: hokein
> Date: Wed Oct 12 02:59:54 2016
> New Revision: 283981
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283981=rev
> Log:
> [ClangTidy] Add UsingInserter and NamespaceAliaser

Hi Haojian,

Many, if not all buildbots building Clang *also* build
clang-tools-extra. Any commit you make to your projects are bound to
affect many more buildbots than you would expect. So I'm asking you to
be careful with your commits, as this is not the first time.

One rule of thumb that I took it to heart very early on, after making
the same mistakes myself, is to *always* build and test someone else's
patch on my machine, in a configuration that is likely to be present
in most buildbots.

That practically means the following:

1. Have a check-out with LLVM+Clang+RT
2. Update it to the latest trunk, apply the patch
2.1 If it doesn't apply cleanly, refuse the patch, ask to rebase (you
could rebase it wrong and not notice, I've done that)
2.2 The original author rebases and updates the review
2.3 Goto 2
3. Run "make check-all" and it has to pass.
4. Commit, and hope for the best.

If even after that, it broke some obscure buildbot, that's life, we
can deal with that.

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


Re: r283827 - [Driver][Diagnostics] Make 'show option names' default for driver warnings

2016-10-11 Thread Renato Golin via cfe-commits
On 11 October 2016 at 16:34, Bruno Cardoso Lopes
 wrote:
> Thanks Renato!

So, Daniel Jasper did a trick on r283853 (clang || true) to make it
not fail when it returns on error. However, I wasn't able to make it
return anything but 0, so I'm at odds why this fails on the bot.

I was expecting it to actually return non-zero, since it emits an
error, which is even weirder. So, using "not clang" doesn't work in
this case. Do you have any ideas why this behaviour is like that?

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


Re: r283853 - Explicitly ignore return code in test for test systems that use pipefail

2016-10-11 Thread Renato Golin via cfe-commits
On 11 October 2016 at 12:39, Daniel Jasper  wrote:
> Just because I don't know shell very well :). Feel free to use "not"
> instead.

Ah, ok. I'll reapply. :)

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


Re: r283853 - Explicitly ignore return code in test for test systems that use pipefail

2016-10-11 Thread Renato Golin via cfe-commits
On 11 October 2016 at 07:13, Daniel Jasper via cfe-commits
 wrote:
> Author: djasper
> Date: Tue Oct 11 01:13:18 2016
> New Revision: 283853
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283853=rev
> Log:
> Explicitly ignore return code in test for test systems that use pipefail

Hi Daniel,

I missed this commit and reverted the original patch.

However, before we reapply, why not use "not" instead of "|| true" ?

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


Re: r283827 - [Driver][Diagnostics] Make 'show option names' default for driver warnings

2016-10-11 Thread Renato Golin via cfe-commits
On 11 October 2016 at 10:14, Renato Golin  wrote:
> clang-4.0: warning: no such sysroot directory: '/FOO' [-Wmissing-sysroot]
> error: unable to create target: 'No available targets are compatible
> with this triple.'
> 1 error generated.

Reverted in r283868, as it was also breaking ARM bots.

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


r283868 - Revert "[Driver][Diagnostics] Make 'show option names' default for driver warnings"

2016-10-11 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Tue Oct 11 05:26:33 2016
New Revision: 283868

URL: http://llvm.org/viewvc/llvm-project?rev=283868=rev
Log:
Revert "[Driver][Diagnostics] Make 'show option names' default for driver 
warnings"

This reverts commit r283827, as it's breaking all ARM/AARch64 bots.

Removed:
cfe/trunk/test/Driver/show-option-names.c
Modified:
cfe/trunk/include/clang/Frontend/CompilerInvocation.h
cfe/trunk/lib/Frontend/CompilerInvocation.cpp

Modified: cfe/trunk/include/clang/Frontend/CompilerInvocation.h
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/include/clang/Frontend/CompilerInvocation.h?rev=283868=283867=283868=diff
==
--- cfe/trunk/include/clang/Frontend/CompilerInvocation.h (original)
+++ cfe/trunk/include/clang/Frontend/CompilerInvocation.h Tue Oct 11 05:26:33 
2016
@@ -48,8 +48,7 @@ class DiagnosticsEngine;
 /// report the error(s).
 bool ParseDiagnosticArgs(DiagnosticOptions , llvm::opt::ArgList ,
  DiagnosticsEngine *Diags = nullptr,
- bool DefaultDiagColor = true,
- bool DefaultShowOpt = true);
+ bool DefaultDiagColor = true);
 
 class CompilerInvocationBase : public RefCountedBase {
   void operator=(const CompilerInvocationBase &) = delete;

Modified: cfe/trunk/lib/Frontend/CompilerInvocation.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Frontend/CompilerInvocation.cpp?rev=283868=283867=283868=diff
==
--- cfe/trunk/lib/Frontend/CompilerInvocation.cpp (original)
+++ cfe/trunk/lib/Frontend/CompilerInvocation.cpp Tue Oct 11 05:26:33 2016
@@ -957,7 +957,7 @@ static bool parseShowColorsArgs(const Ar
 
 bool clang::ParseDiagnosticArgs(DiagnosticOptions , ArgList ,
 DiagnosticsEngine *Diags,
-bool DefaultDiagColor, bool DefaultShowOpt) {
+bool DefaultDiagColor) {
   using namespace options;
   bool Success = true;
 
@@ -977,9 +977,7 @@ bool clang::ParseDiagnosticArgs(Diagnost
   Opts.ShowFixits = !Args.hasArg(OPT_fno_diagnostics_fixit_info);
   Opts.ShowLocation = !Args.hasArg(OPT_fno_show_source_location);
   Opts.AbsolutePath = Args.hasArg(OPT_fdiagnostics_absolute_paths);
-  Opts.ShowOptionNames =
-  Args.hasFlag(OPT_fdiagnostics_show_option,
-   OPT_fno_diagnostics_show_option, DefaultShowOpt);
+  Opts.ShowOptionNames = Args.hasArg(OPT_fdiagnostics_show_option);
 
   llvm::sys::Process::UseANSIEscapeCodes(Args.hasArg(OPT_fansi_escape_codes));
 
@@ -2406,9 +2404,8 @@ bool CompilerInvocation::CreateFromArgs(
   Success &= ParseAnalyzerArgs(*Res.getAnalyzerOpts(), Args, Diags);
   Success &= ParseMigratorArgs(Res.getMigratorOpts(), Args);
   ParseDependencyOutputArgs(Res.getDependencyOutputOpts(), Args);
-  Success &=
-  ParseDiagnosticArgs(Res.getDiagnosticOpts(), Args, ,
-  false /*DefaultDiagColor*/, false 
/*DefaultShowOpt*/);
+  Success &= ParseDiagnosticArgs(Res.getDiagnosticOpts(), Args, ,
+ false /*DefaultDiagColor*/);
   ParseCommentArgs(LangOpts.CommentOpts, Args);
   ParseFileSystemArgs(Res.getFileSystemOpts(), Args);
   // FIXME: We shouldn't have to pass the DashX option around here

Removed: cfe/trunk/test/Driver/show-option-names.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Driver/show-option-names.c?rev=283867=auto
==
--- cfe/trunk/test/Driver/show-option-names.c (original)
+++ cfe/trunk/test/Driver/show-option-names.c (removed)
@@ -1,5 +0,0 @@
-// RUN: (%clang -c -target i386-apple-darwin10 -isysroot /FOO %s 2>&1 || true) 
| FileCheck --check-prefix=CHECK-SHOW-OPTION-NAMES %s
-// CHECK-SHOW-OPTION-NAMES: warning: no such sysroot directory: 
'{{([A-Za-z]:.*)?}}/FOO' [-Wmissing-sysroot]
-
-// RUN: (%clang -c -target i386-apple-darwin10 -fno-diagnostics-show-option 
-isysroot /FOO %s 2>&1 || true) | FileCheck 
--check-prefix=CHECK-NO-SHOW-OPTION-NAMES %s
-// CHECK-NO-SHOW-OPTION-NAMES: warning: no such sysroot directory: 
'{{([A-Za-z]:.*)?}}/FOO'{{$}}


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


Re: r283827 - [Driver][Diagnostics] Make 'show option names' default for driver warnings

2016-10-11 Thread Renato Golin via cfe-commits
On 11 October 2016 at 01:01, Bruno Cardoso Lopes via cfe-commits
 wrote:
> Author: bruno
> Date: Mon Oct 10 19:01:22 2016
> New Revision: 283827
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283827=rev
> Log:
> [Driver][Diagnostics] Make 'show option names' default for driver warnings
>
> Currently, driver level warnings do not show option names (e.g. warning:
> complain about foo [-Woption-name]) in a diagnostic unless
> -fdiagnostics-show-option is explictly specified. OTOH, the driver by
> default turn this option on for CC1. Change the logic to show option
> names by default in the driver as well.
>
> Differential Revision: https://reviews.llvm.org/D24516

Hi Bruno,

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/3292

clang-4.0: warning: no such sysroot directory: '/FOO' [-Wmissing-sysroot]
error: unable to create target: 'No available targets are compatible
with this triple.'
1 error generated.

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


Re: r283753 - Revert r283683 because r283680 got reverted.

2016-10-10 Thread Renato Golin via cfe-commits
On 10 October 2016 at 15:20, Nico Weber via cfe-commits
 wrote:
> Author: nico
> Date: Mon Oct 10 09:20:35 2016
> New Revision: 283753
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283753=rev
> Log:
> Revert r283683 because r283680 got reverted.

Great commit message! :D
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [libcxx] r283659 - [cmake] Split linked libraries into private & public, for linker script

2016-10-08 Thread Renato Golin via cfe-commits
On 8 October 2016 at 11:27, Michal Gorny via cfe-commits
 wrote:
> Author: mgorny
> Date: Sat Oct  8 05:27:45 2016
> New Revision: 283659
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283659=rev
> Log:
> [cmake] Split linked libraries into private & public, for linker script
>
> Introduce LIBCXX_LIBRARIES_PUBLIC in addition to LIBCXX_LIBRARIES that
> holds 'public' interface libraries -- that is, libraries that both
> libc++ links to and programs linked against it need to link to.
>
> Currently this includes the ABI library and optionally -lunwind (when
> LIBCXXABI_USE_LLVM_UNWINDER is on). The libraries are included in the
> linker script, in order to make it possible to link C++ programs using
> clang with compiler-rt runtime out-of-the-box.
>
> Differential Revision: https://reviews.llvm.org/D25008

Hum, this seems to have broken our unwind finder:

http://lab.llvm.org:8011/builders/libcxx-libcxxabi-libunwind-arm-linux/builds/205

[100%] Linking CXX shared library ../../../lib/libc++.so
[100%] Linking CXX static library ../../../lib/libc++.a
/usr/bin/ld: cannot find -lunwind
clang-3.8: error: linker command failed with exit code 1 (use -v to
see invocation)

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


Re: [clang-tools-extra] r283534 - Fix buildbot error.

2016-10-07 Thread Renato Golin via cfe-commits
On 7 October 2016 at 13:06, Renato Golin  wrote:
> On 7 October 2016 at 10:23, Haojian Wu via cfe-commits
>  wrote:
>> Author: hokein
>> Date: Fri Oct  7 04:23:28 2016
>> New Revision: 283534
>>
>> URL: http://llvm.org/viewvc/llvm-project?rev=283534=rev
>> Log:
>> Fix buildbot error.
>>
>> The error maybe caused by the mixed environment of the two lint tests.
>> Cleanup the environment before running each test.
>
> Hi,
>
> Can you revert all changes and test it again on your machine before
> pushing it upstream?
>
> Your changes and reverts are really upsetting all our buildbots and
> making them completely unstable.

Right, your tests were breaking all over the place on ranges that had
nothing to do with your commits, so I reverted on r283553.

Please let me know if you need help with tests before you commit it again.

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


[clang-tools-extra] r283553 - Revert "[clang-move] Support moving multiple classes in one run."

2016-10-07 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Fri Oct  7 08:58:10 2016
New Revision: 283553

URL: http://llvm.org/viewvc/llvm-project?rev=283553=rev
Log:
Revert "[clang-move] Support moving multiple classes in one run."

This reverts commit r283526 et al as it keeps randomly breaking bots, even after
the commit has gone, on other people's commit ranges.

Revert "[clang-move] Simplify lint tests" (r283545).
Revert "Fix buildbot error." (r283534).
Revert "Revert "fix buildbot error" since it is not right fix." (r283538).

Added:
clang-tools-extra/trunk/test/clang-move/Inputs/database_template.json
Removed:
clang-tools-extra/trunk/test/clang-move/Inputs/multiple_class_test.cpp
clang-tools-extra/trunk/test/clang-move/Inputs/multiple_class_test.h
clang-tools-extra/trunk/test/clang-move/move-multiple-classes.cpp
Modified:
clang-tools-extra/trunk/clang-move/ClangMove.cpp
clang-tools-extra/trunk/clang-move/ClangMove.h
clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp
clang-tools-extra/trunk/test/clang-move/move-class.cpp
clang-tools-extra/trunk/unittests/clang-move/ClangMoveTests.cpp

Modified: clang-tools-extra/trunk/clang-move/ClangMove.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-move/ClangMove.cpp?rev=283553=283552=283553=diff
==
--- clang-tools-extra/trunk/clang-move/ClangMove.cpp (original)
+++ clang-tools-extra/trunk/clang-move/ClangMove.cpp Fri Oct  7 08:58:10 2016
@@ -287,43 +287,31 @@ ClangMoveTool::ClangMoveTool(
 : Spec(MoveSpec), FileToReplacements(FileToReplacements),
   OriginalRunningDirectory(OriginalRunningDirectory),
   FallbackStyle(FallbackStyle) {
+  Spec.Name = llvm::StringRef(Spec.Name).ltrim(':');
   if (!Spec.NewHeader.empty())
 CCIncludes.push_back("#include \"" + Spec.NewHeader + "\"\n");
 }
 
 void ClangMoveTool::registerMatchers(ast_matchers::MatchFinder *Finder) {
-  SmallVector ClassNames;
-  llvm::StringRef(Spec.Names).split(ClassNames, ',');
-  Optional InMovedClassNames;
-  for (StringRef ClassName : ClassNames) {
-llvm::StringRef GlobalClassName = ClassName.trim().ltrim(':');
-const auto HasName = hasName(("::" + GlobalClassName).str());
-InMovedClassNames =
-InMovedClassNames ? anyOf(*InMovedClassNames, HasName) : HasName;
-  }
-  if (!InMovedClassNames) {
-llvm::errs() << "No classes being moved.\n";
-return;
-  }
-
+  std::string FullyQualifiedName = "::" + Spec.Name;
   auto InOldHeader = isExpansionInFile(
   MakeAbsolutePath(OriginalRunningDirectory, Spec.OldHeader));
   auto InOldCC = isExpansionInFile(
   MakeAbsolutePath(OriginalRunningDirectory, Spec.OldCC));
   auto InOldFiles = anyOf(InOldHeader, InOldCC);
   auto InMovedClass =
-  hasDeclContext(cxxRecordDecl(*InMovedClassNames));
+  hasDeclContext(cxxRecordDecl(hasName(FullyQualifiedName)));
 
   // Match moved class declarations.
   auto MovedClass = cxxRecordDecl(
-  InOldFiles, *InMovedClassNames, isDefinition(),
+  InOldFiles, hasName(FullyQualifiedName), isDefinition(),
   hasDeclContext(anyOf(namespaceDecl(), translationUnitDecl(;
   Finder->addMatcher(MovedClass.bind("moved_class"), this);
 
   // Match moved class methods (static methods included) which are defined
   // outside moved class declaration.
   Finder->addMatcher(cxxMethodDecl(InOldFiles,
-   ofClass(*InMovedClassNames),
+   ofClass(hasName(FullyQualifiedName)),
isDefinition())
  .bind("class_method"),
  this);

Modified: clang-tools-extra/trunk/clang-move/ClangMove.h
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-move/ClangMove.h?rev=283553=283552=283553=diff
==
--- clang-tools-extra/trunk/clang-move/ClangMove.h (original)
+++ clang-tools-extra/trunk/clang-move/ClangMove.h Fri Oct  7 08:58:10 2016
@@ -37,9 +37,8 @@ public:
   };
 
   struct MoveDefinitionSpec {
-// A comma-separated list of fully qualified names, e.g. "Foo",
-// "a::Foo, b::Foo".
-std::string Names;
+// A fully qualified name, e.g. "X", "a::X".
+std::string Name;
 // The file path of old header, can be relative path and absolute path.
 std::string OldHeader;
 // The file path of old cc, can be relative path and absolute path.

Modified: clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp
URL: 
http://llvm.org/viewvc/llvm-project/clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp?rev=283553=283552=283553=diff
==
--- clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp (original)
+++ clang-tools-extra/trunk/clang-move/tool/ClangMoveMain.cpp Fri Oct  7 
08:58:10 2016
@@ 

Re: [clang-tools-extra] r283534 - Fix buildbot error.

2016-10-07 Thread Renato Golin via cfe-commits
On 7 October 2016 at 10:23, Haojian Wu via cfe-commits
 wrote:
> Author: hokein
> Date: Fri Oct  7 04:23:28 2016
> New Revision: 283534
>
> URL: http://llvm.org/viewvc/llvm-project?rev=283534=rev
> Log:
> Fix buildbot error.
>
> The error maybe caused by the mixed environment of the two lint tests.
> Cleanup the environment before running each test.

Hi,

Can you revert all changes and test it again on your machine before
pushing it upstream?

Your changes and reverts are really upsetting all our buildbots and
making them completely unstable.

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


[PATCH] D25254: test-suite: Change extension used for reference outputs by Makefile-based harness so we can start improving how the CMake-based harness works without breaking the old system or the bui

2016-10-05 Thread Renato Golin via cfe-commits
rengolin added a comment.

Can you expand on how you plan to add the second set of reference outputs?

We already have multiple reference outputs, for example big endian vs. little 
endian. I was expecting you to have done a similar thing, which doesn't involve 
changing every single reference file. :)

One way this could be simpler is to change the Makefile on each affected 
directories to duplicate the tests & check differently against the reference 
file. It can be the same reference, but with different thresholds for different 
fp-contract options.


https://reviews.llvm.org/D25254



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


[PATCH] D24998: Add a new optimization option -Og

2016-10-04 Thread Renato Golin via cfe-commits
rengolin added reviewers: echristo, dberlin, keith.walker.arm.
rengolin added a comment.

Hi Sylvestre,

Paul's comments on the bug are still pertinent: `-Og` is not the same as `-O1`.

`-Og` means for "optimised for debuggers" which is short for "preserve the 
debug illusion without bloating the code". This is not at all what `-O1` is, 
even though they're used indistinguishably via `-O1 -g`.

As a stop-gap, I guess having `-Og == -O1` would stop errors from being 
reported, but if we could do a quick assessment on the list to make sure this 
has the expected semantics (and adding a full new option if not), would be the 
best way forward.

I'm adding a few debug folks here, in hope they have a better idea (and would 
add more folks, if necessary). :)

cheers,
--renato


https://reviews.llvm.org/D24998



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


[PATCH] D24084: [CMake] Cleanup libunwind lookup code.

2016-10-04 Thread Renato Golin via cfe-commits
rengolin added a comment.

@EricWF any comments?


https://reviews.llvm.org/D24084



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


[PATCH] D24083: [CMake] Fix libc++abi __aeabi_idiv() link error.

2016-10-04 Thread Renato Golin via cfe-commits
rengolin added a comment.

In https://reviews.llvm.org/D24083#534464, @EricWF wrote:

> In https://reviews.llvm.org/D24083#534459, @logan wrote:
>
> > One solution might be adding the `libclang_rt.builtins.${arch}.a` detection 
> > rules[1] to CMakeLists.txt, and manually specify 
> > `-lclang_rt.builtins-${arch}.a` when `LIBCXXABI_USE_COMPILER_RT` is 
> > enabled.  How do you think about this solution?
>
>
> That SGTM. There's a similar workaround in libc++ to link the sanitizer 
> run-times on OS X (found here 
> ).


+1


https://reviews.llvm.org/D24083



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


[PATCH] D22272: ARM: define __ARM_VFPV5__ when present.

2016-10-04 Thread Renato Golin via cfe-commits
rengolin accepted this revision.
rengolin added a comment.
This revision is now accepted and ready to land.

Hi Tim,

This patch seems stale. I think neither me nor Richard have any strong feelings 
against this, so I'll just approve and let you decide on which solution is 
best. I have a mild preference for both.

cheers,
--renato


https://reviews.llvm.org/D22272



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


Re: Broken bot

2016-09-23 Thread Renato Golin via cfe-commits
Funny, git-svnrevert is buggy, I had to do it by hand, but now it's
done: r282289.

Let me know if you need help testing it.

--renato

On 23 September 2016 at 21:28, Renato Golin  wrote:
> Now has broken the other:
>
> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/3162
>
> But when I try to revert, git get entangled with another commit and
> brings a lot of unrelated changes to it.
>
> I'll continue trying to revert, but if you can do it faster, I'd appreciate.
>
> thanks!
> --renato
>
> On 23 September 2016 at 20:04, Renato Golin  wrote:
>> Hi Sebastian,
>>
>> This commit:
>>
>> http://llvm.org/viewvc/llvm-project?revision=282259=revision
>>
>> Has broken our AArch64 bot:
>>
>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/10449
>>
>> But the cfe part seems odd, and I can't revert. Can you please have a look?
>>
>> cheers,
>> --renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: [PATCH] D24481: make “#pragma STDC FP_CONTRACT” on by default

2016-09-23 Thread Renato Golin via cfe-commits
rengolin added a subscriber: rengolin.
rengolin added a comment.

Folks, this commit has broken both AArch64 test-suite buildbots:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/3162

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/10449

I have reverted in r282289, let me know if you need help testing on AArch64.


Repository:
  rL LLVM

https://reviews.llvm.org/D24481



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


Re: Broken bot

2016-09-23 Thread Renato Golin via cfe-commits
Now has broken the other:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-full/builds/3162

But when I try to revert, git get entangled with another commit and
brings a lot of unrelated changes to it.

I'll continue trying to revert, but if you can do it faster, I'd appreciate.

thanks!
--renato

On 23 September 2016 at 20:04, Renato Golin  wrote:
> Hi Sebastian,
>
> This commit:
>
> http://llvm.org/viewvc/llvm-project?revision=282259=revision
>
> Has broken our AArch64 bot:
>
> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/10449
>
> But the cfe part seems odd, and I can't revert. Can you please have a look?
>
> cheers,
> --renato
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r282255 - Fix for r280064 that added options for fp denormals and exceptions.

2016-09-23 Thread Renato Golin via cfe-commits
On 23 September 2016 at 17:12, Sjoerd Meijer  wrote:
> I don't think I am committing at will:  I thought it was okay to commit 
> directly because it is a simple fix (or should be) for my own  previous 
> half-working patch, but I don't mind going through phab.

A review would have caught many issues with this patch, for example,
the no default issue, and the fact that it has no tests at all.

As a rule of thumb, wait until you get several no-comments-LGTM
reviews in a row in the same area to start committing small patches
before review in that area. Just a few changes isn't enough.


> I am indeed suspecting it is missing default case (probably got confused 
> because e.g. ThreadModel also doesn't have one, at least not there).

Please, also do a build on ARM, and at least try to run check-all, as
that will catch most bugs. And don't forget to add tests.

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


Re: r282255 - Fix for r280064 that added options for fp denormals and exceptions.

2016-09-23 Thread Renato Golin via cfe-commits
On 23 September 2016 at 16:21, Sjoerd Meijer via cfe-commits
 wrote:
> Author: sjoerdmeijer
> Date: Fri Sep 23 10:21:33 2016
> New Revision: 282255
>
> URL: http://llvm.org/viewvc/llvm-project?rev=282255=rev
> Log:
> Fix for r280064 that added options for fp denormals and exceptions.
> These options were forgotten to be copied in setCommandLineOpts.

This broke:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/12164


> +  Options.FPDenormalType =
> +
> llvm::StringSwitch(CodeGenOpts.FPDenormalMode)
> +  .Case("ieee", llvm::FPDenormal::IEEE)
> +  .Case("preserve-sign", llvm::FPDenormal::PreserveSign)
> +  .Case("positive-zero", llvm::FPDenormal::PositiveZero);

No Default case?



> +  Options.NoTrappingFPMath = CodeGenOpts.NoTrappingMath;

This is not the same as the one above. Are you sure this patch is correct?

Has this been reviewed at all?

Please, don't commit patches at will when nothing is breaking, and put
the patch for review next time.

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


r282184 - [OpenBSD] Add type sign information for OpenBSD

2016-09-22 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Thu Sep 22 14:28:20 2016
New Revision: 282184

URL: http://llvm.org/viewvc/llvm-project?rev=282184=rev
Log:
[OpenBSD] Add type sign information for OpenBSD

Like NetBSD, OpenBSD prefers having a consistent set of typedefs
across the architectures it supports over strictly following the ARM
ABIs.  The diff below makes sure that clang's view of those types
matches OpenBSD's system header files.  It also adds a test that
checks the relevant types on all OpenBSD platforms that clang works
on.  Hopefully we can add mips64 and powerpc to that list in the
future.

Patch by Mark Kettenis 

Modified:
cfe/trunk/lib/Basic/Targets.cpp
cfe/trunk/test/Preprocessor/init.c

Modified: cfe/trunk/lib/Basic/Targets.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/lib/Basic/Targets.cpp?rev=282184=282183=282184=diff
==
--- cfe/trunk/lib/Basic/Targets.cpp (original)
+++ cfe/trunk/lib/Basic/Targets.cpp Thu Sep 22 14:28:20 2016
@@ -4679,8 +4679,10 @@ class ARMTargetInfo : public TargetInfo
 DoubleAlign = LongLongAlign = LongDoubleAlign = SuitableAlign = 64;
 const llvm::Triple  = getTriple();
 
-// size_t is unsigned long on MachO-derived environments, NetBSD and 
Bitrig.
+// size_t is unsigned long on MachO-derived environments, NetBSD,
+// OpenBSD and Bitrig.
 if (T.isOSBinFormatMachO() || T.getOS() == llvm::Triple::NetBSD ||
+T.getOS() == llvm::Triple::OpenBSD ||
 T.getOS() == llvm::Triple::Bitrig)
   SizeType = UnsignedLong;
 else
@@ -4688,6 +4690,7 @@ class ARMTargetInfo : public TargetInfo
 
 switch (T.getOS()) {
 case llvm::Triple::NetBSD:
+case llvm::Triple::OpenBSD:
   WCharType = SignedInt;
   break;
 case llvm::Triple::Win32:
@@ -4885,6 +4888,7 @@ public:
 
 switch (getTriple().getOS()) {
 case llvm::Triple::NetBSD:
+case llvm::Triple::OpenBSD:
   PtrDiffType = SignedLong;
   break;
 default:

Modified: cfe/trunk/test/Preprocessor/init.c
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/Preprocessor/init.c?rev=282184=282183=282184=diff
==
--- cfe/trunk/test/Preprocessor/init.c (original)
+++ cfe/trunk/test/Preprocessor/init.c Thu Sep 22 14:28:20 2016
@@ -8463,6 +8463,29 @@
 // RUN: %clang_cc1 -triple lanai-unknown-unknown -E -dM < /dev/null | 
FileCheck -match-full-lines -check-prefix LANAI %s
 // LANAI: #define __lanai__ 1
 //
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=amd64-unknown-openbsd6.1 < 
/dev/null | FileCheck -match-full-lines -check-prefix OPENBSD %s
+// RUN: %clang_cc1 -E -dM -ffreestanding 
-triple=arm-unknown-openbsd6.1-gnueabi < /dev/null | FileCheck 
-match-full-lines -check-prefix OPENBSD %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=i386-unknown-openbsd6.1 < 
/dev/null | FileCheck -match-full-lines -check-prefix OPENBSD %s
+// RUN: %clang_cc1 -E -dM -ffreestanding -triple=sparc64-unknown-openbsd6.1 < 
/dev/null | FileCheck -match-full-lines -check-prefix OPENBSD %s
+// OPENBSD:#define __ELF__ 1
+// OPENBSD:#define __INT16_TYPE__ short
+// OPENBSD:#define __INT32_TYPE__ int
+// OPENBSD:#define __INT64_TYPE__ long long int
+// OPENBSD:#define __INT8_TYPE__ signed char
+// OPENBSD:#define __INTMAX_TYPE__ long long int
+// OPENBSD:#define __INTPTR_TYPE__ long int
+// OPENBSD:#define __OpenBSD__ 1
+// OPENBSD:#define __PTRDIFF_TYPE__ long int
+// OPENBSD:#define __SIZE_TYPE__ long unsigned int
+// OPENBSD:#define __UINT16_TYPE__ unsigned short
+// OPENBSD:#define __UINT32_TYPE__ unsigned int
+// OPENBSD:#define __UINT64_TYPE__ long long unsigned int
+// OPENBSD:#define __UINT8_TYPE__ unsigned char
+// OPENBSD:#define __UINTMAX_TYPE__ long long unsigned int
+// OPENBSD:#define __UINTPTR_TYPE__ long unsigned int
+// OPENBSD:#define __WCHAR_TYPE__ int
+// OPENBSD:#define __WINT_TYPE__ int
+//
 // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd < 
/dev/null | FileCheck -match-full-lines -check-prefix PPC64-FREEBSD %s
 // PPC64-FREEBSD-NOT: #define __LONG_DOUBLE_128__ 1
 //


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


Re: OpenBSD/arm types

2016-09-22 Thread Renato Golin via cfe-commits
On 22 September 2016 at 16:19, Mark Kettenis  wrote:
> No I don't.

No problems. Committed in r282184.

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


Re: OpenBSD/arm types

2016-09-22 Thread Renato Golin via cfe-commits
Hi Mark,

It seems not many people have additional comments, so LGTM.

Do you have commit access?

cheers,
--renato

On 20 September 2016 at 19:41, Mark Kettenis via cfe-commits
 wrote:
> As discussed in cfe-dev@:
>
> Like NetBSD, OpenBSD prefers having a consistent set of typedefs
> across the architectures it supports over strictly following the ARM
> ABIs.  The diff below makes sure that clang's view of those types
> matches OpenBSD's system header files.  It also adds a test that
> checks the relevant types on all OpenBSD platforms that clang works
> on.  Hopefully we can add mips64 and powerpc to that list in the
> future.
>
>
> Index: lib/Basic/Targets.cpp
> ===
> --- lib/Basic/Targets.cpp   (revision 281825)
> +++ lib/Basic/Targets.cpp   (working copy)
> @@ -4679,8 +4679,10 @@
>  DoubleAlign = LongLongAlign = LongDoubleAlign = SuitableAlign = 64;
>  const llvm::Triple  = getTriple();
>
> -// size_t is unsigned long on MachO-derived environments, NetBSD and 
> Bitrig.
> +// size_t is unsigned long on MachO-derived environments, NetBSD,
> +// OpenBSD and Bitrig.
>  if (T.isOSBinFormatMachO() || T.getOS() == llvm::Triple::NetBSD ||
> +T.getOS() == llvm::Triple::OpenBSD ||
>  T.getOS() == llvm::Triple::Bitrig)
>SizeType = UnsignedLong;
>  else
> @@ -4688,6 +4690,7 @@
>
>  switch (T.getOS()) {
>  case llvm::Triple::NetBSD:
> +case llvm::Triple::OpenBSD:
>WCharType = SignedInt;
>break;
>  case llvm::Triple::Win32:
> @@ -4885,6 +4888,7 @@
>
>  switch (getTriple().getOS()) {
>  case llvm::Triple::NetBSD:
> +case llvm::Triple::OpenBSD:
>PtrDiffType = SignedLong;
>break;
>  default:
> Index: test/Preprocessor/init.c
> ===
> --- test/Preprocessor/init.c(revision 281825)
> +++ test/Preprocessor/init.c(working copy)
> @@ -8463,6 +8463,29 @@
>  // RUN: %clang_cc1 -triple lanai-unknown-unknown -E -dM < /dev/null | 
> FileCheck -match-full-lines -check-prefix LANAI %s
>  // LANAI: #define __lanai__ 1
>  //
> +// RUN: %clang_cc1 -E -dM -ffreestanding -triple=amd64-unknown-openbsd6.1 < 
> /dev/null | FileCheck -match-full-lines -check-prefix OPENBSD %s
> +// RUN: %clang_cc1 -E -dM -ffreestanding 
> -triple=arm-unknown-openbsd6.1-gnueabi < /dev/null | FileCheck 
> -match-full-lines -check-prefix OPENBSD %s
> +// RUN: %clang_cc1 -E -dM -ffreestanding -triple=i386-unknown-openbsd6.1 < 
> /dev/null | FileCheck -match-full-lines -check-prefix OPENBSD %s
> +// RUN: %clang_cc1 -E -dM -ffreestanding -triple=sparc64-unknown-openbsd6.1 
> < /dev/null | FileCheck -match-full-lines -check-prefix OPENBSD %s
> +// OPENBSD:#define __ELF__ 1
> +// OPENBSD:#define __INT16_TYPE__ short
> +// OPENBSD:#define __INT32_TYPE__ int
> +// OPENBSD:#define __INT64_TYPE__ long long int
> +// OPENBSD:#define __INT8_TYPE__ signed char
> +// OPENBSD:#define __INTMAX_TYPE__ long long int
> +// OPENBSD:#define __INTPTR_TYPE__ long int
> +// OPENBSD:#define __OpenBSD__ 1
> +// OPENBSD:#define __PTRDIFF_TYPE__ long int
> +// OPENBSD:#define __SIZE_TYPE__ long unsigned int
> +// OPENBSD:#define __UINT16_TYPE__ unsigned short
> +// OPENBSD:#define __UINT32_TYPE__ unsigned int
> +// OPENBSD:#define __UINT64_TYPE__ long long unsigned int
> +// OPENBSD:#define __UINT8_TYPE__ unsigned char
> +// OPENBSD:#define __UINTMAX_TYPE__ long long unsigned int
> +// OPENBSD:#define __UINTPTR_TYPE__ long unsigned int
> +// OPENBSD:#define __WCHAR_TYPE__ int
> +// OPENBSD:#define __WINT_TYPE__ int
> +//
>  // RUN: %clang_cc1 -E -dM -ffreestanding -triple=powerpc64-unknown-freebsd < 
> /dev/null | FileCheck -match-full-lines -check-prefix PPC64-FREEBSD %s
>  // PPC64-FREEBSD-NOT: #define __LONG_DOUBLE_128__ 1
>  //
> ___
> 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


[libunwind] r281346 - [3.9.1] Merge r279871 - [ARM] Adding .arch directives around WMMX unwind code

2016-09-13 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Tue Sep 13 10:40:36 2016
New Revision: 281346

URL: http://llvm.org/viewvc/llvm-project?rev=281346=rev
Log:
[3.9.1] Merge r279871 - [ARM] Adding .arch directives around WMMX unwind code

Modified:
libunwind/branches/release_39/src/UnwindRegistersRestore.S
libunwind/branches/release_39/src/UnwindRegistersSave.S

Modified: libunwind/branches/release_39/src/UnwindRegistersRestore.S
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_39/src/UnwindRegistersRestore.S?rev=281346=281345=281346=diff
==
--- libunwind/branches/release_39/src/UnwindRegistersRestore.S (original)
+++ libunwind/branches/release_39/src/UnwindRegistersRestore.S Tue Sep 13 
10:40:36 2016
@@ -392,6 +392,7 @@ DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9li
 @  values pointer is in r0
 @
   .p2align 2
+  .arch armv5te
 
DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm12restoreiWMMXEPy)
   ldcl p1, cr0, [r0], #8  @ wldrd wR0, [r0], #8
   ldcl p1, cr1, [r0], #8  @ wldrd wR1, [r0], #8
@@ -418,6 +419,7 @@ DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9li
 @  values pointer is in r0
 @
   .p2align 2
+  .arch armv5te
 
DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm19restoreiWMMXControlEPj)
   ldc2 p1, cr8, [r0], #4  @ wldrw wCGR0, [r0], #4
   ldc2 p1, cr9, [r0], #4  @ wldrw wCGR1, [r0], #4

Modified: libunwind/branches/release_39/src/UnwindRegistersSave.S
URL: 
http://llvm.org/viewvc/llvm-project/libunwind/branches/release_39/src/UnwindRegistersSave.S?rev=281346=281345=281346=diff
==
--- libunwind/branches/release_39/src/UnwindRegistersSave.S (original)
+++ libunwind/branches/release_39/src/UnwindRegistersSave.S Tue Sep 13 10:40:36 
2016
@@ -387,6 +387,7 @@ DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9li
 @  values pointer is in r0
 @
   .p2align 2
+  .arch armv5te
 DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm9saveiWMMXEPy)
   stcl p1, cr0, [r0], #8  @ wstrd wR0, [r0], #8
   stcl p1, cr1, [r0], #8  @ wstrd wR1, [r0], #8
@@ -413,6 +414,7 @@ DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9li
 @  values pointer is in r0
 @
   .p2align 2
+  .arch armv5te
 
DEFINE_LIBUNWIND_PRIVATE_FUNCTION(_ZN9libunwind13Registers_arm16saveiWMMXControlEPj)
   stc2 p1, cr8, [r0], #4  @ wstrw wCGR0, [r0], #4
   stc2 p1, cr9, [r0], #4  @ wstrw wCGR1, [r0], #4


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


r280968 - Revert "[XRay] ARM 32-bit no-Thumb support in Clang"

2016-09-08 Thread Renato Golin via cfe-commits
Author: rengolin
Date: Thu Sep  8 12:12:32 2016
New Revision: 280968

URL: http://llvm.org/viewvc/llvm-project?rev=280968=rev
Log:
Revert "[XRay] ARM 32-bit no-Thumb support in Clang"

This reverts commit r280889, as the original LLVM commits broke the thumb
buildbots.

Removed:
cfe/trunk/test/CodeGen/xray-attributes-supported-arm.cpp

Removed: cfe/trunk/test/CodeGen/xray-attributes-supported-arm.cpp
URL: 
http://llvm.org/viewvc/llvm-project/cfe/trunk/test/CodeGen/xray-attributes-supported-arm.cpp?rev=280967=auto
==
--- cfe/trunk/test/CodeGen/xray-attributes-supported-arm.cpp (original)
+++ cfe/trunk/test/CodeGen/xray-attributes-supported-arm.cpp (removed)
@@ -1,13 +0,0 @@
-// RUN: %clang_cc1 %s -fxray-instrument -std=c++11 -x c++ -emit-llvm -o - 
-triple arm-unknown-linux-gnu | FileCheck %s
-
-// Make sure that the LLVM attribute for XRay-annotated functions do show up.
-[[clang::xray_always_instrument]] void foo() {
-// CHECK: define void @_Z3foov() #0
-};
-
-[[clang::xray_never_instrument]] void bar() {
-// CHECK: define void @_Z3barv() #1
-};
-
-// CHECK: #0 = {{.*}}"function-instrument"="xray-always"
-// CHECK: #1 = {{.*}}"function-instrument"="xray-never"


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


Re: r280597 - [AVX-512] Remove masked integer mullo builtins and replace with native IR.

2016-09-05 Thread Renato Golin via cfe-commits
On 6 September 2016 at 00:27, Craig Topper  wrote:
> This failure doesn't make sense. It's acting like the test was updated for
> r280596, but not the intrinsic header or the clang binary. That's the only
> way I can think that the output IR could contain
> @llvm.x86.avx512.mask.padd.b.256.

Hi Craig,

I don't know, but this is a fresh build with sources (hopefully) in sync:

http://lab.llvm.org:8011/builders/clang-cmake-thumbv7-a15/builds/15232

and still shows a lot of avx builtin problems...

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


Re: r280597 - [AVX-512] Remove masked integer mullo builtins and replace with native IR.

2016-09-05 Thread Renato Golin via cfe-commits
On 3 September 2016 at 20:19, Craig Topper via cfe-commits
 wrote:
> Author: ctopper
> Date: Sat Sep  3 14:19:49 2016
> New Revision: 280597
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280597=rev
> Log:
> [AVX-512] Remove masked integer mullo builtins and replace with native IR.
>
> Modified:
> cfe/trunk/include/clang/Basic/BuiltinsX86.def
> cfe/trunk/lib/Headers/avx512bwintrin.h
> cfe/trunk/lib/Headers/avx512dqintrin.h
> cfe/trunk/lib/Headers/avx512fintrin.h
> cfe/trunk/lib/Headers/avx512vlbwintrin.h
> cfe/trunk/lib/Headers/avx512vldqintrin.h
> cfe/trunk/lib/Headers/avx512vlintrin.h
> cfe/trunk/test/CodeGen/avx512bw-builtins.c
> cfe/trunk/test/CodeGen/avx512dq-builtins.c
> cfe/trunk/test/CodeGen/avx512f-builtins.c
> cfe/trunk/test/CodeGen/avx512vl-builtins.c
> cfe/trunk/test/CodeGen/avx512vlbw-builtins.c
> cfe/trunk/test/CodeGen/avx512vldq-builtins.c

Hi Craig,

This caused a regression on our buildbot:

http://lab.llvm.org:8011/builders/clang-cmake-armv7-a15-full/builds/14466

Unfortunately, our bots didn't detect because of a change in the
builder which made all bots not report any errors.

If you can't fix it quickly, please revert and we'll investigate that
later, as right now, we're dealing with a large number of concurrent
failures and we won't have time to investigate further.

Sorry.

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


Re: [PATCH] D24083: [CMake] Fix libc++abi __aeabi_idiv() link error.

2016-08-31 Thread Renato Golin via cfe-commits
rengolin added a comment.

This looks like a work around the fact that --rtlib is being ignored with 
--nodefaultlibs. I'm not sure that's a sane behaviour, if you explicitly 
specify --rtlib.


https://reviews.llvm.org/D24083



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


Re: [PATCH] D24084: [CMake] Cleanup libunwind lookup code.

2016-08-31 Thread Renato Golin via cfe-commits
rengolin added a comment.

In https://reviews.llvm.org/D24084#530427, @logan wrote:

> We can either (1) specify the path to libunwind or (2) manually download 
> `unwind.h` header from libunwind project and place it to `include` directory.


That is a horrible dependency... I never hit it because I always test libc++ 
with libunwind.

Marshall (@mclow.lists), isn't there a better way of doing this? It sounds 
terrible...

cheers,
--renato


https://reviews.llvm.org/D24084



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


Re: [PATCH] D24082: [CMake] Fix libc++abi arm build w/o libunwind.

2016-08-31 Thread Renato Golin via cfe-commits
rengolin added a comment.

That match would only make sense if LLVM's unwinder was forced on ARM targets, 
and they're most certainly not. Expecting both unwindwers to behave identically 
makes no sense.

This fix looks good to me, but I'll let Marshall or Eric have a look first.


https://reviews.llvm.org/D24082



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


Re: [PATCH] D24084: [CMake] Cleanup libunwind lookup code.

2016-08-31 Thread Renato Golin via cfe-commits
rengolin added a comment.

> We have to do so because we need the modified "unwind.h" from libunwind. 
> (Note:  which is bundled with clang/gcc is not sufficient.)


So, you need libunwind's sources, even if you're not building or using them, to 
build libc++abi?


https://reviews.llvm.org/D24084



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


Re: r280065 - Fix for commit 280064 that break the build.

2016-08-31 Thread Renato Golin via cfe-commits
On 31 August 2016 at 11:30, Sjoerd Meijer  wrote:
> Regression test test/CodeGen/noexceptionsfpmath.c makes sure 
> -fno-trapping-math ends up as a function attribute, and I relied on that. 
> Flag -fno-trapping-math is used a lot in test/Driver/fast-math.c, but you are 
> right that there is no test that test that explicitly test the output for 
> this. I will add a test case for that.

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


Re: r280065 - Fix for commit 280064 that break the build.

2016-08-31 Thread Renato Golin via cfe-commits
On 30 August 2016 at 09:56, Sjoerd Meijer via cfe-commits
 wrote:
> Author: sjoerdmeijer
> Date: Tue Aug 30 03:56:00 2016
> New Revision: 280065
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280065=rev
> Log:
> Fix for commit 280064 that break the build.

Any more info on this? Is this being worked to replace the deleted tests?

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


Re: r280133 - PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) input types.

2016-08-31 Thread Renato Golin via cfe-commits
Thanks!

On 31 August 2016 at 01:02, Richard Smith  wrote:
> Hopefully r280178 should fix this.
>
> On Tue, Aug 30, 2016 at 4:00 PM, Renato Golin 
> wrote:
>>
>> On 30 August 2016 at 22:44, Renato Golin  wrote:
>> > This breakage was hidden by Duncan's build breakage:
>> >
>> > http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/11172
>>
>> Also,
>> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/9813
>>
>> Same error...
>>
>> cheers,
>> --renato
>
>
___
cfe-commits mailing list
cfe-commits@lists.llvm.org
http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits


Re: r280133 - PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) input types.

2016-08-30 Thread Renato Golin via cfe-commits
On 30 August 2016 at 22:44, Renato Golin  wrote:
> This breakage was hidden by Duncan's build breakage:
>
> http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/11172

Also, http://lab.llvm.org:8011/builders/clang-cmake-aarch64-quick/builds/9813

Same error...

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


Re: r280133 - PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) input types.

2016-08-30 Thread Renato Golin via cfe-commits
On 30 August 2016 at 19:55, Richard Smith via cfe-commits
 wrote:
> Author: rsmith
> Date: Tue Aug 30 13:55:16 2016
> New Revision: 280133
>
> URL: http://llvm.org/viewvc/llvm-project?rev=280133=rev
> Log:
> PR30195: Fix clang-cl attempting to precompile bogus (non-precompilable) 
> input types.
>
> Modified:
> cfe/trunk/include/clang/Driver/Types.h
> cfe/trunk/lib/Driver/Driver.cpp
> cfe/trunk/lib/Driver/Types.cpp
> cfe/trunk/test/Driver/cl-pch.c

Hi Richard,

This breakage was hidden by Duncan's build breakage:

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/11172

Just "Exit code 254"

http://lab.llvm.org:8011/builders/clang-cmake-aarch64-42vma/builds/11172/steps/ninja%20check%201/logs/FAIL%3A%20Clang%3A%3Acl-pch.c

Can you have a look, pls?

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


  1   2   3   4   >