[llvm] r252537 - Fix -Wdeprecated warnings due to the use of copy ops on SCEVPredicate derived class objects

[David Blaikie via llvm-commits]

On Thu, Nov 12, 2015 at 8:29 AM, Vasileios Kalintiris <
Vasileios.Kalintiris at imgtec.com> wrote:

> The test-case compiles fine with & without the base struct:
> https://goo.gl/gChBXX
>

Ah, seems it's the existence of a friend:

struct base {
  virtual void f2();
  // friend struct other;
protected:
  ~base() = default;
};

struct derived final : base { };

Warning fires if the friend decl is uncommented.

I'm still not sure we want to abide by that behavior. If we do, we should
consider implementing it in clang's version of the warning too...

>
>
> -Vasileios
> ------------------------------
> *From:* David Blaikie [dblaikie at gmail.com]
> *Sent:* 12 November 2015 16:21
> *To:* Vasileios Kalintiris
> *Cc:* llvm-commits at lists.llvm.org
> *Subject:* Re: [llvm] r252537 - Fix -Wdeprecated warnings due to the use
> of copy ops on SCEVPredicate derived class objects
>
>
>
> On Thu, Nov 12, 2015 at 7:06 AM, Vasileios Kalintiris <
> Vasileios.Kalintiris at imgtec.com> wrote:
>
>> Hi David,
>>
>> This introduced a "class has virtual functions and accessible non-virtual
>> destructor" warning that is being printed a lot of times (g++ 5.2.1). Can
>> you look at this?
>>
>
> We should disable that warning on GCC. This API seems safe to me, no? The
> base class's dtor is protected (so external users can't polymorphically
> delete objects) and the derived classes have public non-virtual dtors, but
> are final (so no further classes can derived from them)
>
> This is not the only API that uses that pattern - oh, maybe it's the
> FoldingSetNode that's complicating this? Could you check if this produces
> the warning on GCC (is there a pastebin that runs that version of GCC so I
> can check this myself easily?)
>
> struct base {
> };
>
> struct middle: base {
>   virtual void func();
> protected:
>   ~middle() = default;
> };
>
> struct derived final : middle {
> };
>
> & then if you remove the base class, does the warning go away?
>
> - Dave
>
>
>>
>> Thanks,
>> Vasileios
>>
>> [8/101] /usr/local/bin/g++   -DGTEST_HAS_RTTI=0 -D_DEBUG -D_GNU_SOURCE
>> -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
>> -Ilib/Transforms/Utils -I/home/vk/repos/llvm/lib/Transforms/Utils -Iinclude
>> -I/home/vk/r
>> epos/llvm/include -fPIC -fvisibility-inlines-hidden -Wall -W
>> -Wno-unused-parameter -Wwrite-strings -Wcast-qual
>> -Wno-missing-field-initializers -pedantic -Wno-long-long
>> -Wno-maybe-uninitialized -Wnon-virtual-dtor -Wno-comment -std
>> =c++11 -g -fPIC   -gsplit-dwarf  -fno-exceptions -fno-rtti -MMD -MT
>> lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/SimplifyIndVar.cpp.o
>> -MF
>> lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/SimplifyIndVar.cpp.o.d
>> -o
>> lib/Transforms/Utils/CMakeFiles/LLVMTransformUtils.dir/SimplifyIndVar.cpp.o
>> -c /home/vk/repos/llvm/lib/Transforms/Utils/SimplifyIndVar.cpp
>> In file included from
>> /home/vk/repos/llvm/include/llvm/Analysis/ScalarEvolutionExpressions.h:19:0,
>>                  from
>> /home/vk/repos/llvm/lib/Transforms/Utils/SimplifyIndVar.cpp:22:
>> /home/vk/repos/llvm/include/llvm/Analysis/ScalarEvolution.h:174:9:
>> warning: ‘class llvm::SCEVPredicate’ has virtual functions and accessible
>> non-virtual destructor [-Wnon-virtual-dtor]
>>    class SCEVPredicate : public FoldingSetNode {
>>          ^
>> /home/vk/repos/llvm/include/llvm/Analysis/ScalarEvolution.h:244:9:
>> warning: base class ‘class llvm::SCEVPredicate’ has accessible non-virtual
>> destructor [-Wnon-virtual-dtor]
>>    class SCEVEqualPredicate final : public SCEVPredicate {
>>          ^
>> /home/vk/repos/llvm/include/llvm/Analysis/ScalarEvolution.h:275:9:
>> warning: base class ‘class llvm::SCEVPredicate’ has accessible non-virtual
>> destructor [-Wnon-virtual-dtor]
>>    class SCEVUnionPredicate final : public SCEVPredicate {
>>          ^
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.llvm.org/pipermail/llvm-commits/attachments/20151112/280b7f25/attachment.html>