HDTenEightyP/NetNews huggingface dataset:
From: mrs@cygnus.com (Mike Stump)
Subject: Re:  Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 13:32:59 GMT

You might want to use the header files from libg++, as these problems
will not arise then.

> Date: Fri, 21 Aug 92 13:41:02 EDT
> From: samborn@lynchpin.mtkgc.com (Kevin Samborn)
> Message-Id: <9208211741.AA09577@lynchpin.mtkgc.com>
> To: bug-gcc@prep.ai.mit.edu

> I am trying to use g++2.1 on SunOS 4.1.1 Rev B.  

> Whenever I include standard include files, (in this case coming from
> /usr/lang/SC1.0/CC/include), I get the errors similar to the following:

> In file included from /usr/lang/SC1.0/include/CC/malloc.h:9,
>                  from /usr/lang/SC1.0/include/CC/stdlib.h:21,
>                  from Main.C:1:
> /usr/lang/SC1.0/include/CC/alloca.h:10:
>         declaration of `char * __builtin_alloca (int)'
> <built-in>:0: conflicts with built-in
>         declaration `void * __builtin_alloca (int)'
> In file included from /usr/openwin3/include/X11/Xos.h:69,
>                  from /usr/openwin3/include/X11/Intrinsic.h:37,
>                  from Main.C:2:
> /usr/lang/SC1.0/include/CC/strings.h:22:
>         declaration of `unsigned int  strlen (const char *)'
> <built-in>:0: conflicts with built-in
>         declaration `int  strlen (const char *)'

> This happens even when I pass the -fno-builtin option to g++.

> Is there anyway to turn off type checking for builtin functions?

Newsgroups: gnu.gcc.bug
From: kelly@ipld01.hac.com (Keith Kelly)
Subject: Errors compiling libg++ (v2.2) on Alliant FX/2800 with g++ (v2.2.2)
Organization: Hughes Aircraft Company - Canoga Park, CA
              Imaging Guidance Design Laboratory
Distribution: gnu
Date: Fri, 4 Sep 1992 18:30:48 GMT

I'm trying to build the libg++ (version 2.2) library on an Alliant FX/2800
using the GNU c++ (Version 2.2.2) compiler.  Whenever it tries to compile
any routine with the va_start function, the compiler complains with:

warning: implicit declaration of function `__builtin_args_info'

The libg++.a library eventually builds but it has unresolved references to
__builtin_args_info.  The va-i860.h file refers to this function but it is
unclear as the where it is actually defined.  Any ideas?  Thanks in advance

kelly@ipld01.hac.com

-- 
Keith Kelly                    Internet   : kelly@ipla01.hac.com         
"Of all the things I've lost   UUCP       : ...!usc!!hacgate!ipla01!kelly
 I miss my mind the most"      Phone      : (818) 702-2328

Newsgroups: gnu.gcc.bug
From: gsk@marble.COM (Geoffrey S. Knauth)
Subject: GCC documentation, extra word
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 25 Aug 1992 08:56:52 GMT

`FUNCTION_EPILOGUE (FILE, SIZE)', paragraph 4, line 4, extra word `in'

----------
     On machines where functions may or may not have frame-pointers, the
     function exit code must vary accordingly.  Sometimes the code for
     these two cases is completely different.  To determine whether a
