From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14778 invoked by alias); 27 Jul 2004 07:07:30 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 14755 invoked by alias); 27 Jul 2004 07:07:29 -0000 Date: Tue, 27 Jul 2004 07:07:00 -0000 Message-ID: <20040727070729.14754.qmail@sourceware.org> From: "romixlev at yahoo dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20040726080349.16711.romixlev@yahoo.com> References: <20040726080349.16711.romixlev@yahoo.com> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c++/16711] [3.4/3.5 regression] Bug in reporting integral constant expressions problems X-Bugzilla-Reason: CC X-SW-Source: 2004-07/txt/msg03226.txt.bz2 List-Id: ------- Additional Comments From romixlev at yahoo dot com 2004-07-27 07:07 ------- Subject: Re: [3.4/3.5 regression] Bug in reporting integral constant expressions problems Actually, my bug report comes from the following area. I'm using PROP, a sort of C++ preprocessor, that was developed may be 10 years ago, which translates a superset of C++ into "normal" C++. Among other things it supports algebraic data types and garbage collection for C++. For a given algebraic data type there can be several diffeent constructors (in the sense of algebraic datatypes, not in C++ sense) with and without arguments. The constructors with arguments are dynamically creating the objects on the heap. The unit constructors (i.e. those without arguments) do not create objects. Instead they are represented by some special values like (AlgebraicDataType *)small_integer. In principle, they are like enumerations. But these values should be assignable to a pointer to the AlgebraicDataType, they are always defined like: #define UniConstructorName (AlgebraicDataType * ) small_integer Later this macro is used everywhere in the code generated by PROP. The funny thing about this is that I'm using it since 6-7 years and have never had problems with it undar any compiler. So, when I switched to GCC 3.4.1 I was very surprised to see, that suddenly the automatically generated code was illigal... But now, after some clarifications, I see that the standard really does not allow such conversions into non-integral types insdie an integral constant expression. So, I simply changed PROP to generate a a code that it standard compliant. Now it works fine. BTW, there was a small problem while changing PROP. Since PROP uses bootstraping (i.e. written in itself), its code was generated with the old version of it and of course was using these illegal constructs. I had to change them by hand (!!!) in several hundred places, before I could compile a new version of PROP. After that I regenerated it with the new version and now it does not use illegal constructs. An G++ option that would explicitly allow old behavior (at least for some time, before making this constructs totally obsolette) would help in such situations. But I guess, I ask too much, or? :) --- jsm at polyomino dot org dot uk wrote: > > ------- Additional Comments From jsm at polyomino > dot org dot uk 2004-07-26 20:30 ------- > Subject: Re: New: Bug in reporting integral > constant expressions > problems > > On Mon, 26 Jul 2004, romixlev at yahoo dot com > wrote: > > > G++ 3.4.1 rejects some integral constant > expressions that were allowed in the > > earlier versions. The same file compiled with GCC > as a C file does not produce > > any errors. This report seems to be related to > Bugzilla Bug 16489. > > Both the C and C++ standards are clear that casts to > non-integer types > aren't allowed in integral constant expressions > (C90, C++) / integer > constant expressions (C99). Thus the bug is the > nondiagnosis of: > > > // Size of array should be an integral constant > expression, or? > > // But G++ does not complain about this expression > > */ > > int array [((int)(void*)1)]; > > The constant expressions bugs for C are bugs 456 and > 5675. Addressing > them is on my C standards conformance roadmap > , but > after dealing with other > miscellaneous obscure bugs such as 13801, and it is > a fair amount of work > to implement properly an obscure area of the > standard with little > relevance to real code. Given the obscurity of the > area (and that there > is hardly a great deal of user interest in the finer > points of > conformance), I'm surprised that this came up as a > bug report, and still > more so that real code is actually using such things > that are/were > undocumented extensions to constant expressions. > (The intention will > still be that such undocumented extensions are > liable to be removed > without notice, as those in C++ have been with the > implementation of the > new parser, but it's interesting that such removal > has had *any* impact on > user code.) > > > > -- > > > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16711 > > ------- You are receiving this mail because: ------- > You reported the bug, or are watching the reporter. > __________________________________ Do you Yahoo!? Yahoo! Mail - You care about security. So do we. http://promotions.yahoo.com/new_mail -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=16711