SGI--memory: auto_ptr::operator= bug

SGI--memory: auto_ptr::operator= bug

[j.sampaio]

I found (in fact, it was the -Wall) a bug on both operator=
methods of auto_ptr: they don't return a reference to them selfs
as they say (for a=a=a). It's not very dificult: just add
"return *this;" in the end of the functions.

Joao

PS: my egcs is 2.91.66 (1.1.2 if i'm not wrong)
>From calkinsc@www.protospace.com Mon Jul 12 17:45:00 1999
From: Charles Calkins <calkinsc@www.protospace.com>
To: egcs-bugs@egcs.cygnus.com
Subject: EGCS 1.1.2 compiler error
Date: Mon, 12 Jul 1999 17:45:00 -0000
Message-id: <Pine.SGI.3.93.990712193539.11A-101000@www.protospace.com>
X-SW-Source: 1999-07/msg00463.html
Content-length: 1229

	Greetings

	This past weekend I was working on a project and came across the
following message:

timer.cc: In method `char Timer<TimerTest>::Start<TimerTest>(int, void (TimerTest::*)())':
timer.cc:57:   instantiated from here
timer.cc:41: Internal compiler error 40.
timer.cc:41: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
timer.cc:41: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

	I have checked the list of known bugs and it does not appear to fit
any of the cases, so attached is a gzip-compressed, tar archive of the
original source (timer.cc), the .ii file as per requested on that web page,
and the screen output of g++ -v --save-temps (info.txt).  I am running Linux
2.2.10-ac9, gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release), and
the system originally RedHat 5.2, modified, and upgraded to RedHat 6.0.  The
command line that generated the above was:

	g++ -o timer timer.cc -lpthreads

	(no optimization level was selected).  If I can provide any further
infomation, please let me know.  Thanks.

							Charles

--
Charles Calkins				calkinsc@protospace.com
Senior Software Developer 		http://www.protospace.com/~calkinsc
ProtoSpace Corporation			St. Louis, MO
>From jason@cygnus.com Mon Jul 12 18:12:00 1999
From: Jason Merrill <jason@cygnus.com>
To: "Kaveh R. Ghazi" <ghazi@caip.rutgers.edu>
Cc: egcs-bugs@egcs.cygnus.com, law@cygnus.com
Subject: Re: gcc-2.95, new libstdc++ testsuite failures due to libiberty change
Date: Mon, 12 Jul 1999 18:12:00 -0000
Message-id: <u9908lwdxj.fsf@yorick.cygnus.com>
References: <199907122136.RAA25676@caip.rutgers.edu>
X-SW-Source: 1999-07/msg00464.html
Content-length: 344

>>>>> Kaveh R Ghazi <ghazi@caip.rutgers.edu> writes:

 > BTW, your tweak on both branches not only fixes the logic, but it also
 > adds mkstemps (which is LGPL'ed) to the NEEDED list.  Doesn't this
 > break the purpose of the original change, which was to clean out the
 > LGPL stuff?

D'oh!  That was just there for testing.  Will fix.

Jason
>From N8TM@aol.com Mon Jul 12 18:54:00 1999
From: N8TM@aol.com
To: emil@cls.usask.ca, egcs-bugs@egcs.cygnus.com
Subject: Re: paranoia results (C and Fortran)
Date: Mon, 12 Jul 1999 18:54:00 -0000
Message-id: <c7d3689f.24bbf619@aol.com>
X-SW-Source: 1999-07/msg00465.html
Content-length: 1421

In a message dated 7/12/99 4:06:28 PM PST, emil@cls.usask.ca writes:

> DEFECT:  Calculated 7.38905609548934539e+00 for
>  	(1 + (-1.11022302462515654e-16) ^ (-1.80143985094819840e+16);
>  	differs from correct value by -3.44130679508225512e-09 .
>  	This much error may spoil financial
>  	calculations involving tiny interest rates.
 This would mean that you're using an unsatisfactory implementation of pow(). 
 That's not directly under the control of egcs.  I've worked out a powl() for 
686 which passes all the usual tests, but I haven't detected any interest in 
that.  Definitely getting off-topic.


>>* is neither chopped nor correctly rounded.
/ is neither chopped nor correctly rounded.
Addition/Subtraction neither rounds nor chops.
Sticky bit used incorrectly or not at all.
FLAW:  lack(s) of guard digits or failure(s) to correctly round or chop
(noted above) count as one flaw in the final tally below.

This simply means that you're invoking double rounding by running an x86 in 
default mode, which rounds to 64 bits mantissa, and following up by rounding 
to 53 bits.  It's not the fault of egcs that this is a useful mode for 
running this processor family.  Set it to 53-bit rounding mode if you don't 
like it, as certain other compilers do.  When you run in single (float) 
precision, you don't see this problem, as the 64-bit mantissa arithmetic 
doesn't drop any bits.

Tim
tprince@computer.org
>From bauhaus@uni-duisburg.de Mon Jul 12 19:06:00 1999
From: bauhaus@uni-duisburg.de (Georg Bauhaus)
To: egcs-bugs@egcs.cygnus.com
Subject: internal compiler error 109
Date: Mon, 12 Jul 1999 19:06:00 -0000
Message-id: <199907122308.BAA18729@sonnenregen.uni-duisburg.de>
X-SW-Source: 1999-07/msg00466.html
Content-length: 1068

//  dear "egcs-bugs",

//  #include <string> "results" in an internal compiler error 109
//  (only saying that this doesn't happen if #include <string> is
//  omitted; this is funny somehow; i filed a report having the opposite
//  premis resulting in the same error only few days ago. the code *is*
//  erroneous, i think. :)

#include <string>

class S {

  static const string spec_rev_ = "";
  // static const string spec_rev_ = string("");  // error
  // static const char spec_rev_[] = "";  // no error, no warning
  // static const char * spec_rev_ = "";  // warning

};

/*
c++ -c  -x c++ -Wall Templates.hh
Templates.hh:11: Internal compiler error 109.
Templates.hh:11: Please submit a full bug report to `egcs-bugs@egcs.cygnus.com'.
Templates.hh:11: See <URL: http://egcs.cygnus.com/faq.html#bugreport > for details.

Linux sonnenregen 2.2.1 #3 SMP Fri Apr 23 06:04:04 CEST 1999 i586 unknown
Debian GNU/Linux
c++ -v
Reading specs from /usr/lib/gcc-lib/i486-linux/egcs-2.91.66/specs
gcc version egcs-2.91.66 Debian GNU/Linux (egcs-1.1.2 release)

-# georg
*/
>From loening@ucla.edu Mon Jul 12 19:57:00 1999
From: Andy Loening <loening@ucla.edu>
To: egcs-bugs@egcs.cygnus.com
Subject: core dump using pow and structures with egcs
Date: Mon, 12 Jul 1999 19:57:00 -0000
Message-id: <Pine.GSO.4.05.9907121915210.457-100000@ganesh.crump.ucla.edu>
X-SW-Source: 1999-07/msg00467.html
Content-length: 2292

Hello People,

I might have a bug for you guys to chew on here.  From what I can tell,
this is the simplest case I could come up with.  I did need three elements
in the structure and two pows to produce this bug.


test.c
------------------------------------------------------------------
#include <math.h> 

typedef struct {
  double x;
  double y;
  double z; 
} RealPoint; 

int main (void) {
  
  RealPoint p1 = {25.0, 25.0, 25.0};
  double a;

  a = (pow(3,2)+pow(4,2));

  return; 
}
---------------------------------------------------------------


When I compile and run this, I get a core dump.  I'm compiling with:
"egcs -lm -Ox -o test test.c"
where x is 2 or 3.

This is a redhat 6.0 gnu/linux box and "egcs -v" gives me
gcc version egcs-2.91.66 19990314/Linux (egcs-1.1.2 release)           

I also get the same thing on a mandrake 5.3 gnu/linux box where
"egcs -v" gives me: gcc version egcs-2.90.29 980515 (egcs-1.0.3 release) 
In this case, any optimization level will cause the crash.  Note that gcc
version 2.7.2.3 on this box does not give this behaviour.

So, I compiled with -ggdb (this is back on the redhat 6.0 based system,
egcs version 1.1.2) did a bt in gdb, and this is what I get:

------------------------------------------------------------------
Core was generated by `./test'. Program terminated with signal 11,
Segmentation fault. Reading symbols from
/opt/rsi/idl_5.2/bin/bin.linux/__setfpucw.so...done. 
Reading symbols from /lib/libm.so.6...done. 
Reading symbols from /lib/libc.so.6...done. 
Reading symbols from /lib/ld-linux.so.2...done. 
#0 0x8048515 in main () at /usr/include/bits/mathinline.h:376 376
__inline_mathcode2 (pow, __x, __y, \ 
(gdb) bt 
#0 0x8048515 in main () at /usr/include/bits/mathinline.h:376
#1 0x4004fcb3 in __libc_start_main (main=0x8048440 <main>, argc=1,
    argv=0xbffffb84, init=0x8048310 <_init>, fini=0x80485bc <_fini>,
    rtld_fini=0x4000a350 <_dl_fini>, stack_end=0xbffffb7c)
    at ../sysdeps/generic/libc-start.c:78                                   
----------------------------------------------------------------



If you guys want any more information, please feel free to get in touch
with me (loening@ucla.edu). Oh, and I'm not on this list, so replying to
the list won't send anything to me.

Thanks,
	Andy

Re: SGI--memory: auto_ptr::operator= bug

[Alexandre Oliva]

On Jul 12, 1999, j.sampaio@ip.pt wrote:

> I found (in fact, it was the -Wall) a bug on both operator=
> methods of auto_ptr: they don't return a reference to them selfs
> as they say (for a=a=a). It's not very dificult: just add
> "return *this;" in the end of the functions.

Thanks, this is already fixed in the upcoming gcc 2.95.

-- 
Alexandre Oliva http://www.dcc.unicamp.br/~oliva IC-Unicamp, Bra[sz]il
oliva@{dcc.unicamp.br,guarana.{org,com}} aoliva@{acm.org,computer.org}
oliva@{gnu.org,kaffe.org,{egcs,sourceware}.cygnus.com,samba.org}
** I may forward mail about projects to mailing lists; please use them