Page MenuHomePhabricator

jcai19 (Jian Cai)
User

Projects

User does not belong to any projects.

User Details

User Since
May 15 2019, 3:25 PM (26 w, 5 d)

Recent Activity

Wed, Nov 13

jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Support arbitrary numbers of fragments between the symbols of kind
MCDataFragment. Getting the size of MCFillFragments seems to be less
straightforward https://llvm.org/doxygen/MCAssembler_8cpp_source.html#l00287.

Wed, Nov 13, 9:05 PM · Restricted Project

Tue, Nov 12

jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Making this work only on ".if" is IMO a non-starter, at least without understanding why. So I looked into what broke with llvm/test/MC/MachO/reloc-diff.s.

Basically, with LLVM's current representation, assuming that consecutive fragments are never moved with respect to each-other is invalid. In both ELF and Mach-O. In ELF, we have the ability to use numbered subsections that can insert new fragments between existing fragments. In Mach-O, fragments can effectively be turned into subsections with the 'subsections_via_symbols' directive. Committing this patch as-is would both be ugly and wrong, since we'd allow computing nonsense offsets -- even if we only restrict it to ".if".

I think it's a mistake that it works like that, and I'm going to spend a little bit of time to see if it'll be easy to fix this representational mistake in LLVM (in a separate patch), so that we have fragment lists which _are_ guaranteed to be kept exactly in the order they appear.

