HDTenEightyP/NetNews huggingface dataset:
From: sidley@somcru.med.unc.edu (Richard F. Sidley)
Subject: unable to build gcc 2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 14:54:17 GMT

I have followed your directions carefully for building the compiler (those in
the INSTALL file).  I used the following:

configure --target=sparc-sun-sunos4.1.1

	(I have a Sun SPARCstation 1 with the above OS)

make LANGUAGES=c

make stage1

make CC="stage1/gcc -Bstage1/" CFLAGS="-g -O" LANGUAGES="c"

...and this bombed saying it couldn't find cccp related files.  I even tried
putting in links to those files in the stage1 subdirectory, then it couldn't
find other files.

So, I said, enough of that and tried to install it anyway so that I could try
it out on a real C file.  I used:

make install LANGUAGES="c"

...and this bombed saying it couldn't do a make install-common.

Come on.  I know this is supposedly beta, but one would expect the Makefile to
be good.  Am I doing something wrong?

Rich

P.S. I did change Makefile.in to have prefix point to /usr/Local rather than
     /usr/local.  Other than that, this is exactly what I got off prep last
     night.

Richard F. Sidley, Systems Manager
General Clinical Research Center
University of North Carolina, School of Medicine
CB# 7600, 3027 APCF
Chapel Hill, NC  27599-7600

(919) 966-4802 voice
(919) 966-1576 FAX
sidley@med.unc.edu INTERNET


Newsgroups: gnu.gcc.bug
From: jody@algorithmics.COM (Jody Goldberg)
Subject: Bug in support for hp-pa
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 06:30:53 GMT

Version :Reading specs from /usr/local/lib/gcc-lib/hp9k720-hpux/2.2.2/specs
gcc version 2.2.2

Code
----Cut Here ---------
void fun(a,b,c,d)
        char * a, *b, * c;
        double  d;
{
        d = 23.0;
}

main()
{
        fun(0,0,0,4.0);
}
------cut here--------

Probable location in config/pa.h the macro 
"ASM_DOUBLE_ARG_DESCRIPTORS" is called with the wrong bound test (i<4) instead
of (i < 3)

Hope this helps
	Jody

Newsgroups: gnu.gcc.bug
From: asmith@synoptics.com (Andrew Smith)
Subject: Re:  gcc 2.2.2 optimizer bug/68k
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 20 Jul 1992 20:49:22 GMT

I'll bet that you did not declare "addr" as a volatile pointer! Unless you
do that, GCC is entitled to think that *addr can never change, so it doesn't
need to recalculate it each time through the loop.

Don't ask me why it still leaves the loop in the program - that is the real bug!


Andrew.

 
> C code: 
> 
>         graph_AMOVE(0,-i);
>         while (!(*addr & 32));
>  
> ------------------------------- 
> 68k assembler code not optimized 
> 
>         jbsr _graph_AMOVE 
>         addqw #8,sp
> L86:
>         movel _addr,a0
>         moveb a0@(1),d0
>         andb #32,d0
>         tstb d0
>         jne L87
>         jra L86
> L87:
>  
> --------------------------------- 
> 68k assembler code with optimization (-O) 
>  
>         jbsr _graph_AMOVE
>         addqw #8,sp
>         movel _addr,a0
>         moveb a0@(1),d0
>         andb #32,d0
> L97:
>         tstb d0
>         jeq L97
>         clrl d0
> 
> 
> -- 
> _____________
> Hermann Hueni Seidenweg 40, CH-3012 Bern,		    +41 31 234 607
> Jucker Informatik, Anlikerweg 5, CH-3626 Huenibach,	    +41 33 434 868
> Physiological Institute, University of Berne, CH-3012 Bern, +41 31 658 726
> e-mail: hueni@optolab.unibe.ch			       fax: +41 31 654 611
> 
> 


Newsgroups: gnu.gcc.bug
From: psm@sics.se (Peter Magnusson)
Subject: gcc 2.2.2: "unsigned preserving" rule of "-traditional" causes problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 23:10:25 GMT

Comparing an "int" with a 32-bit constant generates strange code when the
"traditional" flag is selected.

Gcc version 2.2.2 (running on SPARCstation ELC 4/25 SunOS 4.1.2).

