is it a bug?

is it a bug?

[Denisss]

Hello!

I don't know if it's a bug, but I send You a report.

I've got something like that in my code:
bool t = false;
if (t = true)
...

When I compile this with -Wall flag, compiler must show warning, but it doesn't!

g++ -Wall -o mytry mytry.cpp

When I change my code to something like that:
int t = 0;
if (t = 1)
...

GCC shows warning for the second line.

i586-mandriva-linux-gnu

../configure --prefix=/usr --libexecdir=/usr/lib --with-slibdir=/lib
--mandir=/usr/share/man --infodir=/usr/share/info
--enable-checking=release
--enable-languages=c,c++,ada,fortran,objc,obj-c++,java
--host=i586-mandriva-linux-gnu --with-cpu=generic --with-system-zlib
--enable-threads=posix --enable-shared --enable-long-long
--enable-__cxa_atexit__ --disable-lubunwind-exceptions
--enable-clocale=gnu --enable-java-awt=gtk
--with-java-home=/usr/lib/jvm/java-1.4.2-gcj-1.4.2.0/jre
--enable-gtk-cairo --enable-libjava-multilib --enable-ssp
--disable-libssp
 gcc ver. 4.2.2 20071128 (prerelease) (4.2.2-3.1mdv2008.0)

Thanks.

Re: IS IT A BUG ????

[Jim Wilson]

Srujan.K.V.S. wrote:
>      The following is the program to print magic squares.I`m getting 
> wierd output when i remove the printf statement "printf("a")" from the 
> code. 

Please see
   http://gcc.gnu.org/bugs.html
for info on how to submit bug reports.

You did not include enough info for us to do anything with this bug 
report.  We need to know the gcc version, the target (OS and CPU), the 
optimization options used, and possibly also other info.  Also, bugs 
should be submitted into bugzilla rather than mailed to the list.
-- 
Jim Wilson, GNU Tools Support, http://www.specifix.com

IS IT A BUG ????

[Srujan.K.V.S.]

Hi,

 	 The following is the program to print magic squares.I`m getting 
wierd output when i remove the printf statement "printf("a")" from the 
code. The required output is obtained by simply substituting that by 
putchar('\0'). I would be very glad if someone can let me know.
Please kindly help me regarding this.

Expecting an early rep,


Srujan.K.V.S


************************************************************************

//This is a simple program to design magic squares.
//A magic square is an arangment of numbers of numbers from 1 to n^2 such
// that any row, diagonal or column sums to the same. This program wil
  //work for only odd sized squares
#include<stdio.h>
#include<stdlib.h>
#include<math.h> 
main() {
         int n,x=1,i,j,k,p,r,t;
         scanf("%d",&n);
         printf("%d\n",n);
         p=n*n;
         int a[n][n];
         for(i=0;i<n;i++)
                 for(j=0;j<n;j++)
                         a[i][j]=0;
         i=0;j=(n-1)/2;
         a[i][j]=1;// starting  1 int the first row central column. :)
         //We try to put the next number in the top left diagonal square
 	//from the recent numbered square.
         //If we have already numbered , we then number the square just
 	//below it.
         for(k=1;k<p;k++)
         {
                 if((i-1)<0&&j!=0&&a[n-1][j-1]==0) i=n;
                 if((j-1)<0&&i!=0&&a[i-1][n-1]==0) j=n;
                 if(i==0&&j==0&&a[n-1][n-1]==0)
                 {
                         i=n;j=n;
                 }
                 x++;
                 if(a[i-1][j-1]==0)
                 {
                         //The following printf statement if removed is 
alering the output when n=5
                         printf("a");

                         a[i-1][j-1]=x;
                         i=i-1;
                         j=j-1;

                 }
                 else
                 {
                         if((i+1)>(n-1)) i=-1;
                         a[i+1][j]=x;
                         i=i+1;
                         j=j;
                 }
         }
         for(i=0;i<n;i++)
         {
                 for(j=0;j<n;j++)
                         printf("%4d \t",a[i][j]);
                 printf("\n");
         }
}
*****************************************************************************

Is it a bug?

[Lev Assinovsky]

