HDTenEightyP/NetNews huggingface dataset:
From: TRANLE@intellicorp.com (Minh Tran-Le)
Subject: gcc-2.3.3: config/hp320.h line 361 has a trailing whitespace.
Reply-To: tranle@intellicorp.com
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 27 Dec 1992 18:06:26 GMT

In the config file config/hp320.h there is a trailing whitespace after
the '\' character at line 361.

Thanks,
Minh Tran-Le.

---------------------------------------------------------------------------
*** hp320.h.~1~	Tue Dec  8 07:33:07 1992
--- hp320.h	Sun Dec 27 09:59:23 1992
***************
*** 358,362 ****
      union { double d; int i[2]; } dummy_u;			\
      dummy_u.d = (VALUE);					\
!     asm_fprintf (FILE, "%I0x%x%08x", dummy_u.i[0], dummy_u.i[1]); \ 
    } while (0)
  
--- 358,362 ----
      union { double d; int i[2]; } dummy_u;			\
      dummy_u.d = (VALUE);					\
!     asm_fprintf (FILE, "%I0x%x%08x", dummy_u.i[0], dummy_u.i[1]); \
    } while (0)
  
-------


Newsgroups: gnu.gcc.bug
From: eks@daimi.aau.dk (Eigil Krogh S|rensen)
Subject: Re: GCC-2.3.2 - problem with limits.h
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark
Distribution: gnu
Date: Tue, 22 Dec 1992 17:20:01 GMT

gml4410@ggr.co.UK (Lack Mr G M) writes:

>Problem:
>          The building procedure all went Ok.  The problem was seen when
>building libg++-2.3.  This build fails in String.cc  when  it  #includes
>the  file  <limits.h>.   The  gcc-lib  version  of  limits.h attempts to
>include the file <syslimits.h>, however, no such file has been installed
>(it is supposed to be a copy of the gsyslimits.h file if needed). 

Just a short comment:
On a Motorola systemV68 R3, 68030(mvme147) based I had the same "problem"
with gcc-2.3.2.

make fix-includes for gcc-2.3.1 makes it right so I could see in the .h
files from that how limits.h should be.

  - Eigil


Newsgroups: gnu.gcc.bug
From: I.G.Batten@fulcrum.co.UK (Ian G Batten, Ian G Batten)
Subject: Emacs with GCC 2.3.3
Organization: Fulcrum Communications
Distribution: gnu
Date: Thu, 31 Dec 1992 11:08:13 GMT

My previous message is in error.  The mistake was that I had not run the
fixincludes script.  Interestingly, emacs compile correctly without
fixincludes having been run but does not execute correctly.

ian