For this review, I have two requests:

  1. Undo all the ".if"-only hacks. (understanding that it will cause some tests to fail, for now).
  2. Fix the code to support arbitrary numbers of fragments between the symbols, of kinds MCFillFragment and MCDataFragment (and maybe others if they are fixed size -- I haven't looked through all of the kinds). Probably best would be to introduce a helper function to calculate the delta between two arbitrary symbols, given an optional layout (and either return an answer or a failure indication). This should make AttemptToFoldSymbolOffsetDifference significantly more straightforward.

    I believe these examples should work, and will after making the latter change: ` 1: .arch armv7a nop .arch armv4 nop .arch armv7a nop .if . - 1b != 0 .word 0x12345678 .endif

    2: nop .zero 0x10000 nop .if . - 2b == 4 .word 0x12345678 .endif `
Tue, Nov 12, 2:03 PM · Restricted Project
jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Tue, Nov 12, 11:14 AM · Restricted Project
jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Tue, Nov 12, 11:14 AM · Restricted Project
jcai19 added inline comments to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Tue, Nov 12, 12:10 AM · Restricted Project

Mon, Nov 11

jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Fix a typo.

Mon, Nov 11, 12:12 PM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Fix test cases.

Mon, Nov 11, 12:02 PM · Restricted Project
jcai19 added a comment to D70062: MCObjectStreamer: assign MCSymbols in the dummy fragment to offset 0..

Thanks for this patch!

Mon, Nov 11, 11:35 AM · Restricted Project
jcai19 retitled D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements from [MC] Enhance parsing of .if conditions to [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Mon, Nov 11, 10:59 AM · Restricted Project
jcai19 added inline comments to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Mon, Nov 11, 10:50 AM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Remove the code redundant to D70062.

Mon, Nov 11, 10:49 AM · Restricted Project

Sat, Nov 9

jcai19 retitled D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements from [MC] Calculate difference of symbols in two fragments when possible to [MC] Enhance parsing of .if conditions.
Sat, Nov 9, 10:43 AM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Handle cases at https://bugs.llvm.org/show_bug.cgi?id=41825.

Sat, Nov 9, 10:43 AM · Restricted Project

Wed, Nov 6

jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Thanks for the update. I'll wait a few days to see what comments we get. If there are none then I guess there aren't any strong objections.

To clarify the remarks about resolving .if at layout time. I think that there are two major obstacles.

  • MC assembles instructions once, if the condition in the .if is not satisfied the contents of the block aren't even parsed. For example, the following will assemble if the .if condition fails, but will fail to parse if the .if condition passes. We'd need to change MC to either reparse (effectively making it a multipass assembler), or to parse and remember all parts. This is doable but it isn't a small change. ` .text .if 0 You aren't parsing me are you? .else nop .endif `
  • The second problem, and not one unique to llvm-mc, is that it is possible to write a program that doesn't converge, something like (not testable as it needs relaxation and late evaluation of .if): ` label: beq after In thumb 2 this 2-byte branch will be relaxed to a 4-byte branch if out of range. .if . - label == 2 .space 1024 * 1024 sufficient to make after out of range .endif after: nop ` In pass 1, beq is 2-bytes in size, the .if passes, beq is then relaxed to 4-bytes, which would make the .if fail, which then makes beq 2-bytes ... The interaction with relaxation could be fixed by making all size increases permanent. However I think it is possible to write multiple .if conditions that conflict. In Arm's old 2 - pass assembler (pass -1 find all sizes so layout is known, pass-2 encode instructions knowing layout), we had an error message when the equivalent of .if evaluated differently in subsequent passes. In summary, I think it would be a major change to MC to support something like late evaluation of .if in a reliable way.
Wed, Nov 6, 11:43 AM · Restricted Project

Tue, Nov 5

jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

I think that this needs some wider review for a couple of reasons. It looks like this is heading towards a special case evaluation just for .if. I'm not comfortable going too much further in the approval process as this is exceeding my knowledge of MC, and I'd like see some supporting opinions on whether this is the right thing to do. Will be worth adding some more reviewers, particularly someone familiar with Mach-O. You may need an RFC to the llvm-dev mailing list to draw some attention.

Tue, Nov 5, 4:27 PM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Add test cases.

Tue, Nov 5, 4:00 PM · Restricted Project
jcai19 added inline comments to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Tue, Nov 5, 11:34 AM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Address some concerns.

Tue, Nov 5, 11:34 AM · Restricted Project

Fri, Nov 1

jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Update tests.

Fri, Nov 1, 4:53 PM · Restricted Project
jcai19 added inline comments to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Fri, Nov 1, 4:53 PM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Update test cases.

Fri, Nov 1, 4:44 PM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Update test cases and move their location.

Fri, Nov 1, 4:25 PM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Fix format.

Fri, Nov 1, 2:52 PM · Restricted Project
jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

There are also some test cases for other ISA's in https://bugs.llvm.org/show_bug.cgi?id=41825.

Fri, Nov 1, 2:43 PM · Restricted Project
jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

When I run check-llvm with this patch applied I get 7 failures:

LLVM :: DebugInfo/Mips/delay-slot.ll
LLVM :: DebugInfo/Mips/dsr-fixed-objects.ll
LLVM :: DebugInfo/Mips/dsr-non-fixed-objects.ll
LLVM :: DebugInfo/Mips/fn-call-line.ll
LLVM :: MC/AsmParser/directive_fill_2.s
LLVM :: MC/MachO/reloc-diff.s
LLVM :: MC/X86/expand-var.s

This is applied to master revision 12c9ffd108345f643df98dfa8653af1a4311ed86 and the tests don't fail with master. Is it possible your most recent changes have broken something? I'm testing a release build of LLVM with clang, assertions enabled.

Fri, Nov 1, 2:43 PM · Restricted Project
jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

I'd like to see some more test cases for the error cases. Off the top of my head I can think of these cases:

// Align fragment in between MCDataFragments
9997: nop ;
      .align 4
      nop
.if . - 9997b == 4 ;
// Fill (I think) fragment in between MCDataFragments
9997: nop ;
      .space 4
      nop
.if . - 9997b == 4 ;
// Relaxable (in Thumb) fragment in between MCDataFragments
9997: nop ;
      b external
      nop
.if . - 9997b == 4 ;
// Constant pool between MCDataFragments,
9997:
      ldr r0,=0x12345678 ;
      .ltorg
      nop  
.if . - 9997b == 4 ;

There is also something called a MCCompactEncodingInstFragment that would cause this to fail, but I think that only exists as part of NaCl bundle locking, which I think isn't too much of a concern.

Fri, Nov 1, 2:33 PM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Made sure the patch pass check-clang and check-llvm.

Fri, Nov 1, 2:33 PM · Restricted Project

Wed, Oct 30

jcai19 abandoned D69296: [ARM] Uses "Sun Style" syntax for section switching.

Linux has been patched by to use normal section switching syntax https://lkml.org/lkml/2019/10/30/807. Abandon this LLVM patch as we should be fine without it.

Wed, Oct 30, 11:03 AM · Restricted Project

Tue, Oct 29

jcai19 added a comment to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

When I run check-llvm with this patch applied I get 7 failures:

LLVM :: DebugInfo/Mips/delay-slot.ll
LLVM :: DebugInfo/Mips/dsr-fixed-objects.ll
LLVM :: DebugInfo/Mips/dsr-non-fixed-objects.ll
LLVM :: DebugInfo/Mips/fn-call-line.ll
LLVM :: MC/AsmParser/directive_fill_2.s
LLVM :: MC/MachO/reloc-diff.s
LLVM :: MC/X86/expand-var.s

This is applied to master revision 12c9ffd108345f643df98dfa8653af1a4311ed86 and the tests don't fail with master. Is it possible your most recent changes have broken something? I'm testing a release build of LLVM with clang, assertions enabled.

Tue, Oct 29, 11:32 AM · Restricted Project

Mon, Oct 28

jcai19 added inline comments to D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Mon, Oct 28, 11:18 PM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Update the test case.

Mon, Oct 28, 11:18 PM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Update the patch based on comments.

Mon, Oct 28, 11:17 PM · Restricted Project
jcai19 updated the summary of D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Mon, Oct 28, 10:35 AM · Restricted Project
jcai19 added reviewers for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements: dschuff, sunfish.
Mon, Oct 28, 10:34 AM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Update commit log.

Mon, Oct 28, 10:33 AM · Restricted Project
jcai19 updated the diff for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.

Add a test case.

Mon, Oct 28, 10:20 AM · Restricted Project
jcai19 updated the diff for D69296: [ARM] Uses "Sun Style" syntax for section switching.

Fix wrong patch.

Mon, Oct 28, 10:17 AM · Restricted Project
jcai19 updated the diff for D69296: [ARM] Uses "Sun Style" syntax for section switching.

Add a test case.

Mon, Oct 28, 10:09 AM · Restricted Project

Fri, Oct 25

jcai19 added a comment to D69296: [ARM] Uses "Sun Style" syntax for section switching.

@nickdesaulniers Maybe we should fix kernel instead? The fix will be cleaner that way.

Fri, Oct 25, 6:01 PM · Restricted Project
jcai19 updated the diff for D69296: [ARM] Uses "Sun Style" syntax for section switching.

Right now once we toggle SunStyleELFSectionSwitchSyntax on an architecture, all the section switching assembly is emitted on sun-style syntax, which is the reason why some test cases fail as they assume the regular syntax. To deal with this issue, I introduced a new variable that would allow the architecture to parse sun-style assembly while not emitting it.

Fri, Oct 25, 4:56 PM · Restricted Project
jcai19 reopened D69296: [ARM] Uses "Sun Style" syntax for section switching.
Fri, Oct 25, 4:56 PM · Restricted Project
jcai19 added a comment to D69296: [ARM] Uses "Sun Style" syntax for section switching.

Sorry about the breakage. I have reverted the commit. Will reland once I fix it.

Thanks much for the revert!

Going forward, when reverting things, please say in the revert commit message _why_ you're reverting (e.g. "breaks bots, see original review", or "breaks CodeGen/cfstring3.c on most bots", or similar) :)

Fri, Oct 25, 2:29 PM · Restricted Project
jcai19 added a comment to D69296: [ARM] Uses "Sun Style" syntax for section switching.

This breaks tests everywhere, see eg http://45.33.8.238/linux/2607/step_6.txt

Please take a look and revert if it takes a while to fix.

And please always watch http://lab.llvm.org:8011/console for a bit after landing.

Fri, Oct 25, 2:20 PM · Restricted Project
jcai19 committed rGa6b0219fc4a7: Revert "[ARM] Uses "Sun Style" syntax for section switching" (authored by jcai19).
Revert "[ARM] Uses "Sun Style" syntax for section switching"
Fri, Oct 25, 2:11 PM
jcai19 added a reverting change for rG03de2f84fc4a: [ARM] Uses "Sun Style" syntax for section switching: rGa6b0219fc4a7: Revert "[ARM] Uses "Sun Style" syntax for section switching".
Fri, Oct 25, 2:11 PM
jcai19 committed rG03de2f84fc4a: [ARM] Uses "Sun Style" syntax for section switching (authored by jcai19).
[ARM] Uses "Sun Style" syntax for section switching
Fri, Oct 25, 1:34 PM
jcai19 closed D69296: [ARM] Uses "Sun Style" syntax for section switching.
Fri, Oct 25, 1:33 PM · Restricted Project
jcai19 updated the diff for D69296: [ARM] Uses "Sun Style" syntax for section switching.

Update commit message.

Fri, Oct 25, 12:10 PM · Restricted Project
jcai19 updated the diff for D69296: [ARM] Uses "Sun Style" syntax for section switching.

Formatted.

Fri, Oct 25, 11:02 AM · Restricted Project
jcai19 added inline comments to D69296: [ARM] Uses "Sun Style" syntax for section switching.
Fri, Oct 25, 11:02 AM · Restricted Project

Thu, Oct 24

jcai19 added a reviewer for D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements: echristo.
Thu, Oct 24, 3:25 PM · Restricted Project
jcai19 updated subscribers of D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Thu, Oct 24, 3:14 PM · Restricted Project
jcai19 created D69411: [MC] Parse .if conditions with symbols in consecutive MCDataFragements.
Thu, Oct 24, 3:03 PM · Restricted Project
jcai19 updated the diff for D69296: [ARM] Uses "Sun Style" syntax for section switching.

Update comments.

Thu, Oct 24, 10:33 AM · Restricted Project

Wed, Oct 23

jcai19 updated subscribers of D69296: [ARM] Uses "Sun Style" syntax for section switching.
Wed, Oct 23, 9:55 AM · Restricted Project

Tue, Oct 22

jcai19 added a comment to D69296: [ARM] Uses "Sun Style" syntax for section switching.

I can see that this would allow "Sun Style" syntax for section switching that seems to be permitted for the Arm target. The question is why, and why just Arm? Looking at the GNU as code it looks like:

  • This syntax was supported for Solaris, it only has tests for Solaris
  • The syntax isn't gated by target, but it doesn't work on any target that uses # as the comment character (x86), it fails with a cryptic error message, this suggests it works on Arm and AArch64 by accident rather than by intention.
  • The comment in MCAsmInfo.h states "instead of the normal ELF syntax", looking at the implementation it seems like both can be used at once as there isn't a parsing difference, however this might not be by design.
Tue, Oct 22, 9:40 PM · Restricted Project
jcai19 updated the diff for D69296: [ARM] Uses "Sun Style" syntax for section switching.

Update comments.

Tue, Oct 22, 9:27 PM · Restricted Project
jcai19 updated the diff for D69296: [ARM] Uses "Sun Style" syntax for section switching.
Tue, Oct 22, 9:18 PM · Restricted Project

Mon, Oct 21

jcai19 added reviewers for D69296: [ARM] Uses "Sun Style" syntax for section switching: peter.smith, eli.friedman, kristof.beyls, t.p.northover.
Mon, Oct 21, 9:46 PM · Restricted Project
jcai19 created D69296: [ARM] Uses "Sun Style" syntax for section switching.
Mon, Oct 21, 9:36 PM · Restricted Project

Oct 15 2019

jcai19 committed rG0650355c09ab: [clang] refactor -Wa,-W test cases. (authored by jcai19).
[clang] refactor -Wa,-W test cases.
Oct 15 2019, 11:17 AM
jcai19 committed rL374932: [clang] refactor -Wa,-W test cases..
[clang] refactor -Wa,-W test cases.
Oct 15 2019, 11:17 AM

Oct 14 2019

jcai19 committed rG72593d3bdcdc: [clang] add requirements to -Wa,-W test cases. (authored by jcai19).
[clang] add requirements to -Wa,-W test cases.
Oct 14 2019, 3:50 PM
jcai19 committed rL374837: [clang] add requirements to -Wa,-W test cases..
[clang] add requirements to -Wa,-W test cases.
Oct 14 2019, 3:50 PM
jcai19 committed rG4ec5205da701: Add support to -Wa,-W in clang (authored by jcai19).
Add support to -Wa,-W in clang
Oct 14 2019, 3:28 PM
jcai19 committed rG89478148d836: Revert "Add support to -Wa,-W in clang" (authored by jcai19).
Revert "Add support to -Wa,-W in clang"
Oct 14 2019, 3:28 PM
jcai19 closed D68884: Add support to -Wa,-W in clang.
Oct 14 2019, 3:28 PM · Restricted Project
jcai19 committed rL374834: Add support to -Wa,-W in clang.
Add support to -Wa,-W in clang
Oct 14 2019, 3:28 PM
jcai19 committed rL374833: Revert "Add support to -Wa,-W in clang".
Revert "Add support to -Wa,-W in clang"
Oct 14 2019, 3:28 PM
jcai19 committed rGe9089c223cea: [ARM][AsmParser] handles offset expression in parentheses (authored by jcai19).
[ARM][AsmParser] handles offset expression in parentheses
Oct 14 2019, 3:22 PM
jcai19 closed D68764: [ARM][AsmParser] handles offset expression in parentheses.
Oct 14 2019, 3:21 PM · Restricted Project
jcai19 committed rL374832: [ARM][AsmParser] handles offset expression in parentheses.
[ARM][AsmParser] handles offset expression in parentheses
Oct 14 2019, 3:21 PM
jcai19 added a comment to D68764: [ARM][AsmParser] handles offset expression in parentheses.

Thanks for the patch and for following up on code review!

Oct 14 2019, 3:19 PM · Restricted Project
jcai19 updated the diff for D68884: Add support to -Wa,-W in clang.

For autogenerated comment log.

Oct 14 2019, 2:31 PM · Restricted Project
jcai19 committed rG753d789c4416: Add support to -Wa,-W in clang (authored by jcai19).
Add support to -Wa,-W in clang
Oct 14 2019, 2:22 PM
jcai19 committed rL374822: Add support to -Wa,-W in clang.
Add support to -Wa,-W in clang
Oct 14 2019, 2:22 PM
jcai19 updated the diff for D68764: [ARM][AsmParser] handles offset expression in parentheses.

Fix a typo

Oct 14 2019, 2:03 PM · Restricted Project
jcai19 added inline comments to D68764: [ARM][AsmParser] handles offset expression in parentheses.
Oct 14 2019, 2:03 PM · Restricted Project

Oct 11 2019

jcai19 added inline comments to D68764: [ARM][AsmParser] handles offset expression in parentheses.
Oct 11 2019, 1:45 PM · Restricted Project
jcai19 updated the diff for D68764: [ARM][AsmParser] handles offset expression in parentheses.

Update based on comments.

Oct 11 2019, 1:45 PM · Restricted Project
jcai19 updated the diff for D68884: Add support to -Wa,-W in clang.

Update test cases.

Oct 11 2019, 1:18 PM · Restricted Project
jcai19 updated subscribers of D68884: Add support to -Wa,-W in clang.
Oct 11 2019, 1:18 PM · Restricted Project
jcai19 updated the diff for D68884: Add support to -Wa,-W in clang.

Fix typos.

Oct 11 2019, 1:14 PM · Restricted Project
jcai19 added a reviewer for D68884: Add support to -Wa,-W in clang: bcain.
Oct 11 2019, 1:14 PM · Restricted Project
jcai19 created D68884: Add support to -Wa,-W in clang.
Oct 11 2019, 1:14 PM · Restricted Project

Oct 10 2019

jcai19 updated the diff for D68764: [ARM][AsmParser] handles offset expression in parentheses.

Expand test cases and rename test file.

Oct 10 2019, 5:04 PM · Restricted Project
jcai19 added inline comments to D68764: [ARM][AsmParser] handles offset expression in parentheses.
Oct 10 2019, 5:04 PM · Restricted Project
jcai19 updated the diff for D68764: [ARM][AsmParser] handles offset expression in parentheses.

Fix a typo.

Oct 10 2019, 11:50 AM · Restricted Project
jcai19 added a comment to D68764: [ARM][AsmParser] handles offset expression in parentheses.
acceet offset

typo

Oct 10 2019, 11:50 AM · Restricted Project
jcai19 updated the summary of D68764: [ARM][AsmParser] handles offset expression in parentheses.
Oct 10 2019, 11:50 AM · Restricted Project
jcai19 updated the diff for D68764: [ARM][AsmParser] handles offset expression in parentheses.

Fix bugs.

Oct 10 2019, 12:29 AM · Restricted Project
jcai19 updated the diff for D68764: [ARM][AsmParser] handles offset expression in parentheses.

Remove typos.

Oct 10 2019, 12:02 AM · Restricted Project

Oct 9 2019

jcai19 created D68764: [ARM][AsmParser] handles offset expression in parentheses.
Oct 9 2019, 11:52 PM · Restricted Project
jcai19 added a reviewer for D68764: [ARM][AsmParser] handles offset expression in parentheses: nickdesaulniers.
Oct 9 2019, 11:52 PM · Restricted Project

Oct 8 2019

jcai19 added inline comments to D68598: [IA] Recognize hexadecimal escape sequences.
Oct 8 2019, 4:08 PM · Restricted Project
jcai19 added inline comments to D68598: [IA] Recognize hexadecimal escape sequences.
Oct 8 2019, 12:01 AM · Restricted Project

Oct 4 2019

jcai19 accepted D68483: [IA] Recognize hexadecimal escape sequences.

Thank you for the fix! LGTM. Please give some time to @nickdesaulniers for comments.

Oct 4 2019, 5:29 PM · Restricted Project
jcai19 added inline comments to D68483: [IA] Recognize hexadecimal escape sequences.
Oct 4 2019, 4:04 PM · Restricted Project

Sep 16 2019

jcai19 closed D66627: [clang-tidy] add checks to bugprone-posix-return.
Sep 16 2019, 3:31 PM · Restricted Project
jcai19 committed rG155a43edb0c1: [compiler-rt][crt] make test case nontrivial in check_cxx_section_exists (authored by jcai19).
[compiler-rt][crt] make test case nontrivial in check_cxx_section_exists
Sep 16 2019, 2:47 PM