>>   frame pointer is in wanted, the macro can refer to the variable
     `frame_pointer_needed'.  The variable's value will be 1 at run
     time in a function that needs a frame pointer.

Newsgroups: gnu.gcc.bug
From: volker@sfb256.iam.uni-bonn.de ( Volker A. Brandt )
Subject: Re: Problems compiling stage2 on C1 Convex
Organization: Applied Math, University of Bonn, Germany
Distribution: gnu
Date: Tue, 25 Aug 1992 14:16:48 GMT

In article <1992Aug6.143611.6557@dartvax.dartmouth.edu> pete@othello.dartmouth.edu (Pete Schmitt) writes:
[...problem description deleted ...]
>This only happens at stage2 on the convex.  Anyone get past this point?

Yes, I had no problems building gcc/g++ 2.2.2 on our Convex C210 (well, none
but the usual Convex problems ...)

I'd put the binaries on one of the Convex User Group ftp servers except that
RMS doesn't allow it unless accompanied by source and I don't feel like 
pumping megabytes across the Atlantic for no reason ... 

-- Volker

-- 
----------------------------------------------------------------------------
Bitnet:   UNM409@DBNRHRZ1                              Volker A. Brandt
UUCP:     ...!unido!DBNRHRZ1.bitnet!unm409             Angewandte Mathematik
Internet: volker@sfb256.iam.uni-bonn.de                (Bonn, Germany)

Newsgroups: gnu.gcc.bug
From: chupchup@ferkel.ucsb.edu (Robert Earl)
Subject: Re: Bug in cygnus 2.0.1 (2.1 and 2.2.2 of mainstream)
Organization: (EVIL!)
Distribution: gnu
Date: Thu, 3 Sep 1992 11:00:46 GMT

system@kryton.UUCP (Scott Beckstead) writes:

| Yet in the file rtl.c There is a code fragment that 
| looks like this 

| 	if(!strcmp(somevalue,someothervalue))
| 		someaction;

| This seems like a particularly BAD idea considering the values returned by
| this fully ansi compliant library (yes it does change the behavior of
| the programs)  I have modified my library to fix this but the code
| really should be fixed so that a unary not of a non boolean return
| is not used as a boolean.  Because with the value -1 I'm sure you see the
| problem.  (!(-1) is 0 but !(1) is -2 and !(0) is -1) 

What on earth are you talking about?  The "!" operator NEVER returns
ANYTHING but 0 or 1.  Maybe you're thinking about the "~" operator.

| I beleive the intent of this code to be:

|      if(!(strcmp(somevalue,someothervalue) == 0))
|              someaction;  

Well, you're wrong, and you've just introduced a bug.

-- 
"If you've got a pig that likes jumping fences, | robert earl
you have to make its fence a lot higher all at  | rearl@ucsd.edu
once -- if you do it by increments, all you're  | rearl@piggy.ucsb.edu
doing is training a jumping pig." -Henry Spencer|

Newsgroups: gnu.gcc.bug
From: ng620@byte.pnl.gov
Subject: internet address test
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 2 Sep 1992 16:23:42 GMT

I am trying to determine if this is a valid internet address.

Mary Powers

Newsgroups: gnu.gcc.bug
From: system@kryton.UUCP (Scott Beckstead)
Subject: Bug in cygnus 2.0.1 (2.1 and 2.2.2 of mainstream)
Organization: Paradox Alley F&SF BBS 805-492-8789
Distribution: gnu
Date: Wed, 2 Sep 1992 06:33:44 GMT

I am currently porting a cygnus version of gcc (gpp objc etc.) to a new system.
In my libraries (ansi) strcmp return -1 for less than, 1 for greater than and
0 for equality.  The spec merely states negative for less than positive for greater
than and 0 for equal.  Yet in the file rtl.c There is a code fragment that 
looks like this 

	if(!strcmp(somevalue,someothervalue))
		someaction;

This seems like a particularly BAD idea considering the values returned by
this fully ansi compliant library (yes it does change the behavior of
the programs)  I have modified my library to fix this but the code
really should be fixed so that a unary not of a non boolean return
is not used as a boolean.  Because with the value -1 I'm sure you see the
problem.  (!(-1) is 0 but !(1) is -2 and !(0) is -1) 

I beleive the intent of this code to be:

     if(!(strcmp(somevalue,someothervalue) == 0))
             someaction;  

the function name is read_rtx()

If there is some other purpose to this code it is undocumented and unclear
what it might be.  I am unwilling to make the code change because I do not
fully understand what is happening here. It is quicker for me to modify 
the library functions (without degrading ansi compliance) because I KNOW
what their intent is.
Scott


Newsgroups: gnu.gcc.bug
From: c$dje@watson.ibm.com (David Edelsohn)
Subject: gcc-2.2.2 crash -- int ternary operator indexing character array
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 17:39:50 GMT

	I previously reported this as a general bug in gcc-2.2.2 that
causes a fatal signal 11 internal error in gcc-2.2.2 with an extensive code
fragment.  I have tracked the problem further to a specific type of
expression -- a ternary operator testing an integer variable with the same
variable also used as the resulting index into a character array.  The
following code fragment will crash gcc-2.2.2 with a fatal signal 11
internal error on the following types of machines:

	Digital DECstations running Ultrix 4.2A
	IBM Risc System/6000s running AIX 3.1 and 3.2.
	Sun Sparcstations running SunOS 4.1.2


int main()
{
    unsigned char this[64];
    unsigned char other;
    unsigned int index;

    other = this[index < 64 ? index : 0];

    exit(0);
}


If either use of index is changed to another variable, the program will
compile without incident.  Also, if index is changed to a character type,
the program will compile.
	Appended is a verbose compilation for an AIX system.  I would
appreciate a patch for gcc to fix this problem.

				Thanks, David

% gcc -v -c foobar.c
Reading specs from /contrib/lib/gcc-lib/rs6000/2.2/specs
gcc version 2.2
 /contrib/lib/gcc-lib/rs6000/2.2/cpp -lang-c -v -undef -D__GNUC__=2 -D_IBMR2 -D_AIX -D___IBMR2__ -D___AIX__ -D___IBMR2 -D___AIX -D__CHAR_UNSIGNED__ foobar.c /tmp/ccW8cCrx.i
GNU CPP version 2.2
 /contrib/lib/gcc-lib/rs6000/2.2/cc1 /tmp/ccW8cCrx.i -quiet -dumpbase foobar.c -version -o /tmp/ccW8cCrx.s
GNU C version 2.2.2 compiled by GNU C version 2.2.
gcc: Internal compiler error: program cc1 got fatal signal 11

===============================================================================
David Edelsohn                                      T.J. Watson Research Center
c$dje@watson.ibm.com                                P.O. Box 218
+1 914 945 3011 (Tieline 862)                       Yorktown Heights, NY 10598
"If G-D had wanted us to vote, he would have given us candidates" -- Jay Leno


Newsgroups: gnu.gcc.bug
From: kelly@ipld01.hac.com (Keith Kelly)
Subject: Errors compiling libg++ (v2.2) on Alliant FX/2800
Organization: Hughes Aircraft Company - Canoga Park, CA
              Imaging Guidance Design Laboratory
Distribution: gnu
Date: Fri, 4 Sep 1992 17:03:47 GMT

I'm trying to build the libg++ library (version 2.2) using the gnu c++
compiler (version 2.2.2) on an Alliant FX/2800 but whenever I try to
compile any routine that has 'va_start' in it (several in iostream, more
in iostream/stdio), the compiler complains with:

warning: implicit declaration of function `__builtin_args_info'

