HDTenEightyP/NetNews huggingface dataset:
From: marshall@software.org (Eric Marshall)
Subject: complete bug report for "trouble linking Objective C files"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 16 Dec 1992 13:42:00 GMT

	>    To enable someone to investigate the bug, you should include all
	> these things:
	> 
	>    * The version of GNU CC.  You can get this by running it with the
	>      `-v' option.

	2.3.2

	>      Without this, we won't know whether there is any point in looking
	>      for the bug in the current version of GNU CC.
	> 
	>    * A complete input file that will reproduce the bug.  If the bug is
	>      in the C preprocessor, send a source file and any header files
	>      that it requires.  If the bug is in the compiler proper (`cc1'),
	>      run your source file through the C preprocessor by doing `gcc -E
	>      SOURCEFILE > OUTFILE', then include the contents of OUTFILE in the
	>      bug report.  (When you do this, use the same `-I', `-D' or `-U'
	>      options that you used in actual compilation.)

	m.m contains:

		main(){}

	>    * The command arguments you gave GNU CC or GNU C++ to compile that
	>      example and observe the bug.  For example, did you use `-O'?  To
	>      guarantee you won't omit something important, list all the options.

	-lobjc

	>    * The type of machine you are using, and the operating system name
	>      and version number.

	SPARCStation 1 running SunOS 4.1.1

	>    * The operands you gave to the `configure' command when you installed
	>      the compiler.

	--target=sparc-sun-sunos4.1

	>    * A complete list of any modifications you have made to the compiler
	>      source.  (We don't promise to investigate the bug unless it
	>      happens in an unmodified compiler.  But if you've made
	>      modifications and don't tell us, then you are sending us on a wild
	>      goose chase.)

	None.

	>    * Details of any other deviations from the standard procedure for
	>      installing GNU CC.

	None.

	>    * A description of what behavior you observe that you believe is
	>      incorrect.  For example, "The compiler gets a fatal signal," or,
	>      "The assembler instruction at line 208 in the output is incorrect."
	The compiler emits the following message and does not produce
an a.out file:

	m.m:0: storage size of `_OBJC_SELECTOR_REFERENCES' isn't known

Newsgroups: gnu.gcc.bug
From: TRANLE@intellicorp.com (Minh Tran-Le)
Subject: gcc-2.3.2: -Wshadow warnings ...
Reply-To: tranle@intellicorp.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 20:27:10 GMT

Why does gcc give me a shadow warning when compiling the xxx.c file
included at the end of this message ?

