similar to: [LLVMdev] LLVM use of C++ exceptions and RTTI

Hi Al, > It's good that llvm/lib builds with exceptions and RTTI disabled as it > supports doing optimization and codegen on very constrained platforms. > Judging by REQUIRES_EH in makefiles, only a few bits like TableGen, llvm-ar > and llvm-ranlib need them, and I doubt these would need to run on a target. > It's unlikely exceptions would get in in a random patch, because

In that case, RTTI and exception should also be disabled from CMake generated projects right? Currently they are enabled all over my MSVC projects. On Thu, Oct 14, 2010 at 3:57 AM, Duncan Sands <baldrick at free.fr> wrote: > Hi Al, > >> It's good that llvm/lib builds with exceptions and RTTI disabled as it >> supports doing optimization and codegen on very constrained

Hi Francois, > In that case, RTTI and exception should also be disabled from CMake > generated projects right? > Currently they are enabled all over my MSVC projects. I'm not sure what you are asking. The goal is for LLVM to not require RTTI or exception handling. Thus these can be disabled by the build system (by specifying -fno-rtti etc), since they won't be used anyway. Not

Pekka Jääskeläinen wrote: > Jeffrey Yasskin wrote: >> I've put together http://llvm.org/docs/Packaging.html to document >> these kinds of requests for all packagers in one place. Let me know if >> any of the advice I've put there is wrong. (At the moment, > > Looks good to me. BTW exception support for LLVM is not required > to link with code that uses

On Thu, Oct 14, 2010 at 4:09 PM, Duncan Sands <baldrick at free.fr> wrote: > Hi Francois, > >> In that case, RTTI and exception should also be disabled from CMake >> generated projects right? >> Currently they are enabled all over my MSVC projects. > > I'm not sure what you are asking.  The goal is for LLVM to not require > RTTI or exception handling.

Siddharth, I'm not sure what coding standards you refer to when you say "some C++ coding standard". This question is answered in the LLVM Coding Standards document here: https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions <https://www.llvm.org/docs/CodingStandards.html#do-not-use-rtti-or-exceptions> As such LLVM's coding standards prohibit the

Jeffrey Yasskin wrote: > I've put together http://llvm.org/docs/Packaging.html to document > these kinds of requests for all packagers in one place. Let me know if > any of the advice I've put there is wrong. (At the moment, Looks good to me. BTW exception support for LLVM is not required to link with code that uses exceptions. At least our toolset seems to link fine with LLVM

Hi Chris, Thanks for answering, Can u clarify on this comment mentioned in https://github.com/Z3Prover/z3/issues/861 . cplusplus no exception support · Issue #861 · Z3Prover/z3 · GitHub - LLVM's *source code* does not use exceptions for performance reasons and so is compiled by default with -fno-exceptions. When using LLVM's libraries via it's C++ interface it is important

Forgot to CC the list, sorry. ----- Forwarded Message ----- > From: Samuel Crow <samuraileumas at yahoo.com> > To: FlyLanguage <flylanguage at gmail.com> > Cc: > Sent: Monday, July 18, 2011 10:40 AM > Subject: Re: [LLVMdev] RTTI gone in 3.0? > > Hi FlyLanguage, > > I thought LLVM disabled RTTI a long time ago.  It was just too slow. > > --Sam >

LLVM does not allow the use of exceptions in our code. We do not allow throwing or catching them. That does not mean you cannot compile the code with exceptions enabled, it just means we don't use them. Clang is a full C++ compiler. Even though LLVM & Clang do not use exceptions in their implementation, Clang does support compiling C++ code that uses exceptions. Does this answer your

Hi all, Can anyone explain why exceptions are disabled in LLVM, even if some C++ coding standard tells to use exceptions ? Thanks, Siddharth -------------- next part -------------- An HTML attachment was scrubbed... URL: <http://lists.llvm.org/pipermail/llvm-dev/attachments/20180501/ed7903db/attachment-0001.html>

> Looks like your shared library is not being compiled with symbols. > Did you verify that your sources are compiled with -g? I think so, this is the makefile (based on the one in the Hello pass): > LEVEL = ../../.. > LIBRARYNAME = CGF > LOADABLE_MODULE = 1 > USEDLIBS = > > ifneq ($(REQUIRES_RTTI), 1) > ifneq ($(REQUIRES_EH), 1) > EXPORTED_SYMBOL_FILE =

On Thu, Aug 14, 2014 at 6:01 PM, Reid Kleckner <rnk at google.com> wrote: > I thought Linux distros compile LLVM with RTTI and exceptions enabled when > packaging. > The question is why. RTTI makes sense -- they may well need it. But exceptions should work fine in the rest of the application even if LLVM is compiled with them, no? -------------- next part -------------- An HTML

> Currently what debugger has to do is to demangle RTTI name and try to > match it to DW_AT_name attribute to find type. As you can see it does > not work for any of 3 examples. > > I've asked about the problem on G++ maillist, and one of the proposed > solutions is to emit DW_AT_linkage_name for types.  > > Can this solution be also implemented in LLVM?  It could, but

Mangled names can be long indeed, but pretty-printed types are also long. I can evaluate effect on size on clang codebase itself. If you disable RTTI, than obviously you can't use it. So if RTTI is disabled, we can disable mangled names in DWARF. Clang is compiled without standard C++ RTTI because it has it's own RTTI. In general, however, many libraries use standard RTTI. 2018-03-02

Here is result of experiment: (Original size , with DW_AT_linkage_name for composites, % increase) clang-7.0 1926574256 1952846192 1.4% clang-tidy 1220980360 1238498112 1.4% llvm-mt 7404728 7525328 1.6 % std::cout << "hello world!" 21552 22080 2.4 % IMO, not that big price for reliable dynamic type identification (Full disclosure: I need depend on this feature, since

> On Jan 9, 2017, at 10:29 AM, Renato Golin via llvm-dev <llvm-dev at lists.llvm.org> wrote: > > On 9 January 2017 at 18:20, Reid Kleckner <rnk at google.com> wrote: >> I object to the first. If you need a new type name, use a typedef. It's time >> honored and everyone, including C programmers, will know what you're doing. >> I don't understand

On Fri, Mar 2, 2018 at 3:58 PM, Roman Popov via llvm-dev < llvm-dev at lists.llvm.org> wrote: > Hi all, > > As you may know modern C++ debuggers (GDB and LLDB) support dynamic type > identification for polymorphic objects, by utilizing C++ RTTI. > Unfortunately this feature does not work with Clang and GDB >= 7.x . The > last compiler that worked well was G++ 6.x >

Hi all, As you may know modern C++ debuggers (GDB and LLDB) support dynamic type identification for polymorphic objects, by utilizing C++ RTTI. Unfortunately this feature does not work with Clang and GDB >= 7.x . The last compiler that worked well was G++ 6.x I've asked about this issue both on GDB and LLDB maillists. Unfortunately it's hard or impossible to fix it on debugger side.

Hi, I've written a CallGraphSCCPass that compiles successfully, but when I try to run it with opt, it fails: Symbol not found: __ZTIN4llvm16CallGraphSCCPassE If I simply change the pass to be a FunctionPass or a ModulePass, opt can run it just fine. I'm on Mac OS X, so I thought perhaps I was running into bug #2771 [1], but I'm getting the same error on Ubuntu Linux: