HDTenEightyP/NetNews huggingface dataset:
From: pth@ibm-1.mpa.ipp-garching.mpg.de (Peter Huebner)
Subject: Looks like a bug in the gcc optimizer
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 18:54:36 GMT

I have compiled a program on a IBM-RS6000 with gcc -O2 (version 2.2.2)
twice with a constant kappa = 1.0 and kappa = 0.0, with which huge
expressions are multiplied. I was very surprised that the code for the
kappa = 0.0 case was longer then the one for the kappa = 1.0 case.  I
have included a short test program and the assembler codes produced
for both cases. For me as I am doing numerics it would be essential if
optimizing removed terms multiplied by zero. At least a option
enforcing this would be great.

Thanks a lot, Peter Huebner


Program:
/*********************************************************************/
#include <stdio.h>

#define kappa 0.0

main()
{
  double x, y;

  x = 2.0 + kappa*y*y*y*y*y*y;

  printf("%e\n",x);
}
/********************************************************************/

Assemblercode, generated with the command "gcc -O2 test.c -c" and kappa = 0.0:
/********************************************************************/
	.toc
gcc2_compiled.:
	.extern .__main
	.extern printf[DS]
	.extern .printf
	.csect _test.rw_c[RO]
	.align 2
LC..2:
	.byte "%e"
	.byte 10, 0
	.toc
LC..0:
	.tc FD_0_0[TC],0,0
LC..1:
	.tc FD_40000000_0[TC],1073741824,0
LC..3:
	.tc LC..2[TC],LC..2
.csect [PR]
	.align 2
	.globl main
	.globl .main
	.csect main[DS]
main:
	.long .main, TOC[tc0], 0
	.csect [PR]
.main:
	mflr 0
	stfd 31,-8(1)
	st 0,8(1)
	stu 1,-72(1)
	bl .__main
	cror 15,15,15
	lfd 1,LC..0(2)
	fm 1,31,1
	fm 1,1,31
	fm 1,1,31
	fm 1,1,31
	lfd 0,LC..1(2)
	fm 1,1,31
	fma 1,1,31,0
	l 3,LC..3(2)
	stfd 1,56(1)
	l 4,56(1)
	l 5,60(1)
	bl .printf
	cror 15,15,15
	ai 1,1,72
	l 0,8(1)
	mtlr 0
	lfd 31,-8(1)
	br
LT..main:
	.long 0
	.byte 0,0,34,65,129,0,0,0
	.long LT..main-.main
	.short 4
	.byte "main"
_section_.text:
.csect .data[RW]
	.long _section_.text
/***************************************************************/

Assemblercode, generated with the command "gcc -O2 test.c -c" and kappa = 1.0:
/***************************************************************/
	.toc
gcc2_compiled.:
	.extern .__main
	.extern printf[DS]
	.extern .printf
	.csect _test.rw_c[RO]
	.align 2
LC..2:
	.byte "%e"
	.byte 10, 0
	.toc
LC..0:
	.tc FD_0_0[TC],0,0
LC..1:
	.tc FD_40000000_0[TC],1073741824,0
LC..3:
	.tc LC..2[TC],LC..2
.csect [PR]
	.align 2
	.globl main
	.globl .main
	.csect main[DS]
main:
	.long .main, TOC[tc0], 0
	.csect [PR]
.main:
	mflr 0
	stfd 31,-8(1)
	st 0,8(1)
	stu 1,-72(1)
	bl .__main
	cror 15,15,15
	lfd 1,LC..0(2)
	fm 1,31,1
	fm 1,1,31
	fm 1,1,31
	fm 1,1,31
	lfd 0,LC..1(2)
	fm 1,1,31
	fma 1,1,31,0
	l 3,LC..3(2)
	stfd 1,56(1)
	l 4,56(1)
	l 5,60(1)
	bl .printf
	cror 15,15,15
	ai 1,1,72
	l 0,8(1)
	mtlr 0
	lfd 31,-8(1)
	br
LT..main:
	.long 0
	.byte 0,0,34,65,129,0,0,0
	.long LT..main-.main
	.short 4
	.byte "main"
_section_.text:
.csect .data[RW]
	.long _section_.text
/**********************************************************************/ 




