search for: relwithdebinfo

Hi all, These two cmake configuration are using different optimization levels (O2 vs O3). What is the rational for that? I know that O1 is "supposingly" more friendly for debugging, but I don't think we make such claim for O2 vs O3, are we? I'd expect RelWithDebInfo to be what the name says, i.e. Release + debug-information. -- Mehdi

...t > from MSVC, which is using this for its command line options: > > /GS- /TP /analyze- /W3 /wd"4391" /wd"4722" /wd"4291" /wd"4800" > /Zc:wchar_t /I"E:\llvm\compiler-rt\lib\asan\.." /Zi /Gm- /O2 /Ob1 > /Fd"RTAsan_dynamic.i386.dir\RelWithDebInfo\vc120.pdb" /fp:precise /D > "WIN32" /D "_WINDOWS" /D "NDEBUG" /D "EBUG" /D "ASAN_HAS_EXCEPTIONS=1" > /D "ASAN_DYNAMIC=1" /D "INTERCEPTION_DYNAMIC_CRT" /D > "__func__=__FUNCTION__" /D "CMAKE_INTDIR=\&q...

Hi All, I have tried to build llvm tip as following: cmake -DCMAKE_CXX_FLAGS:STRING="-DLLVM_ENABLE_DUMP" -DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm After running 'make', I have got error messages like below. llvm/lib/CodeGen/MachineRegisterInfo.cpp:462:67: error: no ‘void llvm::MachineRegisterInfo::dumpUses(unsigned int) const’ member function declared in class ‘llvm::MachineRegisterInfo’ llvm/lib/CodeGen/MachineScheduler....

...gt; On Apr 6, 2017, at 7:38 AM, jingu at codeplay.com via llvm-dev <llvm-dev at lists.llvm.org> wrote: >> >> Hi All, >> >> I have tried to build llvm tip as following: >> >> cmake -DCMAKE_CXX_FLAGS:STRING="-DLLVM_ENABLE_DUMP" -DCMAKE_BUILD_TYPE=RelWithDebInfo ../llvm >> >> After running 'make', I have got error messages like below. >> >> llvm/lib/CodeGen/MachineRegisterInfo.cpp:462:67: error: no ‘void llvm::MachineRegisterInfo::dumpUses(unsigned int) const’ member function declared in class ‘llvm::MachineRegisterInfo’ &...

hi, does anyone know how to resolve this? It's a very simple IR file (below), fails with: LLVM ERROR: invalid symbol kind for ADRP relocation PLEASE submit a bug report to https://bugs.llvm.org/ and include the crash backtrace. Stack dump: 0. Program arguments: \p\llvm-project-bin32\RelWithDebInfo\bin\llc.exe -O0 debug_output(1).ll -filetype=obj #0 0x01522349 (C:\p\llvm-project-bin32\RelWithDebInfo\bin\llc.exe+0x1272349) #1 0x019bb8fc (C:\p\llvm-project-bin32\RelWithDebInfo\bin\llc.exe+0x170b8fc) I have no idea where to even start looking, but it seems related to the store. ; ModuleID =...

...debug-info generation API) to facilitate testing is fine. Regarding DWARF parsing speed where strings are concerned: DWARF 5 will ruin this because DW_FORM_strx is a ULEB; so, every DIE that has a DW_AT_name or DW_AT_linkage_name will become variable-size (just as bad as DW_FORM_string). In a RelWithDebInfo build of Clang, I got just over 100 million DIEs and 40.2% had DW_AT_name. I didn't try to count DIEs that had DW_AT_linkage_name without DW_AT_name; it can happen, though, so the number of variable-size DIEs in DWARF 5 will actually be higher than that. Maybe we should propose a fixed-si...

On Thu, Oct 23, 2014 at 3:38 PM, Aaron Ballman <aaron at aaronballman.com> wrote: > On Thu, Oct 23, 2014 at 2:57 PM, Aaron Ballman <aaron at aaronballman.com> wrote: >> On Thu, Oct 23, 2014 at 2:46 PM, Timur Iskhodzhanov <timurrrr at google.com> wrote: >>> 2014-10-23 11:34 GMT-07:00 Aaron Ballman <aaron at aaronballman.com>: >>>> On Thu, Oct

...rs who've helped us get here (I've tried to CC everyone, sincere apologies if I've accidentally left you out). I believe Djordje and I have shown that there isn't an outsized binary size or compile time impact of enabling this feature. The aggregate size of DWARF in a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%, and we didn't find a significant compile time impact. We've shared CTMark results (both compile-time & DWARF section size numbers), as well as a size analysis of stage2 builds of {llc, clang, lldb} in [1]. Djordje has also shared a nice location statist...

...26 PM >> To: Matthias Braun >> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; jingu at codeplay.com <mailto:jingu at codeplay.com> >> Subject: Re: [llvm-dev] Question about LLVM Building Error with "- >> DLLVM_ENABLE_DUMP" and "RelWithDebInfo" >> >> >>> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev <llvm- >> dev at lists.llvm.org> wrote: >>> >>> I think the idea is to keep NDEBUG out of headers when possible. So I >> think this should better be something like: &g...

...ias Braun >>>> Cc: llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>; jingu at codeplay.com <mailto:jingu at codeplay.com> >>>> Subject: Re: [llvm-dev] Question about LLVM Building Error with "- >>>> DLLVM_ENABLE_DUMP" and "RelWithDebInfo" >>>> >>>> >>>>> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev <llvm- >>>> dev at lists.llvm.org <mailto:dev at lists.llvm.org>> wrote: >>>>> >>>>> I think the idea is to keep NDEBUG out o...

