GCC bug?

GCC bug?

[Tom Uban]

One of the people here has discovered what we believe to be a bug with gcc.
The version I am currently running is:

	gcc version egcs-2.90.27 980315 (egcs-1.0.2 release)
	Cygnus b19.1
	Windows95

I plan to update to the latest version pretty soon, but I wanted to make
sure that no major problems cropped up in the gnu-win32 mail group before
I took the time to switch.

The bug is outlined in the code that follows.

Can someone test this on the latest release and let me know if it is still
broken?

--tnx
--tom

------------------------------------------------------------------------------
class test
{
  public:
    test(int a);
    test(int a, char b);

    int mA;
    char mB;

private:             // making this public "fixes" the problem
    test(const test &hack_to_copy);
};

test::test(int a)
{
    mA=a;
}

test::test(int a, char b)
{
    mA=a;
    mB=b;
}


test t1(2);          // this is ok
test t2(2, 'a');     // this is ok
test testarray[]=    
{
    test(3),         // Anything in the array using this type of constructor
    test(4, 'b'),    // generates an error when the copy constructor is
    test(5),         // private.  It works just fine if the copy constructor
    test(6, 'c')     // is not defined or is public.
};

// Apparently, gcc believes it must make a temporary object and then copy
// it into the array.  Other compilers, specifically CAD-UL and Borland
// 4.5 do not reject this array initialization, and by all indications the 
// code is not generating temporary objects under these compilers.  

// In books such as "C++ for Professional Programmers" (by Stephen Blaha,
// Thomson Computer Press) on pg. 121 and "The C++ Programming Language 2nd
// Edition" (by Bjarne Stroustrup, Addison Wesley) on pg. 579, it is
// implied that each object of the array is constructed directly, and that no
// intervening object requiring a public copy constructor is required.  It is
// on that basis, and the fact that the above compilers do not complain about
// the code either, that I believe this to be a bug in gcc.


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: GCC bug?

[Theodore Jump]

>...blah blah blah...
> class declaration with private copy constructor
>...
> array initialization
>...

>Can someone test this on the latest release and let me know if it is still
>broken?

With EGCS 1.1 on Cygwin B19.1/CoolView DLL g++ chokes on it.

For reference, Microsoft Visual C++ 5 SP3 chokes also.

Intel C++ 3.0 does *not*.

I wonder what the 'spec' says, precisely, about this?
______________________________________________________________________
http://www.i21.com/~tjump                  http://www.fighterduel.com
----------------------------------------------------------------------
Congrats to Marco Pantani, Jan Ullrich, Bobby Julich, Erik Zabel,
Christophe Rinero and all the rest of the riders of Le Tour '98!
-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: GCC bug?

[Mumit Khan]

Tom Uban <uban@mail.netnitco.net> writes:
> 
> One of the people here has discovered what we believe to be a bug with gcc.

[ ... ]

> The bug is outlined in the code that follows.
> 
> Can someone test this on the latest release and let me know if it is still
> broken?
> 

Tom, 

After looking at section 12.6.2 of the draft working paper (I don't have
standard yet), I now agree that it is a bug. I've submitted a condensed
version to egcs-bugs. Let's see what egcs folks say.

Regards,
Mumit

-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: GCC bug?

[Mumit Khan]

tjump@cais.com (Theodore Jump) writes:
> 
> With EGCS 1.1 on Cygwin B19.1/CoolView DLL g++ chokes on it.
> 
> For reference, Microsoft Visual C++ 5 SP3 chokes also.
> 
> Intel C++ 3.0 does *not*.
> 
> I wonder what the 'spec' says, precisely, about this?

I thought it was a bug too, but I was mistaken.

Here's what Jason Merrill says quoting chapter and verse:

 -- using template mhl.format --
Date:    22 Oct 1998 03:30:07 PDT
To:      khan@cygnus.com (Mumit Khan), egcs-bugs@cygnus.com

From:    Jason Merrill <jason@cygnus.com>
Subject: Re: egcs-1.1: C++ aggregate initialization bug?

>>>>> Mumit Khan <khan@xraylith.wisc.edu> writes:

 >  I believe that egcs is incorrect in trying to use a copy constructor in
 >  the aggregate initialization below. According to Dec'96 DWP Sec 12.6.2.2 
 >  "Explicit Initialization", the initialization should only call test(int), 
 >  and not nomplain about non-public copy constructor. 

Nope.

  8.5 - Initializers [dcl.init]

  -12- The initialization that occurs in argument passing, function return,
  throwing an exception (except.throw), handling an exception
  (except.handle), and brace-enclosed initializer lists (dcl.init.aggr) is
  called copy-initialization and is equivalent to the form

       T x = a;

Jason


-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: GCC bug?

[Stephen Vance]

Mumit Khan wrote:

> Tom,
>
> After looking at section 12.6.2 of the draft working paper (I don't have
> standard yet), I now agree that it is a bug. I've submitted a condensed
> version to egcs-bugs. Let's see what egcs folks say.
>
> Regards,
> Mumit