Newsgroups: gnu.gcc.bug
From: jgk@ohm.ee.utulsa.edu (Jeff Kohlbeck ph. 627-0753)
Subject: installation_problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 22:46:41 GMT

	I have a problem that I hope you may help me solve. For the last three day I have tried to install gcc version 2.2.2 on our sparc sunos 4.1.1 machines.  The installation runs fine.  But after everything is installed, running gcc results with the following error:
gcc: installation problem, cannot exec cpp: No such file or directory
	I have read the documentation and either am missing the solution to this problem or do not understand what is happening in the Makefile. I have tried thied the installation several times from scratch and modifing the installation point in the Makefile, with no results.
	Any help you can provide is appreciated.
			Jeff Kohlbeck Grad
			System Admin EE Dept.
			University of Tulsa
			jgk@ohm.ee.utulsa.edu

Newsgroups: gnu.gcc.bug
From: h8751608@d25.wu-wien.ac.at (Franz Brandel)
Subject: no subject (file transmission)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 12:28:59 GMT

Franz Brandel                                        Vienna, 13th October 1992

login: h8751608 (wu-wien.ac.at)
University of Economics, Vienna (Austria)



Please note, that gcc recogniceses then Linker-switch -l, only if
you type it at the bottom of comand-line. A fact, wich is not mentioned in
the Manual.


Sincerely 

Franz Brandel




Newsgroups: gnu.gcc.bug
From: dcb@us-es.SEl.DE
Subject: Page 186 of the ARM
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 11:18:33 GMT

hello there,

I typed in the code from section 9.7, page 186 of the ARM.

I have gnu 2.2.2 on Sun 4 hardware.

The compiler didn't issue the required error messages.

Regards

David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841

Newsgroups: gnu.gcc.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: gcc manual buglet
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 12:36:11 GMT