It works for me: ------ Build started: Project: LLVMHexagonCodeGen, Configuration: RelWithDebInfo Win32 ------ cl : Command line warning D9002: ignoring unknown option '/Zc:inline' HexagonFrameLowering.cpp ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped ========== Here's the info from the "about" window: Microsoft Visual Studio Professional 2013...

...>>>> <mailto:llvm-dev at lists.llvm.org>;jingu at codeplay.com >>>>>> <mailto:jingu at codeplay.com> >>>>>> Subject: Re: [llvm-dev] Question about LLVM Building Error with "- >>>>>> DLLVM_ENABLE_DUMP" and "RelWithDebInfo" >>>>>> >>>>>> >>>>>>> On Apr 7, 2017, at 4:45 PM, Matthias Braun via llvm-dev <llvm- >>>>>> dev at lists.llvm.org <mailto:dev at lists.llvm.org>> wrote: >>>>>>> >>>>>>...

...;ve helped us get here (I've tried to CC everyone, sincere apologies if I've accidentally left you out). > > I believe Djordje and I have shown that there isn't an outsized binary size or compile time impact of enabling this feature. The aggregate size of DWARF in a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%, and we didn't find a significant compile time impact. We've shared CTMark results (both compile-time & DWARF section size numbers), as well as a size analysis of stage2 builds of {llc, clang, lldb} in [1]. > > Djordje has also shared a nice locati...

On 09/29/2018 01:09 AM, Hans Wennborg via llvm-dev wrote: > Trunk still has the different gcc and clang versions. > > What's worse, the 7.0.0 release has them too :-( I completely missed > this and we can't fix it for 7.0.1 since that would also be an ABI > break. > Is this something we could fix by adding a symbol alias to the linker script for libLLVM.so? -Tom >

Hi, Trying to compile llvm with the following configuration on Linux x86-64: cmake -G Ninja -DBUILD_SHARED_LIBS=ON \ -DCMAKE_SHARED_LINKER_FLAGS="-fuse-ld=gold" \ -DCMAKE_EXE_LINKER_FLAGS="-fuse-ld=gold"\ -DCMAKE_BUILD_TYPE=RelWithDebInfo ' \ -DCMAKE_C_FLAGS="-O2 -g" \ -DCMAKE_CXX_FLAGS="-O2 -g" \ -DENABLE_LINKER_BUILD_ID=ON \ -DLLVM_ENABLE_ASSERTIONS=ON \ -DLLVM_ENABLE_PIC=ON \...

...rzysztof > > On Feb 12, 2016 7:42 PM, "Krzysztof Parzyszek via llvm-dev" > <llvm-dev at lists.llvm.org <mailto:llvm-dev at lists.llvm.org>> wrote: > > It works for me: > > ------ Build started: Project: LLVMHexagonCodeGen, Configuration: > RelWithDebInfo Win32 ------ > cl : Command line warning D9002: ignoring unknown option '/Zc:inline' > HexagonFrameLowering.cpp > ========== Build: 1 succeeded, 0 failed, 0 up-to-date, 0 skipped > ========== > > > Here's the info from the "about" wi...

...enable this on openSUSE but it seems to break standalone lldb (note that we don't ship static libs): cmake -DCMAKE_C_COMPILER=clang -DCMAKE_CXX_COMPILER=clang++ -DCMAKE_CXX_FLAGS=-stdlib=libc++ -DLLVM_BUILD_LLVM_DYLI B=ON -DLLVM_LINK_LLVM_DYLIB=ON -DCMAKE_INSTALL_PREFIX=/usr -DCMAKE_BUILD_TYPE=RelWithDebInfo -DLLVM_LIBDIR_SUFFIX=64 -DLLDB_PA TH_TO_LLVM_BUILD=/usr -DLLDB_PATH_TO_CLANG_BUILD=/usr -DLLVM_RUNTIME_OUTPUT_INTDIR=/home/abuild/rpmbuild/BUILD/lldb-3.8.0/buil d/bin -DLLVM_LIBRARY_OUTPUT_INTDIR=/home/abuild/rpmbuild/BUILD/lldb-3.8.0/build/lib64 -DPYTHON_VERSION_MAJOR=2 -DPYTHON_VERSIO N_MINOR=7 -...

...ve helped us get here (I've tried to CC everyone, sincere apologies if I've accidentally left you out). > > I believe Djordje and I have shown that there isn't an outsized binary size or compile time impact of enabling this feature. The aggregate size of DWARF in a stage2 x86_64 RelWithDebInfo clang build grows by under 0.2%, and we didn't find a significant compile time impact. We've shared CTMark results (both compile-time & DWARF section size numbers), as well as a size analysis of stage2 builds of {llc, clang, lldb} in [1]. > > Djordje has also shared a nice locat...

Just ran into the same problem, but with `-DLLVM_BUILD_TOOLS=ON` since the tools link against shlib and use the C++ interface I can't use Cosmin's solution. I managed to get through with using `RelWithDebInfo` instead of `Debug` On Sat, Jun 22, 2019 at 5:20 AM Cosmin Apreutesei via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Update: looks like the the problem was that the cmake script in > tools/llvm-shlib was set to export all symbols instead of just the C > symbols, and those ar...

...east 2 GB > of memory per core. However, I usually do Release builds, so Debug builds > might > need more. If you aren't using LLVM_PARALLEL_LINK_JOBS it's pretty easy > to > run out of memory once ninja starts linking the tools and unittests. > > -Tom For Debug (or RelWithDebInfo) I usually figure on around 5GB per thread to avoid swapping. Compiling is never an issue, it's the linking phase that uses memory. LLVM_PARALLEL_LINK_JOBS works well for ninja builds, it has been a real help. --paulr