[Bug c++/32402] New: Error while allocating array of pointers to objects of a pure virtual class

[p dot vestjens at gmail dot com]

The compiler thinks we're allocating the actual abstract objects instead of an
array of pointers and reports the following error: "cannot allocate an object
of abstract type '...'". Since we're actual allocating an array of pointers,
this should not be an error.

The following code (reproduce.cpp) demonstrates the problem:

class pure
{
public:
  pure() {}
  virtual bool isPure () = 0;
};

class notPure : public pure
{
public:
  notPure() {}
  virtual bool isPure () { return false; };
};

int main ()
{
  pure ** list;
  list = new (pure (*[3]));
  for (int i = 0; i  < 3; i ++) {
list [i] = new notPure();
  }
}

The error is reported on line 18 "list = new (pure (*[3]));".

gcc -v results in:
Using built-in specs.
Target: i686-linux
Configured with: ../gcc-4.1.1/configure
--prefix=/p/TargetPlatforms/x86-Linux-cdk/cross-gcc/build/tools
--target=i686-linux --build=i686-pc-mingw32 --host=i686-pc-mingw32
--disable-multilib
--with-local-prefix=/p/TargetPlatforms/x86-Linux-cdk/cross-gcc/build/tools
--with-system-zlib --disable-libunwind-exceptions --disable-nls --enable-shared
--enable-languages=c,c++ --enable-__cxa_atexit --enable-c99 --enable-long-long
--enable-threads=posix --enable-win32-registry=oce-gcc4.1.1-glibc2.5
Thread model: posix
gcc version 4.1.1

We're cross compiling from Windows to Linux.
The command line is very basic: "gcc reproduce.cpp"
This results in the following compiler output:

reproduce.cpp: In function 'int main()':
reproduce.cpp:18: error: cannot allocate an object of abstract type 'pure'
reproduce.cpp:2: note:   because the following virtual functions are pure
within 'pure':
reproduce.cpp:5: note:  virtual bool pure::isPure()

The preprocessed file looks as follows:

# 1 "reproduce.cpp"
# 1 ""
# 1 ""
# 1 "reproduce.cpp"
class pure
{
public:
  pure() {}
  virtual bool isPure () = 0;
};

class notPure : public pure
{
public:
  notPure() {}
  virtual bool isPure () { return false; };
};

int main ()
{
  pure ** list;
  list = new (pure (*[3]));
  for (int i = 0; i < 3; i ++) {
list [i] = new notPure();
  }
}


-- 
   Summary: Error while allocating array of pointers to objects of a
pure virtual class
   Product: gcc
   Version: 4.1.1
Status: UNCONFIRMED
  Severity: normal
      Priority: P3
 Component: c++
AssignedTo: unassigned at gcc dot gnu dot org
ReportedBy: p dot vestjens at gmail dot com


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

[p dot vestjens at gmail dot com]

--- Comment #1 from p dot vestjens at gmail dot com  2007-06-19 14:47 
---
Created an attachment (id=13736)
 --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13736&action=view)
Sourcefile demonstrating the problem


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402

[Bug c++/32402] Error while allocating array of pointers to objects of a pure virtual class

[p dot vestjens at gmail dot com]

--- Comment #5 from p dot vestjens at gmail dot com  2007-11-13 13:38 
---
Okay. First of all the code causing the problems isn't actually my own code. It
is used in the Connexis middleware layer of IBM's Rational Rose Real-Time
application. The reproduce.cpp file was created by IBM's support department to
reproduce the problem. They claim that the file compiles with the GNU 3.2
compiler but not with the GNU 3.4.4 and 4.1.0 compilers. I'm using GNU 4.1.1
which also doesn't compile the code, but WindRiver's Tornado 2 GNU 2.7.2 and
the MS Visual Studio 6 compiler do.

The problem seems to lie in the abundant use of parentheses:
- "list = new (pure(*[3]));" => does not compile
- "list = new (pure*[3]);" => compiles
- "list = new pure(*[3]);" => does not compile
- "list = new pure*[3];" => compiles

So, the only question still relevant to me is whether the original construction
is valid C++ code according to the ISO C++ standard. I tried verifying this
using the grammar printed in Stroustrup's "C++ Programming language (third
edition" but did not quite succeed. I guess grammatically it is ok, but
semantically the GCC compiler interprets the construction differently from its
previous version(s).

How do we determine if the original construction is correct, both grammatically
and semantically? If it isn't valid, IBM should fix their code. If it is, there
might be a bug in GCC.


-- 


http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402