search for: wweak

...e destructors or anchor methods. We seem to use one or the one, relatively inconsistently. What i’ve gone for is that if a class already had an inline destructor then i left it alone and added an anchor method. Otherwise I added an out of line destructor. Now if I compile Instructions.cpp with -Wweak-vtable, the only warnings given are: ../include/llvm/PassSupport.h:226:8: warning: 'PassRegistrationListener' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Wweak-vtables] struct PassRegistrationListener { ^ In file includ...

...laikie wrote: >>>> For a bit of an experiment I've been trying to compile LLVM & Clang >>>> with -Weverything (disabling any errors that seem like more noise/less >>>> interesting). One warning I've recently hit a few instances of is >>>> -Wweak-vtable which is, in fact, an explicitly documented LLVM coding >>>> standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch >>>> ). Some instances of this have been easy to fix (see attached patch - >>>> if it looks good to anyone I'll check that...

...v 29, 2011, at 12:26 AM, David Blaikie wrote: >> For a bit of an experiment I've been trying to compile LLVM & Clang >> with -Weverything (disabling any errors that seem like more noise/less >> interesting). One warning I've recently hit a few instances of is >> -Wweak-vtable which is, in fact, an explicitly documented LLVM coding >> standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch >> ). Some instances of this have been easy to fix (see attached patch - >> if it looks good to anyone I'll check that in) but a particular se...

...2:26 AM, David Blaikie wrote: >>> For a bit of an experiment I've been trying to compile LLVM & Clang >>> with -Weverything (disabling any errors that seem like more noise/less >>> interesting). One warning I've recently hit a few instances of is >>> -Wweak-vtable which is, in fact, an explicitly documented LLVM coding >>> standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch >>> ). Some instances of this have been easy to fix (see attached patch - >>> if it looks good to anyone I'll check that in) but a p...

...(rule of 0/5)) - I'd avoid adding a dtor to a class that doesn't have/need one (& whenever I see empty-bodied dtors I try to remove them - not always possible). > > I was probably the first one to use (or at least do a lot of them) the explicit anchors in an attempt to make LLVM -Wweak-vtables clean but never got around to going all the way there. I think Chris Lattner even advocated for not out-of-lining dtors just to make the vtables strong, instead using an explicit anchor. But I'm pretty ambivalent about it. In theory the style guide advocates this for build perf reasons...

...d Blaikie wrote: >>> Thanks Chris, committed as r145578. I don't suppose you'll mind some >>> similar commits as I encounter them? >> >> Yep, please feel free. > > While you said this - given that I've now gone & fixed /every/ > violation of -Wweak-vtables across LLVM & Clang (apart from some llvm > target tblgen problems - not sure how practical they are to fix. And > gtest also fires this warning) I thought I should probably get at > least a '*nod*' before I check this in. Looks fine to me, please do. > (also, I im...