Thanks,
Minh Tran-Le.
---------------------------------------------------------------------------
Compile command used:

    267 mtranle@rigel> gcc2 -c -Wshadow -O xxx.c
    xxx.c:3: warning: declaration of `end' shadows global declaration

/* -- file xxx.c -- */
char **end;

int f1(int *start, int *end);

int f2()
{
	return 1;
}
/* -- end of file xxx.c -- */
-------

Newsgroups: gnu.gcc.bug
From: jason@jarthur.claremont.edu (Jason Merrill)
Subject: Patch for profiling output on Sequent Symmetry, 2.3.2
Organization: Minimal
Distribution: gnu
Date: Mon, 14 Dec 1992 21:26:07 GMT

The local label syntax was changed a few versions back to start with .L so
that the Sequent as would strip them, but the profiling output was not
changed at the same time, so the actual profiling labels get stripped and
the references are to labels which never existed anyway.  This patch fixes
that.

*** 1.0	1992/12/14 23:29:33
--- config/seq386.h	1992/12/14 23:29:46
***************
*** 76,82 ****
  
  #undef FUNCTION_PROFILER
  #define FUNCTION_PROFILER(FILE, LABELNO)  \
!    fprintf (FILE, "\tmovl $LP%d,%%eax\n\tcall mcount\n", (LABELNO));
  
  /* Assembler pseudo-op for shared data segment. */
  #define SHARED_SECTION_ASM_OP ".shdata"
--- 76,82 ----
  
  #undef FUNCTION_PROFILER
  #define FUNCTION_PROFILER(FILE, LABELNO)  \
!    fprintf (FILE, "\tmovl $.LP%d,%%eax\n\tcall mcount\n", (LABELNO));
  
  /* Assembler pseudo-op for shared data segment. */
  #define SHARED_SECTION_ASM_OP ".shdata"

--
Jason Merrill					jason@jarthur.claremont.edu

Newsgroups: gnu.gcc.bug
From: rcf@sioux.eel.ufl.edu (Robert Fellenz)
Subject: g++ not finding library libg++.a
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 16 Dec 1992 23:00:45 GMT

Architecture:  HP9000/425
Operating Sys: HP-UX 8.0
GNU CC vers.:  gcc-2.3.2


I currently have gcc and g++ compiled from gcc-2.3.2.  The gcc compiler
works fine but g++ is haveing some linking problems.  The following is an
example of what occurse:

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

	bash$ g++ intr.cc
	
	ld: cannot find library for -lg++
	ld: (Warning) did not generate an output file
	collect: /bin/ld returned 1 exit status

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

I would appreciate any help you can give me.

Thanks in advance...


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

Robert Fellenz
University of Florida
System Administrator

Newsgroups: gnu.gcc.bug
From: root@ibibel.glas.apc.ORG (Admin)
Subject: robotussin problem
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 13 Dec 1992 11:45:50 GMT

robotussin(Sep 1990 last entry in ChangeLog) 
groks on /lib/crtp1.o (ISC 3.0 (SoftDevSys 3.0): (stderr:)
robotussin: Oops! possible bug - reloc reference to ignored symbol
(on all xcrtxx1.o's things are same) 
	Best wishes,
	AGL


Newsgroups: gnu.gcc.bug
From: leisner@wrc.xerox.COM ( Marty Leisner)
Subject: Bug passing arguments in inline?
Reply-To: leisner@eso.mc.xerox.com
Organization: Xerox
Distribution: gnu
Date: Fri, 18 Dec 1992 16:54:15 GMT

I thing this is a bug.
I'm using gcc 2.3.2 on SunOS sparcs 4.1.2

This is my program:

static void inline test_args()
{
}

main()
{
        test_args(0);
        test_args();
        test_args(2);
}


This is my command line (although I think -finline-functions isn't necessary in this case)

It seems if an argument is passed, the function is called...(even though its empty).

I'm not fluent in sparc assembler -- the moves occur after the call?

This is the assembly output:
gcc2_compiled.:
text
	.align 4
	.global _main
	.proc	04
_main:
	!#PROLOGUE# 0
	save %sp,-136,%sp
	!#PROLOGUE# 1
	call ___main,0
	nop
	call _test_args,0
	mov 0,%o0
	call _test_args,0
	mov 2,%o0
	ret
	restore
	.align 4
	.proc	020
_test_args:
	!#PROLOGUE# 0
	save %sp,-112,%sp
	!#PROLOGUE# 1
	ret
	restore

--
marty
leisner.henr801c@xerox.com  leisner@eso.mc.xerox.com
Member of the League for Programming Freedom

Newsgroups: gnu.gcc.bug
From: apardon@vub.ac.BE (Antoon Pardon)
Subject: fixinclude problem on EP/IX machine
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 10:27:29 GMT

I have tried to install gcc 2.2.2 on a CDC machine running EP/IX 1.4.3
This is a mipsbox with some modifications to the O.S. Its a sysv-bsd
hybrid.

I used mips-sysv as the target for the configure command.

All seems to work well execpt for the following problems:

When doing the "make install-fixincludes" I messages like the ones below:
(The ones I include here for reference are all those tried to treat
string.h)

  ...

  Fixing ./bsd43/string.h
  Deleting /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./bsd43/string.h; no f

  ...

  Fixing ./bsd43/string.h
  Can't copy ./bsd43/string.h
  chmod: WARNING: can't access /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./
  ./fixincludes: /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./bsd43/des/sysv
  mv: /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./bsd43/des/sysv/./bsd43/st

  ...

  Fixing ./bsd43/string.h
  Can't copy ./bsd43/string.h
  chmod: WARNING: can't access /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./
  ./fixincludes: /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./bsd43/sysv/./b
  mv: /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./bsd43/sysv/./bsd43/string

  ...

  Fixing ./bsd43/string.h
  Can't copy ./bsd43/string.h
  chmod: WARNING: can't access /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./
  ./fixincludes: /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./posix/sysv/./b
  mv: /bfu/ltst/lib/gcc-lib/mips-sysv3/2.2.2/include/./posix/sysv/./bsd43/string

  ...

Note too that there is no mentioning of fixing ./string.h although that does exi
Which is probably the cause of the following warnings I almost always receive wh
compiling things:

          stage3/gcc -Bstage3/ -c    -g -O     -I. -I. -I./config cp-lex.c
  In file included from cp-lex.c:28:
  /sysv/usr/include/string.h:53: warning: conflicting types for built-in functio
  /sysv/usr/include/string.h:59: warning: conflicting types for built-in functio

Can someone tell me what I should do to repair these or at least give
me an idea where too look.

And now that I'am asking is the following something to worry about?

          ar qc libgcc1.null dummy.o
  ar: Warning:ignoring second definition of __foo defined in archive
  ar: Warning:ignoring second definition of __foo defined in archive
  ar: Warning:ignoring second definition of __foo defined in archive


========================================================================
Antoon Pardon                                    <apardon@is1.vub.ac.be>
Brussels Free University Computing Centre                   02/650.37.16
========================================================================
--
========================================================================
Antoon Pardon                                    <apardon@is1.vub.ac.be>
Brussels Free University Computing Centre                   02/650.37.16
========================================================================

Newsgroups: gnu.gcc.bug
From: clump@asparagus.cs.mcgill.ca (Clark VERBRUGGE)
Subject: MINDOUBLE in gcc
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 11 Dec 1992 09:48:12 GMT

I thought that MINDOUBLE was the smallest value a double
could hold. Yet when i compile the following program:

#include <values.h>

#include <math.h>

main()
{
        double d1,d2;

        d1 = MINDOUBLE;
        d2 = MAXDOUBLE;

        printf("Min=%lf\nMax=%lf\n",d1,d2);
}

I get a 'constant-out-of-range' warning for the
statement assigning MINDOUBLE to d1, and it prints
out "Min=0.000000".

Actually, cc does this as well (but it doesn't even acknowledge
that MINDOUBLE is out of range), so i'm not certain that
this is really a bug.

This is gcc version 1.37.1, running on a Sparc.

Clark Verbrugge
clump@cs.mcgill.ca

Newsgroups: gnu.gcc.bug
From: bjornw@colargol.edb.tih.no (Bjoern Wennberg)
Subject: Bug in gcc-2.3.2 and double (ISC)
Organization: Colargol, Trondheim College of Engineering
Distribution: gnu
Date: Mon, 14 Dec 1992 14:13:42 GMT

OS: Interactive-3.0 SYSVR3.2
COMPILER: gcc-2.3.2
DESCRIPTION OF BUG: gcc-2.3.2 doesn't handle doubles right:

Here is a small example which illustrates the problem:
input file: c.c

#include <stdio.h>
#include <float.h>
#include <math.h>

void main() { 
  double d = DBL_MAX;
  printf("%G\n", d);
}

gcc gives wrong output:
# gcc-v
Reading specs from /usr/local/lib/gcc-lib/i486-isc/2.3.2/specs
gcc version 2.3.2

# gcc c.c
# a.out
INF

Using the native c-compiler gives the correct output:
# cc c.c
# a.out
1.79769E+308


Strange is that compiling with gcc-2.2.2 gives this:
#/global/gnu/bin/gcc -v
Reading specs from /global/gnu/lib/gcc-lib/isc/2.2.2/specs
gcc version 2.2.2
#/global/gnu/bin/gcc c.c
#a.out
1.79769E+308

Can someone please fix this ?

bjornw>
--
bjornw@edb.tih.no     Bjoern Wennberg     Trondheim College of Engeneering

Newsgroups: gnu.gcc.bug
From: mattes@azu.informatik.uni-stuttgart.de (Eberhard Mattes)
Subject: PCC_BITFIELD_TYPE_MATTERS
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 19:00:15 GMT

If PCC_BITFIELD_TYPE_MATTERS is undefined or 0, the following program
prints 3 instead of 2 (GCC 2.3.1). Is this a bug or a feature? (I
don't fully understand the description of PCC_BITFIELD_TYPE_MATTERS.)

----------
#include <stdio.h>
#include <stddef.h>

#pragma pack(1)

struct demo
{
  struct
    {
      short field1:5;
      short field2:5;
      short field3:6;
    } bits;
  char next;
};

int main (void)
{
  printf ("%d\n", offsetof (struct demo, next));
  return 0;
}

----------

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

Newsgroups: gnu.gcc.bug
From: slhpv@cc.usu.edu
Subject: Re: syslimits.h non existant
Organization: Utah State University
Distribution: gnu
Date: Wed, 16 Dec 1992 23:40:15 GMT


In article <9212141459.AA29837@cuthbert.bashstreet>, dunstan@gec-epl.co.UK (Dunstan_Vavasour) writes:
>
> But my system does not have a syslimits.h file. Would the copy of
> syslimits.h in .../gcc-lib/sparc-sun-sunos4.1/2.3.2/include/syslimits.h 
> do instead ? Or did my make install-fixincludes not work right ?
> 
When I intalled gcc-2.3.2 on a hp730 running hpux I discovered that
I also am missing syslimits.h, on a hunch I checked for sys/limits.h
but it also does not exist.  Anyone know what I should be doing to
fix this?

-Dave

Newsgroups: gnu.gcc.bug
From: schwab@lamothe.informatik.uni-dortmund.de (Andreas Schwab)
Subject: GCC 2.3.2: Bug in combiner
Reply-To: schwab@ls5.informatik.uni-dortmund.de (Andreas Schwab)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 14 Dec 1992 11:47:25 GMT

GCC 2.3.2 (m68k, Atari TT) generates wrong code for this function:

-------------------- x.c
struct rect { short x, y, w, h; };

f (struct rect r)
{
  short x[4];
  x[0] = r.x;
  x[1] = r.y;
  x[2] = r.x + r.w - 1;
  x[3] = r.y + r.h - 1;
  g (x);
}
--------------------

when compiled with: gcc -S -O2 x.c

-------------------- x.s
#NO_APP
gcc2_compiled.:
.text
	.even
.globl _f
_f:
	link a6,#-8
	movel d2,sp@-
	movel a6@(8),d1
	movel a6@(12),d2
	bfexts d1{#0:#16},d0
	movew d0,a6@(-8)
	movew d1,a6@(-6)
	addw d2,d0		| <-- d2 should be upper half of d2
	subqw #1,d0
	movew d0,a6@(-4)
	addw d2,d1
	subqw #1,d1
	movew d1,a6@(-2)
	pea a6@(-8)
	jbsr _g
	movel a6@(-12),d2
	unlk a6
	rts
--------------------

I guess that the bug is in combine.c:num_sign_bit_copies near line 6454:

--------------------
  /* If we haven't been able to figure it out by one of the above rules,
     see if some of the high-order bits are known to be zero.  If so,
     count those bits and return one less than that amount.  If we can't
     safely compute the mask for this mode, always return BITWIDTH.  */

  if (bitwidth > HOST_BITS_PER_WIDE_INT)
    return bitwidth;
--------------------

This seems wrong. If the number of sign bit copies cannot be computed,
the value for the worst case should be returned, which is 1.
If this is changed, the above example compiles correctly.
--
Andreas Schwab
schwab@ls5.informatik.uni-dortmund.de

Newsgroups: gnu.gcc.bug
From: jorgnsn@qucis.queensu.ca (John Jorgensen)
Subject: Minor installation bug: fixincludes omits syslimits.h on SunOs 4.1.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 17 Dec 1992 17:53:21 GMT

VERSION OF GNU CC: 

	2.3.2


COMPLETE INPUT FILE THAT TRIGGERS THE PROBLEM:

# This is a shell archive.  Remove anything before this line,
# then unpack it by saving it in a file and typing "sh file".
#
# Wrapped by buffoon! on Thu Dec 17 12:35:07 EST 1992
# Contents:  limittest.c
 
echo x - limittest.c
sed 's/^@//' > "limittest.c" <<'@//E*O*F limittest.c//'
#include <limits.h>
@//E*O*F limittest.c//
chmod u=rw,g=r,o=r limittest.c
 
exit 0


COMMAND TO COMPILE THE FILE AND OBSERVE THE BUG:

	gcc -c limittest.c


TYPE OF MACHINE AND OPERATING SYSTEM:

	Sun3 running SunOS 4.1.1
	Sun4 running SunOS 4.1.2


CONFIGURE OPERANDS:

	configure m68k-sun-sunos4.1	# for the sun3
	configure sparc-sun-sunos4.1	# for the sun4

LOCAL MODIFICATIONS TO COMPILER SOURCE:

	none


DESCRIPTION OF INCORRECT BEHAVIOUR:

	Any file that includes <limit.h> produces the following error:

% gcc -c limittest.c
In file included from limittest.c:1:
/usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.3.2/include/limits.h:11:  syslimits.h: No such file or directory


UNEDUCATED GUESS ABOUT THE CAUSE:

	I think the problem is that in the Makefile, syslimits.h
	is not included in the definition of INSTALLED_H, so that
	it is not moved into $(libsubdir)/tmp before all the
	existing files in $(libsubdir)/include are removed.  As a
	result, if fixincludes doesn't need to fix the system
	limits.h, you get left with no syslimits.h file.

	At any rate, when I copied gsyslimits.h from the source
	directory into $(libsubdir)/include, the problem went
	away. 

Newsgroups: gnu.gcc.bug
From: etxmesa@eos.ericsson.SE (Michael Salmon)
Subject: Re: syslimits.h non existant on sunos4.N
Reply-To: etxmesa@eos.ericsson.se (Michael Salmon)
Organization: Ericsson Telecom AB
Distribution: gnu
Date: Tue, 15 Dec 1992 10:34:26 GMT

In article <9212141459.AA29837@cuthbert.bashstreet>, dunstan@gec-epl.co.UK (Dunstan_Vavasour) writes:
|> I have recently made gcc-2.3.2. I then proceeded to make glibc-1.05.
|> 
|> I am using a spaarcstation IPC running SunOS 4.1.1 Rev B.
|> 
|> A have had recurrent error messages about syslimits.h not being found.
|> 
|> On investigation, the copy of .../gcc-lib/sparc-sun-sunos4.1/2.3.2/include/limits.h
|> contains the lines:
|> 
|> ----8<--snip--snip-------------------------------------------------------------
|> 
|> 
|> /* This administrivia gets added to the beginning of limits.h
|>    if the system has its own version of limits.h.  */
|> 
|> /* We use _GCC_LIMITS_H_ because we want this not to match
|>    any macros that the system's limits.h uses for its own purposes.  */
|> #ifndef _GCC_LIMITS_H_  /* Terminated in limity.h.  */
|> #define _GCC_LIMITS_H_
|> 
|> #ifndef _LIBC_LIMITS_H_
|> /* Use <...> so that we find syslimits.h only in system include dirs.  */
|> #include <syslimits.h>
|> #endif
|> 
|> ----8<--snip--snip-------------------------------------------------------------

You do however have sys/limits.h.

-- 

Michael Salmon

#include	<standard.disclaimer>
#include	<witty.saying>
#include	<fancy.pseudo.graphics>

Ericsson Telecom AB
Stockholm

Newsgroups: gnu.gcc.bug
From: jivano@samser.gold.SUb.ORG (Swami Sangit Jivano)
Subject: Configuring gcc 2.3.1 on sco3.2v4 gives sco3.2v2 (errounously)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 22:00:36 GMT

When you configure the gcc 2.3.1 for sco version 3.2v4, e.g. with the call:

	configure --target=i386-*-sco3.2v4*

the sub-script 'config.sub' returns "i386-unknown-sco3.2v2" (instead of ...v4)
and configure is unable to differ between the older version "...3.2v2" and
the newer one "...3.2v4" - allthough the 'configure' script would like to
treat these versions differently.

Presumably 'config.sub' should be expanded like this:


	--- 1.1	1992/12/11 09:38:53
	+++ config.sub	1992/12/15 09:17:41
	@@ -66,6 +66,10 @@
			os=
			basic_machine=$1
			;;
	+	-sco3.2v4*)
	+		os=-sco3.2v4
	+		basic_machine=i386-unknown
	+		;;
		-sco*)
			os=-sco3.2v2
			basic_machine=i386-unknown

Newsgroups: gnu.gcc.bug
From: juando@cnm.US.ES (Juan Domingo Martin Gomez)
Subject: Temporaries destroyed too soon
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 18 Dec 1992 21:14:45 GMT

Here is the description of the bug.
Please reply by e-mail as I don't have access to news.

GCC VERSION:
    gcc version 2.3.2

LANGUAGE:
    C++

SAMPLE INPUT FILE:

-----------------------------------------------------------------------
#include <iostream.h>

class Foo
{
public:
    Foo();
    ~Foo();

    Foo &method();
};

Foo f1()
{
    return Foo();
}

Foo::Foo()
{
    cout << "Foo created" << endl;
}

Foo::~Foo()
{
    cout << "Foo destroyed" << endl;
}

Foo &Foo::method()
{
    cout << "Method called for Foo " << endl;
    return *this;
}

main()
{
    // f1() returns a temporary object. The member function
    // method() returns a reference to the same object.
    f1().method().method();
}
-----------------------------------------------------------------------


COMMAND LINE:
    gcc -o foo foo.cc

PLATFORM:
    Sun SparcStation IPX (sun4c) running SunOS 4.1.3

CONFIGURATION OF GCC:
    -sparc-sun-sunos4.1

DESCRIPTION:

If you compile and run the example you will observe that the temporary
object (Foo) returned by f1() is destroyed *before* the method is called
for second time in the statement. In some other tests I have done it
happens the same: temporaries are destroyed just after they are referenced
for the first time. However it is possible (and legal, I think) to reference
a temporary more than once in a single statement. I think destructors for
temporaries should be called after the statement has finished its execution.

-- 
Juan D. Martin                     Centro Nacional de Microelectronica
<juando@cnm.us.es>                                   Edificio C.I.C.A.
Phone: 34-5-4623811                             Av/ Reina Mercedes s/n
Fax:   34-5-4624506                               41012-SEVILLA, SPAIN


Newsgroups: gnu.gcc.bug
From: jivano@samser.gold.SUb.ORG (Swami Sangit Jivano)
Subject: Floating point problems with SCI international supplement.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 15 Dec 1992 23:02:11 GMT

PROBLEM:

We encountered floating point problems when we tried to compile the gcc
version 2.3.1 in a German language environment. 'rcc' as well as 'gcc'
generated wrong floating point constants into C-programs compiled
in environments using the (German) decimal comma instead of the (English)
decimal point.

One of the symptoms is, that the initial compiler generation will
hang up in the stage1 test of the floating point min and max values
(./enquire will loop).

The problem is exemplified with the following little test program:

	#include <stdio.h>
	int main()
	{  float a = 10.0;
	   printf("a=%f a/10=%f\n",a,a/10.0);
	}

which should output "10.000 and 1.000" but with one compiler outputs
"1.000 1.000" and with the other "10.000 10.000".


WHAT I THINK HAD HAPPENED:

Floating point literals in the program got not generated correctly -
sometimes (depending on the source-context) 1.0 was generated instead
of the given values.

The cause of this is the usage of 'strtod()' within the compilers
rcc and gcc to convert the external floating point literals to their
internal reperesentation. And this routine (as well as any routines relying
on it - like 'scanf()' etc.) is dependent on the actual decimal point
at run-time. 


MY TEMP FIX:

To circumvent the problem, specify English during compilations, like

	export LANG=english_us.8859

instead of (eg.)

	export LANG=german_germany.8859

A final solution will probably be available with the GNU runtime
library, I think. (And then just don't use the compiler switch
'-scointl' when compiling the gcc itself).


REMARKS:

If you happen to know, whether and when I can get the latest GNU
runtime libs for SCO 3.2v4, please do me a favour and send me a message.

Newsgroups: gnu.gcc.bug
From: sbb@laplace.eng.SUn.COM (Steve Byrne)
Subject: Re: Objective-C gcc bug?
Organization: FSF hackers, Smalltalk division
Distribution: gnu
Date: Tue, 15 Dec 1992 13:46:19 GMT

[Problem description about _OBJC_SELECTOR_REFERENCES]

I too ran into this problem.  I think it's a bug.  What does make
it work is doing a message send somewhere in one of the methods.  I don't know 
whether it has to be an instance method, or whether class methods will
do, but just doing a single method invocation seems to do the trick.  Using
this, I have been able to get Objective C programes to compile and execute
properly.

Steve


PS: Don't forget to put -lobjc on the link line :-)


Newsgroups: gnu.gcc.bug