Page MenuHomePhabricator

jfb (JF Bastien)
User

Projects

User does not belong to any projects.

User Details

User Since
Jan 27 2014, 9:36 AM (281 w, 3 h)

Recent Activity

Today

jfb added a comment to D63388: WIP: experimenting with EH optimizations.
In D63388#1546335, @jfb wrote:
https://wg21.link/p1676

404

Mailing has not been published yet. I wonder if this link works?

https://isocpp.org/files/papers/P1676R0.pdf

Mon, Jun 17, 1:00 PM
jfb added a comment to D63363: [Signals] Create a plugin directory just for signals.
In D63363#1546504, @jfb wrote:
In D63363#1546464, @jfb wrote:

Can you describe what the goal of your plugin architecture is? Maybe you need an RFC by email before moving stuff around.

I want to understand what you're going for because as they are today the signals mostly work, and aren't really tested (because injecting these conditions isn't trivial). Anything you change is likely to break some subtle invariant which will only repro when your change is deployed at scale.

My goal is to remove non-plugin libraries dependencies on plugins. Today, Target depends on the ProcessUtility plugin because of UnixSignals. If Signals were their own plugin that could be accessed through the PluginManager interface, that dependency would go away. As Pavel said, this feels somewhat over engineered and contrived, but it is the simplest path forward. I am willing to drop this patch and go for a different solution if there is a nicer solution agreed upon by the community, so an RFC sounds like a nice idea. :)

Removing the dependency seems fine, but we have to be careful with how signals work: they're inherently global state, and you want to register / de-register them exactly where they're registered / de-registered right now to keep them working exactly the same. If you change this, we need to really think through why that's a good idea (it might be!).

I think there's some misunderstading here. This code has nothing to do with signal handlers. All these classes do is describe the set of possible signals on a given target (e.g. if remote-debugging a linux mips machine from a darwin x86 host, we need to know what number does linux use to represent SIGSEGV on mips, etc.)...

Mon, Jun 17, 12:24 PM
jfb added inline comments to D63423: [Diagnostics] Diagnose misused xor as pow.
Mon, Jun 17, 11:06 AM · Restricted Project
jfb added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

Why have .c and .cpp tests?

Mon, Jun 17, 10:57 AM · Restricted Project
jfb added inline comments to D63215: Fixing @llvm.memcpy not honoring volatile.
Mon, Jun 17, 10:29 AM · Restricted Project
jfb added a comment to D63363: [Signals] Create a plugin directory just for signals.
In D63363#1546464, @jfb wrote:

Can you describe what the goal of your plugin architecture is? Maybe you need an RFC by email before moving stuff around.

I want to understand what you're going for because as they are today the signals mostly work, and aren't really tested (because injecting these conditions isn't trivial). Anything you change is likely to break some subtle invariant which will only repro when your change is deployed at scale.

My goal is to remove non-plugin libraries dependencies on plugins. Today, Target depends on the ProcessUtility plugin because of UnixSignals. If Signals were their own plugin that could be accessed through the PluginManager interface, that dependency would go away. As Pavel said, this feels somewhat over engineered and contrived, but it is the simplest path forward. I am willing to drop this patch and go for a different solution if there is a nicer solution agreed upon by the community, so an RFC sounds like a nice idea. :)

Mon, Jun 17, 10:16 AM
jfb added a comment to D63363: [Signals] Create a plugin directory just for signals.

Can you describe what the goal of your plugin architecture is? Maybe you need an RFC by email before moving stuff around.

Mon, Jun 17, 9:59 AM
jfb added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

What does the suggested for for 2 ^ 32 look like? I hope it's not 1 << 32 :)

Mon, Jun 17, 9:36 AM · Restricted Project
jfb added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

I think you want to avoid warning inside macros as well, say:

#define AWESOME(x, y) ({ blah blah blah; x ^ y; blah })
Mon, Jun 17, 9:36 AM · Restricted Project
jfb updated subscribers of D63423: [Diagnostics] Diagnose misused xor as pow.
Mon, Jun 17, 9:34 AM · Restricted Project
jfb added a comment to D63423: [Diagnostics] Diagnose misused xor as pow.

As a reference: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90885

Mon, Jun 17, 9:30 AM · Restricted Project
jfb added a comment to D63388: WIP: experimenting with EH optimizations.
https://wg21.link/p1676
Mon, Jun 17, 9:10 AM
jfb added a comment to D63388: WIP: experimenting with EH optimizations.