The following bit of code:

   int
     main()
   {
     int a,b;
     b = 0x80000000;
     if (b >= 0x80000000)
       a = 0;
     else
       a = 1;
   }

Generates the following code with "gcc -S":

.text
        .align 4
        .global _main
        .proc   04
_main:
        !#PROLOGUE# 0
        save %sp,-144,%sp
        !#PROLOGUE# 1
        call ___main,0
        nop
        sethi %hi(-2147483648),%o0
        st %o0,[%fp-24]
        ld [%fp-24],%o0
        sethi %hi(2147483647),%o2
        or %o2,%lo(2147483647),%o1
        cmp %o0,%o1
        bleu L2                      <========
        nop
        st %g0,[%fp-20]
        b,a L3
L2:
        mov 1,%o0
        st %o0,[%fp-20]
L3:
L1:
        ret
        restore

When compiled with "gcc -S -traditional", the code is:

.text
        .align 4
        .global _main
        .proc   04
_main:
        !#PROLOGUE# 0
        save %sp,-144,%sp
        !#PROLOGUE# 1
        call ___main,0
        nop
        sethi %hi(-2147483648),%o0
        st %o0,[%fp-24]
        ld [%fp-24],%o0
        sethi %hi(2147483647),%o2
        or %o2,%lo(2147483647),%o1
        cmp %o0,%o1
        ble L2                         <======= !!!!
        nop
        st %g0,[%fp-20]
        b,a L3
L2:
        mov 1,%o0
        st %o0,[%fp-20]
L3:
L1:
        ret
   

Notice the change. The constant is decremented but the comparison is such that
the expression evaluates to false!


Peter Magnusson
Swedish Institute of Computer Science
psm@sics.se

Newsgroups: gnu.gcc.bug
From: tietz@eos.informatik.uni-bonn.de (Benno Tietz)
Subject: bug in gcc -O
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 22 Jul 1992 12:40:02 GMT

Hi,

I found another bug in gcc-920717.

Machine	: Sun 4/330
OS	: 4.1.1
Configuration: ./configure sun4 -prefix=/home/tietz/gnu
Syptoms	: program cc1 gets a fatal signal 6
Command	: 
tietz@eos$ gcc -v -c -O test1.c
	Reading specs from /home/tietz/gnu/lib/gcc-lib/sun4/2.2.2/specs
	gcc version 2.2.2
	 /home/tietz/gnu/lib/gcc-lib/sun4/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix -D__OPTIMIZE__ test1.c /usr/tmp/cca06780.i
	GNU CPP version 2.2.2 (sparc)
	 /home/tietz/gnu/lib/gcc-lib/sun4/2.2.2/cc1 /usr/tmp/cca06780.i -quiet -dumpbase test1.c -O -version -o /usr/tmp/cca06780.s
	GNU C version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
	gcc: Internal compiler error: program cc1 got fatal signal 6

programm:
	/* test1.c */

	struct foo
	{
	};


	bar (y)
	     struct foo y;
	{

	}


additional information: gcc -c test1.c compiles ok

Newsgroups: gnu.gcc.bug
From: ross@zooid.guild.ORG (Ross Ridge)
Subject: Re:  gcc 2.2.2 optimizer bug/68k
Organization: ZOOiD BBS
Distribution: gnu
Date: Sat, 25 Jul 1992 21:02:27 GMT

asmith@synoptics.com (Andrew Smith) writes:
>Don't ask me why it still leaves the loop in the program - that is the
>real bug!

It can't get rid of the loop, if "*addr & 32" is true then it should go
into a infinite loop.  You could optimize the loop by branching to
after the test statement instead of before, but what's the point of
doing nothing faster?

>> C code: 
>>         while (!(*addr & 32));
>> --------------------------------- 
>> 68k assembler code with optimization (-O) 
>>  
>>         movel _addr,a0
>>         moveb a0@(1),d0
>>         andb #32,d0
>> L97:
>>         tstb d0
>>         jeq L97
>>         clrl d0

							Ross Ridge

-- 
Ross Ridge - The Great HTMU					     l/	 //
								    [OO][oo]
ross@zooid.guild.org						    /()\/()/
uunet.ca!zooid!ross						     db	 //