This eventually creates a libg++ library with references to the function
__builtin_args_info which is undefined.

The va-i860.h references this function within the definition for va_start
but it is unclear as to where the function itself is defined.  Any ideas?
Thanks in advance.
-- 
Keith Kelly                    Internet   : kelly@ipla01.hac.com         
"Of all the things I've lost   UUCP       : ...!usc!!hacgate!ipla01!kelly
 I miss my mind the most"      Phone      : (818) 702-2328

Newsgroups: gnu.gcc.bug
From: basti@orthogo.UUCP (Sebastian Wangnick)
Subject: Two bugs within gcc-2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 18:21:17 GMT

I just reinstalled gcc-2.2.2 on our RS6000 (configured rs6000-ibm-aix) and
stumbled again over this damn bug within __builtin_new of libgcc2.c:
Allocating e.g., new int[0], fires the new_handler! I patched this with:

*** libgcc2.c  Thu Aug 27 15:46:30 1992
--- /tmp/lc Thu Aug 27 15:54:20 1992
***************
*** 969,975 ****
  {
    void *p;
    p = malloc (sz);
!   if (p == 0 && sz)
      (*__new_handler) ();
    return p;
  }
--- 969,975 ----
  {
    void *p;
    p = malloc (sz);
!   if (p == 0)
      (*__new_handler) ();
    return p;
  }


Another issue is that using -pg makes the assembler complain (at least in 
AIX 3.2 with the patch you mention in RS6000.README installed): Compiling 
the following program

	int main () {return 0;}

with
	gcc -pg -v -c minimal.C

leads to:
Reading specs from /usr/local/lib/gcc-lib/rs6000-ibm-aix/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/rs6000-ibm-aix/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=
2 -D__GNUG__=2 -D__cplusplus -D_IBMR2 -D_AIX -D___IBMR2__ -D___AIX__ -D___IBMR2
-D___AIX -D__CHAR_UNSIGNED__ minimal.C /tmp/ccWcMDM2.i
GNU CPP version 2.2.2
 /usr/local/lib/gcc-lib/rs6000-ibm-aix/2.2.2/cc1plus /tmp/ccWcMDM2.i -quiet -dum
