Page MenuHomePhabricator

kamleshbhalui (kamlesh kumar)
User

Projects

User does not belong to any projects.

User Details

User Since
Feb 9 2018, 2:05 AM (223 w, 3 d)

Recent Activity

Sep 13 2021

kamleshbhalui added a comment to D108421: Mark openmp internal global dso_local.

ping?

Sep 13 2021, 4:31 PM · Restricted Project, Restricted Project, Restricted Project

Sep 7 2021

kamleshbhalui added a comment to D108421: Mark openmp internal global dso_local.

ping?

Sep 7 2021, 10:22 PM · Restricted Project, Restricted Project, Restricted Project

Sep 5 2021

kamleshbhalui updated the diff for D108421: Mark openmp internal global dso_local.

mark dso_local only when non-pic

Sep 5 2021, 8:16 PM · Restricted Project, Restricted Project, Restricted Project

Sep 1 2021

kamleshbhalui added a comment to D108421: Mark openmp internal global dso_local.

If you read the comment in TargetMachine::shouldAssumeDSOLocal: this is the wrong direction. dso_local is assumed to be marked by the frontend.

Direct accesses and GOT accesses are trade-offs. Direct accesses are not always preferred. The MachO special case is an unfortunate case for their xnu kernel, not a good example here.

Sep 1 2021, 9:16 AM · Restricted Project, Restricted Project, Restricted Project

Aug 23 2021

kamleshbhalui updated the diff for D108421: Mark openmp internal global dso_local.

updated test and make changes local to auto generated global vars for lock.

Aug 23 2021, 8:16 PM · Restricted Project, Restricted Project, Restricted Project

Aug 21 2021

kamleshbhalui added a comment to D108421: Mark openmp internal global dso_local.

assume dso local if relocation model static

I think these are two separate fixes. TargetMachine::shouldAssumeDSOLocal() change might make sense,
but as the comment there notes, this really should be fixed in in CGOpenMPRuntime::getOrCreateInternalVariable() itself (is that not the right default?),
and in it's every user that incorrectly unmarks said global as being `dso_local.

Aug 21 2021, 7:45 AM · Restricted Project, Restricted Project, Restricted Project
kamleshbhalui updated the diff for D108421: Mark openmp internal global dso_local.

assume dso local if relocation model static

Aug 21 2021, 3:37 AM · Restricted Project, Restricted Project, Restricted Project
kamleshbhalui updated the diff for D108421: Mark openmp internal global dso_local.

updated test and make changes local to auto generated global vars for lock.

Aug 21 2021, 3:12 AM · Restricted Project, Restricted Project, Restricted Project

Aug 19 2021

kamleshbhalui updated the diff for D108421: Mark openmp internal global dso_local.

clang formatted

Aug 19 2021, 8:05 PM · Restricted Project, Restricted Project, Restricted Project
kamleshbhalui requested review of D108421: Mark openmp internal global dso_local.
Aug 19 2021, 4:11 PM · Restricted Project, Restricted Project, Restricted Project

Jun 23 2021

kamleshbhalui added a comment to D103131: support debug info for alias variable.

Here is what we get when we replace int with float.

