This is the mail archive of the
gcc-bugs@gcc.gnu.org
mailing list for the GCC project.
[Bug c++/17150] Ugly diagnostics for invalid variably modified type
- From: "gdr at gcc dot gnu dot org" <gcc-bugzilla at gcc dot gnu dot org>
- To: gcc-bugs at gcc dot gnu dot org
- Date: 29 Aug 2004 15:31:12 -0000
- Subject: [Bug c++/17150] Ugly diagnostics for invalid variably modified type
- References: <20040823130059.17150.falk@debian.org>
- Reply-to: gcc-bugzilla at gcc dot gnu dot org
------- Additional Comments From gdr at gcc dot gnu dot org 2004-08-29 15:31 -------
(In reply to comment #0)
> This test case posted for PR 17148:
>
> struct A {};
> struct B : A
> {
> static int foo() { return 1; }
> int i[B::foo()];
> };
>
> produces the ugly diagnostic:
>
> test.cc:6: error: data member may not have variably modified type `int [(((long
> unsigned int)(((long int)B::foo()) - 1)) + 1u)]'
This stupid pretty printing comes from the way GCC currently handles arrays.
When you declare an array
T i[N];
GCC represents the index values as a range type 0...(N-1), hence the curious
-1. Latter, when pretty printing, we try to recover that off-one thingy, hence
the curious +1. The unsignedness come from one more GCC artefact.
Notice that fold() is unable to smash that nonsense down to the trivial thing.
A way out of this mess is to stop fiddling with what user writes and define
normal forms for expressions, with some ordering.
-- Gaby
>
> with g++ 3.5.0 20040815 on alphaev68-unknown-linux-gnu.
--
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=17150