pbase minimal.cc -version -p -o /tmp/ccWcMDM2.s
GNU C++ version 2.2.2 compiled by GNU C version 2.2.2.
 as -o minimal.o /tmp/ccWcMDM2.s
Assembler:
/tmp/ccWcMDM2.s: line 1: Invalid toc entry within .toc scope
/tmp/ccWcMDM2.s: line 24: Invalid toc entry within .toc scope
/tmp/ccWcMDM2.s: line 30: undefined symbol ".mcount"
/tmp/ccWcMDM2.s: line 30: illegal expression type for branch address

I overcame this with the following patch to toplev.c (not knowing what it will 
do to other architectures):

*** toplev.c    Thu Aug 27 10:13:04 1992
--- toplev.c.orig       Thu May 28 07:36:37 1992
***************
*** 1609,1615 ****
    if (profile_flag || profile_block_flag)
!     {
!       text_section ();
!       ASM_OUTPUT_SKIP(asm_out_file,UNITS_PER_WORD);
!       assemble_external_libcall(gen_rtx(SYMBOL_REF,Pmode,"mcount"));
!     }

--- 1609,1611 ----
    if (profile_flag || profile_block_flag)
!     assemble_zeros (UNITS_PER_WORD);


The problem is: I still cannot profile, since ld only has 65536 or so TOC
entries available, and my program (lots of C++) needs 101700 when profiled!
I suppose TOC information is doubled when profiled, so making my code a little
bit bigger will trigger the border even WITHOUT profiling! No FP constants,
only function definitions! So, PLEASE, devise a different scheme or tell IBM
to lift that border.

So long,

Sebastian Wangnick   Orthogon System GmbH
(basti@orthogo.uucp) Linzer Strasse 4
Tel +49 421 219136   D-2800 Bremen 33
Fax +49 421 213093   Germany

Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: GCC 2.2.2 sometimes thinks DEL is printable
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 27 Aug 1992 01:39:15 GMT

For the program

	char x = '\^?';

where ^? stands for a single DEL (0177) character,
GCC 2.2.2 (Sparc, SunOS 4.1.2) outputs the error message

	t.c:1: warning: unknown escape sequence `\^?'

where ^? stands for a single DEL character.
GCC should output something like this instead, since DEL isn't printable:

	t.c:1: warning: unknown escape sequence: `\' followed by char code 0x7f

This problem appears in three places in GCC.  Here is a patch.

Thu Aug 27 01:32:11 1992  Paul Eggert  (eggert@twinsun.com)

	* c-lex.c, cp-lex.c (readescape): DEL isn't printable.
	* c-typeck.c (check_format): Likewise.

===================================================================
RCS file: c-lex.c,v
retrieving revision 2.2.2.3
diff -c -r2.2.2.3 c-lex.c
*** c-lex.c	1992/08/27 01:15:00	2.2.2.3
--- c-lex.c	1992/08/27 01:32:11
***************
*** 852,858 ****
  	pedwarn ("non-ANSI escape sequence `\\%c'", c);
        return c;
      }
!   if (c >= 040 && c <= 0177)
      pedwarn ("unknown escape sequence `\\%c'", c);
    else
      pedwarn ("unknown escape sequence: `\\' followed by char code 0x%x", c);
--- 852,858 ----
  	pedwarn ("non-ANSI escape sequence `\\%c'", c);
        return c;
      }
!   if (c >= 040 && c < 0177)
      pedwarn ("unknown escape sequence `\\%c'", c);
    else
      pedwarn ("unknown escape sequence: `\\' followed by char code 0x%x", c);
