A simple question about virtual destructors.
Hi, My question is what if a compiler will generate a virtual destructor (or convert a nonvirtual to virtual) in a base class if the base class has at least one virtual function and classes down in the hierarchy have nontrivial destructors? In other words make a compiler responsible for proper destruction of a polymorphic object. Are there any serious pros against this? This suggestion can look stupid but just think how many type strokes and hours in searching of memory leaks this could save. Kirill.
Re: A simple question about virtual destructors.
2016-06-02 11:55 GMT+02:00 K : > Hi, > > My question is what if a compiler will generate a virtual destructor (or > convert a nonvirtual to virtual) in a base class if the base class has at > least one virtual function and classes down in the hierarchy have > nontrivial destructors? In other words make a compiler responsible for > proper destruction of a polymorphic object. > > Are there any serious pros against this? One thing that immediately comes to mind is the compiler would need to know about those derived classes and their destructors when compiling the base class. >This suggestion can look stupid > but just think how many type strokes and hours in searching of memory leaks > this could save. -Wnon-virtual-dtor or -Weffc++ could be of some help there. > > Kirill. >
Requesting maintainership for Cygwin and mingw-w64 ports
Hello, I'd like to apply for the position of Cygwin and mingw-w64 gcc port maintainer. What do I need to do to accomplish that? signature.asc Description: OpenPGP digital signature
Re: fstrict-enums and value ranges in VRP
On Thu, Jun 2, 2016 at 2:53 AM, Trevor Saunders wrote:
> On Thu, Jun 02, 2016 at 08:54:36AM +1000, kugan wrote:
>> Hi All,
>>
>> When I compile the following code with g++ using -fstrict-enums and -O2
>>
>> enum v
>> {
>> OK = 0,
>> NOK = 1,
>> };
>>
>> int foo0 (enum v a)
>> {
>> if (a > NOK)
>> return 0;
>> return 1;
>> }
>>
>> vrp1 dump looks like:
>> Value ranges after VRP:
>>
>> a.0_1: VARYING
>> _2: [0, 1]
>> a_3(D): VARYING
>>
>>
>> int foo0(v) (v a)
>> {
>> int a.0_1;
>> int _2;
>>
>> :
>> a.0_1 = (int) a_3(D);
>> if (a.0_1 > 1)
>> goto ;
>> else
>> goto ;
>>
>> :
>>
>> :
>> # _2 = PHI <0(2), 1(3)>
>> return _2;
>>
>> }
>>
>> Should we infer value ranges for the enum since this is -fstrict-enums and
>> optimize it?
>>
>> @item -fstrict-enums
>> @opindex fstrict-enums
>> Allow the compiler to optimize using the assumption that a value of
>> enumerated type can only be one of the values of the enumeration (as
>> defined in the C++ standard; basically, a value that can be
>> represented in the minimum number of bits needed to represent all the
>> enumerators). This assumption may not be valid if the program uses a
>> cast to convert an arbitrary integer value to the enumerated type.
>
> It seems like the "basically" part contradicts the first sentence?
It really depends on what the standard says exactly ;) VRP just uses
TYPE_MIN/MAX_VALUE and the FE is responsible for setting them.
But yes, we have -fno-strict-enums by default for a reason ;)
Richard.
Re: Requesting maintainership for Cygwin and mingw-w64 ports
On Jun 2 18:18, JonY wrote: > Hello, > > I'd like to apply for the position of Cygwin and mingw-w64 gcc port > maintainer. What do I need to do to accomplish that? This sounds like a good idea to me, given that Jon is Cygwin distro maintainer for the native as well as the mingw-w64 cross toolchains for quite some time. Corinna -- Corinna Vinschen Cygwin Maintainer Red Hat signature.asc Description: PGP signature
Re: A simple question about virtual destructors.
On 06/02/16 13:14, Marcin Baczyński wrote: 2016-06-02 11:55 GMT+02:00 K : Hi, My question is what if a compiler will generate a virtual destructor (or convert a nonvirtual to virtual) in a base class if the base class has at least one virtual function and classes down in the hierarchy have nontrivial destructors? In other words make a compiler responsible for proper destruction of a polymorphic object. Are there any serious pros against this? One thing that immediately comes to mind is the compiler would need to know about those derived classes and their destructors when compiling the base class. Yes, this looks like a problem, but then there is a much simple solution: if base class have a virtual function then it must have a virtual destructor and if a base class has a virtual destructor then every class in a hierarchy will have a pointer for destructor in vtbl. This suggestion can look stupid but just think how many type strokes and hours in searching of memory leaks this could save. -Wnon-virtual-dtor or -Weffc++ could be of some help there. Yes, I know -Wall also gave a proper warnings . I wanted to send this as a suggestion to @isocpp.org mailing list, but then decided to ask people who work on compiler for their opinions. This thing with a virtual destructors bothers people for decades and maybe it is time to make a compiler do proper destruction in this case. Kirill.
Mailing-List
A warning found during GCC 6.1.0 compilation process (may be a critical error or bug)
Hello GCC developers and GCC mailing list members: This message concerns some warnings noted by GCC during the compilation of GCC 6.1.0. If GCC had the -Werror flag passed, this would be an error. I'm not sure if this is an error, just a warning that I should ignore, or a bug, but I just wanted you to note the following warning: In file included from ../../gcc/rtl.h:34, from ../../gcc/genpreds.c:27: ../../gcc/vec.h: In static member function ‘static size_t vec::embedded_size(unsigned int) [with T = std::pair, A = va_heap]’: ../../gcc/vec.h:286: instantiated from ‘static void va_heap::reserve(vec*&, unsigned int, bool) [with T = std::pair]’ ../../gcc/vec.h:1406: instantiated from ‘bool vec::reserve(unsigned int, bool) [with T = std::pair]’ ../../gcc/vec.h:1515: instantiated from ‘T* vec::safe_push(const T&) [with T = std::pair]’ ../../gcc/genpreds.c:1524: instantiated from here ../../gcc/vec.h:1026: warning: invalid access to non-static data member ‘vec, va_heap, vl_embed>::m_vecdata’ of NULL object ../../gcc/vec.h:1026: warning: (perhaps the ‘offsetof’ macro was used incorrectly) There are many other warnings, and I will post a link to the compilation logs when the compilation finishes. (I've had to redo the compilation more than once because SSH decided to idle timeout and make noted the hangup, ending the compilation process immediately due to there being no TTY to send messages to, even though I'd had them (and still have them) redirected to a file.) -- Signed, Ethin D. Probst
Re: A warning found during GCC 6.1.0 compilation process (may be a critical error or bug)
On Thu, 2016-06-02 at 14:46 -0500, Ethin Probst wrote: [...snip...] > (I've had to redo the > compilation more than once because SSH decided to idle timeout and > make noted the hangup, ending the compilation process immediately due > to there being no TTY to send messages to, even though I'd had them > (and still have them) redirected to a file.) FWIW when I'm doing such things I use "screen" [1], which persists across multiple ssh logins. You may be also be able to fix this by running the build command from "nohup". Hope this is helpful Dave [1] https://www.gnu.org/software/screen/manual/screen.html [2] http://www.gnu.org/software/coreutils/manual/html_node/nohup-invoca tion.html#nohup-invocation
gcc-6-20160602 is now available
Snapshot gcc-6-20160602 is now available on ftp://gcc.gnu.org/pub/gcc/snapshots/6-20160602/ and on various mirrors, see http://gcc.gnu.org/mirrors.html for details. This snapshot has been generated from the GCC 6 SVN branch with the following options: svn://gcc.gnu.org/svn/gcc/branches/gcc-6-branch revision 237045 You'll find: gcc-6-20160602.tar.bz2 Complete GCC MD5=bb5fa65a6e7ab97c2c50d3f52b1fde23 SHA1=ba427cd8c3c0942e62d5aa85c0ee26b2ee34a2aa Diffs from 6-20160526 are available in the diffs/ subdirectory. When a particular snapshot is ready for public consumption the LATEST-6 link is updated and a message is sent to the gcc list. Please do not use a snapshot before it has been announced that way.