$lldb-11 ./a.out 
(lldb) target create "./a.out"
Current executable set to '/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/a.out' (x86_64).
(lldb) b main
Breakpoint 1: where = a.out`main + 4 at test.c:3:12, address = 0x0000000000400484
(lldb) p oldname
(float) $0 = 1
(lldb) p newname
(void *) $1 = 0x000000003f800000

Yep, looks like it's ignoring the imported declaration in favor of the raw symbol table entry.

How's lldb handle GCC-style debug info (the variable declaration, without any imported declaration) for the alias?

Jun 23 2021, 7:44 AM · debug-info, Restricted Project, Restricted Project
kamleshbhalui added a comment to D103131: support debug info for alias variable.

Here is what we get when we replace int with float.

Jun 23 2021, 4:56 AM · debug-info, Restricted Project, Restricted Project

Jun 22 2021

kamleshbhalui added a comment to D103131: support debug info for alias variable.

Huh, that surprises me - guess gdb favors checking the symbol first. I guess maybe it is using something that determines that that symbol comes from the file with debug info - because on a similar test case (one file without debug info, defining some global variable i, another file with debug info with a using ns::i in the global scope - printing i when stepping into the second file correctly prints the using based alias value, but stepping into the file without debug info and printing i complains about not knowing the type of that i)

How's lldb go?

Jun 22 2021, 7:27 PM · debug-info, Restricted Project, Restricted Project
kamleshbhalui added a comment to D103131: support debug info for alias variable.
0x0000002a:   DW_TAG_variable
                DW_AT_name      ("oldname")
                DW_AT_type      (0x0000003f "int")
                DW_AT_external  (true)
                DW_AT_decl_file ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
                DW_AT_decl_line (1)
                DW_AT_location  (DW_OP_addr 0x0)

0x0000003f:   DW_TAG_base_type
                DW_AT_name      ("int")
                DW_AT_encoding  (DW_ATE_signed)
                DW_AT_byte_size (0x04)

0x00000046:   DW_TAG_variable
                DW_AT_name      ("newname")
                DW_AT_type      (0x0000003f "int")
                DW_AT_decl_file ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
                DW_AT_decl_line (2)
                DW_AT_declaration       (true)

0x00000051:   DW_TAG_imported_declaration
                DW_AT_decl_file ("/folk/kkumar/tcllvm/llvm-build-lldb-rel/bin/test.c")
                DW_AT_decl_line (2)
                DW_AT_import    (0x00000046)
                DW_AT_name      ("newname")

I agree with David, this sequence doesn't seem to do what's desired.
There's nothing that ties "newname" to "oldname" here. What you
want is something more like this:

0x0000002a: DW_TAG_variable
               DW_AT_name ("oldname")
               ...
0x0000003a: DW_TAG_imported_declaration
               DW_AT_import (0x0000002a)
               DW_AT_name ("newname")

That is, there would not be a separate DW_TAG_variable for "newname";
instead, the imported_declaration would import the DIE for "oldname"
giving it the name "newname".

--paulr

Jun 22 2021, 1:48 AM · debug-info, Restricted Project, Restricted Project

Jun 11 2021

kamleshbhalui added a comment to D103131: support debug info for alias variable.

Any idea if the GDB test suite covers this functionality? I'd hope so, but maybe it doesn't.

But yeah, at the moment I don't have any great reason to avoid the imported declaration form - so happy to go with that.

Hi David,

with imported declaration patch and with current patch(in review or say gcc way) this case works ok(we can print type and value of newname)
$cat test.c
int oldname = 1;
extern int newname attribute((alias("oldname")));

but when we make newname static it works with current patch(in review or say gcc way) but it does not work with imported decl patch(https://reviews.llvm.org/D103131?id=347883).

Should we go with gcc way or am I missing something?
note: used gdb debugger.

An ideas what's happening when newname is static? Is the DWARF any different/interesting there? (since the DWARF for imported decl seems like it would have nothing to do with the linkange of the alias - since it doesn't refer to the actual alias in the object file, etc)

Jun 11 2021, 4:44 PM · debug-info, Restricted Project, Restricted Project

Jun 10 2021

kamleshbhalui added a comment to D103131: support debug info for alias variable.

Any idea if the GDB test suite covers this functionality? I'd hope so, but maybe it doesn't.

But yeah, at the moment I don't have any great reason to avoid the imported declaration form - so happy to go with that.

Jun 10 2021, 4:58 PM · debug-info, Restricted Project, Restricted Project

Jun 9 2021

kamleshbhalui added a comment to D103131: support debug info for alias variable.

Mixed feelings - somewhat in favor of "do the thing that's probably already fairly tested/known to work" (GCC's thing). But open to the idea that that approach has problems, for sure.

"Known to work" for whom? gdb, sure, because gcc/gdb cooperate on many things.

Yep. Given the diversity of ways of expressing things in DWARF, no consumer will handle everything that could be produced in the way a producer might intend - so we do sort of have a defacto standard of "what would GCC do/what does GDB understand".

But also GCC/GDB has had more implementation experience with DWARF in general, and with any feature we haven't implemented yet in particular - that I wouldn't throw out their representational choice too quickly - there may be important tradeoffs that were considered, implemented, and discarded due to limitations.

I'll have to check with my debugger guys whether this would work for us; and I'll just reiterate that it's certainly not what the DWARF spec suggests should be done.

I don't agree that it's "certainly not what the DWARF spec suggests should be done" - the spec's pretty generous and exactly how a C or ELF level alias should be rendered in DWARF seems pretty unclear to me. For instance an alias is a symbol in the ELF file, arguably different from a source level alias like a typedef or using declaration that DW_TAG_imported_declaration seems to be promoted for.

I doubt gdb would have trouble with DW_TAG_imported_declaration

Mixed feelings - somewhat in favor of "do the thing that's probably already fairly tested/known to work" (GCC's thing). But open to the idea that that approach has problems, for sure.

"Known to work" for whom? gdb, sure, because gcc/gdb cooperate on many things. I'll have to check with my debugger guys whether this would work for us; and I'll just reiterate that it's certainly not what the DWARF spec suggests should be done.

The Sony debugger will not be able to figure out the address of "newname" given the DWARF as emitted by gcc (because it looks like an external declaration with no address). We'd much rather have the DW_TAG_imported_declaration that the original patch had.

Good to know - any interest in the debugger supporting declarations without addresses? I guess there's no need for GCC compatibility? Clang might emit them under some circumstances... let's see... Hmm, can't find a case now. But there are cases where it would be desirable (such as when compiling some code at -g0 and some with debug info - when you only have the declaration on the debug info side, and no debug info on the definition side (eg: GCC produces a declaration of 'i' in this code: extern int i; int main() { return i; }))

@kamleshbhalui - perhaps you could run the gdb and lldb test suites without either change, then with both the variable declaration and imported declaration versions to see how the results vary? (Well, I guess the lldb test suite probably won't show any changes - but maybe worth running anyway) - along with the manual test you've described in the patch description, to demonstrate that both solutions address that?

Jun 9 2021, 10:36 PM · debug-info, Restricted Project, Restricted Project

May 28 2021

kamleshbhalui added a comment to D103131: support debug info for alias variable.

$cat test.h
int oldname;

May 28 2021, 8:18 PM · debug-info, Restricted Project, Restricted Project
kamleshbhalui updated the diff for D103131: support debug info for alias variable.

matching gcc behavior

May 28 2021, 5:42 AM · debug-info, Restricted Project, Restricted Project

May 26 2021

kamleshbhalui updated the diff for D103131: support debug info for alias variable.

match gcc behavior

May 26 2021, 9:56 PM · debug-info, Restricted Project, Restricted Project
kamleshbhalui updated the diff for D103131: support debug info for alias variable.

removed unnecessary code.

May 26 2021, 3:25 AM · debug-info, Restricted Project, Restricted Project

May 25 2021

kamleshbhalui added a comment to D103131: support debug info for alias variable.

Looks like GCC emits aliases as a DW_TAG_variable without a location, not as a DW_TAG_imported_declaration - what gave you the inspiration to do it in this way? (I think it's probably good, but DWARF doesn't lend itself to novelty so much... can be good to stick with how other folks already do things since it'll be what consumers already know how to handle)

How's this work if the alias target isn't declared in the source - but in inline assembly instead? (I guess GCC probably handles that OK, but the Clang strategy here might not cope with it)

May 25 2021, 7:06 PM · debug-info, Restricted Project, Restricted Project
kamleshbhalui requested review of D103131: support debug info for alias variable.
May 25 2021, 5:51 PM · debug-info, Restricted Project, Restricted Project

Apr 19 2021

kamleshbhalui committed rG36c3918ec55b: [libc++] [C++20] [P0586] Implement safe integral comparisons (authored by Kamlesh Kumar <kamlesbhalui@gmail.com>).
[libc++] [C++20] [P0586] Implement safe integral comparisons
Apr 19 2021, 4:26 PM
kamleshbhalui closed D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.
Apr 19 2021, 4:26 PM · Unknown Object (Project)
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

updated generate_feature_test_macro_components.py.

Apr 19 2021, 9:52 AM · Unknown Object (Project)
kamleshbhalui added a comment to D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

There are still quite some formatting errors, for example () , instead of (),, please use the instructions here to format the patch https://llvm.org/docs/Contributing.html#how-to-submit-a-patch

Apr 19 2021, 9:46 AM · Unknown Object (Project)
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

formatted intcmp.fail.cpp

Apr 19 2021, 5:00 AM · Unknown Object (Project)

Apr 18 2021

kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

formatted the tests as per @Quuxplusone comments

Apr 18 2021, 10:37 PM · Unknown Object (Project)
kamleshbhalui added a reviewer for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons: Quuxplusone.
Apr 18 2021, 5:14 PM · Unknown Object (Project)
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

incorporated @Quuxplusone comments

Apr 18 2021, 5:13 PM · Unknown Object (Project)
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

fixed a typo.

Apr 18 2021, 7:03 AM · Unknown Object (Project)
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

incorporated comments from @Quuxplusone, @Mordante and @curdeius

Apr 18 2021, 6:59 AM · Unknown Object (Project)

Apr 8 2021

kamleshbhalui updated the diff for D99580: [CLANG] [DebugInfo] Convert File name to native format.

Making changes effective only for windows

Apr 8 2021, 4:05 AM · Restricted Project, Restricted Project

Apr 7 2021

kamleshbhalui added a reviewer for D99580: [CLANG] [DebugInfo] Convert File name to native format: rnk.

ping?

Apr 7 2021, 10:24 AM · Restricted Project, Restricted Project
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

Incorporated @Quuxplusone suggestions.

Apr 7 2021, 10:15 AM · Unknown Object (Project)
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

Addressed @curdeius comments.

Apr 7 2021, 8:35 AM · Unknown Object (Project)

Apr 2 2021

kamleshbhalui updated the diff for D99580: [CLANG] [DebugInfo] Convert File name to native format.

Making changes effective only for windows

Apr 2 2021, 7:24 AM · Restricted Project, Restricted Project

Mar 30 2021

kamleshbhalui updated the diff for D99580: [CLANG] [DebugInfo] Convert File name to native format.

updated patch

Mar 30 2021, 11:22 PM · Restricted Project, Restricted Project
kamleshbhalui updated the diff for D99580: [CLANG] [DebugInfo] Convert File name to native format.

clang formatting the patch.

Mar 30 2021, 11:15 PM · Restricted Project, Restricted Project
kamleshbhalui updated the diff for D99580: [CLANG] [DebugInfo] Convert File name to native format.

Marked failed tests as unsupported on windows system
Because now clang emits native path for DIFile.

Mar 30 2021, 9:40 PM · Restricted Project, Restricted Project
kamleshbhalui added a reviewer for D99580: [CLANG] [DebugInfo] Convert File name to native format: amccarth.
Mar 30 2021, 6:52 PM · Restricted Project, Restricted Project
kamleshbhalui added a comment to D99580: [CLANG] [DebugInfo] Convert File name to native format.

@rnk @akhuang - I think we touched on this before maybe in some other thread/patch/discussion?

Ah, @probinson mentioned in the linked thread:

Is this https://bugs.llvm.org/show_bug.cgi?id=44170 which had a tentative patch at https://reviews.llvm.org/D71508 ?
The original complaint wasn't for Windows, but the lack of filepath canonicalization seems like a common symptom.

Might be best, @kamleshbhalui, if you could check if the other (D71508) patch relates to the same issue & if so, continue the discussion over there instead of forking it here.

Mar 30 2021, 6:17 PM · Restricted Project, Restricted Project
kamleshbhalui added a comment to D99580: [CLANG] [DebugInfo] Convert File name to native format.

Another possible issue is that llvm::sys::path and other functions try to map Windows filesystem concepts to Posix ones. There are many cases where there isn't a perfect mapping. For example: Windows has a current working directory _per drive_, and so it can be hard to resolve paths like D:foo.ext, which are relative to something other than the "current working directory." Details like this can come into play in the immediate vicinity of the code change, so I have some trepidation.

Agree with you but this problem exist with and without this patch.

It looks like the code change is for everyone, but the new test is specific to mingw.

Mar 30 2021, 3:48 PM · Restricted Project, Restricted Project
kamleshbhalui requested review of D99580: [CLANG] [DebugInfo] Convert File name to native format.
Mar 30 2021, 5:16 AM · Restricted Project, Restricted Project

Mar 28 2021

kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

Updated the tests

Mar 28 2021, 9:35 PM · Unknown Object (Project)

Mar 5 2021

kamleshbhalui added a comment to D98006: Fixed Test for cases when DISABLE_NEW_COUNT is defined.

This doesn't answer my question unfortunately.
What configuration (platform/OS/compiler, cmake invocation etc.) you used when you found the failures?
What were these failures precisely?

Mar 5 2021, 7:20 AM · Unknown Object (Project)
kamleshbhalui added a comment to D98006: Fixed Test for cases when DISABLE_NEW_COUNT is defined.

Can you give some details please about the config on which these tests failed?

Mar 5 2021, 7:01 AM · Unknown Object (Project)
kamleshbhalui retitled D98006: Fixed Test for cases when DISABLE_NEW_COUNT is defined from Fixed test to Fixed Test for cases when DISABLE_NEW_COUNT is defined.
Mar 5 2021, 6:58 AM · Unknown Object (Project)
kamleshbhalui updated the diff for D98006: Fixed Test for cases when DISABLE_NEW_COUNT is defined.

Added one fixed test

Mar 5 2021, 1:29 AM · Unknown Object (Project)
kamleshbhalui updated the diff for D98006: Fixed Test for cases when DISABLE_NEW_COUNT is defined.

Fixed more tests

Mar 5 2021, 1:06 AM · Unknown Object (Project)

Mar 4 2021

kamleshbhalui added a reviewer for D98006: Fixed Test for cases when DISABLE_NEW_COUNT is defined: ldionne.
Mar 4 2021, 10:26 PM · Unknown Object (Project)
kamleshbhalui requested review of D98006: Fixed Test for cases when DISABLE_NEW_COUNT is defined.
Mar 4 2021, 10:25 PM · Unknown Object (Project)

Mar 2 2021

kamleshbhalui committed rG5c3fc5093aaf: [libunwind] [risc-v] This patch is for fixing (authored by kamleshbhalui).
[libunwind] [risc-v] This patch is for fixing
Mar 2 2021, 3:08 PM
kamleshbhalui closed D97762: [RISCV] fixes cross unwinding failure.
Mar 2 2021, 3:08 PM · Restricted Project, Unknown Object (Project)
kamleshbhalui requested review of D97762: [RISCV] fixes cross unwinding failure.
Mar 2 2021, 3:37 AM · Restricted Project, Unknown Object (Project)

Mar 1 2021

kamleshbhalui committed rGb17d46430fce: [libunwind] This adds support in libunwind for rv32 hard float (authored by kamleshbhalui).
[libunwind] This adds support in libunwind for rv32 hard float
Mar 1 2021, 5:33 PM
kamleshbhalui closed D80690: [RISCV] Support libunwind for riscv32.
Mar 1 2021, 5:32 PM · Unknown Object (Project), Restricted Project
kamleshbhalui abandoned D97750: Fix memleak for 5de2d189e6ad4.
Mar 1 2021, 5:02 PM · Restricted Project
kamleshbhalui requested review of D97750: Fix memleak for 5de2d189e6ad4.
Mar 1 2021, 5:01 PM · Restricted Project

Feb 14 2021

kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

addressed @Mordante comments.

Feb 14 2021, 4:25 PM · Unknown Object (Project)
kamleshbhalui added inline comments to D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.
Feb 14 2021, 3:23 PM · Unknown Object (Project)
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

used _LIBCPP_NO_HAS_CHAR8_T and _LIBCPP_HAS_NO_UNICODE_CHARS macro to guard char8_t, and char16_t, char32_t.

Feb 14 2021, 10:25 AM · Unknown Object (Project)
kamleshbhalui updated the diff for D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.

addressed @curdeius comments.
added tests, few test snippets taken from the link given by @curdeius.

Feb 14 2021, 10:07 AM · Unknown Object (Project)

Jan 12 2021

kamleshbhalui requested review of D94511: [libc++] [C++20] [P0586] Implement safe integral comparisons.
Jan 12 2021, 9:28 AM · Unknown Object (Project)

Jan 4 2021

kamleshbhalui updated the diff for D80690: [RISCV] Support libunwind for riscv32.

fixed a nit.

Jan 4 2021, 8:29 PM · Unknown Object (Project), Restricted Project
kamleshbhalui updated the diff for D80690: [RISCV] Support libunwind for riscv32.

rebased with the main branch. do not see any conflict.
@ldionne or @abdulras can you please have a look at this, this patch is in this state for a long time.
FYI, I have been using this patch in VxWorks.

Jan 4 2021, 8:22 PM · Unknown Object (Project), Restricted Project

Nov 5 2020

kamleshbhalui accepted D90817: [RISCV] Use the 'si' lib call for (double (fp_to_sint/uint i32 X)) when F extension is enabled..

LGTM!

Nov 5 2020, 3:42 AM · Restricted Project

Oct 14 2020

kamleshbhalui added a comment to D88727: vector (iterator,iterator) constructor doesn't deduce second arg.

Is this a problem unique to vector? Do the other containers have the same constructor? Do those constructors have the same issue?
Checking ... list does not seem to have this problem. deque does not either. forward_list does not either.

<deque> has the following code:

template <class _InputIter>
    deque(_InputIter __f, _InputIter __l,
          typename enable_if<__is_cpp17_input_iterator<_InputIter>::value>::type* = 0);
template <class _InputIter>
    deque(_InputIter __f, _InputIter __l, const allocator_type& __a,
          typename enable_if<__is_cpp17_input_iterator<_InputIter>::value>::type* = 0);

I don't think that making vector different from the other containers is the right approach. Then again, I'm not 100% sure why the existing code is failing - so I should look at tha

Oct 14 2020, 9:10 AM · Unknown Object (Project)
kamleshbhalui added a comment to D88727: vector (iterator,iterator) constructor doesn't deduce second arg.

ping?

Oct 14 2020, 8:27 AM · Unknown Object (Project)

Oct 2 2020

kamleshbhalui updated the diff for D88727: vector (iterator,iterator) constructor doesn't deduce second arg.

Added test suggested by @mclow.lists .

Oct 2 2020, 8:08 AM · Unknown Object (Project)
kamleshbhalui added a comment to D88727: vector (iterator,iterator) constructor doesn't deduce second arg.

So the actual problem in the bug report is that the first argument cannot be used to deduce the type.

I think it is not correct to remove the type restrictions here, they are there for a reason.

Oct 2 2020, 6:13 AM · Unknown Object (Project)
kamleshbhalui updated the summary of D88727: vector (iterator,iterator) constructor doesn't deduce second arg.
Oct 2 2020, 4:21 AM · Unknown Object (Project)
kamleshbhalui requested review of D88727: vector (iterator,iterator) constructor doesn't deduce second arg.
Oct 2 2020, 4:20 AM · Unknown Object (Project)

Aug 30 2020

kamleshbhalui committed rGdeb99610ab00: Improve doc comments for several methods returning bools (authored by kamleshbhalui).
Improve doc comments for several methods returning bools
Aug 30 2020, 1:04 AM
kamleshbhalui closed D86848: [MLIR] Improving the Comment .
Aug 30 2020, 1:03 AM · Unknown Object (Project)

Aug 29 2020

kamleshbhalui requested review of D86848: [MLIR] Improving the Comment .
Aug 29 2020, 10:51 PM · Unknown Object (Project)

Jul 31 2020

kamleshbhalui accepted D85002: [RISCV] eliminate the repetition declare of SDLoc DL.

LGTM!

Jul 31 2020, 12:53 AM · Restricted Project

Jul 30 2020

kamleshbhalui updated the diff for D81391: [RISC-V] Do not crash when using -ftrapping-math.

rebased with the master.

Jul 30 2020, 2:28 AM · Restricted Project

Jul 26 2020

kamleshbhalui updated the diff for D80690: [RISCV] Support libunwind for riscv32.

addressed @mhorne comments.

Jul 26 2020, 11:14 PM · Unknown Object (Project), Restricted Project

Jul 23 2020

kamleshbhalui added a comment to D81391: [RISC-V] Do not crash when using -ftrapping-math.

@asb and @luismarques do you suggest anything here ?

Jul 23 2020, 2:14 AM · Restricted Project
kamleshbhalui added a comment to D80690: [RISCV] Support libunwind for riscv32.

ping?

Jul 23 2020, 2:04 AM · Unknown Object (Project), Restricted Project

Jun 29 2020

kamleshbhalui added a comment to D80690: [RISCV] Support libunwind for riscv32.

ping?

Jun 29 2020, 3:12 AM · Unknown Object (Project), Restricted Project

Jun 24 2020

kamleshbhalui added inline comments to D82446: [clang] Fix duplicate warning.
Jun 24 2020, 6:59 AM · Restricted Project
kamleshbhalui created D82446: [clang] Fix duplicate warning.
Jun 24 2020, 3:44 AM · Restricted Project

Jun 22 2020

kamleshbhalui updated the diff for D80690: [RISCV] Support libunwind for riscv32.

addressed @mhorne and @MaskRay concerns.

Jun 22 2020, 9:07 AM · Unknown Object (Project), Restricted Project

Jun 19 2020

kamleshbhalui updated the diff for D80690: [RISCV] Support libunwind for riscv32.

rebased and cleaned up the diff.

Jun 19 2020, 9:44 AM · Unknown Object (Project), Restricted Project
kamleshbhalui added a comment to D82171: [libc++] Require concepts support for <numbers>.

D77505 broke a bunch of bots. This fixes the regression.

I lack commit privileges. Please land as "Raul Tambre <raul@tambre.ee>"

Jun 19 2020, 6:59 AM · Unknown Object (Project)
kamleshbhalui committed rG4f6c4b473c4a: [libc++] Implement <numbers> (authored by tambre).
[libc++] Implement <numbers>
Jun 19 2020, 2:07 AM
kamleshbhalui closed D77505: [libc++] Implement <numbers>.
Jun 19 2020, 2:07 AM · Unknown Object (Project)
kamleshbhalui added a comment to D77505: [libc++] Implement <numbers>.

Please commit this for me in case no one else has objections. I lack commit privileges.

Jun 19 2020, 12:29 AM · Unknown Object (Project)

Jun 18 2020

kamleshbhalui committed rG7622ea5835f0: [RISCV64] Emit correct lib call for fp(float/double) to ui/si (authored by kamleshbhalui).
[RISCV64] Emit correct lib call for fp(float/double) to ui/si
Jun 18 2020, 7:35 AM
kamleshbhalui closed D80526: [RISCV64] emit correct lib call for fp(double) to ui/si.
Jun 18 2020, 7:35 AM · Restricted Project
kamleshbhalui added a reviewer for D82014: [compiler-rt] Replaced __SOFT_FP__ with __SOFTFP__: MaskRay.
Jun 18 2020, 2:41 AM · Restricted Project, Restricted Project

Jun 17 2020

kamleshbhalui updated the summary of D82014: [compiler-rt] Replaced __SOFT_FP__ with __SOFTFP__.
Jun 17 2020, 8:03 AM · Restricted Project, Restricted Project
kamleshbhalui updated the summary of D82014: [compiler-rt] Replaced __SOFT_FP__ with __SOFTFP__.
Jun 17 2020, 8:03 AM · Restricted Project, Restricted Project
kamleshbhalui created D82014: [compiler-rt] Replaced __SOFT_FP__ with __SOFTFP__.
Jun 17 2020, 8:03 AM · Restricted Project, Restricted Project
kamleshbhalui updated the summary of D82014: [compiler-rt] Replaced __SOFT_FP__ with __SOFTFP__.
Jun 17 2020, 8:03 AM · Restricted Project, Restricted Project
kamleshbhalui added a reviewer for D80526: [RISCV64] emit correct lib call for fp(double) to ui/si: efriedma.
Jun 17 2020, 7:31 AM · Restricted Project
kamleshbhalui updated the diff for D80526: [RISCV64] emit correct lib call for fp(double) to ui/si.

Addressed @efriedma comments.
added test for strictfp.

Jun 17 2020, 7:31 AM · Restricted Project