===================================================================
RCS file: c-typeck.c,v
retrieving revision 2.2.2.5
diff -c -r2.2.2.5 c-typeck.c
*** c-typeck.c	1992/08/12 01:23:10	2.2.2.5
--- c-typeck.c	1992/08/27 01:32:11
***************
*** 1627,1633 ****
  	}
        if (fci->format_chars == 0)
  	{
! 	  if (format_char >= 040 && format_char <= 0177)
  	    sprintf (message,
  		     "unknown conversion type character `%c' in format",
  		     format_char);
--- 1627,1633 ----
  	}
        if (fci->format_chars == 0)
  	{
! 	  if (format_char >= 040 && format_char < 0177)
  	    sprintf (message,
  		     "unknown conversion type character `%c' in format",
  		     format_char);
===================================================================
RCS file: cp-lex.c,v
retrieving revision 2.2.2.2
diff -c -r2.2.2.2 cp-lex.c
*** cp-lex.c	1992/07/24 18:55:24	2.2.2.2
--- cp-lex.c	1992/08/27 01:32:11
***************
*** 2235,2241 ****
      case '[':
        return c;
      }
!   if (c >= 040 && c <= 0177)
      warning ("unknown escape sequence `\\%c'", c);
    else
      warning ("unknown escape sequence: `\\' followed by char code 0x%x", c);
--- 2235,2241 ----
      case '[':
        return c;
      }
!   if (c >= 040 && c < 0177)
      warning ("unknown escape sequence `\\%c'", c);
    else
      warning ("unknown escape sequence: `\\' followed by char code 0x%x", c);

Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Subject: GCC 2.2.2's print-tree.c contains overflow in constant expression
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 1 Sep 1992 02:45:22 GMT