For a bit of an experiment I've been trying to compile LLVM & Clang with -Weverything (disabling any errors that seem like more noise/less interesting). One warning I've recently hit a few instances of is -Wweak-vtable which is, in fact, an explicitly documented LLVM coding standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch ). Some instances of this have been easy to fix (see attached patch - if it looks good to anyone I'll check that in) but a particular set of them have been a littl...

...o override the built-in dynamic_cast operator to detect shared library issues (http://gcc.gnu.org/faq.html#dso). Basically we'd assert at runtime when a duplicated RTTI is found, giving us a chance to backtrace the offending class. I'm looking for a better solution with llvm; I know about -Wweak–vtables, but compiling with it gives me hundreds of errors, and some of them are false positives. So is there any legal way of catching dynamic_cast problems? Maybe dyld_interposing? I'd like to avoid replacing all dynamic_casts with another call if possible (because there are several hundreds...

...handling On Sep 30, 2011, at 3:04 PM, Somorjai, Akos wrote: Thanks! Yes, we are trying to avoid that situation as much as possible. Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? There's a -Wweak-vtables which will point out a lot of these cases. I have to warn you that in previous releases, it's still pretty experimental; Doug Gregor has done a lot of work on it on ToT. Another option is to run 'nm' on the objects/executables you're interested in. For example, this file...

On Nov 29, 2011, at 12:26 AM, David Blaikie wrote: > For a bit of an experiment I've been trying to compile LLVM & Clang > with -Weverything (disabling any errors that seem like more noise/less > interesting). One warning I've recently hit a few instances of is > -Wweak-vtable which is, in fact, an explicitly documented LLVM coding > standard ( http://llvm.org/docs/CodingStandards.html#ll_virtual_anch > ). Some instances of this have been easy to fix (see attached patch - > if it looks good to anyone I'll check that in) but a particular set of > th...

...d: AA (); AA (const AA&); // Disabled public: virtual ~AA (); }; In mem.cpp #include "mem.hpp" AA::~AA() { } And I still get the following warning: warning: 'AA' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Wweak-vtables,3] What am I doing wrong? Shall I declare the destructor to be pure virtual (then the warning goes away)? This is not always an option, because not all of these classes are ABCs. Thanks, Akos From: Ákos Somorjai <asomorjai at graphisoft.com<mailto:asomorjai at graphisoft.com>&g...

...l ~AA (); > }; > > In mem.cpp > > #include "mem.hpp" > > AA::~AA() > { > } > > And I still get the following warning: > > warning: 'AA' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Wweak-vtables,3] Which version of Clang are you using? Like I said, this warning was still experimental even a few months ago, and it's gotten a lot of attention on ToT. In particular, this case no longer warns. John. -------------- next part -------------- An HTML attachment was scrubbed... URL:...

On Fri, Aug 7, 2015 at 10:22 AM, Hans Wennborg via llvm-dev < llvm-dev at lists.llvm.org> wrote: > On Thu, Aug 6, 2015 at 12:04 PM, David Chisnall via llvm-dev > <llvm-dev at lists.llvm.org> wrote: > > [Ooops, sent to the old list address by mistake] > > > > On 30 Jul 2015, at 21:04, tom at stellard.net wrote: > >> > >> For flags like

...;> Thanks Chris, committed as r145578. I don't suppose you'll mind some >>>> similar commits as I encounter them? >>> >>> Yep, please feel free. >> >> While you said this - given that I've now gone & fixed /every/ >> violation of -Wweak-vtables across LLVM & Clang (apart from some llvm >> target tblgen problems - not sure how practical they are to fix. And >> gtest also fires this warning) I thought I should probably get at >> least a '*nod*' before I check this in. > > Looks fine to me, please...

...aikie > Date: Mon Dec 19 20:50:00 2011 > New Revision: 146960 > > URL: http://llvm.org/viewvc/llvm-project?rev=146960&view=rev > Log: > Unweaken vtables as per http://llvm.org/docs/CodingStandards.html#ll_virtual_anch So now that I've got Clang & LLVM almost entirely -Wweak-vtables clean I was wondering: Where/how could the build configuration be changed to help keep it that way? (so that anyone building LLVM/Clang with Clang (including bots) would build with -Wweak-vtables as an error?) (there are actually a couple of cases still to fix, to be honest - llvm-tblgen...

...t-in dynamic_cast operator to detect shared library issues > (http://gcc.gnu.org/faq.html#dso). Basically we'd assert at runtime when a > duplicated RTTI is found, giving us a chance to backtrace the offending class. > > I'm looking for a better solution with llvm; I know about -Wweak–vtables, but > compiling with it gives me hundreds of errors, and some of them are false positives. > So is there any legal way of catching dynamic_cast problems? Maybe > dyld_interposing? I'd like to avoid replacing all dynamic_casts with another > call if possible (because there a...

...: protected: AA (); AA (constAA&); // Disabled public: virtual ~AA (); }; In mem.cpp #include "mem.hpp" AA::~AA() { } And I still get the following warning: warning: 'AA' has no out-of-line virtual method definitions; its vtable will be emitted in every translation unit [-Wweak-vtables,3] Which version of Clang are you using? Like I said, this warning was still experimental even a few months ago, and it's gotten a lot of attention on ToT. In particular, this case no longer warns. John. -------------- next part -------------- An HTML attachment was scrubbed... URL:...

...ep 30, 2011, at 3:04 PM, Somorjai, Akos wrote: > Thanks! Yes, we are trying to avoid that situation as much as possible. > > Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? There's a -Wweak-vtables which will point out a lot of these cases. I have to warn you that in previous releases, it's still pretty experimental; Doug Gregor has done a lot of work on it on ToT. Another option is to run 'nm' on the objects/executables you're interested in. For example, this file...

Thanks! Yes, we are trying to avoid that situation as much as possible. Is there any compiler/linker/static analyzer option that would point out those problems (in 13 million lines, large part of that being legacy code)? Currently I don't know any better way than runtime logging and asserting. Also, what shall we do we external source libraries (like Teigha from Open Design Alliance), where

...I assume he wrote this policy - and, as I said in my previous email, I wouldn't mind seeing some justification or just seeing the rule go away & drop the anchors I added previously (or, if we're going to keep it, we could add more anchors & actually get to the point where we're -Wweak-vtable clean & enable that warning)) On Wed, Jun 12, 2013 at 1:44 PM, Patrik Hägglund H <patrik.h.hagglund at ericsson.com> wrote: > I tried to build LLVM with ’gcc-4.8.1 –flto’, and when linking unittest > programs, I got the following error: > > > > /tmp/cc8pMk84.ltra...