https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
Paolo Carlini changed:
What|Removed |Added
CC|gcc-bugs at gcc dot gnu.org|
--- Comment #14 from Paolo Carli
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #13 from Jonathan Wakely 2010-10-31
12:42:00 UTC ---
(In reply to comment #12)
>
> I m sure this IS a bug , and I cant understand why this (documented) bug is
> still new 3 years later.
It's a bug, and should be fixed, but it's not
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #12 from William Waisse 2010-10-31 11:59:13
UTC ---
I m no more working for the company that was trying to port this code to
linux/GCC 3 YEARS AGO . They finally abandonned the idea to get their
professional application working on GC
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #11 from Jonathan Wakely 2010-10-31
11:31:01 UTC ---
(In reply to comment #10)
> Ok, I've read the bug report following a report from a friend, and after
> checking various sources I've come to the following conclusion:
>
> new pure(
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
Mark Karpeles changed:
What|Removed |Added
CC||mark at tibanne dot com
--- Comment #10 f
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #9 from Jonathan Wakely 2010-10-30
11:46:47 UTC ---
As an extra data point, this compiles with -std=c++0x
struct pure;
void f()
{
pure (*arr[3]);
pure** p = new (decltype(arr));
delete[] p;
}
This shows that allocating
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
Jonathan Wakely changed:
What|Removed |Added
Keywords||rejects-valid
Status|UNCONF
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #7 from Jonathan Wakely 2010-10-28
17:30:28 UTC ---
It doesn't depend on abstract types, this fails, even though it should be able
to declare an array of pure* without seeing the definition of pure:
struct pure;
void f()
{
pure*
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=32402
--- Comment #6 from Jonathan Wakely 2010-10-28
17:21:03 UTC ---
(N.B. this now gets the bogus warning from PR 46159)
Grammatically:
new (pure (*[3]));
is a new-expression, with type-id "pure(*[3])"
that type-id has type-specifier-seq "pure
--- 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 sup
--- Comment #4 from zackw at panix dot com 2007-11-12 19:41 ---
I am no C++ expert, so I don't know what
new pure (*[3])
actually means, but I am nearly certain it does *not* mean "allocate an array
of 3 pointers to type pure". That would be
new pure *[3]
without the parentheses
--- Comment #3 from gcc at waisse dot org 2007-11-12 15:42 ---
My problem is exactly the same as the one shown in the example code posted by
Patrick Vestjens, all of the pure functions are re-implemented in the
inherithing clas, so the inheriting class is no more pure but its still
impo
--- Comment #2 from gcc at waisse dot org 2007-11-12 15:06 ---
same kind of problem here, I'm currently porting an application from PGI/MFC to
gcc/QT and I'm not able to build this code with the error message :
/opt/cimlib/gcc_scali/AssembleurLocalPetsc.h:49: error: cannot allocate an
o
--- 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
14 matches
Mail list logo