Newsgroups: gnu.gcc.bug
From: flebbe@wega.tat.physik.uni-tuebingen.de (Olaf Flebbe)
Subject: gcc2.2.2 on MIPS dies on unroll-loops
Organization: TAT (Theoretical Astrophysics Tuebingen), U. of Tuebingen, FRG
Distribution: gnu
Date: Thu, 23 Jul 1992 08:30:24 GMT

Hello *,

I recently found a bug in gcc2.2.2 on several mips R3000
architectures: mips-sony-news, mips-sgi-irix4, mips-dec-ultrix.

Compiling the following piece of code (now senseless, because i tried to
cut it down to only a few lines; this is the shortest version I have)
with  "gcc -O -funroll-loops -c neugit.c"
will yield:
----
neugit.c: In function `gitter':
neugit.c:35: internal error--unrecognizable insn:
(insn 440 438 361 (set (reg:SI 6)
       (mem:SI (plus:SI (reg:SI 29)
               (const_int 90120)))) -1 (nil)
   (nil))
gcc: Internal compiler error: program cc1 got fatal signal 4
----
#!/bin/sh
# This is a shell archive (shar 3.46)
# made 07/23/1992 08:37 UTC by ???@nova
# Source directory /usr/wega/flebbe/tmp
#
# existing files will NOT be overwritten unless -c is specified
#
# This shar contains:
# length  mode       name
# ------ ---------- ------------------------------------------
#    579 -rw-r--r-- neugit.c
#
# ============= neugit.c ==============
if test -f 'neugit.c' -a X"$1" != X"-c"; then
	echo 'x - skipping neugit.c (File already exists)'
else
echo 'x - extracting neugit.c (Text)'
sed 's/^X//' << 'SHAR_EOF' > 'neugit.c' &&
#include <math.h>
#include <stdlib.h>
X
#define MAXGIT 150
X
typedef struct {
X  double x, y;
} vector_t;
X
void gitter( int count, vector_t pos[], 
X	    int *nww, 
X	    double r, double *rho) { 
X  int i, j, miny, maxy, hy;
X  float help, d;
X
X  int   gitt[MAXGIT][MAXGIT];
X  
X  int *data = (int *)malloc(count*sizeof(int));
X  
X  for (i = 0; i < count; i++) {
X    rho[i] = 0.;
X  }
X  
X  for (i = 1; i < count; i++) {
X      for (hy = miny; hy<= maxy; hy++) {
X	while(j >=0) {
X	  d = pos[i].y - pos[j].y;
X	  if ( d <= r) {
X	    d = sqrt( d);
X	    rho[i] += help;
X	  }
X      }
X    }
X  }
}
X
SHAR_EOF
chmod 0644 neugit.c ||
echo 'restore of neugit.c failed'
Wc_c="`wc -c < 'neugit.c'`"
test 579 -eq "$Wc_c" ||
	echo 'neugit.c: original size 579, current size' "$Wc_c"
fi
exit 0


--
  Olaf Flebbe,  Theoretische Astrophysik Tuebingen
  Internet:     flebbe@tat.physik.uni-tuebingen.de

Newsgroups: gnu.gcc.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: -static provokes warning
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 12:36:34 GMT

In GCC 2.2.2 on (for example) an IBM RT running 4.3BSD (configured as
`romp-aos') specifying the -static option produces a warning (although
it's not identified as such).

    $ gcc -v -static
    gcc: unrecognized option `-static'
    gcc version 2.2.2

The manual says:

`-static'
     ...  On other systems, this option has no effect.


I think GCC shouldn't issue the warning.

Newsgroups: gnu.gcc.bug
From: seanc@espresso.boeing.COM (Sean Callahan 5-3309)
Subject: protoize bug ... sorry my error. Retract bug report.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 29 Jul 1992 15:42:59 GMT

A combination of a #ifdef along with my incorrect usage of the protoize 
-c option explains the below problem. Sorry for any inconvenience!

Sean Callahan