In the manual for gcc 2.2.2, the `Bug Reporting' node, @code is used for
@emph is (I believe) intended:

  one instruction might be wrong.  We need @code{you} to do this part!

Newsgroups: gnu.gcc.bug
From: marc@ccv.FR (Marc Bassini)
Subject: gcc bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 20:42:21 GMT

VERSION:2.2.2

INPUT:	#include <stdarg.h>
	foo(char *const bar, ...)
	{
	 va_list ap;
	 va_start(ap, bar);
	 char *tmp;
	 while ((tmp = va_arg(ap, char *const)) != (char *const) NULL)
	  {}
	 va_end(ap);
	}

The following macro is extracted from:
		gcc-lib/sparc-sun-sunos4.1/2.2.2/include/va-sparc.h:

#define va_arg(pvar,TYPE)					\
__extension__							\
({ TYPE __va_temp;						\
   ((__builtin_classify_type (__va_temp) >= 12)			\
    ? ((pvar) += __va_rounded_size (TYPE *),			\
       **(TYPE **) ((pvar) - __va_rounded_size (TYPE *)))	\
    : __va_rounded_size (TYPE) == 8				\
    ? ({ union {TYPE d; int i[2];} u;				\
	 u.i[0] = ((int *) (pvar))[0];				\
	 u.i[1] = ((int *) (pvar))[1];				\
	 (pvar) += 8;						\
	 u.d; })						\
    : ((pvar) += __va_rounded_size (TYPE),			\
       *((TYPE *) ((pvar) - __va_rounded_size (TYPE)))));})

ARGUMENTS:	-g -c

MACHINE:	sparc elc running SunOS Release 4.1.1

OPERANDS:	sparc-sun-sunos4.1

INPUT doesn't work because when TYPE is const, __va_temp needs
initialization.

		Marc Bassini (marc@ccv.fr, marc@cnam.cnam.fr)
			Computers, Communications & Visions (C2V)
			82 bd Haussmann, 75008 Paris FRANCE
			Phone 40.08.07.07, Fax 43.87.35.99

Newsgroups: gnu.gcc.bug
From: dave@jato.jpl.nasa.gov (Dave Hayes)
Subject: Please add to FAQ and gcc-2.2.2 readme! (Was Re: Compiling X11R5 - HELP.)
Reply-To: dave@jato.jpl.nasa.gov
Organization: Jet Propulsion Lab - Pasadena, CA
Distribution: gnu
Date: Wed, 14 Oct 1992 16:29:26 GMT

hwn@cci.dk (Henrik W. Nielsen) writes:
>I have just compiled X11R5 on my Sun IPC (SunOS 4.1.1) using gcc-2.
>It's a standard 8-bit color IPC configuration.
>It compiles without any errors, but when trying to start X, I get the
>following error message:
>Getting interface configuration: Operation not supported on socket
>sunOpenFrameBuffer: Inappropriate ioctl for device
...
>Some suggested that I had not used fixincludes for gcc and X11 from the Gnu
>package, they were right. Now I have re-installed a new gcc compiler. I tested
>it with the following:
>        #include <sys/ioctl.h>
>        SIOCGIFCONF
> 
>which I ran through cc -E and gcc -E and the output was the same.

(The following is courtesy of Jeffrey A Law <law@schirf.cs.utah.edu>)

The way to test for the proper includes with gcc-2.2.2 is as follows:

	strings - `which gcc` | egrep gcc-lib

The output of this should be a pathname...look in that directory for
an "include" directory. If there isn't one, put a symlink in that 
directory to where the "fixincludes" stuff is. In my case this looked
like:

	include -> sparc-sun-sunos4.1.1/2.2.2/include

Apparently either the understanding of where gcc is to find the includes
is not there, or gcc is confused about where they are supposed to be.
If this is a problem with the way 2.2.2 was installed, I'd appreciate
a followup somewhere. 

Thanks to all who responded to my similar request. 
-- 
Dave Hayes - Network & Communications Engineering - JPL / NASA - Pasadena CA
dave@elxr.jpl.nasa.gov       dave@jato.jpl.nasa.gov         ...usc!elroy!dxh

   History is not usually what has happened.
            History is what some people have thought to be significant.

Newsgroups: gnu.gcc.bug
From: Joseph.FRancis@ircam.FR (Joseph Francis)
Subject: Bug: i860 address operands in gcc-2.2.2
Organization: IRCAM, Paris (France)
Distribution: gnu
Date: Mon, 12 Oct 1992 17:08:13 GMT

In gcc-2.2.2, targeted for the i860 processor, the following code exists
in file "i860.h", in the configuration directory:

under PRINT_OPERAND(FILE, X, CODE)

if (GET_CODE (X) == MEM)
  PRINT_OPERAND_PART (FILE, XEXP (X, 0),
                      const_int_operand (XEXP (X, 0))
                              ? OPERAND_HIGH_PART
                              : OPERAND_HIGH_ADJ_PART);

this produces assembler instructions for constant integer address
operands (i.e., fixed memory locations, here 0xabcdefgh) with bad
offset adjust instructions.

		orh	h%0xabcdefgh,r0,r31
		st.l    r16,l%0xabcdefgh(r31)

		and when assembled and executed the resulting address
		becomes 0xabceefgh

the code should be something more like:

if (GET_CODE (X) == MEM)
  PRINT_OPERAND_PART (FILE, XEXP (X, 0),
                           OPERAND_HIGH_ADJ_PART);

which produces the code

		orh	ha%0xabcdefgh,r0,r31
		st.l	r16,l%0xabcdefgh(r31)

Works for me.


-- 
| Le Jojo: Fresh 'n' Clean, speaking out to the way you want to live
| today; American - All American; doing, a bit so, and even more so.

Newsgroups: gnu.gcc.bug
From: Mehmet.Yilmaz@cyber.urz.uni-wuppertal.dbp.DE
Newsgroups: gnu.gcc.bug
Subject: a problem with kitinstal.com
Date: 14 Oct 92 21:37:52 GMT
Article-I.D.: MHS.921014182517153-BUGHW*_G=Mehmet_S=Yilmaz_OU=CYBER_OU=URZ_PRMD=UNI-WUPPERTAL_ADMD=DBP_C=DE_
Distribution: gnu
Organization: GNUs Not Usenet

hi!

i've got a problem with the KITINSTAL procedure, which i copied from
prep.ai.mit.edu .

the procedure gives the error
        %GCC-I_CTRLY Installation cancelled due to CTRL/Y .

as i tried to understand, why this happens, i found out the following;
 - it asks me as last question, the directory, where the BISON will be
   located. i give the same directory, as for GCC top directory.
 - line 150
   $ VMI$CALLBACK SET PURGE ASK
   ($  VMI$CALLBACK = "CALL CALLBACK")
 - line 369
   on CALLBACK, it goes to  DO_SET  (line 390) and  following to
   DO_SET_PURGE  (line 396).
 - the third parameter is ASK, so
   $IF p3.EQS."ASK"             (line 399)
   $        THEN
   $retry:
   $        CALL ASK YORN "Purge files replaced by installation?" "Y"
 - i searched for a subprocedure named "ASK", but couldn't find it.

so, that was what i've found out. i don't know, if this helps.
but i can't install the executable files of gnu cc.

i'll be very pleased, if you could help me to install it.

mehmet yilmaz  (student)
university wuppertal, germany

yilmaz@cyber.urz.uni-wuppertal.dbp.de
Newsgroups: gnu.gcc.bug
From: ccsam004@hamlet.ucdavis.edu (Brian C Hill)
Subject: gcc2.2.2 and libmld.a on DECS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 15 Oct 1992 05:00:21 GMT

	After I configure with mips-mips-ultrix and make LANGUAGE=c
one of the cc statements tries to link with an 'mld' library. I
Don't have this anywhere. I tried it on several DEC stations
that are maintained by different sysadm's and I get the same
error. What's going on?

   +----------------------------------------------------------------------+
   | Brian C. Hill                     INTERNET: hillb@cs.ucdavis.edu     |
   | System Administrator/Programmer   BITNET:   bchill@ucdavis           |
   +----------------------------------------------------------------------+
   | Computer Science & Computing Services PHONE: (916) 752-8878 (or 6547)|
   | University of California, Davis       FAX:   (916) 752-4767 (or 9154)|
   +----------------------------------------------------------------------+

Newsgroups: gnu.gcc.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: simple typo in comment at top of reorg.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 21:43:56 GMT

       (2) `fill_eager_delay_slots' is more complicated: it is used for
       scheduling conditional jumps, or for scheduling jumps which cannot
       be filled using (1).  A machine need not have annulled jumps to use
       this strategy, but it helps (by keeping more options open).
       `fill_eager_delay_slots' tries to guess the direction the branch

I believe the second `fill_eager_delay_slots' is supposed to say
`fill_simple_delay_slots'.

Newsgroups: gnu.gcc.bug
From: chad@helix1.chem.iastate.edu (chad hoffman)
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 10 Oct 1992 19:53:17 GMT

Subject: gcc-1.42 compilation error

I'm attempting to compile gnu finger-1.36 on an SGI Iris running
under Irix 4.0.1, and am using gcc-1.42. The error I get is:

util.c: In function strdup:
util.c:402 : argument 's' doesn't match function prototype

The section of code in util.c is:

char *
strdup(s)
char *s

I've had this problem before and have found that using the Iris's
standard C compiler doesn't produce this error.

Chad Hoffman
Biochemistry/Biophysics
Iowa State University
chad@helix1.chem.iastate.edu



Newsgroups: gnu.gcc.bug
From: dcb@us-es.SEl.DE
Subject: bug report
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 16 Oct 1992 15:08:03 GMT

Hello there,

I have gcc 2.2.2 on sun 4 hardware, with SunOs 4.1.1

Given the following code


#include <stream.h>

static int c = 0;

struct S {
	int loc;
	S() { 
		loc = 0; 
	}
	~S() { 
		++c; 
	}
};

int main() {
	int i;

	for (i = 0; i < 2; ++i) 		// note no {
		for (S j; j.loc < 1; j.loc++) {
			cout << c << "\n";
		}	
	// note no }
	cout << c << "\n";

	return 0;
}

then I get output

0
0
0

But if I change the body of main to 

int main() {
	int i;

	for (i = 0; i < 2; ++i) {	// note {
		for (S j; j.loc < 1; j.loc++) {
			cout << c << "\n";
		}
	}		// note }
	cout << c << "\n";

	return 0;
}

then I get 

0
1
2

This bug happens wether -O is used or not.

If this isn't a bug, then I'd appreciate an ARM page number for the
reason why its different.

Regards

David C Binderman     Dept US/ESI, Bau 60, SEL-Alcatel AG, Lorenz Strasse 10,
D-7000 Stuttgart 40, Germany      dcb@us-es.sel.de   Tel: +49 711 821 3841
Watch out for those dangerous fishy maultaschen !

Newsgroups: gnu.gcc.bug
From: strous@fys.ruu.NL (Louis Strous)
Subject: *p++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 13 Oct 1992 14:42:16 GMT

Sir,

  Optimalization seems to mishandle the order of statements when indirection,
  postfix increment, and floating point numbers are involved.  The skeleton
  program which follows below succeeds without, but fails after optimalization.
  The much larger program I'm actually working on retains the bug if I
  do without optimalization, however.  That bothers me. 

  Skeleton program:

#include <stdio.h>

main()
{
 int	r[7];
 float	a[] = {5, 1, 3, 5, 9, 1, 7};
 float 	b[] = {2, 4, 3, 0, 3, 1, 3};
 float  *x, *y;
 int	*d, n, *c;

 x = a; y = b; c = r; d = c; n = 7;
 while (n) {*c++ = *x++ == *y++; n--;}
 for (n = 0; n<7; n++) printf("%d ", d[n]); printf("\n");
 return;
}

  This was compiled on a DECstation 5000/200 under Ultrix, using
  version 2.2.2 (as far as I can tell) of GNU CC.

  gcc -o test test.c; test
   yields  0 0 1 0 0 1 0, which was expected, whereas
  gcc -O -o test test.c; test
   yields  0 1 0 0 1 0 1.

  I have not been able to find out which kinds of optimalization are
  standard on this system.

  If all instances of the word "float" are replaced with "int", then
  the proper result is returned both in the optimized and the non-optimized
  cases.  "double" shows the same results as "float".

  Changing the relevant code to
  {l = *x++ == *y++; *c++ = l; n--}
  or
  {*c = *x++ == *y++; c++; n--}
  does not remove the bug; I assume this generates optimized code identical
  to the original.
  
  Changing the code to
  {*c++ = *x == *y; x++; y++; n--;}
  does yield the expected result.

  These and some other rewrites using deferred pointer increments are
  consistent with the pointer increment - for pointers to non-integer only -
  being done before the value it references is retrieved, instead of the
  other way around, as C syntax prescribes.

  Regards,

  Louis Strous
  Astronomical Department
  Utrecht University
  The Netherlands

Newsgroups: gnu.gcc.bug
From: james@racerx.UUCP (James Montebello)
Subject: Problems moving from GCC2.x to GCC1.x (yes, backwards)
Organization: Bridge Information Systems
Distribution: gnu
Date: Wed, 14 Oct 1992 17:37:13 GMT

The included file compiles and links fine with both GCC 1.42 and 2.2.2.
on a SS2 running 4.1.1.

However, when run, I get a Bus Error in inet_netof() in the executable
compiled with 1.42, while the 2.2.2 version runs and works fine. GDB
claims that the input struct 'myip' is identical in both cases. I've
checked the include files used by both and they look OK (I've even
tried using the 2.2.2 "fixed" includes with the 1.42 compiler). I
haven't yet looked at the assembled output, but I have no experience
with SPARC code, so that would probably prove fruitless. 

You may say, "So? Use the 2.2.2 version." I would, except that nifty
tool Purify doesn't work with 2.x objects, only 1.x objects, and I
*really* want to "purify" the application that contains this fragment.

What's up here?


#include <stdio.h>
#include <malloc.h>

#include <sys/types.h>
#include <netinet/in.h>
#include <arpa/inet.h>
#include <netdb.h>

main(int ac, char **av)
{
    struct hostent *he;
    struct in_addr myip;
    unsigned int netp;
	
    he = gethostbyname(av[1]);	/* name of this host expected as 1st parm */

	memset(&myip,'\0',sizeof(struct in_addr));
    memcpy(&myip.s_addr, he->h_addr_list[0], sizeof(myip.s_addr));
    netp = inet_netof(myip);	/* kaboom */
}
-- 
------------------------------------------------------------------------
james montebello (james@bridge.com)         'my employer has no opinions'		
Experience: a comb life gives you after you lose your hair.
	- Judith Stern

Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: Re: 2.2.2 constant expression range checking
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 7 Oct 1992 18:40:53 GMT

>static u_char badmap[] = {
>	'\200', '\201', '\202', '\203', '\204', '\205', '\206', '\207',
>};

>gcc-test.c:8: warning: constant expression out of range for unsigned type

The warning is correct, since '\200' equals -128, and -128 is out of
range for the type unsigned char.  You can fix the problem by writing
0200 instead of '\200'.

Newsgroups: gnu.gcc.bug
From: phr@napa.telebit.com (Paul Rubin)
Subject: re: simple typo in comment at top of reorg.c
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 14 Oct 1992 21:44:58 GMT

   (2) `fill_eager_delay_slots' is more complicated: it is used for
   scheduling conditional jumps, or for scheduling jumps which cannot
   be filled using (1).  A machine need not have annulled jumps to use
   this strategy, but it helps (by keeping more options open).
   `fill_eager_delay_slots' tries to guess the direction the branch
   will go; if it guesses right 100% of the time, it can reduce the
   branch penalty as much as `fill_eager_delay_slots' does.  If it