Mumit, and any others who are interested --

    The final standard is now available in PDF form by electronic download for
US$18 from

http://webstore.ansi.org/ansidocstore/default.asp

Quite affordable, IMO.

--
Stephen Vance                           |  http://www.deneb.com
Deneb Robotics, Inc.                    |  mailto:vance@deneb.com
5500 New King Street                    |  Phone: (248) 267-9696
Troy, MI 48098-2615                     |  Fax:   (248) 267-8585

What is done well is done quickly enough. -Augustus Caesar



-
For help on using this list (especially unsubscribing), send a message to
"gnu-win32-request@cygnus.com" with one line of text: "help".

Re: gcc bug?

[Christopher Faylor]

On Mon, Apr 02, 2001 at 03:22:04PM -0400, Tom Weichmann wrote:
>I was just compiling the latest Octave (2.1.33) with the latest 
>version of Cygwin, and got an error.  I then tried 2.1.31 which 
>has compiled without problem in the past, and received the same 
>error:
>
>c++  -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -
>HAVE_CONFIG_H -mieee-fp -fno-rtti -fno-exceptions -fno-implicit-
>templates -g -O
> -Wall -rdynamic \
>-L..   -fPIC  -o octave \
>octave.o builtins.o ops.o ../libcruft/blas-xtra/xerbla.o  balance.o  besselj.o
>betainc.o  chol.o  colloc.o  dassl.o  det.o  eig.o  expm.o  fft.o  fft2.o  filt
>r.o  find.o  fsolve.o  gammainc.o  getgrent.o  getpwent.o  getrusage.o  
>givens.
>  hess.o  ifft.o  ifft2.o  inv.o  log.o  lpsolve.o  lsode.o  lu.o  minmax.o  pi
>v.o  qr.o  quad.o  qz.o  rand.o  schur.o  sort.o  svd.o  syl.o  time.o \
>-L../liboctave -L../libcruft -L../src  \
>../src/liboctinterp.a ../liboctave/liboctave.a  ../libcruft/libcruft.a  ../read
>ine/libreadline.a ../kpathsea/libkpathsea.a ../glob/glob.o ../glob/fnmatch.o 
> \
> -lncurses  -lz -lm  -lg2c -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-1 -L/usr/li
>/mingw -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32
>c++: unrecognized option `-rdynamic'
>make[2]: Leaving directory `/usr/local/src/octave-2.1.33/src'
>make[1]: Leaving directory `/usr/local/src/octave-2.1.33'
>
>It seems as if gcc or more specificaly c++ is broke!  Anyone have 
>an idea?

Eliminate the -rdynamic option.  I don't see that this has ever been supported
by Cygwin gcc but I haven't specifically tested an older version.

If -rdynamic actually was accepted (I doubt that it did anything) in
older versions of gcc it was not removed by any patch that I applied to
gcc so undoubtedly this was done by the gcc 2.95.3 developers.

cgf

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple

gcc bug?

[Tom Weichmann]

Hello,

I was just compiling the latest Octave (2.1.33) with the latest 
version of Cygwin, and got an error.  I then tried 2.1.31 which 
has compiled without problem in the past, and received the same 
error:

c++  -I. -I.. -I../liboctave -I../src -I../libcruft/misc  -I../glob -I../glob -
HAVE_CONFIG_H -mieee-fp -fno-rtti -fno-exceptions -fno-implicit-
templates -g -O
 -Wall -rdynamic \
-L..   -fPIC  -o octave \
octave.o builtins.o ops.o ../libcruft/blas-xtra/xerbla.o  balance.o  besselj.o
betainc.o  chol.o  colloc.o  dassl.o  det.o  eig.o  expm.o  fft.o  fft2.o  filt
r.o  find.o  fsolve.o  gammainc.o  getgrent.o  getpwent.o  getrusage.o  
givens.
  hess.o  ifft.o  ifft2.o  inv.o  log.o  lpsolve.o  lsode.o  lu.o  minmax.o  pi
v.o  qr.o  quad.o  qz.o  rand.o  schur.o  sort.o  svd.o  syl.o  time.o \
-L../liboctave -L../libcruft -L../src  \
../src/liboctinterp.a ../liboctave/liboctave.a  ../libcruft/libcruft.a  ../read
ine/libreadline.a ../kpathsea/libkpathsea.a ../glob/glob.o ../glob/fnmatch.o 
 \
 -lncurses  -lz -lm  -lg2c -L/usr/lib/gcc-lib/i686-pc-cygwin/2.95.3-1 -L/usr/li
/mingw -lcygwin -luser32 -lkernel32 -ladvapi32 -lshell32
c++: unrecognized option `-rdynamic'
make[2]: Leaving directory `/usr/local/src/octave-2.1.33/src'
make[1]: Leaving directory `/usr/local/src/octave-2.1.33'

It seems as if gcc or more specificaly c++ is broke!  Anyone have 
an idea?

Thank You For Your Time,
Tom Weichmann

--
Want to unsubscribe from this list?
Check out: http://cygwin.com/ml/#unsubscribe-simple