Forwarded message:
> From seanc Tue Jul 28 16:24:46 1992
> Subject: protoize bug
> To: bug-gcc@prep.ai.mit.edu
> Date: Tue, 28 Jul 92 16:24:46 PDT
> X-Mailer: ELM [version 2.3 PL0]
> 
> 
> I have an approximately 2000 line C sourcefile. It has a globally scoped 
> external variable defined in the file as shown below.
> 
> AllIntersect CMAISP;
> 
> where AllIntersect is defined in an included header file as
> 
> typedef struct AllIntersect AllIntersect;
> 
> struct AllIntersect {
> 	IheaderP head, tail;
> 	int total;
> 	int total_headers;
> };
> 
> CMAISP is used throughout the file over 100 times. No errors are reported 
> until line 1508 where protoize complains that 
> 
> `CMAISP' undeclared (first use this function)
> 
> and protoize fails.
> 
> I can fix the problem by inserting 
> 
> extern AllIntersect CMAISP; 
> 
> above the function where the complaints begin...but that is obviously
> not acceptable.  I am converting a program consisting of 60 large 
> source files!
> 
> If you can be of any help I would greatly appreciate it!
> 
> The version is 2.2.2.2
> 
> Thankyou,
> Sean Callahan
> seanc@atc.boeing.com
> 
> 


Newsgroups: gnu.gcc.bug
From: jearls@phoenix.csc.calpoly.edu (Johnson Earls)
Subject: GCC 2.2.2 on a Sun4 (Sparc) :  union getting trashed in func call
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 27 Jul 1992 19:09:09 GMT

Version:		gcc 2.2.2

Source code:

-------- snip snip --------
typedef union atomVal
{
  char c;
  long l;
  double d;
  void *p;
} atomVal;

typedef struct object
{
  struct object *parent;
  int count;
  int *methods;
  char *name;
  long size;
} *object;

typedef struct AtomData
{
  atomVal value;
} *AtomData;

typedef struct Atom
{
  struct object info;
  struct AtomData data;
} *Atom;

struct Atom test_atom_struct;

Atom test_atom = &test_atom_struct;

void atom_set(Atom h, atomVal v)
{
  h->data.value = v;
}

main()
{
  atomVal av;

  av.p = &test_atom;

  atom_set(test_atom, av);
}
-------- snip snip --------

Compile line:		gcc -g test.c

Machine:		Sun:  SPARCserver 690MP running SunOS 4.1.2
			Also: SPARC IPC running SunOS 4.1.2

Configure options:	./configure sun4-sunos4.1.2

Modifications to GCC:	None

Description:

The union variable `av' does not get passed to the subroutine
correctly.

Typescript of the problem:

Script started on Mon Jul 27 12:03:59 1992

%%%  gcc -v
Reading specs from /usr/local/lib/gcc-lib/sun4-sunos4.1.2/2.2.2/specs
gcc version 2.2.2
%%%  gcc -g test.c
%%%  gdb a.out
GDB is free software and you are welcome to distribute copies of it
 under certain conditions; type "show copying" to see the conditions.
There is absolutely no warranty for GDB; type "show warranty" for details.
GDB 4.4, Copyright 1991 Free Software Foundation, Inc...
(gdb) b main
Breakpoint 1 at 0x22bc: file test.c, line 42.
(gdb) run
Starting program: /home/cscstd/ijkl/jearls/Work/a.out 

Breakpoint 1, main () at test.c:42
42        av.p = &test_atom;
(gdb) s
44        atom_set(test_atom, av);
(gdb) print av
$1 = {c = 0 '\000', l = 16552, d = 3.5123274336104573e-310, p = 0x40a8}
(gdb) s
atom_set (h=0x40c0, v={c = 17 '\021', l = 289411200, 
      d = 1.3562482849288595e-225, p = 0x11401080}) at test.c:35
35        h->data.value = v;
(gdb) print v
$2 = {c = 17 '\021', l = 289411200, d = 1.3562482849288595e-225, 
  p = 0x11401080}
(gdb) q
%%%  exit

script done on Mon Jul 27 12:04:33 1992


If this is part of ANSI C, or isn't a bug for some other reason, sorry
for the inconvenience.

- John

Newsgroups: gnu.gcc.bug
From: lbmoore@tchden.UUCP (Louis B. Moore)
Subject: VMSINSTAL
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 25 Jul 1992 16:59:56 GMT

Hello,

No bugs to report, but perhaps a comment, or request for enhancement.

In the VMSINSTAL, it would be nice to have an option as to which help
library to update. 


Although we do use VAXc I am looking forward to allowing our programmers
to get familiar with G++.

                                            Thanks for all your efforts,


    Louis B. Moore, Systems Programmer, The Children's Hospital of Denver
     tchden!lbmoore@csn.org

