r293398 - Modules: Enforce that ModuleManager::removeModules deletes the tail

Author: dexonsmith Date: Sat Jan 28 17:02:12 2017 New Revision: 293398 URL: http://llvm.org/viewvc/llvm-project?rev=293398&view=rev Log: Modules: Enforce that ModuleManager::removeModules deletes the tail ModuleManager::removeModules always deletes a tail of the ModuleManager::Chain. Change the

r293399 - Modules: Clean up ModuleFile::Imports in ModuleManager::removeModules

Author: dexonsmith Date: Sat Jan 28 17:12:13 2017 New Revision: 293399 URL: http://llvm.org/viewvc/llvm-project?rev=293399&view=rev Log: Modules: Clean up ModuleFile::Imports in ModuleManager::removeModules I don't have a testcase for this (and I'm not sure if it's an observable bug), but it seem

r293400 - Modules: Return early in ModuleManager::addModule; NFC

Author: dexonsmith Date: Sat Jan 28 17:22:40 2017 New Revision: 293400 URL: http://llvm.org/viewvc/llvm-project?rev=293400&view=rev Log: Modules: Return early in ModuleManager::addModule; NFC Invert the main branch in ModuleManager::addModule to return early and reduce indentation, and clean up a

r293404 - Modules: Simplify the ModuleFile constructor; likely NFC

Author: dexonsmith Date: Sat Jan 28 18:39:09 2017 New Revision: 293404 URL: http://llvm.org/viewvc/llvm-project?rev=293404&view=rev Log: Modules: Simplify the ModuleFile constructor; likely NFC Zero-initialize ModuleFile members directly in the class definition, and move the (now uninteresting) c

Re: r293123 - Remove and replace DiagStatePoint tracking and lookup data structure.

Hi Richard, This commit makes one of the tests fail in: https://reviews.llvm.org/D27689 The implicit modules model expects to be able to "upgrade" an implicit PCM with more -Werror flags *without* affecting the signature. However, with your commit, the command-line diagnostic flags (e.g., -Wco

r293415 - Modules: Fix a minor performance bug from r293393

Author: dexonsmith Date: Sat Jan 28 22:42:21 2017 New Revision: 293415 URL: http://llvm.org/viewvc/llvm-project?rev=293415&view=rev Log: Modules: Fix a minor performance bug from r293393 Oops... r293393 started calling ReadSignature in ModuleManager::addModule even when there was no ExpectedSigna

r293863 - Modules: Simplify CompilerInstance constructor, NFC

Author: dexonsmith Date: Wed Feb 1 23:09:51 2017 New Revision: 293863 URL: http://llvm.org/viewvc/llvm-project?rev=293863&view=rev Log: Modules: Simplify CompilerInstance constructor, NFC Initialize fields directly in header. Note that the ModuleManager field is an IntrusiveRefCntPtr, so there'

Re: [PATCH] D29476: Driver: Do not warn about unused -pthread when linking on darwin

I think you need to close this phabricator revision and create a new one to get your initial comments and the patch onto cfe-commits. > On 2017-Feb-02, at 16:18, Matthias Braun via Phabricator > wrote: > > MatzeB added a subscriber: cfe-commits. > MatzeB added a comment. > > Add cfe-commits.

Re: [PATCH] D29479: Driver: Do not warn about unused -pthread when linking on darwin

Seems reasonable to me. I wonder, should this do something in the case where -nostdlib has been passed, so we're not linking against libc by default? Or should it error/warning/etc.? One comment inline below. > On 2017-Feb-02, at 16:56, Matthias Braun via Phabricator > wrote: > > MatzeB cre

Re: [PATCH] D29479: Driver: Do not warn about unused -pthread when linking on darwin

LGTM. > On 2017-Feb-03, at 14:16, Matthias Braun via Phabricator > wrote: > > MatzeB updated this revision to Diff 87024. > MatzeB added a comment. > > Address review comments: > > - Simplify test > - Only perform the ClaimAll() if we actually link libc, so we get the warning > back when com

Re: r293518 - [ASTMatchers] Sprinkle some constexpr on the global matcher constructors.

Note that this also failed on Linux: http://lab.llvm.org:8011/builders/clang-x86_64-linux-selfhost-modules/builds/2728 This looks like a modules compiler bug, as opposed to a problem in the commit itself. Alex, can you file a PR for this? > On 2017-Feb-01, at 07:35, Alex L via cfe-commits > w

[libcxx] r307357 - cmath: Support clang's -fdelayed-template-parsing

Author: dexonsmith Date: Thu Jul 6 22:13:36 2017 New Revision: 307357 URL: http://llvm.org/viewvc/llvm-project?rev=307357&view=rev Log: cmath: Support clang's -fdelayed-template-parsing r283051 added some functions to cmath (in namespace std) that have the same name as functions in math.h (in th