Newsgroups: gnu.gcc.bug
From: ruud@zuma.AUdacter.NL (Ruud Cox)
Newsgroups: gnu.gcc.bug
Subject: Problems with pointer to pointer to void (type[Pparameter passing)
Date: 24 Dec 92 21:09:03 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Hai,

When we were porting our C libraries to GNU C, we encountered the following
problem:

GCC VERSION:      GNU C 3.2.1
MACHINETYPE:      Sun Sparc station IPX (sun4c)
OS VERSION:       sunos 4.1.3
CONFIGURATION:    sparc-sun-sunos4.3.1
CHANGES TO GCC:   none

COMMANDLINE ARGUMENTS: gcc -c tgcc.c

When compiling undermentioned program GNU C produces the following Warning:

tgcc: In function 'main':
tgcc[A.c: In function 'main':[B[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D.c:10: warning: passing arg 1 of 'test_voidpp' from incompatible pointer type

To my knowledge this is wrong. A cast from pointer to pointer to int is
compatible with a pointer to a pointer to a void.

We could change void ** to void *, but then we can pass 'intp' without '&' to
the funtion without the compiler giving sn error.
----------------------------------------------------------------------------
[A[C[A[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[Ca[B[B[H[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[Btest_voidpp(void **pp)
{
}

main()
{
    int *intp;

    test_voidpp(&intp);
}
-----------------------------------------------------------------[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D
[A                       [B[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[D[Dtest_voidpp(void **pp)[B[H[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B{
}
      [B[D[D[D[D[D[Dmain()
{
[A[C[C[C[C          [B[D[D[D[D[D[D[D[D[D[Dint *intp;
                       [B[H[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B[B    test_voidpp(&intp);
                                                                  [C[C[C[C[C[C[C[C[C[C[C[C[C[C[C[A[C}
----------------------------------------------------------------------------

Ruud Cox
st. Leonardusstraat 10B[D B
5614 EH Eindhoven
Netherlands
e-mail: ruud@zuma.audacter.nl
From: nils@pc2.pc.maricopa.edu (Nils McCarthy)
Newsgroups: gnu.gcc.bug
Subject: undeclared member functions in templates
Date: 28 Dec 92 05:54:39 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Under gcc2.3.3, mips-dec-ultrix4.2, the following code gives a
rather cryptic error message. i certainly didn't know i had
a member function named __vc.

template<class T> class foo {
};

template<class T> void foo<T>::operator []()
{
}

int main()
{
  foo<int> bar;
  return 0;
}

make testing
gcc -x c++ -v -g -Wall -I/u/hopper/local/include    testing.cc   -o testing
Reading specs from /usr/local/lib/gcc-lib/mips-dec-ultrix4.2/2.3.3/specs
gcc version 2.3.3
 /usr/local/lib/gcc-lib/mips-dec-ultrix4.2/2.3.3/cpp -lang-c++ -v -I/u/hopper/local/include -undef -D__GNUC__=2 -D__GNUG__=2 -D__cplusplus -D__ANSI_COMPAT -DMIPSEL -DR3000 -DSYSTYPE_BSD -D_SYSTYPE_BSD -Dbsd4_2 -Dhost_mips -Dmips -Dultrix -Dunix -D__ANSI_COMPAT -D__MIPSEL__ -D__R3000__ -D__SYSTYPE_BSD__ -D___SYSTYPE_BSD__ -D__bsd4_2__ -D__host_mips__ -D__mips__ -D__ultrix__ -D__unix__ -D__ANSI_COMPAT -D__MIPSEL -D__R3000 -D__SYSTYPE_BSD -D___SYSTYPE_BSD -D__bsd4_2 -D__host_mips -D__mips -D__ultrix -D__unix 

-g -Wall -D__LANGUAGE_C_PLUS_PLUS__ -D__LANGUAGE_C_PLUS_PLUS -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C testing.cc /usr/tmp/cca12299.i
GNU CPP version 2.3.3 [AL 1.1, MM 33] DECstation running ultrix
 /usr/local/lib/gcc-lib/mips-dec-ultrix4.2/2.3.3/cc1plus /usr/tmp/cca12299.i -quiet -dumpbase testing.cc -g -Wall -version -o /usr/tmp/cca12299.s
GNU C++ version 2.3.3 [AL 1.1, MM 33] DECstation running ultrix compiled by GNU C version 2.3.3.
testing.cc: In function `int  main ()':
testing.cc:2: method `__vc' not found in class `foo<int>'
testing.cc:2: warning: unused variable `bar'
make: *** [testing] Error 1

Compilation exited abnormally with code 1 at Mon Dec 28 12:51:02

-nils
Newsgroups: gnu.gcc.bug
From: gml4410@ggr.co.UK (Lack Mr G M)
Subject: GCC-2.3.2 - problem with limits.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 21 Dec 1992 16:20:44 GMT

Platform:
          Sun SPARCStation IPC running SunOS 4.1.1
          
configure options:
          --target=sparc-sun-sunos4.1

other info:
          make install-fixincludes *was* done


Problem:
          The building procedure all went Ok.  The problem was seen when
building libg++-2.3.  This build fails in String.cc  when  it  #includes
the  file  <limits.h>.   The  gcc-lib  version  of  limits.h attempts to
include the file <syslimits.h>, however, no such file has been installed
(it is supposed to be a copy of the gsyslimits.h file if needed). 



     NOTE:  EXACTLY the same problem occurs for the following setup:


Platform:
          SG Indigo running Irix 4.0.1     

configure options:
          --target=mips-sgi-irix4

other info:
          make install-fixincludes *was* done



-------------------------- Gordon Lack ----------------------------------
The contents of this message *may* reflect my personal opinion.  They are
*not* intended to reflect those of my employer, or anyone else.

Newsgroups: gnu.gcc.bug
From: bitbug@netcom.com (James Buster)
Subject: bug in libgcc2.c from gcc 2.3.3
Organization: Lynx Real-Time Systems, Inc.
Distribution: gnu
Date: Tue, 29 Dec 1992 21:39:31 GMT

In libgcc2.c, you have the line

	typedef float DFtype __attribute__ ((mode (DF)));

Shouldn't this be `double' rather than `float'?

I get errors from gcc 1.42 complaining about the prototype and declaration
of __fixunsdfdi not matching because float formal parameters of
K&R style function declarations are promoted to double but the prototype's
parameter is not promoted.
-- 
				James Buster
			     bitbug@netcom.com

Newsgroups: gnu.gcc.bug
From: flower@donald.etdesg.trw.com (Rick Flower)
Subject: Re: GCC-2.3.2 - problem with limits.h
Organization: TRW Inc., Redondo Beach, CA
Distribution: gnu
Date: Tue, 22 Dec 1992 20:53:55 GMT

In article <9212211620.AA00738@uk0x06.ggr.co.uk> gml4410@ggr.co.UK (Lack Mr G M) writes:
>Platform:
>          Sun SPARCStation IPC running SunOS 4.1.1
>          
>configure options:
>          --target=sparc-sun-sunos4.1
>
>other info:
>          make install-fixincludes *was* done
>
>
>Problem:
>          The building procedure all went Ok.  The problem was seen when
>building libg++-2.3.  This build fails in String.cc  when  it  #includes
>the  file  <limits.h>.   The  gcc-lib  version  of  limits.h attempts to
>include the file <syslimits.h>, however, no such file has been installed
>(it is supposed to be a copy of the gsyslimits.h file if needed). 
>
>
	You can also add the following setup for this problem :

Platform:
	Sun 3/60 running SunOS 4.1.1

Configure options:
          --target=m68k-sun-sunos4.1

Other info:
          make install-fixincludes done
-- 
+---------------------+-------------------------------------------------------+
|      Available      | Internet Addr: flower@donald.etdesg.TRW.COM or        |
|      for Lease      |                rickf@theweav.cts.com                  |
+---------------------+-------------------------------------------------------+


Newsgroups: gnu.gcc.bug
From: haible@ma2s2.mathematik.uni-karlsruhe.de (Bruno Haible)
Subject: long longs on i386 crash gcc
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 20 Dec 1992 23:46:11 GMT

gcc aborts (cc1 gets signal 6) when called on the following file.
I'm working with gcc 2.2.2, configured as i386-linux.
"gcc -S -g llbug3.i" is the command I used.

================= llbug3.i ===================================================
      typedef char         BYTE;
    typedef unsigned char  UBYTE;
    typedef short          WORD;
    typedef unsigned short UWORD;
    typedef long           LONG;
    typedef unsigned long  ULONG;
    typedef long long           LONGLONG;
    typedef unsigned long long  ULONGLONG;
  typedef unsigned int  boolean;
  typedef signed int  signean;
  typedef UBYTE   uint8;    
  typedef BYTE    sint8;    
  typedef UWORD   uint16;   
  typedef WORD    sint16;   
  typedef ULONG   uint32;   
  typedef LONG    sint32;   
  typedef ULONGLONG  uint64;   
  typedef LONGLONG   sint64;   
    typedef   sint8        sintB;
    typedef   uint8      uintB;
    typedef   sint16        sintW;
    typedef   uint16      uintW;
    typedef   sint32        sintL;
    typedef   uint32      uintL;
  typedef  uint64  oint;
  typedef  oint  object;
    typedef   uint32      tint;
    typedef   uint32      aint;
typedef struct { union { object _GCself; uintB flags[4]; } header;  }
        varobject_;
typedef varobject_ *  Varobject;
typedef struct { union { object _GCself; uintB flags[4]; } header; 
                 object symvalue;     
                 object symfunction;  
                 object proplist;     
                 object pname;        
                 object homepackage;  
               }
        symbol_;
typedef symbol_ *  Symbol;
typedef struct { union { object _GCself; uintB flags[4]; } header;   
                 uintL  length;    
                 uint8  data[0 ];  
               }
        sbvector_;
typedef sbvector_ *  Sbvector;
    typedef void Values;
    extern object* STACK;
  extern struct symbol_tab_ {
 symbol_ S_nil; 
 symbol_ S_t; 
                            }
         symbol_tab_data;
  extern object I_minus1_plus_I (object x);
typedef boolean (*up_function) (object* stackptr, object x);
static  void seq_filterop_help1(stackptr,up_fun,bvl)
  object* stackptr;
  up_function up_fun;
  uintL bvl;
{ uintL dl = 0;
 {uintL bvi = bvl;
  while(!(bvi==0)) 
    { bvi--;
     {(((Sbvector)((void*)(aint)(STACK[-1-(0+2)]) ))
                  ->data[(uintL)(bvi)/8]
                  |=  (1LL<<((~(uintL)(bvi)) % 8))  ) ;
      dl++;
      if (!( ( (( (STACK[-1-(1+4+2)]) ) ==
               ((((object)(((oint)(tint)(0x20)<<32) + 
            ((oint)(aint)(&symbol_tab_data.S_nil)<<0)))))))))
        { ((STACK[-1-(0)])) = I_minus1_plus_I((STACK[-1-(0)])); }
     }
}}  }
=============================================================================
Changing the "1LL" into "1L" makes things work OK.

Bruno Haible
haible@ma2s2.mathematik.uni-karlsruhe.de

Newsgroups: gnu.gcc.bug
From: ado@elsie.nci.nih.gov (Arthur David Olson)
Subject: Gnu GCC 2.3.2 dumps core on some invalid "asm" directives.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 26 Dec 1992 17:42:30 GMT

(We're running SunOS 4.1.1 on a Sun 4/75 and a Sun 3/280.)

Description:
	Gnu GCC 2.3.2 dumps core on some invalid "asm" directives.

Repeat-By:
	The core dump occurs for the "fails.c" file on both Sun3's and Sun4's;
	here are details for the Sun4:

Script started on Sat Dec 26 12:40:08 1992
bossie$ cat fails.c
f() { asm("oops %0" : "=o" (0)); }
bossie$ dbx cc1
Reading symbolic information...
Read 81441 symbols
(dbx) stop in abort
(2) stop in abort
(dbx) run -version fails.c -o fails.o
Running: cc1 -version fails.c -o fails.o 
GNU C version 2.3.2 (sparc) compiled by CC.
enabled: -fdefer-pop -fpeephole -ffunction-cse -fcommon -mfpu -mepilogue
	
 fstopped in abort at 0xf7774310
abort:	save   	%sp, -96, %sp
Current function is push_reload
  694       abort ();
(dbx) where
abort() at 0xf7774310
push_reload(in = (nil), out = 0x1afdf8, inloc = (nil), outloc = 0x1b2aec, class = NO_REGS, inmode = VOIDmode, outmode = VOIDmode, strict_low = 0, optional = 0, needed_for = (nil)), line 694 in "reload.c"
find_reloads(insn = 0x1b2af8, replace = 0, ind_levels = 0, live_known = 0, reload_reg_p = 0x1aaf84), line 2997 in "reload.c"
reload(first = 0x1b2818, global = 0, dumpfile = (nil)), line 1024 in "reload1.c"
rest_of_compilation(decl = 0x1bf298), line 2543 in "toplev.c"
finish_function(nested = 0), line 6092 in "c-decl.c"
yyparse(), line 289 in "c-parse.y"
compile_file(name = 0xf7ffff81 "fails.c"), line 1809 in "toplev.c"
main(argc = 5, argv = 0xf7ffff3c, envp = 0xf7ffff54), line 3291 in "toplev.c"
(dbx) quit
bossie$ exit

script done on Sat Dec 26 12:40:54 1992
-- 
		Arthur David Olson	ado@elsie.nci.nih.gov
		ADO and Elsie are Ampex and Borden trademarks

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: Sun, 3 Jan 1993 18:55:58 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)
From: jhp@photon.COM (Jim Patterson)
Newsgroups: gnu.gcc.bug
Subject: Re: IRIS4d gcc-2.3.1
Date: 27 Dec 92 16:39:27 GMT
Reply-To: jhp@photon.com
Distribution: gnu
Organization: Photon Research Associates, Inc.

Ori Degani (ori@marvin.technion.ac.il) wrote:
: Hi,
:   I tried to compile gcc on an iris4d running irix 4.0.5F
: The problem is that it includes the file /usr/include/syms.h 
: which tries to include: #include "cmplrs/stsupport.h"
: with no luck.  It seems as though it's a problem with the system, 
: but maybe it isn't.  Do you know anything about this?

You need to install the following subsystem from the developers disk
(it isn't installed by default)

dev.cmplrs_hdr.internal 08/07/92 Base Compiler Internal Headers

Jim
-- 
James Patterson	             photon!jhp@ucsd.edu      jhp@photon.com
Photon Research Associates   619-455-9741 (voice)     619-546-3903 (fax)
"... three great virtues of a programmer: laziness,impatience and hubris "
     Larry Wall in _Programming Perl_
Newsgroups: gnu.gcc.bug
From: dcurtis@mrc-crc.ac.UK (Dr. David Curtis)
Subject: fseek() bug in djgpp?
Organization: MRC Human Genome Resource Centre
Distribution: gnu
Date: Wed, 23 Dec 1992 09:09:18 GMT

Am I being completely stupid, or does the djgpp version of fseek() just
not work _at_all_? Seeks to offsets relative to SEEK_CUR just go
completely wrong. I have a file called funcs.doc which suggests that it
should be possible to do seeks backwards or forwards from SEEK_END, but
only forwards from SEEK_CUR. If this is correct it sounds pretty
non-standard to me. Anyway, when I tried this out I found that no seeks
relative to SEEK_CUR worked correctly. See code to prove it below. I am
using DOS 5 and SMARTDRV.SYS, though I doubt this is anything to do with
it, and djgpp version 2.22. I am surprised that bugs as obvious as this
are present in library. What other bugs are known? - I still can't get
my f2c-translated code to run correctly....


Dave Curtis

Academic Department of Psychiatry,    Janet:       d.curtis@UK.AC.IC.SM
St. Mary's Hospital,                  Elsewhere:   d.curtis@SM.IC.AC.UK
Praed Street, London W2.              EARN/Bitnet: dcurtis%CRC@UKACRL
Tel 071-725 1993                      Usenet:...!mcsun!ukc!mrccrc!D.Curtis

Test code:
(TEST.PED is any old text file, though opened in binary mode)

seeking backwards or forwards 5 from SEEK_CUR seems to move forwards by 17!!!

#include <stdio.h>

#define test(c) (printf("Trying %s ...\n",#c),printf("Result was %d\n",c))
#define tell() (printf("Now at %ld, ",ftell(fp)),\
    printf("next character is 0x%x\n",fgetc(fp)))

main()
{
FILE *fp;
fp=fopen("TEST.PED","r+");
test(fseek(fp,0,0));
tell();
test(fseek(fp,0,0));
tell();
test(fseek(fp,0,2));  /* end */
tell();
test(fseek(fp,-10,2));
tell();
test(fseek(fp,10,0));
tell();
test(fseek(fp,5,1));  /* relative */
tell();
test(fseek(fp,-5,1));
tell();
}

Trying fseek(fp,0,0) ...
Result was 0
Now at 0, next character is 0x28
Trying fseek(fp,0,0) ...
Result was 0
Now at 0, next character is 0x28
Trying fseek(fp,0,2) ...
Result was 0
Now at 2212, next character is 0xffffffff
Trying fseek(fp,-10,2) ...
Result was 0
Now at 2202, next character is 0x2e
Trying fseek(fp,10,0) ...
Result was 0
Now at 10, next character is 0xa
Trying fseek(fp,5,1) ...
Result was 0
Now at 37, next character is 0x33
Trying fseek(fp,-5,1) ...
Result was 0
Now at 54, next character is 0x20


Newsgroups: gnu.gcc.bug
From: nils@geom.umn.edu
Subject: (none)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 15:02:24 GMT

Newsgroups: comp.std.c
From: pitts@pullman.mcdata.com (Dave Pitts)
Newsgroups: gnu.gcc.bug
Subject: RTL generation problem in gcc-2.3.2
Date: 23 Dec 92 04:39:07 GMT
Distribution: gnu
Organization: GNUs Not Usenet

Hello:

I'm having a problem with gcc-2.3.2. It seems to generate an invalid RTL
instruction. The error appears as follows:

   $ gcc-cross -B./ -Imvs-include -O -S -c test.c
   test.c: In function `error':
   test.c:332: internal error--unrecognizable insn:
   (insn 1095 29 1096 (set (cc0)
           (compare (const_int 14)
               (reg/v:SI 24))) -1 (nil)
       (nil))
   gcc-cross: Internal compiler error: program cc1 got fatal signal 6

I'm cross compiling on a Sun-3 running SUNOS 3.3 for an IBM MVS C/370 target.
The problem may be in my machine description or tm.h. However, I can't find any
problem with them. According to the gcc.info files all compare RTL instructions
must have the constant in the second position. When I run the compile with -dr
option the offending instruction is in the test.c.rtl file. Is the RTL file 
that is generated machine independent? Or is some knowledge of the target used
in the RTL generation?

I can supply files upon request, if necessary. Or you can anon ftp from
newsit.mcdata.com (144.49.32.40), pathname /foryou/gccmvs.tar.Z.

As a note the compiler does generate correct code for simple tests. But, then
I had to go for broke.

Thanks in advance. And Happy holidays to all.

Dave Pitts
pitts@mcdata.com
Newsgroups: gnu.gcc.bug
From: przemek@viewlogic.COM (Przemek Skoskiewicz)
Subject: Re: fabs seems to be "broken" in 2.3.2...
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Dec 1992 21:20:33 GMT

I've forgotten to mention that the observed behavior is on the following
platforms:

   1.  Sparcstation IPX, SunOS 4.1.3
   2.  Compiled on a Sparc 2, SunOS 4.1.1 with configure options:
           % ./configure sparc-sun-sunos4.1.1

Bug statement:

   "The abs value printed is -5 whereas it should be 5".


Viewlogic Systems, Inc.                         Przemek Skoskiewicz
293 Boston Post Road West
Marlborough, MA 01752-4615, USA
email: przemek@viewlogic.com

Newsgroups: gnu.gcc.bug
From: rfg@netcom.com (Ronald F. Guilmette)
Subject: OOPS!  Make that 15 GCC 2.3.3 bugs!
Organization: Netcom - Online Communication Services  (408 241-9760 guest)
Distribution: gnu
Date: Wed, 30 Dec 1992 09:27:23 GMT

It has been brought to my attention that 5 of the 20 bugs I reported for
the recent 2.3.3 release of GCC were in fact non-bugs.

Specifically, #1, #16, and #17 all involve undefined behavior, and thus,
diagnostics are not strictly required in those cases.

Separately, items #14 and #15 were simply bogus.  I claimed that GCC was
failing to issue errors for erroneous code when in fact the code given
in the examples for those items was perfectly legitimate ANSI C code.

I sincerly apologize for any confusion these mistakes might have caused.

To the best of my knowledge, all of the other 15 items do in fact repre-
sent deviations (on GCC's part) from the letter of the ANSI C standard.


// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra
-- 

// Ron ("Loose Cannon") Guilmette    uucp: ...uunet!lupine!segfault!rfg
//
//      "On the one hand I knew that programs could have a compelling
//       and deep logical beauty, on the other hand I was forced to
//       admit that most programs are presented in a way fit for
//       mechanical execution, but even if of any beauty at all,
//       totally unfit for human appreciation."
//                                              -- Edsger W. Dijkstra

Newsgroups: gnu.gcc.bug
From: mycroft@hal.gnu.ai.mit.edu (Charles Hannum)
Subject: asm() bug on 386?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 24 Dec 1992 23:36:25 GMT

Using GCC 2.3.2 under 386BSD and GCC 2.2.2 under Linux:

bsdsux # ./cc1 -O0 bar.i
 ldexpIOT trap (core dumped)
bsdsux # exit

-- bar.i ------------8<-----snip-----8<-----snip-----8<-----snip-----8<-----
double ldexp (double value, int exp)
{
	double temp, texp, temp2;
	texp = exp;
	asm ("fscale ; fxch %%st(1) ; fstp%L1 %1 "
		: "=f" (temp), "=0" (temp2)
		: "0" (texp), "f" (value));
	return (temp);
}
-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----snip-----8<-----



Newsgroups: gnu.gcc.bug