Hi all!
I tried to build the following program in HP-UX 11.00 using gcc 3.2.3:
=============== cut here ====================
#include <string>
template<class CChar>
struct ACharTraits:
    public std::char_traits<CChar>
{
};

typedef char TCHAR;

std::basic_string<TCHAR, ACharTraits<TCHAR>, std::allocator<TCHAR> > s("aaaa");

int main()
{
    
}

================= cut here ==================

AND GOT:
-bash-2.05b$ g++ -o tstr tstr.cpp
/usr/ccs/bin/ld: Unsatisfied symbols:
   std::basic_string<char, ACharTraits<char>, std::allocator<char> >::_Rep::_S_terminal(first referenced in /var/tmp//cctBl474.o) (data)
   std::basic_string<char, ACharTraits<char>, std::allocator<char> >::_Rep::_S_max_size(first referenced in /var/tmp//cctBl474.o) (data)
collect2: ld returned 1 exit status

IS IT A BUG?

Sincerely, 

----
Lev Assinovsky
Aelita Software Corporation
O&S Core Division, Programmer
ICQ# 165072909

is it a bug?

[Arne Moe]

Hi,

I am having a problem with the code pasted below.

In the first loop, the line

v_old(i) = v(i)

causes the undesired effect:

ds(i-2) = v(i)

h, h_old, v, v_old and ds are properly declared, and the exchange from the
higher level routine is performed correctly. The code has been
successfully compiled on an other compiler (I'm afraid I don't know
which).

The entire program, including an input file (i.inp) and my makefile can be
found at www.stud.ntnu.no/~arnem/download/
The main program unit is called nis2.f

This error almost seems too stupid to be a compiler bug; can there be any
other explanation? (I have a fairly new Red Hat Linux distribution on a
166MHz, 98Mb ram pc; the hardware should be ok...). If it isn't a bug, I'm
sorry to trouble you!


Have a nice day!

yours sincerely
Arne Moe


*******************************************************************


      Subroutine p2a(h, h_old, v, v_old, w, ds,
     &     kappaxz, kappaxy, phi, ge)


      Implicit None
      Include 'parameter.f'
c     parameter.f contains parameter declarations, e.g. nmax.

      Logical too_fast
      Integer tail, front, i

      Real ds(nmax)
      Real h(nmax), h_old(nmax)
      Real v(nmax), v_old(nmax)

      Real vt(nmax), r(nmax)
      Real w(nmax), kappaxz(nmax), kappaxy(nmax), phi(nmax)
      Real dh_dt(nmax), dv_dt(nmax), dwhv_dx(nmax)
      Real F1(nmax), F2(nmax), F3(nmax), F4(nmax)
      Real G1(nmax), G2(nmax), G3(nmax), G4(nmax)
      Real wfunc, vterm, rho, b, m0, m1_d, m2, expn, dt
      Real time, ge(nmax)

      Common /c_too_fast/ too_fast
      Common /c_tailfront/ tail, front
      Common /c_material/ rho, b, m0, m1_d, m2, expn
      Common /c_dt/ dt,   /c_r/ r
      Common /c_vt/ vt
      Common /c_time/ time

      Intrinsic Amin1
      External dhdt, dvdt, vterm


      Do i = tail, front
         h_old(i) = h(i)
         v_old(i) = v(i)   	!also causes: ds(i-2) = v(i)
         print *,'p2a, line 77; i, ds(i), ds(10): ',i, ds(i), ds(10)
      EndDo

      Do i = tail, front
         print *,'p2a, line 81; i, ds(i): ', i, ds(i)
      EndDo
      Read *





arne moe
trettebakken 10, 0755 oslo
tlf.  99 44 37 88 (kostbare mobiltelefonen)
eller 22 02 31 68 (kontoret)
"folkeskikk er gratis"

Is it a bug?

[Magnus Benngard]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain, Size: 10633 bytes --]

Hi!

Version of g++ is:
Reading specs from /usr/local/lib/gcc-lib/i386-unknown-freebsdelf/2.95.1/specs
gcc version 2.95.1 19990816 (release)

System type is:
FreeBSD 3.2-STABLE

Options and error:
g++ -DHAVE_CONFIG_H -I. -I. -I.. -I../libkonq -I/usr/local/include
-I/usr/local/kde/include -I/usr/local/qt/include  -I/usr/X11R6/include    -O2
-c konq_childview.cc In file included from konq_childview.cc:23:
konq_propsview.h:141: syntax error before `(' konq_propsview.h:143: warning:
internal problem, current_class_type differs when adding
`KfmViewSettings::~KfmViewSettings()', please report

Best regards,

Magnus
>From knut@orion.no Thu Aug 26 05:42:00 1999
From: "Knut-HÃ¥vard Aksnes" <knut@orion.no>
To: gcc-bugs@gcc.gnu.org
Subject: Optimization bug in C++
Date: Thu, 26 Aug 1999 05:42:00 -0000
Message-id: <14277.14092.685032.141452@knut.orion.no>
X-SW-Source: 1999-08/msg00974.html
Content-length: 9577

A rewrite of the bug report previously posted as "serious brain damage
in C++ compiler"

The C++ compiler does some very dangerous and optimizations. This
breaks code conformant to the standard CORBA C++ bindings. 

The problem is the choice of cast operators, exemplified by these messages: 

SerialServant.cpp:19: warning: choosing `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *&()' over `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *const &() const'
SerialServant.cpp:19: warning:   for conversion from `NO::orion::markfeed::Feed_var' to `CORBA_Object *'
SerialServant.cpp:19: warning:   because conversion sequence for the argument is better

Explicit casts are used in the code to ensure usage of the right
conversion. The compiler seems to override these casts, this leads to
serious memory leaks in corba code.

Semantics of conversion operators in corba: 

X_var cast to  X *	 The returned object is owned by the caller.
X_var cast to const X *	 The returned object is owned by the X_var object.

Using cast to pointer where cast to pointer to const is intended
creates memory leaks,

The SerialServant.ii.bz2 file can be found at:
http://www.orion.no/SerialServant.ii.bz2

Output from compilation follows:

cd /home/knut/devroot/src/NordPool/Markfeed/
c++ -v --save-temps -DPACKAGE=\"markfeed\" -DVERSION=\"2.91\" -DHAVE_LIBRT=1 -DHAVE_LIBRESOLV=1 -DHAVE_STRSTREAM=1  -I. -I.    -DWITHOUT_NANA  -D_GNU_SOURCE -DACE_HAS_GNU_REPO -DACE_LACKS_PRAGMA_ONCE -D_POSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -D_REENTRANT -I/usr/local/ACE_wrappers/TAO/orbsvcs/orbsvcs -I/usr/local/ACE_wrappers/TAO -I/usr/local/ACE_wrappers   -frepo -pipe -g -O2 -c SerialServant.cpp

c++: Warning: -pipe ignored since -save-temps specified
Reading specs from /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/specs
gcc version 2.95.1 19990816 (release)
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/cpp -lang-c++ -v -I. -I. -I/usr/local/ACE_wrappers/TAO/orbsvcs/orbsvcs -I/usr/local/ACE_wrappers/TAO -I/usr/local/ACE_wrappers -D__GNUC__=2 -D__GNUG__=2 -D__GNUC_MINOR__=95 -D__cplusplus -D__ELF__ -Dunix -D__i386__ -Dlinux -D__ELF__ -D__unix__ -D__i386__ -D__linux__ -D__unix -D__linux -Asystem(posix) -D__EXCEPTIONS -D__OPTIMIZE__ -g -Acpu(i386) -Amachine(i386) -Di386 -D__i386 -D__i386__ -Di686 -Dpentiumpro -D__i686 -D__i686__ -D__pentiumpro -D__pentiumpro__ -DPACKAGE="markfeed" -DVERSION="2.91" -DHAVE_LIBRT=1 -DHAVE_LIBRESOLV=1 -DHAVE_STRSTREAM=1 -DWITHOUT_NANA -D_GNU_SOURCE -DACE_HAS_GNU_REPO -DACE_LACKS_PRAGMA_ONCE -D_POSIX_THREADS -D_POSIX_THREAD_SAFE_FUNCTIONS -D_REENTRANT SerialServant.cpp SerialServant.ii
GNU CPP version 2.95.1 19990816 (release) (i386 Linux/ELF)
#include "..." search starts here:
#include <...> search starts here:
 .
 /usr/local/ACE_wrappers/TAO/orbsvcs/orbsvcs
 /usr/local/ACE_wrappers/TAO
 /usr/local/ACE_wrappers
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/../../../../include/g++-3
 /usr/local/include
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/../../../../i686-pc-linux-gnu/include
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/include
 /usr/include
End of search list.
The following default directories have been omitted from the search path:
End of omitted list.
 /usr/local/lib/gcc-lib/i686-pc-linux-gnu/2.95.1/cc1plus SerialServant.ii -quiet -dumpbase SerialServant.cc -g -O2 -version -frepo -o SerialServant.s
GNU C++ version 2.95.1 19990816 (release) (i686-pc-linux-gnu) compiled by GNU C version 2.95.1 19990816 (release).
SerialServant.cpp: In method `void NO::orion::markfeed::SerialServant::remove()':
SerialServant.cpp:19: warning: choosing `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *&()' over `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *const &() const'
SerialServant.cpp:19: warning:   for conversion from `NO::orion::markfeed::Feed_var' to `CORBA_Object *'
SerialServant.cpp:19: warning:   because conversion sequence for the argument is better
SerialServant.cpp: In method `void NO::orion::markfeed::SerialServant::disconnect_push_supplier()':
SerialServant.cpp:36: warning: choosing `NO::orion::markfeed::PushConsumer_var::operator NO::orion::markfeed::PushConsumer *&()' over `NO::orion::markfeed::PushConsumer_var::operator NO::orion::markfeed::PushConsumer *const &() const'
SerialServant.cpp:36: warning:   for conversion from `NO::orion::markfeed::PushConsumer_var' to `CORBA_Object *'
SerialServant.cpp:36: warning:   because conversion sequence for the argument is better
SerialServant.cpp: In method `class NO::orion::markfeed::PushConsumer * NO::orion::markfeed::SerialServant::admin_interface()':
SerialServant.cpp:41: warning: choosing `NO::orion::markfeed::PushConsumer_var::operator NO::orion::markfeed::PushConsumer *&()' over `NO::orion::markfeed::PushConsumer_var::operator NO::orion::markfeed::PushConsumer *const &() const'
SerialServant.cpp:41: warning:   for conversion from `NO::orion::markfeed::PushConsumer_var' to `NO::orion::markfeed::PushConsumer *'
SerialServant.cpp:41: warning:   because conversion sequence for the argument is better
SerialServant.cpp: In method `class NO::orion::markfeed::Feed * NO::orion::markfeed::SerialServant::peer()':
SerialServant.cpp:90: warning: choosing `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *&()' over `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *const &() const'
SerialServant.cpp:90: warning:   for conversion from `NO::orion::markfeed::Feed_var' to `NO::orion::markfeed::Feed *'
SerialServant.cpp:90: warning:   because conversion sequence for the argument is better
SerialServant.cpp: In method `void NO::orion::markfeed::SerialServant::dump_config()':
SerialServant.cpp:186: warning: choosing `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *&()' over `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *const &() const'
SerialServant.cpp:186: warning:   for conversion from `NO::orion::markfeed::Feed_var' to `CORBA_Object *'
SerialServant.cpp:186: warning:   because conversion sequence for the argument is better
SerialServant.cpp: In method `void NO::orion::markfeed::SerialServant::notify(const char *)':
SerialServant.cpp:193: warning: choosing `NO::orion::markfeed::PushConsumer_var::operator NO::orion::markfeed::PushConsumer *&()' over `NO::orion::markfeed::PushConsumer_var::operator NO::orion::markfeed::PushConsumer *const &() const'
SerialServant.cpp:193: warning:   for conversion from `NO::orion::markfeed::PushConsumer_var' to `CORBA_Object *'
SerialServant.cpp:193: warning:   because conversion sequence for the argument is better
SerialServant.cpp:194: warning: choosing `NO::orion::markfeed::PushConsumer_var::operator NO::orion::markfeed::PushConsumer *&()' over `NO::orion::markfeed::PushConsumer_var::operator NO::orion::markfeed::PushConsumer *const &() const'
SerialServant.cpp:194: warning:   for conversion from `NO::orion::markfeed::PushConsumer_var' to `CORBA_Object *'
SerialServant.cpp:194: warning:   because conversion sequence for the argument is better
SerialServant.cpp: In method `void NO::orion::markfeed::SerialServant::stop()':
SerialServant.cpp:204: warning: choosing `PortableServer::_tao_seq_Octet_var::operator PortableServer::_tao_seq_Octet &()' over `PortableServer::_tao_seq_Octet_var::operator const PortableServer::_tao_seq_Octet &() const'
SerialServant.cpp:204: warning:   for conversion from `PortableServer::ObjectId_var' to `const PortableServer::ObjectId &'
SerialServant.cpp:204: warning:   because conversion sequence for the argument is better
SerialServant.cpp: In method `NO::orion::markfeed::SerialServant::SerialServant(const string &, const string &, unsigned int, NO::orion::markfeed::Feed *, bool, NO::orion::markfeed::RunState)':
SerialServant.cpp:297: warning: choosing `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *&()' over `NO::orion::markfeed::Feed_var::operator NO::orion::markfeed::Feed *const &() const'
SerialServant.cpp:297: warning:   for conversion from `NO::orion::markfeed::Feed_var' to `CORBA_Object *'
SerialServant.cpp:297: warning:   because conversion sequence for the argument is better
SerialServant.cpp:301: warning: choosing `PortableServer::_tao_seq_Octet_var::operator PortableServer::_tao_seq_Octet &()' over `PortableServer::_tao_seq_Octet_var::operator const PortableServer::_tao_seq_Octet &() const'
SerialServant.cpp:301: warning:   for conversion from `PortableServer::ObjectId_var' to `const PortableServer::ObjectId &'
SerialServant.cpp:301: warning:   because conversion sequence for the argument is better
SerialServant.cpp:324: warning: choosing `CORBA_String_var::operator char *()' over `CORBA_String_var::operator const char *() const'
SerialServant.cpp:324: warning:   for conversion from `CORBA::String_var' to `const char *'
SerialServant.cpp:324: warning:   because conversion sequence for the argument is better
SerialServant.cpp: In method `bool NO::orion::markfeed::SerialServant::Connected::process_line(const string &)':
SerialServant.cpp:977: warning: choosing `CORBA_String_var::operator char *()' over `CORBA_String_var::operator const char *() const'
SerialServant.cpp:977: warning:   for conversion from `CORBA::String_var' to `const char *'
SerialServant.cpp:977: warning:   because conversion sequence for the argument is better
 /usr/local/i686-pc-linux-gnu/bin/as -V -Qy -o SerialServant.o SerialServant.s
GNU assembler version 2.9.1 (i686-pc-linux-gnu), using BFD version 2.9.1.0.19

Compilation finished at Thu Aug 26 12:29:54

Re: is it a bug?

[Joe Buck]

> Both, egcs-19980418 and egcs-19980425, complain about the follwing code

> main(){
> 	double *p = new double[3](0);
> }

That's because it isn't C++.  g++ used to have an extension that allowed
the use of constructor arguments with arrays, but it hasn't been
maintained and the egcs team wants to encourage people to program in C++,
not a strange dialect called g++.  So you are likely to see the more
questionable GNU extensions eliminated.

If you need to do something like this (an array of values each of which
is initialized using constructor arguments), use vector<double> instead:

	vector<double> p(3,0.0);

(saying p(3,0) here will result in trouble -- yet another problem).

Re: is it a bug?

[JC Loredo-Osti]

> 
> > Both, egcs-19980418 and egcs-19980425, complain about the follwing code
> 
> > main(){
> > 	double *p = new double[3](0);
> > }
> 
> That's because it isn't C++.  g++ used to have an extension that allowed
> the use of constructor arguments with arrays, but it hasn't been
> maintained and the egcs team wants to encourage people to program in C++,
> not a strange dialect called g++.  So you are likely to see the more
> questionable GNU extensions eliminated.
> 
Yes, I have seen some of those. For this one I look into some books and I
didn't read nothing about it. 

Thanks a lot,
-j

is it a bug?

[JC Loredo-Osti]

Both, egcs-19980418 and egcs-19980425, complain about the follwing code



main(){
	double *p = new double[3](0);
}



However it does compile with egcs-1.0.2 and gcc-2.8.x
(With gcc-2.7.2 it gets a internal compiler error which is supresed by
replacing '(0)' with '(0.0)')

Is it a bug or new feature?

-j

josti@mscs.dal.ca

Re: Is it a bug ?

[Alexandre Oliva]

knizhnik  writes:

> It looks like bug in compiler (if class A has no constructor then
> no error message is produced)

That's because the implicit constructor defined for A won't ever
throw, that is, it is declared as:

A::A() throw() {}

So no exception handling code is inserted there.  Declaring the
constructor of A as such should help, but I believe access control
should not be performed at that point.  The Nov'97 is not clear about
that.

-- 
Alexandre Oliva
mailto:oliva@dcc.unicamp.br mailto:aoliva@acm.org
http://www.dcc.unicamp.br/~oliva
Universidade Estadual de Campinas, SP, Brasil

Is it a bug ?

[knizhnik]

Few days ago I have downloaded egcs and was glad to
see that some bugs which were present in GCC 2.7.2
were fixed in EGCS. But I am failed to compile my program (which was compiled with GCC 2.7.2) 
because of following problem with protected "operator delete":

----------------------------------------------- 
#include <stdlib.h>

class A { 
  protected:
    int a;
    void operator delete(void* p) { ::delete p; }
  public:
    void foo() {}
    void* operator new(size_t size) { return malloc(size); }
    A() {} // no error if comment this line
};

class B : public A { 
};

main() { 
    B* bp = new B;
    bp->foo();
}
------------------------------------------------------
bash$ gcc -Wall -v new.cxx
Reading specs from /usr/local/lib/gcc-lib/alphaev5-dec-osf4.0/egcs-2.90.21/specs
gcc version egcs-2.90.21 971202 (egcs-1.00 release)
 /usr/local/lib/gcc-lib/alphaev5-dec-osf4.0/egcs-2.90.21/cpp -lang-c++ -v -undef
 -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__GNUC_MINOR__=90 -Dunix -D__osf__ -D
__alpha -D__alpha__ -D_LONGLONG -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__ -D__osf_
_ -D__alpha -D__alpha__ -D_LONGLONG -D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix -D
__SYSTYPE_BSD -Asystem(unix) -Asystem(xpg4) -Acpu(alpha) -Amachine(alpha) -D__EX
CEPTIONS -Wall -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C -D__LANGUAGE_C_PLUS_
PLUS__ -D__LANGUAGE_C_PLUS_PLUS -D__cplusplus new.cxx /tmp/ccaajfaa.ii
GNU CPP version egcs-2.90.21 971202 (egcs-1.00 release)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include/g++
 /usr/local/include
 /usr/local/alphaev5-dec-osf4.0/include
 /usr/local/lib/gcc-lib/alphaev5-dec-osf4.0/egcs-2.90.21/include
 /usr/include
End of search list.
 /usr/local/lib/gcc-lib/alphaev5-dec-osf4.0/egcs-2.90.21/cc1plus /tmp/ccaajfaa.i
i -quiet -dumpbase new.cc -Wall -version -o /tmp/ccaajfaa.s
GNU C++ version egcs-2.90.21 971202 (egcs-1.00 release) (alphaev5-dec-osf4.0) co
mpiled by GNU C version egcs-2.90.21 971202 (egcs-1.00 release).
new.cxx: In function `int main()':
new.cxx:6: `static void A::operator delete(void *)' is protected
new.cxx:17: within this context
--------------------------------------------------------------------------------
It looks like bug in compiler (if class A has no constructor then
no error message is produced). I declare protected "operator delete"
to prohibit explicite deallocation of objects of this class. 
I am is not familiar with last ideas of C++ standard, may be if
you are using "operator new" then "operator delete" is also 
required (to be called if exception was raised within "new"), 
but in any case how is it possible to prevent user from explicit class
deallocation ?