Newsgroups: gnu.gcc.bug
From: a2824ak@sunmanager.lrz-muenchen.de (Thomas Kaiser)
Subject: gcc-Optimize
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 22 Jul 1992 17:56:44 GMT

Dear Sirs:

i discovered an bug, when gcc -g -O removed (optimized) a statement. It
removes count-- from the example.

Sorry, i missed the version of gcc:
    it was done with gcc.2.2.2 with target sparc-sun-sunos4.1
    on an SS2 with sunos4.1.1

With regards

Thomas Kaiser
Leibniz Supercomputing Centre
Muenchen
Germany



--
-------------------------------------------------------------------------
Thomas Kaiser         Internet:	kaiser@sunmanager.lrz-muenchen.de
LRZ-Muenchen          X400:	C=DE;A=DBP;P=LRZ-MUENCHEN;OU=LRZ;S=Kaiser
-------------------------------------------------------------------------


Newsgroups: gnu.gcc.bug
From: paulg@tplrd.tpl.oz.AU (Paul Gittings)
Subject: minor gcc 2.2.2  cross-compiler problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 22 Jul 1992 02:31:46 GMT

gcc 2.2.2 configured with a host of sun4 and a target of sun3 has
the following minor problem/discrepancy;

  -Makefile specifies that "enquire.c" be compiled with 
   $(GGC_FOR_TARGET) then tries to run the resulting program
   on the host to produce in an attempt to make float.h

Also, I noted that for the Makefile target libgcc2.a:  uses 
$(GCC_FOR_TARGET) to compile the various files to be included into
the library but uses $(AR) rather than $(AR_FOR_TARGET) to actually 
include the object files. Could this cause problems?

Cheers,                                ___T_e_l_e_c_t_r_o_n_i_c_s__|/\  ___
Paul Gittings                                      Pacing Systems     \/
                                7 Sirius Rd, Lane Cove, NSW 2066, Australia
61-2-4136963 (voice) 61-2-4136868 (fax)     Telex: AA 120576   
ACSnet/AARnet: paulg@tplrd.tpl.oz.au        Internet/Usenet: paulg@tps.com 
---------------------------------------------------------------------------



Newsgroups: gnu.gcc.bug
From: I.G.Batten@fulcrum.bt.co.UK (Ian G Batten)
Subject: gcc 2.2.2 Sun 4 X11R5pl#14 libXt builtin_saveregs problems
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 30 Jul 1992 17:05:23 GMT

I'm quite ready for someone to tell me I've been stupid.

I've built X11R5#14 with gcc 2.2.2 on a Sun 4/470 with SunOS 4.1.1 and a
Sun 4/690 with SunOS 4.1.2.  It appears that in the shared version of
libXt there are unresolved references to builtin_saveregs, caused (I
think) by the explicit call to it in va-sparc.h.  This means that a gcc
compiled libXt isn't a drop-in replacement, as it requires the caller to
be linked with libgcc.

What's the good word?  The standard X clients work, because they were
gcc compiled at the same time.  Most of the other stuff works, because
it doesn't use Xt.  There are a few things that are broken, however.

ian


Newsgroups: gnu.gcc.bug
From: dango@world.std.com (Dan J Golick)
Subject: bug in gcc
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 24 Jul 1992 12:42:52 GMT

/* 
Bug report:

gcc -v :
Reading specs from /usr/local/lib/gcc-lib/i386v32/2.1/specs
gcc version 2.1

This program when compiled with the following compile line gives an internal error (output follows):
gcc -fwritable-strings -DBUG -O2 -g -c -I/usr2/views3/include t.c 

OUTPUT:
t.c: In function `vw_history':
t.c:69: internal error--unrecognizable insn:
(insn 33 32 34 (parallel[ 
           (set (mem:BLK (plus:SI (reg:SI 34)
                       (symbol_ref:SI ("history"))))
               (mem:BLK (reg:SI 26)))
           (use (const_int 15))
           (use (const_int 1))
           (set (reg:SI 29)
               (const_int 0))
           (set (reg:SI 27)
               (plus:SI (reg:SI 35)
                   (const_int 15)))
           (set (reg:SI 28)
               (plus:SI (reg:SI 26)
                   (const_int 15)))
       ] ) -1 (nil)
   (expr_list:REG_UNUSED (reg:SI 29)
       (expr_list:REG_UNUSED (reg:SI 27)
           (expr_list:REG_UNUSED (reg:SI 28)
               (nil)))))
gcc: Internal compiler error: program cc1 got fatal signal 6

The bug goes away by compiling without the BUG define or turning off strength 
optimization as in the following compile line:
gcc -fwritable-strings -O2 -DBUG -fno-strength-reduce -g -c -I/usr2/views3/include t.c
*/