Whoops, previous message was supposed to say the *third*
`fill_eager_delay_slots' should say `fill_simple_delay_slots'.

Newsgroups: gnu.gcc.bug
From: sethg@rodin2.cs.berkeley.edu (Seth Copen Goldstein)
Subject: long long initialization bug?
Organization: /home/auspex/b/threadid/sethg/.organization
Distribution: gnu
Date: Wed, 14 Oct 1992 22:23:40 GMT

I am using gcc version 2.2.2 on a sun4.
I want to initialize a long long with the address of another variable in 
my program and gcc won't let me.  It will however let me initialize an int with
the address of another variable.  For example the following code:

	long long a = 1;
	int b = ((int)(&a));
	long long d = (long long)((int)(&a));

produces the following error messages:

	foo.c:4: initializer element for `d' is not computable at load time

why isn't it computable at runtime?

-seth

Newsgroups: gnu.gcc.bug
From: laurenz@juno.neuroinformatik.ruhr-uni-bochum.de (Laurenz Wiskott)
Subject: gcc-2.2.2 libg++-2.2  a bug ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 9 Oct 1992 16:38:46 GMT

	Dear 'GNU',

We are just changing from the AT&T C++ compiler to your gcc-2.2.2 with
the libg++-2.2. And the bugs changes also. I think I've found a bug
concerning pointer assignment to a pointer of a pointer inside a
global declared class. Here follows a simple example:

----------------------------------------------------------------------

#include <stream.h>

class TestClass
{
 public:

  char *string;
  char **stringPtr;

  TestClass() {
    stringPtr = &string; 
  };

  void testNewDelete(char flag) {
    char *localString;
    cerr << flag <<endl; (*stringPtr) = localString;
    cerr << flag <<endl;
  };
};

char *string;
char **stringPtr;

TestClass outerTestClass;

main()
{
  stringPtr = &string; 

  char *localString;
  cerr << "A" <<endl; (*stringPtr) = localString;

  TestClass innerTestClass;
  cerr << "B" <<endl; innerTestClass.testNewDelete('b');

  cerr << "C" <<endl; outerTestClass.testNewDelete('c');

  cerr << "D" <<endl;
};


-----------------------------------------------------------------

I got always a Segmentation fault for line 'C' and can't see why.

	Kind regards, Laurenz Wiskott.





Newsgroups: gnu.gcc.bug
From: simon@lia.di.epfl.CH (Simon Leinen)
Subject: Re: GNU finger 1.36 vs. IRIX 4.0 ANSI headers
Organization: DI-LIA -- Ecole Polytechnique Federale de Lausanne
Distribution: gnu
Date: Mon, 12 Oct 1992 13:15:27 GMT

chad@helix1.chem.iastate.edu (chad hoffman) writes:

   util.c: In function strdup:
   util.c:402 : argument 's' doesn't match function prototype

   The section of code in util.c is:

   char *
   strdup(s)
   char *s

The argument of the strdup() function is declared as "const char *" in
/usr/include/string.h under IRIX 4.  Just comment out the whole
definition of strdup in util.c - you already have it in libc.a.

   I've had this problem before and have found that using the Iris's
   standard C compiler doesn't produce this error.

But it should, or at least produce a warning, at least in "-ansi" mode...

Hope this helps,
--
Simon.

Newsgroups: gnu.gcc.bug