similar to: GitHub Access Request

Hi Tom, I do not have SVN account, for accessing LLVM. Thanks, Sourabh On Tue 29 Oct, 2019, 9:08 AM Tom Stellard, <tstellar at redhat.com> wrote: > On 10/26/2019 03:39 AM, Sourabh Singh Tomar wrote: > > Hi All, > > > > I recently requested Chris regarding commit access to LLVM. > > He asked me to wait till the GitHub migration completes and then ask in >

Hello everyone, Since MLIR landed today. I'm trying to build it using cmake ../llvm/ -DCMAKE_BUILD_TYPE=RELEASE -DLLVM_TARGETS_TO_BUILD=X86 -DLLVM_ALL_PROJECTS="clang;lld;lldb;mlir" -DBUILD_SHARED_LIBS=ON -DCLANG_DEFAULT_LINKER:STRING=lld and also by adding -DLLVM_ALL_PROJECTS. It's giving this compilation error -- Building CXX object

These errors seem pretty pervasive for me on a clean build. It appears that it arises because when tablegen'd headers are included in a .h file, every place where that .h file is used needs a dependency on the corresponding IncGen targets. This seems broken in the short term and unmaintainable in the long term. There really needs to be a way of automatically generating the right

Hi llvm-dev, cfe-dev, It's been a while since our team is investigating DebugInfo in LLVM, we're looking forward to contribute and enhance in LLVM DebugInfo. We,'ve been investigating mostly on DWARF-5 aspects -- couple of them to mention-- 1. Language aspects 2. Location mostly optimized out ones 3. DebugInfo conformance to DWARF-5 To avoid getting conflicted with some body

Thanks, David for updating us. Regarding, mail address, can use anyone{@gmail or @amd}. but sourav0311 at gmail.com works best for me for mailing lists related stuff. Regarding, GDB side of DWARFv5 side of things, we've testing GDB-8.3 WRT DWARFv5 clang and gcc binaries to get better idea of debuggability of clang generated binaries with GDB. Primary motivation being GDB better handling of

Hi folks, While building openmpi.4.0.0(Optimized debug build), using trunk clang we encountered a crash(assertion failure). Initially assertion seems trivial: [...] void llvm::DwarfExpression::addFragmentOffset(const llvm::DIExpression*): Assertion `FragmentOffset >= OffsetInBits && "overlapping or duplicate fragments"' failed. [...] But, narrowing to RC. We discovered

Try using $PWD/test.cpp on the clang command line. I am seeing the duplicate DIFile entries, but not yet able to reproduce a .debug_line section with multiple directory entries. --paulr From: llvm-dev <llvm-dev-bounces at lists.llvm.org> On Behalf Of Tomar, Sourabh Singh via llvm-dev Sent: Tuesday, September 1, 2020 1:07 PM To: Umesh Kalappa <umesh.kalappa0 at gmail.com>; cfe-dev at

Hello Djordje, Vedant, Thanks a lot for sharing information. I have a doubt, please consider the following simple test case- #include <iostream> int func(int* ptr){ std::cout << *ptr; return *ptr + 5; } int main(int argc, char** argv){ int a = 4; int* ptr_a = &a; int b = func(ptr_a); return 0; } commandline used -- bash$ clang++

Hello Everyone, I'm working on providing support for New Language Tags, prescribed in DWARF-5. DW_LANG_C_plus_plus_03 DW_LANG_C_plus_plus_11 DW_LANG_C_plus_plus_14 While, C++11 and C++14, is defined and can be emitted by Frontend. "include/clang/Basci/LangStandard.h" CPlusPlus = (1 << 5), CPlusPlus11 = (1 << 6), CPlusPlus14 = (1 << 7), CPlusPlus17 = (1 <<

> On Apr 1, 2020, at 2:56 AM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > > > Do you mean documenting the desired frontend behavior, or adding some verifier in > LLVM? A warning for the latter is that SROA may currently emit IR that contains a > mix of declares and values for different fragments of an aggregate variable, so I > assume that is something that

Hello All, I was working on some dwarf-5 features and debugging optimized code support in clang and llvm. Noticed that, DW_TAG_call_site is supported in llvm middle-end. but clang is not emitting these. I was hoping, if someone could provide current status of these features and current status of dwarf-5 features in clang and llvm. That will be immensely helpful. Thanks! Sourabh. --------------

Hi Sourabh, Thanks for raising this issue. To answer your question, (afaik) there isn’t anyone working on DW_AT_start_scope support in tree. We’re looking for a solution to this problem for Swift debugging, where it's important not to make a debug location for a variable available until its (guaranteed) initialization is complete. If at all possible, I’d /much/ rather we use the existing

Hello Everyone, I have general question WRT llvm.dbg.value intrinsic function semantics. Under what circumstances should a frontend choose to emit(at -O0(No optimization)) llvm.dbg.value for a local variable. I saw some debuginfo code in flang(older one), sort of it choose to emit *llvm.dbg.value* for *every load operation* happening on a *local variable*. And as noted below in IR snippet it

> On Sep 10, 2019, at 6:15 AM, Djordje Todorovic via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sourabh, > > Support for call-site related DWARF 5 tag/attributes is implemented very late, in the LLVM middle-end. > Please note that there is also the IR-level flag (DIFlagAllCallsDescribed) that lowers to > the DW_AT_call_all_calls. > > There is also

> On Mar 30, 2020, at 4:13 AM, Jeremy Morse via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > Hi Sourabh, > > On Mon, Mar 30, 2020 at 8:09 AM Sourabh Singh Tomar via llvm-dev > <llvm-dev at lists.llvm.org> wrote: >> Under what circumstances should a frontend choose to emit(at -O0(No optimization)) llvm.dbg.value for a local variable. >> >> I

> On Mar 30, 2020, at 11:57 PM, Sourabh Singh Tomar <sourav0311 at gmail.com> wrote: > >> > My understanding is that this isn't correct: dbg.declare specifies the >> memory address of a variable for the whole lifetime of the function, >> whereas dbg.value (and dbg.addr) specify the value/address until the >> next debug intrinsic. Mixing these two kinds

Hello Everyone, I need to have your thoughts on this. Consider the following test case -- ------------------------------------------- 1 int main(int Argc, char **Argv) { 2 int Local = 6; 3 printf("%d\n",Local); 4 5 { 6 printf("%d\n",Local); 7 int Local = 7; 8 printf("%d\n",Local); 9 }

Hello Everyone, I would like to have your thoughts on this. Overview of the problem =================== While implementing support for the DWARFv5 debug_macro section support in LLVM. I came across these holes: - The macros infrastructure in CLANG/LLVM is inherently tied to a particular version(v4 macinfo). For instance, consider this snippet from CLANG:

Hi All , We have a scenario in our debugger to handle the file index in the debug_ine info like $llvm-dwarfdump -debug-line test.o file_names[ 1]: name: "test.cpp" dir_index: 0 mod_time: 0x00000000 length: 0x00000000 file_names[ 2]: name: "test.cpp" dir_index: 1 mod_time: 0x00000000 length: 0x00000000

Thank You for suggestion Adrian! Generated reproducer for the crash using clang reproducer and CReduce. ::Attachment:: C file. NIT: some clean up is done on this file just to silent some compiler warnings(like implicit declaration etc.) Crash can be reproduced using above test case with following commandline: $clang -g -O3 -mllvm –enable-partial-inlining creducegenerated-cleaned.c -c ---CRASH---