struct vwdays                     /* Scroll region data structure           */
{
    unsigned char l_dash[15];
    unsigned char vw_day_date[14];
    unsigned char l_[2];
    unsigned char vw_day_samps[5];
    unsigned char r_[9];
    unsigned char r_dash[16];
} ;


struct history                      /* Data form data structure               */
{
    struct vwdays vw_days[10];      /* For scroll region on form              */
} ;
struct history history;
int vw_history()
{
int i=0;
    while(tstcall())
    {
#if defined BUG
    strcpy(history.vw_days[i].l_dash, "--------------");
#else
    strcpy(history.vw_days[i].l_dash, "-------------");
#endif
    strcpy(history.vw_days[i].l_, ".");
    i++;
    }
}

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: WRONG LIST (was: Re:  Bugreport on GCC 2.2.2 running as C++ compiler...)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 21 Jul 1992 00:11:44 GMT

In the future please report all g++ bugs to the
        bug-g++@prep.ai.mit.edu
list, thanks.  If they are back-end bugs, they can be reported here,
but please let us know if you think the problem is in the back-end.

You don't need to resubmit this one.

> From: d9hh@dtek.chalmers.se
> Message-Id: <9207192148.AA09547@hacke0.dtek.chalmers.se>
> To: bug-gcc@prep.ai.mit.edu
> Date: Sun, 19 Jul 92 23:48:19 MET DST

> Hi, I think I've found a bug, even though I'm not a 100% sure, this is
> probably something you can figure out in a split second.

> Here we go...

> Version:
> GCC 2.1 and 2.2.2 (these are the versions I've seen the error (?) in).

> Running on machine:
> Some kind of Unix machine (GCC2.2.2), but I've also seen it on my Amiga and on
> a Sun (version 2.1)

> This is what I think is wrong:
> When compiling C++ programs: When assigning a function pointer to
> the adress of another function something in the type checking fails.

> Ok to see it clearly here are some sourcecodes:

> file one (C++)
> --------------

> // Yeah I know I should use iostream.h instead, but I'm trying to
> // make a point here that's all...
> #include "stdio.h"

> void foo(int&);

> void (*bar)(char);

> main() {
> 	int e = 34;
> 	bar = &foo;     // *** Compiler should complain here
> 	bar(e);         // ...booom!!
> }


> void foo(int& a) {
> 	printf("output: %d\n",a);
> }

> EOF


> file two (still C++)
> --------------------

> #include "stdio.h"

> void foo(int*);

> void (*bar)(char);

> main() {
> 	int e = 34;
> 	bar = &foo;    // **** Compiler should complain here
> 	bar(e);
> }


> void foo(int* a) {
> 	printf("output: %d\n",*a);
> }

> EOF

> Ok. when compiling these two files doing 'gcc file1.cc' or 
> 'gcc file2.cc' the compiler says nothing at all about the difference in
> type for bar and foo. See? bar takes a char and foo takes an int reference
> or in file two, an int pointer, still, the compiler says nothing at all.
> When running the programs, all I get is 'bus error' or 'segmentation 
> fault'... (Or a nice crash on my Amiga.. :-).

> Trying to compile with 'gcc -ansi -pedantic -Wall' makes no difference.

> When trying to compile the same thing on CC instead, the compiler
> says this is clearly an error. The most interesting thing, though
> that kind of convinces me is that when compiling file two as plain C
> (which it is) GCC gives a warning about 'assignment from incompatible
> pointer type'.

> Hope this helps. And thanks for providing the world with the best
> compiler ever!


> -- 
> Henrik Harmsen     Internet:  d9hh@dtek.chalmers.se
>                Chalmers University of Technology, Sweden. 
>       "I haven't lost my mind -- it's backed up on tape somewhere."



Newsgroups: gnu.gcc.bug