Tests?

Mon, Jun 17, 9:10 AM

Thu, Jun 13

jfb added a comment to D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.

(You might argue that it's ridiculous to require that nullptr_t have the same size and alignment as void* but not have the same storage representation as a null void*. I'd agree, and I've raised this in committee before, but without success)

Thu, Jun 13, 12:15 PM · Restricted Project, Restricted Project

Wed, Jun 12

jfb added inline comments to D63215: Fixing @llvm.memcpy not honoring volatile.
Wed, Jun 12, 9:27 AM · Restricted Project

Tue, Jun 11

jfb added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..
In D62393#1539012, @jfb wrote:

FWIW we already support -fms-volatile, so there's precedent if you wanted -fnv-volatile (however terrible that is).

Most probably, we don't need this option, clang should emit correct code for volatile vars in Cuda mode automatically.

+1

That having been said, maybe this is a very simple change because it is the same as (or very similar to) what MSVolatile does?

Tue, Jun 11, 4:04 PM · Restricted Project
jfb added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

FWIW we already support -fms-volatile, so there's precedent if you wanted -fnv-volatile (however terrible that is).

Tue, Jun 11, 3:29 PM · Restricted Project
jfb added a comment to D62393: [OPENMP][NVPTX]Mark parallel level counter as volatile..

I think it is important to note that, to the best of my knowledge, no one was implying any bad faith on the part of anyone. To name one specific factor: We have had problems in the past where groups of collaborators/coworkers have done off-list reviews, followed only by a perfunctory/superficial on-list review, resulting in a lack of public discussion around the relevant design and implementation considerations. The review history highlighted by Johannes can give that impression, and we all need the community to watch itself in this regard, because of many potentially-relevant factors, to ensure the quality of our public code reviews is high. I see no reason to believe that everyone here wants to create the best possible code base. Sometimes that means one member of the community pointing out that, in his or her opinion, past reviews might have been insufficiently considered, and we should welcome that, and all work together to address these kinds of concerns going forward.

Hal, I agree that it was very dangerous situations, but I think, you need to prove something before trying to escalate the situation and blame somebody in doing the incorrect things. Johannes did this without any proves, he directly blamed me and others in doing improper things. Though he has no idea at all how things work in Cuda.

Tue, Jun 11, 9:50 AM · Restricted Project

Mon, Jun 10

jfb added inline comments to D62962: Clang implementation of sizeless types.
Mon, Jun 10, 11:06 AM · Restricted Project
jfb updated subscribers of D62960: SVE opaque type for C intrinsics demo.

Tests?

Mon, Jun 10, 10:14 AM · Restricted Project
jfb added inline comments to D62962: Clang implementation of sizeless types.
Mon, Jun 10, 10:14 AM · Restricted Project

Fri, Jun 7

jfb added a comment to D62962: Clang implementation of sizeless types.

How do these types mangle?

Fri, Jun 7, 12:30 PM · Restricted Project

Mon, Jun 3

jfb added inline comments to D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.
Mon, Jun 3, 6:59 PM · Restricted Project, Restricted Project
jfb added inline comments to D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.
Mon, Jun 3, 5:21 PM · Restricted Project, Restricted Project
jfb added inline comments to D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.
Mon, Jun 3, 5:05 PM · Restricted Project, Restricted Project
jfb updated subscribers of D62825: [C++2a] Add __builtin_bit_cast, used to implement std::bit_cast.
Mon, Jun 3, 4:48 PM · Restricted Project, Restricted Project

Tue, May 28

jfb added inline comments to D62428: [libcxx] Slightly improved policy for handling experimental features.
Tue, May 28, 11:21 AM · Restricted Project, Restricted Project
jfb added a comment to D62428: [libcxx] Slightly improved policy for handling experimental features.

The deletions are fine, the doc updates are good, but I think deprecation warnings are not.
Things that are going to happen in the future (a year from now, say) or never (if people don't update their tools) don't belong in the warning spew for every single build

Tue, May 28, 11:16 AM · Restricted Project, Restricted Project

Tue, May 21

jfb accepted D61963: [clang][Darwin] Refactor header search path logic into the driver.
Tue, May 21, 10:18 AM · Restricted Project

May 15 2019

jfb added a comment to D61923: [GWP-ASan] Mutex implementation [2]..
In D61923#1502404, @jfb wrote:

We can't use std::mutex as we must be C-compatible

Can you clarify what you mean by this? I don't understand.
Have you asked on libcxx-dev? Is there interest in the libc++ community for a stand-alone base?

Sorry, poor choice of wording. Our archive must be able to be statically linked into the supporting allocators. At this stage, the plans are to implement GWP-ASan into Scudo and Android's bionic libc. This means we have to be compatible with the the most restrictive aspects of each allocator's build environment, simultaneously.

In practice, we can't use std::mutex because Scudo specifies -nostdlib++ -nodefaultlibs, and if any part of the implementation of std::mutex (and likewise mtx_t) falls outside of the header file, we will fail to link (as is the case with libc++).

May 15 2019, 10:10 AM · Restricted Project, Restricted Project, Restricted Project

May 14 2019

jfb added a comment to D61923: [GWP-ASan] Mutex implementation [2]..
In D61923#1502245, @jfb wrote:

Seems a shame to duplicate mutex again... Why can't use use the STL's version again? It doesn't allocate.

We can't use std::mutex as we must be C-compatible

May 14 2019, 9:03 PM · Restricted Project, Restricted Project, Restricted Project
jfb added a comment to D60593: [GwpAsan] Introduce GWP-ASan..

What does GWP stand for?

Google Wide Profiling.

We use the name GWP-ASan, even though it's "technically neither GWP nor ASan", but because it describes well what the outcome is (sampled allocations with memory detection capabilities). It also mirrors the name used for the identical mechanism implemented in Chromium.

May 14 2019, 4:54 PM · Restricted Project, Restricted Project, Restricted Project
jfb added a comment to D61923: [GWP-ASan] Mutex implementation [2]..

Seems a shame to duplicate mutex again... Why can't use use the STL's version again? It doesn't allocate.

May 14 2019, 4:45 PM · Restricted Project, Restricted Project, Restricted Project
jfb accepted D61862: Use an offset from TOS for idempotent rmw locked op lowering.

One question for Chandler (which can be addressed as a follow up), otherwise LGTM.

May 14 2019, 9:11 AM · Restricted Project

May 9 2019

jfb accepted D58632: [X86] Improve lowering of idemptotent RMW operations.
May 9 2019, 3:34 PM · Restricted Project
jfb added reviewers for D61761: P1144 "Trivially relocatable" (1/3): is_trivially_relocatable, relocate_at, and uninitialized_relocate: mclow.lists, EricWF.
May 9 2019, 3:31 PM
jfb added inline comments to D58632: [X86] Improve lowering of idemptotent RMW operations.
May 9 2019, 12:24 PM · Restricted Project
jfb updated subscribers of D51103: [Support] Add a way to run a function on a detached thread.

IIUC, someone needs to review the Windows bits here.
I volunteer to do this tomorrow unless someone else want to beat me to this :-)

May 9 2019, 10:38 AM · Restricted Project
jfb accepted D61721: SelectionDAG: accommodate atomic floating stores.
May 9 2019, 8:59 AM · Restricted Project

May 8 2019

jfb added inline comments to D58632: [X86] Improve lowering of idemptotent RMW operations.
May 8 2019, 12:46 PM · Restricted Project
jfb added inline comments to D58632: [X86] Improve lowering of idemptotent RMW operations.
May 8 2019, 11:16 AM · Restricted Project

Apr 30 2019

jfb added a comment to D61280: Variable auto-init: don't initialize aggregate padding of all aggregates.

Follow-up test fix in http://llvm.org/r359636

Apr 30 2019, 4:32 PM · Restricted Project
jfb committed rGcdf26f15d19b: Fix auto-init test (authored by jfb).
Fix auto-init test
Apr 30 2019, 4:26 PM
jfb committed rL359636: Fix auto-init test.
Fix auto-init test
Apr 30 2019, 4:26 PM
jfb committed rC359636: Fix auto-init test.
Fix auto-init test
Apr 30 2019, 4:26 PM
jfb accepted D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.
Apr 30 2019, 4:19 PM · Restricted Project, Restricted Project
jfb committed rGd39fbc7e20d8: Variable auto-init: don't initialize aggregate padding of all aggregates (authored by jfb).
Variable auto-init: don't initialize aggregate padding of all aggregates
Apr 30 2019, 3:56 PM
jfb committed rC359628: Variable auto-init: don't initialize aggregate padding of all aggregates.
Variable auto-init: don't initialize aggregate padding of all aggregates
Apr 30 2019, 3:56 PM
jfb committed rL359628: Variable auto-init: don't initialize aggregate padding of all aggregates.
Variable auto-init: don't initialize aggregate padding of all aggregates
Apr 30 2019, 3:56 PM
jfb closed D61280: Variable auto-init: don't initialize aggregate padding of all aggregates.
Apr 30 2019, 3:56 PM · Restricted Project
jfb added a comment to D61280: Variable auto-init: don't initialize aggregate padding of all aggregates.

This seems uncontroversial, I'm happy to make follow-up change if you have suggestions.

Apr 30 2019, 3:56 PM · Restricted Project
jfb added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

Are you sure these are the right semantics for nodestroy? I think there's a reasonable argument that we should not destroy previous elements of a nodestroy array just because an element constructor throws. It's basically academic for true globals because the exception will terminate the process anyway, and even for thread_locals and static locals (where I believe the exception is theoretically recoverable) it's at least arguable that we should either decline to destroy (possibly causing leaks) or simply call std::terminate.

Apr 30 2019, 3:37 PM · Restricted Project, Restricted Project
jfb added a comment to D61280: Variable auto-init: don't initialize aggregate padding of all aggregates.

I don't think the implication is supposed to be that padding is zero-initialized or not depending on where in the aggregate it appears, but it doesn't really matter, I don't think we're arguing about the goal of this patch.

Apr 30 2019, 1:58 PM · Restricted Project
jfb added a comment to D61280: Variable auto-init: don't initialize aggregate padding of all aggregates.

IIRC, C says *members* are initialized as if they were in static storage, which might mean that their interior padding should be zeroed, but I don't think says anything about the padding in the enclosing aggregate. But I think zero-initializing padding is probably the right thing to do in general under this flag.

Apr 30 2019, 1:49 PM · Restricted Project
jfb added a comment to D61323: [WebAssembly] Support EXPLICIT_NAME symbols in llvm-readobj.

Looks like this broke some tests:

/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/test/MC/WebAssembly/import-module.ll:28:15: error: CHECK-NEXT: is not on the line after the previous match
; CHECK-NEXT: Flags: [ UNDEFINED ]
              ^
<stdin>:63:2: note: 'next' match was here
 Flags: [ UNDEFINED ]
 ^
<stdin>:57:11: note: previous match ended here
 Name: foo
          ^
<stdin>:58:1: note: non-matching line after previous match is here
 Flags: [ UNDEFINED, EXPLICIT_NAME ]
^

http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/60583/consoleFull

Apr 30 2019, 1:07 PM · Restricted Project

Apr 29 2019

jfb committed rGea51a8c1e50c: [NFC] typo (authored by jfb).
[NFC] typo
Apr 29 2019, 5:20 PM
jfb committed rL359524: [NFC] typo.
[NFC] typo
Apr 29 2019, 5:17 PM
jfb committed rC359524: [NFC] typo.
[NFC] typo
Apr 29 2019, 5:17 PM
jfb committed rG0d702a7fad87: [NFC] typo (authored by jfb).
[NFC] typo
Apr 29 2019, 5:10 PM
jfb committed rC359523: [NFC] typo.
[NFC] typo
Apr 29 2019, 5:10 PM
jfb committed rL359523: [NFC] typo.
[NFC] typo
Apr 29 2019, 5:09 PM
jfb added a reviewer for D61280: Variable auto-init: don't initialize aggregate padding of all aggregates: rjmccall.
Apr 29 2019, 4:44 PM · Restricted Project
jfb created D61280: Variable auto-init: don't initialize aggregate padding of all aggregates.
Apr 29 2019, 2:13 PM · Restricted Project

Apr 26 2019

jfb committed rG8504b5f64f47: Revert "[sanitizer] NFC: add static_assert to confirm that we use optimal… (authored by jfb).
Revert "[sanitizer] NFC: add static_assert to confirm that we use optimal…
Apr 26 2019, 3:29 PM
jfb committed rCRT359352: Revert "[sanitizer] NFC: add static_assert to confirm that we use optimal….
Revert "[sanitizer] NFC: add static_assert to confirm that we use optimal…
Apr 26 2019, 3:27 PM
jfb added a comment to D61200: [sanitizer] NFC: add static_assert to confirm that we use optimal ByteMap type.

Reverted in r359352.

Apr 26 2019, 3:27 PM · Restricted Project, Restricted Project
jfb committed rL359352: Revert "[sanitizer] NFC: add static_assert to confirm that we use optimal….
Revert "[sanitizer] NFC: add static_assert to confirm that we use optimal…
Apr 26 2019, 3:27 PM
jfb added a comment to D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.

Are you sure these are the right semantics for nodestroy? I think there's a reasonable argument that we should not destroy previous elements of a nodestroy array just because an element constructor throws. It's basically academic for true globals because the exception will terminate the process anyway, and even for thread_locals and static locals (where I believe the exception is theoretically recoverable) it's at least arguable that we should either decline to destroy (possibly causing leaks) or simply call std::terminate.

Apr 26 2019, 9:52 AM · Restricted Project, Restricted Project
jfb updated subscribers of D61165: Fix a crash where a [[no_destroy]] destructor was not emitted in an array.
Apr 26 2019, 9:52 AM · Restricted Project, Restricted Project

Apr 25 2019

jfb added a comment to D55229: [COFF] Statically link certain runtime library functions.

Looks like this might have broken bots:

/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/CodeGenCXX/runtime-dllstorage.cpp:121:26: error: CHECK-IA-DAG: expected string not found in input
// CHECK-DYNAMIC-IA-DAG: declare dllimport i32 @__cxa_thread_atexit(void (i8*)*, i8*, i8*)
                         ^
<stdin>:1:1: note: scanning from here
; ModuleID = '/Users/buildslave/jenkins/workspace/clang-stage1-cmake-RA-incremental/llvm/tools/clang/test/CodeGenCXX/runtime-dllstorage.cpp'
^
<stdin>:42:1: note: possible intended match here
declare dso_local i32 @__cxa_thread_atexit(void (i8*)*, i8*, i8*) #2
^

http://green.lab.llvm.org/green/job/clang-stage1-cmake-RA-incremental/60461/

Apr 25 2019, 5:03 PM · Restricted Project, Restricted Project
jfb added a comment to D61106: [analyzer][UninitializedObjectChecker] PR41590: Regard _Atomic types as primitive.

Have you checked what the C and C++ standards say about _Atomic / std::atomic initialization, and how they should actually be initialized by developers?

Apr 25 2019, 1:39 PM · Restricted Project

Apr 24 2019

jfb committed rGfb742da34c13: posix_spawn should retry upon EINTR (authored by jfb).
posix_spawn should retry upon EINTR
Apr 24 2019, 4:24 PM
jfb committed rL359152: posix_spawn should retry upon EINTR.
posix_spawn should retry upon EINTR
Apr 24 2019, 4:22 PM
jfb closed D61096: posix_spawn should retry upon EINTR.
Apr 24 2019, 4:22 PM · Restricted Project
jfb added a comment to D61096: posix_spawn should retry upon EINTR.

Hmm, we have this utility function RetryAfterSignal() but it doesn't have maxRetries.

http://llvm.org/doxygen/namespacellvm_1_1sys.html#aea8b04d954b2cebd8a26d5d712634312

Apr 24 2019, 3:39 PM · Restricted Project
jfb added a comment to D61096: posix_spawn should retry upon EINTR.

Apr 24 2019, 3:00 PM · Restricted Project
jfb created D61096: posix_spawn should retry upon EINTR.
Apr 24 2019, 2:59 PM · Restricted Project
jfb committed rG46d67fa6c5f9: Revert "[llvm-objdump] errorToErrorCode+message -> toString" (authored by jfb).
Revert "[llvm-objdump] errorToErrorCode+message -> toString"
Apr 24 2019, 9:50 AM
jfb committed rL359110: Revert "[llvm-objdump] errorToErrorCode+message -> toString".
Revert "[llvm-objdump] errorToErrorCode+message -> toString"
Apr 24 2019, 9:50 AM

Apr 19 2019

jfb added inline comments to D59380: Fold constant & invariant loads into uses over barrier instructions.
Apr 19 2019, 12:17 PM · Restricted Project

Apr 11 2019

jfb committed rGef202c308b5f: Variable auto-init: also auto-init alloca (authored by jfb).
Variable auto-init: also auto-init alloca
Apr 11 2019, 5:10 PM
jfb committed rL358243: Variable auto-init: also auto-init alloca.
Variable auto-init: also auto-init alloca
Apr 11 2019, 5:10 PM
jfb committed rC358243: Variable auto-init: also auto-init alloca.
Variable auto-init: also auto-init alloca
Apr 11 2019, 5:10 PM
jfb closed D60548: Variable auto-init: also auto-init alloca.
Apr 11 2019, 5:10 PM · Restricted Project
jfb added a comment to D60548: Variable auto-init: also auto-init alloca.

I got an lgtm from @pcc on IRC, so I'll commit this.

Apr 11 2019, 5:10 PM · Restricted Project
jfb added inline comments to D60548: Variable auto-init: also auto-init alloca.
Apr 11 2019, 3:29 PM · Restricted Project
jfb updated the diff for D60548: Variable auto-init: also auto-init alloca.
  • Change name, qualify declaration.
Apr 11 2019, 2:36 PM · Restricted Project
jfb added inline comments to D60548: Variable auto-init: also auto-init alloca.
Apr 11 2019, 2:36 PM · Restricted Project
jfb updated the diff for D60548: Variable auto-init: also auto-init alloca.
  • Move patternFor to a shared file as requested by @rjmccall
Apr 11 2019, 1:20 PM · Restricted Project
jfb added inline comments to D60548: Variable auto-init: also auto-init alloca.
Apr 11 2019, 1:20 PM · Restricted Project
jfb added a comment to D60548: Variable auto-init: also auto-init alloca.
In D60548#1463181, @jfb wrote:
In D60548#1462124, @jfb wrote:

One downside to alloca is that we can's use __attribute__((uninitialized)) because it's a builtin. Maybe we need a separate uninitialized alloca? What do you all think?

Actually I'm wondering if we should just implement:

#pragma clang attribute push (__attribute__((uninitialized)), apply_to = variable(unless(is_global)))

And lean on that for alloca, instead of having a new uninitialized alloca builtin. The pragma is useful for debugging regardless, so I think overall it's better.

Apr 11 2019, 12:46 PM · Restricted Project
jfb added a comment to D60548: Variable auto-init: also auto-init alloca.
In D60548#1462124, @jfb wrote:

One downside to alloca is that we can's use __attribute__((uninitialized)) because it's a builtin. Maybe we need a separate uninitialized alloca? What do you all think?

Apr 11 2019, 12:46 PM · Restricted Project

Apr 10 2019

jfb committed rCRT358145: [NFC] Use clearer naming for local variables.
[NFC] Use clearer naming for local variables
Apr 10 2019, 4:25 PM
jfb committed rG2f46de8c0b25: [NFC] Use clearer naming for local variables (authored by jfb).
[NFC] Use clearer naming for local variables
Apr 10 2019, 4:22 PM
jfb committed rL358145: [NFC] Use clearer naming for local variables.
[NFC] Use clearer naming for local variables
Apr 10 2019, 4:21 PM
jfb accepted D60298: Fix a hang when lowering __builtin_dynamic_object_size.
Apr 10 2019, 4:17 PM · Restricted Project
jfb added a comment to D60548: Variable auto-init: also auto-init alloca.

One downside to alloca is that we can's use __attribute__((uninitialized)) because it's a builtin. Maybe we need a separate uninitialized alloca? What do you all think?

Apr 10 2019, 3:58 PM · Restricted Project
jfb created D60548: Variable auto-init: also auto-init alloca.
Apr 10 2019, 3:57 PM · Restricted Project
jfb added a comment to D60480: [WIP] integration of pstl into libc++.

Not sure what is up with phabricator, but it won't let me respond inline to EricWF, specifically -

__FIRST_MOVER_ADVANTAGE

libc++ and libstdc++ have different 'uglification' protocols. As I said to mclow early on in this process, If I'm the one that has to do the grunt work of *all* of the uglification (very much has been case, BTW), it's going to follow libstdc++ convention as much as is possible.

libc++ code should follow libc++ conventions.

Apr 10 2019, 10:01 AM · Restricted Project

Apr 8 2019

jfb added a comment to D60372: [gn] Support for building libc++abi.

For those without context, it would be really helpful if every GN commit had a link to documentation about what GN is, and how LLVM supports it. The initial commit had a note, maybe the LLVM docs should have this?

Apr 8 2019, 9:28 AM · Restricted Project