Re: [libcxx] r323453 - [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

I don't really understand why, but our bots seemed to survive this: http://lab.llvm.org:8080/green/view/Libcxx/job/libcxx_master_cmake/2137/ Console output is here: http://lab.llvm.org:8080/green/view/Libcxx/job/libcxx_mas

Re: [libcxx] r323453 - [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

> On Jan 25, 2018, at 13:07, Don Hinton wrote: > > On Thu, Jan 25, 2018 at 12:54 PM, Chris Bieneman > wrote: > Historically we have supported building libcxx without llvm-config available > on the system. > > In all likelihood the bots didn't fail because the bots do

Re: [libcxx] r323453 - [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

> On Jan 25, 2018, at 16:18, Duncan P. N. Exon Smith via cfe-commits > wrote: > > > >> On Jan 25, 2018, at 13:07, Don Hinton > <mailto:hinto...@gmail.com>> wrote: >> >> On Thu, Jan 25, 2018 at 12:54 PM, Chris Bieneman > <mailto:be...@a

Re: [libcxx] r323453 - [cmake] [libcxx] Call llvm_setup_rpath() when adding shared libraries.

> On Jan 25, 2018, at 17:09, Don Hinton wrote: > > > > On Thu, Jan 25, 2018 at 4:21 PM, Duncan P. N. Exon Smith > mailto:dexonsm...@apple.com>> wrote: > > >> On Jan 25, 2018, at 16:18, Duncan P. N. Exon Smith via cfe-commits >>

Re: [PATCH] D34249: [libc++] Don't use UTIME_OMIT to detect utimensat on Apple

Using runtime availability checking doesn't make sense for a system Libc++, as you point out. If we add runtime checks they ought to be non-default, and hidden behind configuration flags. Also, do I remember correctly that __builtin_available requires linking against Foundation (and thus the O

Re: [PATCH] D27827: [ObjC] CodeGen support for @available on macOS

> On 2017-Feb-20, at 13:11, Alex Lorenz via Phabricator > wrote: > > arphaman added inline comments. > > > > Comment at: lib/CodeGen/CodeGenFunction.h:2479 > > + llvm::Value *EmitObjCIsOSVersionAtLeast(ArrayRef Args); > + > > I think it's better to treat th

r297655 - Modules: Use hash of PCM content for SIGNATURE

Author: dexonsmith Date: Mon Mar 13 13:45:08 2017 New Revision: 297655 URL: http://llvm.org/viewvc/llvm-project?rev=297655&view=rev Log: Modules: Use hash of PCM content for SIGNATURE Change ASTFileSignature from a random 32-bit number to the hash of the PCM content. - Move definition ASTFileS

Re: [PATCH] D27387: [libc++] Add a key function for bad_function_call

Yes, they are: -- $ clang -dM -x c /dev/null -E -mmacosx-version-min=10.10.0 | grep VERSION_MIN #define __ENVIRONMENT_MAC_OS_X_VERSION_MIN_REQUIRED__ 101000 -- However, they're somewhat awkward, extremely vendor-specific, and unrelated to libc++ version numbers. I think a separate ABI flag would

Re: [PATCH] D27429: [Chrono][Darwin] On Darwin use CLOCK_UPTIME_RAW instead of CLOCK_MONOTONIC

From a Darwin perspective, this LGTM (it's what we're shipping on macOS 10.12 and iOS 10). Eric, do you have a good idea for how to test this? > On 2016-Dec-05, at 14:36, Bruno Cardoso Lopes via Phabricator > wrote: > > bruno created this revision. > bruno added reviewers: mclow.lists, dexons

r288872 - Driver: Remove support for -fobjc-gc*

Author: dexonsmith Date: Tue Dec 6 18:31:10 2016 New Revision: 288872 URL: http://llvm.org/viewvc/llvm-project?rev=288872&view=rev Log: Driver: Remove support for -fobjc-gc* As a first step toward removing Objective-C garbage collection from Clang, remove support from the driver. I'm hoping thi

Re: r288866 - [c++17] P0135R1: Guaranteed copy elision.

+Eric, Marshall I haven't looked, but: from the test name, "copy.fail.cpp", I suspect there is a bug/incompatibility in the test. It likely relies on the compiler trying (and failing) to copy something in a context where r288866 guarantees that there is no copy. > On 2016-Dec-08, at 18:00, Ad

Re: r288866 - [c++17] P0135R1: Guaranteed copy elision.

Hmm, never mind. The test seems to preclude copy elision if I'm looking in the right place: std::streambuf &get(); int main() { std::streambuf sb = get(); // expected-error } > On 2016-Dec-08, at 19:17, Duncan P. N. Exon Smith via cfe-commits > wrote: > > +

Re: r288866 - [c++17] P0135R1: Guaranteed copy elision.

> On 2016-Dec-08, at 19:29, Richard Smith wrote: > > On 8 Dec 2016 7:17 pm, "Duncan P. N. Exon Smith via cfe-commits" > wrote: > +Eric, Marshall > > I haven't looked, but: from the test name, "copy.fail.cpp", I suspect there > is a bug/inco

Re: [PATCH] D27429: [Chrono][Darwin] On Darwin use CLOCK_UPTIME_RAW instead of CLOCK_MONOTONIC

Two points to make here: 1. CLOCK_UPTIME_RAW exactly matches the previous behaviour, so even if it's wrong, it's not a regression. See the next sentence from the one Eric quoted: CLOCK_UPTIME_RAW clock that increments monotonically, in the same manner as CLOCK_MO

[libcxx] r301060 - cmath: Skip Libc for integral types in isinf, etc.

Author: dexonsmith Date: Fri Apr 21 18:14:55 2017 New Revision: 301060 URL: http://llvm.org/viewvc/llvm-project?rev=301060&view=rev Log: cmath: Skip Libc for integral types in isinf, etc. For std::isinf, the standard requires effectively calling isinf as double from Libc for integral types. But i

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

[Some necromancy here...] This commit effectively reverted r173361 and r173825, breaking UNIX conformance for our c99 wrapper. See: http://pubs.opengroup.org/onlinepubs/9699919799/utilities/c99.html > When c99 encounters a com

r301508 - Darwin: Define __STDC_NO_THREADS__ on Darwin targets

Author: dexonsmith Date: Wed Apr 26 20:47:22 2017 New Revision: 301508 URL: http://llvm.org/viewvc/llvm-project?rev=301508&view=rev Log: Darwin: Define __STDC_NO_THREADS__ on Darwin targets Darwin doesn't support C11 threads.h. Define `__STDC_NO_THREADS__` so that users can check for it. rdar:/

r301592 - Preprocessor: Suppress -Wnonportable-include-path for header maps

Author: dexonsmith Date: Thu Apr 27 16:41:51 2017 New Revision: 301592 URL: http://llvm.org/viewvc/llvm-project?rev=301592&view=rev Log: Preprocessor: Suppress -Wnonportable-include-path for header maps If a file search involves a header map, suppress -Wnonportable-include-path. It's firing lots

r301593 - Headers: Make the type of SIZE_MAX the same as size_t

Author: dexonsmith Date: Thu Apr 27 16:49:45 2017 New Revision: 301593 URL: http://llvm.org/viewvc/llvm-project?rev=301593&view=rev Log: Headers: Make the type of SIZE_MAX the same as size_t size_t is usually defined as unsigned long, but on 64-bit platforms, stdint.h currently defines SIZE_MAX u

[libcxx] r302095 - CMake: Only add test/ subdirectory when it exists

Author: dexonsmith Date: Wed May 3 18:33:54 2017 New Revision: 302095 URL: http://llvm.org/viewvc/llvm-project?rev=302095&view=rev Log: CMake: Only add test/ subdirectory when it exists r296685 started adding the test/ subdirectory even when LIBCXX_INCLUDE_TESTS=OFF. This is great for testing l

Re: [PATCH] D25932: Unconditionally pass `-lto_library` to the linker on Darwin

> On 2016-Oct-24, at 21:43, Mehdi AMINI wrote: > > mehdi_amini created this revision. > mehdi_amini added a reviewer: dexonsmith. > mehdi_amini added a subscriber: cfe-commits. > > We're only doing it with -flto currently, however it never "hurt" > to pass it, and users that are linking without

Re: [PATCH] D12922: Add support for function attribute "notail"

I wonder if 'notailcall' be better, since it contains a verb (like 'noinline'). I don't have a strong opinion; just putting the alternative out there. > On 2015-Sep-16, at 19:21, Akira Hatanaka via cfe-commits > wrote: > > ahatanak created this revision. > ahatanak added a reviewer: aaron.bal

Re: [PATCH] D12922: Add support for function attribute "notail"

dexonsmith added a subscriber: dexonsmith. dexonsmith added a comment. I wonder if 'notailcall' be better, since it contains a verb (like 'noinline'). I don't have a strong opinion; just putting the alternative out there. http://reviews.llvm.org/D12922 __

Re: [PATCH] D13004: Create a new attribute set when the definition is parsed after a declaration of a function

> On 2015-Sep-21, at 01:42, Akira Hatanaka via cfe-commits > wrote: > > ahatanak created this revision. > ahatanak added a subscriber: cfe-commits. > > An assert is triggered when the test case program is compiled with -Oz: > > Assertion failed: (!F->hasFnAttribute(llvm::Attribute::OptimizeFo

Re: [PATCH] D13117: [DarwinDriver] Use -lto_library to specify the path for libLTO.dylib

dexonsmith added a subscriber: dexonsmith. dexonsmith added a comment. The code LGTM, but there ought to be a way to add a LIT test for this. Looking for -object_path_lto, I found this: --- // RUN: %clang -target x86_64-apple-darwin10 -### %s \ // RUN: -

Re: [PATCH] D13117: [DarwinDriver] Use -lto_library to specify the path for libLTO.dylib

The code LGTM, but there ought to be a way to add a LIT test for this. Looking for -object_path_lto, I found this: -- // RUN: %clang -target x86_64-apple-darwin10 -### %s \ // RUN: -mlinker-version=117 -flto 2> %t.log // RUN: cat %t.log // RUN: FileCheck -check-prefix=LINK_OBJECT_LTO_PATH %s < %

Re: [PATCH] D13117: [DarwinDriver] Use -lto_library to specify the path for libLTO.dylib

Sorry for the review fragmentation, but I just noticed there's no test for the new warning. Can you add one? After that, LGTM. > On 2015-Sep-24, at 11:57, Bruno Cardoso Lopes wrote: > > bruno updated this revision to Diff 35664. > bruno added a comment. > > Added test per Duncan's comment. >

Re: [PATCH] D13117: [DarwinDriver] Use -lto_library to specify the path for libLTO.dylib

dexonsmith added a comment. Sorry for the review fragmentation, but I just noticed there's no test for the new warning. Can you add one? After that, LGTM. Repository: rL LLVM http://reviews.llvm.org/D13117 ___ cfe-commits mailing list cfe-commi

Re: [PATCH] D11908: Clang support for -fthinlto.

> On 2015-Sep-23, at 10:28, Teresa Johnson wrote: > > tejohnson updated this revision to Diff 35527. > tejohnson added a comment. > > Updated the patch for the new LLVM/gold patch > (http://reviews.llvm.org/D13107). > > Two changes: > > - I put back the original change to pass a new plugin o

Re: [PATCH] D11908: Clang support for -fthinlto.

> On 2015-Sep-30, at 10:40, Teresa Johnson wrote: > > On Wed, Sep 30, 2015 at 10:19 AM, Duncan P. N. Exon Smith > wrote: >> >>> On 2015-Sep-23, at 10:28, Teresa Johnson wrote: >>> >>> tejohnson updated this revision to Diff 35527. >>> tejohnson added a comment. >>> >>> Updated the patch for

Re: [PATCH] D11908: Clang support for -fthinlto.

+echristo, +espindola, +pcc > On 2015-Sep-30, at 12:39, Teresa Johnson wrote: > > On Wed, Sep 30, 2015 at 11:11 AM, Duncan P. N. Exon Smith > wrote: >> >>> On 2015-Sep-30, at 10:40, Teresa Johnson wrote: >>> >>> On Wed, Sep 30, 2015 at 10:19 AM, Duncan P. N. Exon Smith >>> wrote:

Re: [PATCH] D11908: Clang support for -fthinlto.

> On 2015-Oct-02, at 08:59, Teresa Johnson wrote: > > On Fri, Oct 2, 2015 at 8:53 AM, Manuel Klimek wrote: >> klimek added a comment. >> >> In http://reviews.llvm.org/D11908#258570, @tejohnson wrote: >> >>> Sorry for the duplicate - my previous response didn't go to Duncan or Mehdi >>> for s

r246095 - DI: Clarify meaning of createTempFunctionFwdDecl() arg, NFC

Author: dexonsmith Date: Wed Aug 26 17:21:09 2015 New Revision: 246095 URL: http://llvm.org/viewvc/llvm-project?rev=246095&view=rev Log: DI: Clarify meaning of createTempFunctionFwdDecl() arg, NFC I stared at `false /*declaration*/` for quite some time before giving up and checking the actual fun

r246099 - DI: Update DISubprogram testcases after LLVM r246098

Author: dexonsmith Date: Wed Aug 26 17:50:48 2015 New Revision: 246099 URL: http://llvm.org/viewvc/llvm-project?rev=246099&view=rev Log: DI: Update DISubprogram testcases after LLVM r246098 Modified: cfe/trunk/test/CodeGen/debug-info-scope-file.c cfe/trunk/test/CodeGenCXX/PR20038.cpp

Re: [PATCH] D13525: [CodeGen] Attach function attributes to functions created in CGBlocks.cpp.

> On 2015-Oct-07, at 11:35, Akira Hatanaka wrote: > > ahatanak created this revision. > ahatanak added reviewers: dexonsmith, echristo. > ahatanak added a subscriber: cfe-commits. > > This patch makes changes to attach function attributes to the following > functions created in CGBlocks.cpp: >

r249849 - Analysis: Make CFG::graph_iterator dereference to non-const

Author: dexonsmith Date: Fri Oct 9 11:50:55 2015 New Revision: 249849 URL: http://llvm.org/viewvc/llvm-project?rev=249849&view=rev Log: Analysis: Make CFG::graph_iterator dereference to non-const Since the original commit in r145858, we've had `CFG::graph_iterator` and `CFG::const_graph_iterator

Re: [libcxx] r249738 - Split out of .

+Ted > On 2015-Oct-14, at 15:32, Richard Smith via cfe-commits > wrote: > >> While building module 'LLVM_Utils' imported from >> ../lib/Support/APFloat.cpp:15: >> In file included from :1: >> In file included from ../include/llvm/ADT/APFloat.h:20: >> In file included from ../include/llvm/ADT/A

Re: [PATCH] D12922: Add support for function attribute "notail"

> On 2015-Oct-13, at 09:55, Aaron Ballman wrote: > > aaron.ballman added a comment. > > In http://reviews.llvm.org/D12922#265452, @ahatanak wrote: > >> I think there are a couple of things that have to be discussed: >> >> 1. Name of the attribute: Should it be "notail" or "notailcall"? Perhap

Re: [PATCH] D14266: CodeGen: Update for debug info API change.Depends on D14265.

This LGTM (although obviously gated on LLVM changes). > On 2015-Nov-02, at 16:28, Peter Collingbourne wrote: > > pcc created this revision. > pcc added a reviewer: dexonsmith. > pcc added a subscriber: cfe-commits. > > http://reviews.llvm.org/D14266 > > Files: > lib/CodeGen/CGDebugInfo.cpp >

r252358 - CodeGen: Remove implicit ilist iterator conversions, NFC

Author: dexonsmith Date: Fri Nov 6 17:00:41 2015 New Revision: 252358 URL: http://llvm.org/viewvc/llvm-project?rev=252358&view=rev Log: CodeGen: Remove implicit ilist iterator conversions, NFC Make ilist iterator conversions explicit in clangCodeGen. Eventually I'll remove them everywhere. Mod

r252360 - StaticAnalyzer: Remove implicit ilist iterator conversions, NFC

Author: dexonsmith Date: Fri Nov 6 17:04:58 2015 New Revision: 252360 URL: http://llvm.org/viewvc/llvm-project?rev=252360&view=rev Log: StaticAnalyzer: Remove implicit ilist iterator conversions, NFC Remove implicit ilist iterator conversions from clangStaticAnalyzer. Modified: cfe/trunk/li

Re: [libcxx] r275114 - Don't compute modulus of hash if it is smaller than the bucket count.

ly expected. It depends on what operation it's performing. I > expected a bit of a performance drop in some cases but I have a plan to fix > those. > Do you have a link to LNT? > > On Wed, Jul 13, 2016 at 6:41 PM, Duncan P. N. Exon Smith > wrote: > Hmm. I implied ther

Re: [libcxx] r275114 - Don't compute modulus of hash if it is smaller than the bucket count.

> On 2016-Jul-17, at 14:09, Eric Fiselier wrote: > > What I'm curious about if this performance regression was cause by (1) the > removal of this 2 week old optimization or (2) the implementation of "fast > mod". I suspect it's because of (1). > BTW, definitely from the 2 week old optimizati

r278525 - BugReporter: Use ilist_half_embedded_sentinel_traits, NFC

Author: dexonsmith Date: Fri Aug 12 11:46:25 2016 New Revision: 278525 URL: http://llvm.org/viewvc/llvm-project?rev=278525&view=rev Log: BugReporter: Use ilist_half_embedded_sentinel_traits, NFC This avoids duplicated code with llvm/ADT/ilist.h. No functionality change. Modified: cfe/trunk/

Re: [libcxxabi] r278579 - Fix ASAN failures in the demangler

This seems like a good candidate to cherry-pick to 3.9. > On 2016-Aug-12, at 17:02, Mehdi Amini via cfe-commits > wrote: > > Author: mehdi_amini > Date: Fri Aug 12 19:02:33 2016 > New Revision: 278579 > > URL: http://llvm.org/viewvc/llvm-project?rev=278579&view=rev > Log: > Fix ASAN failures i

Re: [PATCH] D16467: [libcxx] re.results.form: Format out-of-range subexpression references as null

Ping. Marshall, does this look okay? > On 2016-Jan-25, at 10:32, Duncan P. N. Exon Smith via cfe-commits > wrote: > > dexonsmith updated this revision to Diff 45879. > dexonsmith added a comment. > > Addressed Marshall's review comments: deferring to > match

Re: [PATCH] D16467: [libcxx] re.results.form: Format out-of-range subexpression references as null

dexonsmith added a subscriber: dexonsmith. dexonsmith added a comment. Ping. Marshall, does this look okay? http://reviews.llvm.org/D16467 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-co

[PATCH] D16791: unordered_map: Match emplace_hint logic when _LIBCPP_DEBUG, NFC

dexonsmith created this revision. dexonsmith added a reviewer: EricWF. dexonsmith added a subscriber: cfe-commits. When `!defined(_LIBCPP_DEBUG)`, unordered_map::emplace_hint() forwards to emplace(). Do the same when `defined(_LIBCPP_DEBUG)`. This has no real functionality change, just unifies t

[PATCH] D16792: unordered_map: Use __hash_table::__emplace_unique(), NFC

dexonsmith created this revision. dexonsmith added a reviewer: EricWF. dexonsmith added a subscriber: cfe-commits. Instead of duplicating code in unordered_map::emplace(), use __hash_table::__emplace_unique(). http://reviews.llvm.org/D16792 Files: include/unordered_map Index: include/unordere

Re: [PATCH] D16360: unordered_map: Avoid unnecessary mallocs when no insert occurs

dexonsmith updated this revision to Diff 46603. dexonsmith added a comment. Eric, I think this addresses all of your review comments. There are a couple of prep NFC commits that I sent for review: http://lists.llvm.org/pipermail/cfe-commits/Week-of-Mon-20160201/148661.html http://lists.llvm.org/p

Re: [PATCH] D16360: unordered_map: Avoid unnecessary mallocs when no insert occurs

Marshall, thanks for the link to #2464. That does look scary. Nevertheless, I think this -- and the other over-eager allocations in {unordered_,}{multi,}{map,set} -- are worth optimizing as long as we can do it in a standards-compliant way. It's a pretty serious regression in performance compare

Re: [PATCH] D16360: unordered_map: Avoid unnecessary mallocs when no insert occurs

dexonsmith added a comment. Marshall, thanks for the link to #2464. That does look scary. Nevertheless, I think this -- and the other over-eager allocations in {unordered_,}{multi,}{map,set} -- are worth optimizing as long as we can do it in a standards-compliant way. It's a pretty serious regr

[libcxx] r259682 - re.results.form: Format out-of-range subexpression references as null

Author: dexonsmith Date: Wed Feb 3 13:30:20 2016 New Revision: 259682 URL: http://llvm.org/viewvc/llvm-project?rev=259682&view=rev Log: re.results.form: Format out-of-range subexpression references as null Rather than crashing in match_results::format() when a reference to a marked subexpression

Re: [PATCH] D16467: [libcxx] re.results.form: Format out-of-range subexpression references as null

Committed in r259682. > On 2016-Feb-03, at 11:16, Marshall Clow wrote: > > mclow.lists accepted this revision. > mclow.lists added a comment. > This revision is now accepted and ready to land. > > LGTM > > > http://reviews.llvm.org/D16467 > > >

Re: [PATCH] D16467: [libcxx] re.results.form: Format out-of-range subexpression references as null

dexonsmith added a comment. Committed in r259682. http://reviews.llvm.org/D16467 ___ cfe-commits mailing list cfe-commits@lists.llvm.org http://lists.llvm.org/cgi-bin/mailman/listinfo/cfe-commits

Re: [libcxx] r259682 - re.results.form: Format out-of-range subexpression references as null

Hans, do you mind merging this to the 3.8 branch? Marshall, do you agree this is okay to take? > On 2016-Feb-03, at 11:30, Duncan P. N. Exon Smith via cfe-commits > wrote: > > Author: dexonsmith > Date: Wed Feb 3 13:30:20 2016 > New Revision: 259682 > > URL: htt

Re: [PATCH] D16914: [CodeGen] Fix an assert in CodeGenFunction::EmitFunctionEpilog

> On 2016-Feb-04, at 18:54, Akira Hatanaka via cfe-commits > wrote: > > ahatanak created this revision. > ahatanak added a subscriber: cfe-commits. > > The assert near CGCall.cpp:2465 is triggered because > QualType::isObjCRetainableType() is called on different types. In > CodeGenFunction::

Re: r260002 - Add a missing call to MDNode::deleteTemporary().

> On 2016-Feb-06, at 10:39, Adrian Prantl via cfe-commits > wrote: > > Author: adrian > Date: Sat Feb 6 12:39:34 2016 > New Revision: 260002 > > URL: http://llvm.org/viewvc/llvm-project?rev=260002&view=rev > Log: > Add a missing call to MDNode::deleteTemporary(). > Follow-up to r259975. Kudos

Re: [PATCH] D16948: [libcxx] Filesystem TS Part 1 -- path

Light review below, looks like great work. I noticed the tests seem somewhat inconsistent about whether to glue `&` to the type or use two spaces (i.e., ` & `). Which one is preferred in this codebase? Or is it laissez-faire? The rest of my comments are inline. > On 2016-Feb-06, at 12:48, Eric

Re: [PATCH] D16948: [libcxx] Filesystem TS Part 1 -- path

dexonsmith added a subscriber: dexonsmith. dexonsmith added a comment. Light review below, looks like great work. I noticed the tests seem somewhat inconsistent about whether to glue `&` to the type or use two spaces (i.e., ` & `). Which one is preferred in this codebase? Or is it laissez-faire

Re: [PATCH] D16948: [libcxx] Filesystem TS Part 1 -- path

> On 2016-Feb-06, at 15:40, Eric Fiselier wrote: > >> > +// The "hash_value" function is tested as part of [path.compare] >> > +// in class.path/path.members/path.compare.pass.cpp >> > +int main() {} >> >> Okay, I get the idea of the one above. I'm guessing this is just how >> we mark that som

Re: [PATCH] D16792: unordered_map: Use __hash_table::__emplace_unique(), NFC

> On 2016-Feb-06, at 13:28, Eric Fiselier wrote: > > EricWF added a comment. > > This is very subtly broken. The requirements in the standard for emplace are > > [unord.req] Table 102 > >> a_eq.emplace(args) > >> Requires: : value_type shall be EmplaceConstructible into X from args. > > >

[PATCH] SemaCXX: Support templates in availability attributes

This patch adds support for templates in availability attributes. - If the context for an availability diagnostic is a `FunctionTemplateDecl`, look through it to the `FunctionDecl`. - Add `__has_feature(attribute_availability_in_templates)`. Is there anything else I should be testing to be

[PATCH] D17053: [libcxx]: vector: Use < instead of != to improve failure mode

dexonsmith created this revision. dexonsmith added reviewers: mclow.lists, EricWF. dexonsmith added a subscriber: cfe-commits. The following program is obviously broken: #include int main(int argc, const char * argv[]) { std::vector v; v.push_back(0); v.pop_back()

Re: [PATCH] D17053: [libcxx]: vector: Use < instead of != to improve failure mode

I'm not sure I disagree. What got me slightly motivated was seeing that UBSan doesn't catch this. > On 2016-Feb-09, at 16:04, Marshall Clow wrote: > > mclow.lists added a comment. > > Undefined behavior is just that, undefined. > > I'm not that interested in "fixing" this; I don't think it's

Re: [PATCH] D17053: [libcxx]: vector: Use < instead of != to improve failure mode

dexonsmith added a subscriber: dexonsmith. dexonsmith added a comment. I'm not sure I disagree. What got me slightly motivated was seeing that UBSan doesn't catch this. http://reviews.llvm.org/D17053 ___ cfe-commits mailing list cfe-commits@lists.l

Re: [PATCH] D17053: [libcxx]: vector: Use < instead of != to improve failure mode

dexonsmith added a comment. Ah, so the cost isn't necessarily the same. I don't think this is worth it then. (Although, paradoxically, it opens up an avenue for testing, via a custom allocator which counts http://reviews.llvm.org/D17053 ___ cfe-comm

Re: [PATCH] D17053: [libcxx]: vector: Use < instead of != to improve failure mode

Ah, so the cost isn't necessarily the same. I don't think this is worth it then. (Although, paradoxically, it opens up an avenue for testing, via a custom allocator which counts On 2016-Feb-09, at 16:14, Marshall Clow wrote: > > mclow.lists added a comment. > >> Since `__new_last` and `__end_

Re: [PATCH] D17053: [libcxx]: vector: Use < instead of != to improve failure mode

> On 2016-Feb-09, at 16:40, Howard Hinnant wrote: > > On Feb 9, 2016, at 7:17 PM, Duncan P. N. Exon Smith via cfe-commits > wrote: >> >> Any other ideas for improving the failure mode? > > Here’s a suggestion: > > https://github.com/llvm-mirror/lib

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

> On 2016-Feb-10, at 13:25, Bob Wilson wrote: > > >> On Feb 10, 2016, at 12:59 PM, Tim Northover wrote: >> >> On 10 February 2016 at 12:52, Eric Fiselier wrote: >>> @Tim Are these tests in the clang test suite? >> >> Yep, at http://llvm.org/git/test-suite.git. >> >>> Marshall and I were ju

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

I'm hoping only a year or two (or three...)? > On 2016-Feb-10, at 14:29, Eric Fiselier wrote: > > > Can we hold off a little longer? > > Yes we can. The entire point of the AFAIK was to encourage migration to > libc++ so it makes some > sense to keep them while they still serve this purpose. >

Re: [libcxx] r260514 - Teach __hash_table how to handle unordered_map's __hash_value_type.

(For anyone else trying to line up this commit message with the patch: it looks like this message is a dup of r260513, and this patch is one of its described follow-ups: > On 2016-Feb-11, at 04:25, Eric Fiselier via cfe-commits > wrote: > > The following changes are planed for future revisions:

Re: r260496 - [Objective-c] Stop attaching section "datacoal_nt" to global variables.

> On 2016-Feb-10, at 22:36, Akira Hatanaka via cfe-commits > wrote: > > Author: ahatanak > Date: Thu Feb 11 00:36:35 2016 > New Revision: 260496 > > URL: http://llvm.org/viewvc/llvm-project?rev=260496&view=rev > Log: > [Objective-c] Stop attaching section "datacoal_nt" to global variables. >

Re: r260201 - [CMake] Providing a CMake cache for 3-stage builds

> On 2016-Feb-08, at 22:01, Chris Bieneman via cfe-commits > wrote: > > Author: cbieneman > Date: Tue Feb 9 00:01:47 2016 > New Revision: 260201 > > URL: http://llvm.org/viewvc/llvm-project?rev=260201&view=rev > Log: > [CMake] Providing a CMake cache for 3-stage builds > > This cache file ca

Re: [PATCH] D16360: unordered_map: Avoid unnecessary mallocs when no insert occurs

dexonsmith updated this revision to Diff 47936. dexonsmith added a comment. Updated the patch to apply against r260513. The logic is much simpler now; thanks Eric for the cleanup. Let me know if there's anything else to do! http://reviews.llvm.org/D16360 Files: include/__hash_table test/

Re: [libcxx] r260012 - Cleanup node-type handling in the unordered containers

> On 2016-Feb-10, at 19:10, Marshall Clow wrote: > > On Wed, Feb 10, 2016 at 2:46 PM, Duncan P. N. Exon Smith via cfe-commits > wrote: > I'm hoping only a year or two (or three...)? > > As I pointed out to Eric on IRC, those files have had a "deprecation

Re: r261163 - Add 'nopartial' qualifier for availability attributes.

> On 2016-Feb-17, at 14:05, Manman Ren via cfe-commits > wrote: > > Author: mren > Date: Wed Feb 17 16:05:48 2016 > New Revision: 261163 > > URL: http://llvm.org/viewvc/llvm-project?rev=261163&view=rev > Log: > Add 'nopartial' qualifier for availability attributes. > > An optional nopartial c

[PATCH] D17469: [libcxx] Add deployment knobs to tests (for Apple platforms)

dexonsmith created this revision. dexonsmith added reviewers: EricWF, mclow.lists. dexonsmith added a subscriber: cfe-commits. The tests for libc++ specify `-target` on the command-line to the compiler, but this is problematic for a few reasons. Firstly, the `-target` option isn't supported on Ap

Re: [PATCH] D16360: unordered_map: Avoid unnecessary mallocs when no insert occurs

Honestly I didn't think much about the testing style. I used r239666 as a reference and modified it for std::unordered_map. I'll redo the tests when I have a moment, based on the newer examples. Probably next week some time? > On 2016-Feb-19, at 17:53, Eric Fiselier wrote: > > EricWF added a c

Re: [PATCH] D16360: unordered_map: Avoid unnecessary mallocs when no insert occurs

dexonsmith added a comment. Honestly I didn't think much about the testing style. I used r239666 as a reference and modified it for std::unordered_map. I'll redo the tests when I have a moment, based on the newer examples. Probably next week some time? http://reviews.llvm.org/D16360 ___

r261442 - Lex: Remove explicitly deleted copy constructor, NFC

Author: dexonsmith Date: Sat Feb 20 12:53:45 2016 New Revision: 261442 URL: http://llvm.org/viewvc/llvm-project?rev=261442&view=rev Log: Lex: Remove explicitly deleted copy constructor, NFC `std::unique_ptr` already deletes these, so there's no reason for the boiler-plate in HeaderMap. Modified:

r261443 - Lex: clang-format HeaderMap.h, NFC

Author: dexonsmith Date: Sat Feb 20 12:55:08 2016 New Revision: 261443 URL: http://llvm.org/viewvc/llvm-project?rev=261443&view=rev Log: Lex: clang-format HeaderMap.h, NFC Modified: cfe/trunk/include/clang/Lex/HeaderMap.h Modified: cfe/trunk/include/clang/Lex/HeaderMap.h URL: http://llvm.or

r261446 - Lex: Add some unit tests for corrupt header maps

Author: dexonsmith Date: Sat Feb 20 14:39:51 2016 New Revision: 261446 URL: http://llvm.org/viewvc/llvm-project?rev=261446&view=rev Log: Lex: Add some unit tests for corrupt header maps Split the implementation of `HeaderMap` into `HeaderMapImpl` so that we can write unit tests that don't depend

r261448 - Lex: Check buckets on header map construction

Author: dexonsmith Date: Sat Feb 20 15:00:58 2016 New Revision: 261448 URL: http://llvm.org/viewvc/llvm-project?rev=261448&view=rev Log: Lex: Check buckets on header map construction If the number of buckets is not a power of two, immediately recognize the header map as corrupt, rather than waiti

r261449 - Lex: Check whether the header map buffer has space for the buckets

Author: dexonsmith Date: Sat Feb 20 15:24:31 2016 New Revision: 261449 URL: http://llvm.org/viewvc/llvm-project?rev=261449&view=rev Log: Lex: Check whether the header map buffer has space for the buckets Check up front whether the header map buffer has space for all of its declared buckets. Ther

r261455 - Lex: Add a test for HeaderMap::lookupFileName()

Author: dexonsmith Date: Sat Feb 20 16:53:22 2016 New Revision: 261455 URL: http://llvm.org/viewvc/llvm-project?rev=261455&view=rev Log: Lex: Add a test for HeaderMap::lookupFileName() Add a simple test for `HeaderMap::lookupFileName()`. I'm planning to add better error checking in a moment, and

r261456 - Lex: Use dbgs() instead of fprintf() in HeaderMap::dump()

Author: dexonsmith Date: Sat Feb 20 17:09:14 2016 New Revision: 261456 URL: http://llvm.org/viewvc/llvm-project?rev=261456&view=rev Log: Lex: Use dbgs() instead of fprintf() in HeaderMap::dump() This way it's easy to change HeaderMapImpl::getString() to return a StringRef. There's a slight chang

r261459 - Lex: Change HeaderMapImpl::getString() to return StringRef, NFC

Author: dexonsmith Date: Sat Feb 20 17:12:51 2016 New Revision: 261459 URL: http://llvm.org/viewvc/llvm-project?rev=261459&view=rev Log: Lex: Change HeaderMapImpl::getString() to return StringRef, NFC Modified: cfe/trunk/include/clang/Lex/HeaderMap.h cfe/trunk/lib/Lex/HeaderMap.cpp Modif

<    1   2   3   4   5   >