GCC 2.2.2's print-tree.c contains an expression of the form
`1 << (HOST_BITS_PER_INT - 1)', which contains an arithmetic overflow,
and thus runs afoul of compilers that check for integer overflow in
expressions.

The expression in question is used merely to turn off the top bit of a
numerator to avoid problems with taking remainders of negative numbers;
a simple fix is to use unsigned remainder instead.  Here is a patch.
Another fix would be to replace `1 << (HOST_BITS_PER_INT - 1)' with
`(unsigned) 1 << (HOST_BITS_PER_INT - 1)'.

Mon Aug 31 20:09:29 1992  Paul Eggert  (eggert@twinsun.com)

	* print-tree.c (print_node): Avoid 1 << (HOST_BITS_PER_INT - 1),
	which overflows.

===================================================================
RCS file: print-tree.c,v
retrieving revision 2.2
diff -c -r2.2 print-tree.c
*** print-tree.c	1992/04/27 16:54:16	2.2
--- print-tree.c	1992/08/31 20:09:29
***************
*** 193,199 ****
        return;
      }
  
!   hash = ((int) node & ~(1 << (HOST_BITS_PER_INT - 1))) % HASH_SIZE;
  
    /* If node is in the table, just mention its address.  */
    for (b = table[hash]; b; b = b->next)
--- 193,199 ----
        return;
      }
  
!   hash = (unsigned) node % HASH_SIZE;
  
    /* If node is in the table, just mention its address.  */
    for (b = table[hash]; b; b = b->next)

Newsgroups: gnu.gcc.bug
From: mattes@azu.informatik.uni-stuttgart.de (Eberhard Mattes)
Subject: Abnormal program termination (packed bit field)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 25 Aug 1992 20:49:30 GMT

This happened with GCC 2.2.2 for 80386, with #pragma pack of i386v4.h.

gcc -c bug.c
Abnormal program termination
core dumped

------------------------------- cut here -------------------------------------
#pragma pack(1)

struct
{
  unsigned short field1 : 5;
  unsigned short field2 : 6;
} var1;

void fun1 (void)
{
  var1.field2 = 1;
}
------------------------------- cut here -------------------------------------

Eberhard Mattes (mattes@azu.informatik.uni-stuttgart.de)

Newsgroups: gnu.gcc.bug
From: mrs@cygnus.com (Mike Stump)
Subject: WRONG LIST (was: Re:  gcc bug)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 29 Aug 1992 12:55:06 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.

> Message-Id: <9208171418.AA15781@life.ai.mit.edu>
> To: bug-gcc@prep.ai.mit.edu
> Cc: spb@ai.mit.edu
> Date: Mon, 17 Aug 92 15:18:47 +0100
> From: spb@mahler.clh.icnet.uk

> I have managed to generate an internal
> compiler error # 62 when compiling the following
> source files. Could you help, please?


> make xlims
> /usr/local/bin/gcc -I. -I/home/mahler.clh.icnet.uk/oracle6/c/lib -O
> -Wall -DOPENLOOK -c specialist.cc

Newsgroups: gnu.gcc.bug
From: terry@wag.caltech.edu (Terry R. Coley)
Subject: possible bug in gcc/g++
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 25 Aug 1992 10:33:29 GMT

The following code complains of too many initializers in aggregate
initialization under g++/gcc and not on other systems (Silicon
Graphics, Turbo C++).  Removing the union allows the initialization
to succeed.

I scanned the GCC info under emacs on the system where the software is
installed and did not see this mentioned.  The output from g++ -v bug.cc
is:

Reading specs from /usr/local/lib/gcc-lib/sun4-sunos4/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sun4-sunos4/2.2.2/cpp -lang-c++ -v -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__unix__ -D__sparc -D__sun -D__unix bug.cc /usr/tmp/cca05009.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sun4-sunos4/2.2.2/cc1plus /usr/tmp/cca05009.i -quiet -dumpbase bug.cc -version -o /usr/tmp/cca05009.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
bug.cc:19: warning: excess elements in aggregate initializer
bug.cc:19: warning: excess elements in aggregate initializer
bug.cc:19: warning: excess elements in aggregate initializer
bug.cc:19: warning: excess elements in aggregate initializer
bug.cc:19: warning: excess elements in aggregate initializer
 /usr/local/lib/gcc-lib/sun4-sunos4/2.2.2/as -o bug.o /usr/tmp/cca05009.s
 /usr/local/lib/gcc-lib/sun4-sunos4/2.2.2/ld -e start -dc -dp /lib/crt0.o -L/usr/local/lib/gcc-lib/sun4-sunos4/2.2.2 -L/usr/local/lib bug.o -lg++ -lgcc -lc -lgcc

Source:

// exproper.c++

typedef enum { BADBINOP = 0, PLUS, MINUS, MULT, DIV, POWR } binoptype;
typedef enum { BADUNOP = 0, NEG = POWR+1, SIN, COS, TAN } unoptype;

typedef struct {
  char *s;
  union {
    binoptype bop;
    unoptype uop;
  };
}
op_to_charp;

op_to_charp BINOPS[] = { {"+", PLUS},
			 {"-", MINUS},
			 {"*", MULT},
			 {"/", DIV},
			 {"^", POWR} };

main() {
  int dummy;
}

	- Terry
terry@wag.caltech.edu 818-397-2724 818-585-0918 (FAX)
Terry Coley, Caltech 139-74, Pasadena, CA  91125

Newsgroups: gnu.gcc.bug
From: samborn@lynchpin.mtkgc.COM (Kevin Samborn)
Subject: Re:  Using g++2.1 with standard C library on SunOS 4.1.1 Rev B.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 31 Aug 1992 14:23:16 GMT

/\/\ On Sat, 29 Aug 92 06:32:59 PDT, Mike Stump said:

   Mike> You might want to use the header files from libg++, as these
   Mike> problems will not arise then.

How do I do this?  The headers that are causing me the problems are
(right now) the headers malloc.h and stdlib.h.  Both of these are
included from X Window header files.

What I would really like to do, is turn off builtin functions, and the
builtin function prototypes.

> I am trying to use g++2.1 on SunOS 4.1.1 Rev B.

> Whenever I include standard include files, (in this case coming from
> /usr/lang/SC1.0/CC/include), I get the errors similar to the
> following:

> In file included from /usr/lang/SC1.0/include/CC/malloc.h:9,
>                  from /usr/lang/SC1.0/include/CC/stdlib.h:21,
>                  from Main.C:1:
> /usr/lang/SC1.0/include/CC/alloca.h:10:
>         declaration of `char * __builtin_alloca (int)'
> <built-in>:0: conflicts with built-in
> declaration `void * __builtin_alloca (int)'
> In file included from /usr/openwin3/include/X11/Xos.h:69,
>                  from /usr/openwin3/include/X11/Intrinsic.h:37,
>                  from Main.C:2:
> /usr/lang/SC1.0/include/CC/strings.h:22:
>         declaration of `unsigned int  strlen (const char *)'
> <built-in>:0: conflicts with built-in
>         declaration `int  strlen (const char *)'

> This happens even when I pass the -fno-builtin option to g++.

> Is there anyway to turn off type checking for builtin functions?

--
kevin samborn
Sakura Global Capital
samborn@mtkgc.com

Newsgroups: gnu.gcc.bug