HDTenEightyP/NetNews huggingface dataset:
From: bromley@think.com (Mark Bromley)
Subject: bitfields
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 21:38:55 GMT

These are all questions/comments rather than bugs.  Is there a more
appropriate mailing list?

I'd like to see bitfields be efficient enough so that I could always use
them rather than doing manual packing/unpacking.  Unfortunately there are
still some big hits.

1) On the sparc bitfields seem to allocated in a big endian fashion.  There
is a competing concern in that the least significant 12 bits are faster to
access.  Its a little grotty to have to explicitly pad out the definition
so that important bits fall in the low 12 bits.

2) The compiler seems to always emit a read-modify-write for each
assignment to a bitfield.  When one has carefully aligned fields on word
boundaries it is possible to produce much better code when there are
successive assignments to all the fields in a word.  Eg

    typedef struct x {
      /* ... */
      signed int a	: 14;
      unsigned int b	:  6;
      unsigned int c	: 12;
    } HASH_ENTRY;

    struct x *p;

    p->a = aa;
    p->b = bb;
    p->c = cc;

The sequence of individual read-modify-writes takes 18 cycles on the
cypress sparc chip.  By taking advantage of the fact that the whole word is
being filled you can cut this in half.

3) Logical operations (bitwise and, xor, or) on a bitfield are done by
extracting the field, doing the operation and then reinserting the new
value.  Its possible to do these in place.  Eg

   struct flags {
     unsigned pad:31;
     unsigned turn:1;
   };

   struct flags f;

   f.turn ^= 1;

For this I see sparc code like:

	and %l0,1,%o0
	xor %o0,1,%o0
	and %l0,-2,%l0
	or %l0,%o0,%l0

It could be:

	xor %l1,1,%l1


Newsgroups: gnu.gcc.bug
From: Bruce_Martin@next.com (Bruce Martin)
Subject: crash when optimizing inline function
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 3 Oct 1992 08:35:54 GMT

GCC version: 2.2.2 (also crashes the 9/25/92 snapshot)
Configuraton: i386-mach
Host: 386


Compile the enclosed code '-O2', and it will abort in allocate_reload_reg().

static inline char
_char_move_in(char *src)
{
    char val;
    asm volatile (
        "movb (%1), %0"
        : "=r" (val)
        : "r" (src));
    return val;
}

int move_string(char *src, char *dst, int max)
{
    int i = max;

    while (i-- > 0) {
        *dst = _char_move_in(src);
        dst++;
        if (!*src++)
            break;
    }
    return max - i;
}


It crashes when trying to perform a reload for this instruction (this output
is from the .lreg file):

(insn 39 37 41 (set (mem:QI (reg/v:SI 22))
       (asm_operands/v ("movb (%1), %0") ("=r") 0[
               (reg/v:SI 21)
           ]
           [
               (asm_input:SI ("r"))
           ]  ("crash.c") 9)) -1 (nil)
   (nil))


The code that it dies in is:

  /* We should have found a spill register by now.  */
  if (count == n_spills)
    {
      if (noerror)
        return 0;
      abort ();
    }

Newsgroups: gnu.gcc.bug
From: joe@veritas.COM (Joe Fasano)
Subject: gcc bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 2 Oct 1992 15:03:00 GMT

I am running gcc-2.2.2 on a sparcstation running
SunOS 4.1.2.

This bug is also on DECstation OSF/1
and older versions of gcc.


I am running gcc-2.2.2 on a sparcstation running
SunOS 4.1.2

This bug also appears on DecStation OSF/1
and on older gcc compilers.


#define  TEMPFILE "/tmp/cvXXXXXX"
main()
{
   char* tmp_file, *mktemp();

   if (!(tmp_file = mktemp(TEMPFILE)) || !strcmp(tmp_file, ""))
      printf("ERROR\n");
   else
      printf("tmp_file = '%s'\n",tmp_file);

}

/*----------- Workaround ------------*/


#ifdef __GNUC__
static char TEMPFILE[256]; /*bug in GNUC mktemp(), want's to core dump on short arrays */
#endif
main()
{
   char* tmp_file, *mktemp();

#ifdef __GNUC__
   strcpy (TEMPFILE,"/tmp/cvXXXXXX");
#endif
   if (!(tmp_file = mktemp(TEMPFILE)) || !strcmp(tmp_file, ""))
      printf("ERROR\n");
   else
      printf("tmp_file = '%s'\n",tmp_file);

}

joe@veritas.com
 -----------------------------------------------------------------------------
 Joe Fasano                         Internet: joe@veritas.com
 Veritas Software                   uucp:   ...!{apple,pyramid}!veritas!joe
 4800 Great America Pkwy, Ste 420
 Santa Clara, CA  95054             Phone:  408-727-1222



joe@veritas.com
 -----------------------------------------------------------------------------
 Joe Fasano                         Internet: joe@veritas.com
 Veritas Software                   uucp:   ...!{apple,pyramid}!veritas!joe
 4800 Great America Pkwy, Ste 420
 Santa Clara, CA  95054             Phone:  408-727-1222

Newsgroups: gnu.gcc.bug
From: gsk@lear.home.marble.com (Geoffrey S. Knauth)
Subject: gcc-2.2.2, longlong.h, 2 missing "\n\"
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 26 Sep 1992 20:16:23 GMT

*** longlong.h~	Wed Jun  3 17:51:17 1992
--- longlong.h	Sat Sep 26 23:59:53 1992
***************
*** 356,362 ****
  
  #if defined (__mc68000__)
  #define add_ssaaaa(sh, sl, ah, al, bh, bl) \
!   __asm__ ("add%.l %5,%1
  	addx%.l %3,%0"							\
  	   : "=d" ((unsigned long int)(sh)),				\
  	     "=&d" ((unsigned long int)(sl))				\
--- 356,362 ----
  
  #if defined (__mc68000__)
  #define add_ssaaaa(sh, sl, ah, al, bh, bl) \
!   __asm__ ("add%.l %5,%1\n\
  	addx%.l %3,%0"							\
  	   : "=d" ((unsigned long int)(sh)),				\
  	     "=&d" ((unsigned long int)(sl))				\
***************
*** 365,371 ****
  	     "%1" ((unsigned long int)(al)),				\
  	     "g" ((unsigned long int)(bl)))
  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
!   __asm__ ("sub%.l %5,%1
  	subx%.l %3,%0"							\
  	   : "=d" ((unsigned long int)(sh)),				\
  	     "=&d" ((unsigned long int)(sl))				\
--- 365,371 ----
  	     "%1" ((unsigned long int)(al)),				\
  	     "g" ((unsigned long int)(bl)))
  #define sub_ddmmss(sh, sl, ah, al, bh, bl) \
!   __asm__ ("sub%.l %5,%1\n\
  	subx%.l %3,%0"							\
  	   : "=d" ((unsigned long int)(sh)),				\
  	     "=&d" ((unsigned long int)(sl))				\

Newsgroups: gnu.gcc.bug
From: marc@athena.mit.edu (Marc Horowitz)
Subject: gdb doesn't see the correct arguments on function breakpoint
Reply-To: Marc Horowitz <marc@mit.edu>
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 08:55:41 GMT

decstation, ultrix 4.2A
gcc 2.2.2
gdb 4.6

If I set a breakpoint on a function, and put a display one of the
arguments, when the breakpoint occurs, the value displayed is
incorrect until I "next" once.  It should be correct immediately, so I
can "break foo if arg == 42" or something like that.

		Marc

Newsgroups: gnu.gcc.bug
From: fjh@munta.cs.mu.oz.au (Fergus James HENDERSON)
Subject: Re: Bug (?) in gcc-2.2.2's preprocessor
Organization: Computer Science, University of Melbourne, Australia
Distribution: gnu
Date: Mon, 5 Oct 1992 10:52:38 GMT

oliva@dcc.unicamp.br (Alexandre Oliva) writes:

>When I use the system's C compiler, the program works. When I use gcc,
>or even g++ (I began writing it in C++), it does not work any more.
[...]
>and in /usr/include/sys/ioccom.h, there is this line:
>
>#define _IOR(x,y,t)	(_IOC_OUT|((sizeof(t)&_IOCPARM_MASK)<<16)|('x'<<8)|y)
>
>I noticed that Sun's cpp changes the 'x' to 'm', but gcc's does not.
>Which one is correct?  What can I do to fix the problem, so that I can
>be sure my program can by compiled in other Unix systems?

This is not a bug in gcc - gcc is following the ANSI standard here -
but instead it is a difference between ANSI C and traditional K&R C.
If you compile with -traditional, then gcc's preprocessor will
behave like Sun's.

PS. If you had compiled with -Wtraditional, gcc would have told you this
itself. I would strongly suggest that everyone compiles with all warnings
enabled unless there is a good reason to avoid this. By "all warnings",
I mean something like the following:
	gcc -O -ansi -pedantic -Wall -Wshadow -Wwrite-strings -Wid-clash-31 \
	    -Wpointer-arith -Wcast-qual -Wtraditional -Wcast-align

-- 
Fergus Henderson             fjh@munta.cs.mu.OZ.AU      
This .signature virus is a self-referential statement that is true - but 
you will only be able to consistently believe it if you copy it to your own
.signature file!

Newsgroups: gnu.gcc.bug
From: ian@cygnus.com (Ian Lance Taylor)
Subject: HP/UX does not provide symbol types in syms.h
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 18:52:05 GMT

HP/UX 8.0, like mips, does not provide the sdbout symbol types in
syms.h.  The following patch solves the problem.

diff -u -r1.1.1.1 sdbout.c
--- 1.1.1.1     1992/07/29 11:34:05
+++ sdbout.c    1992/09/24 16:42:31
@@ -53,7 +53,7 @@
 
 /* Mips systems use the SDB functions to dump out symbols, but
    do not supply usable syms.h include files.  */
-#if defined(USG) && !defined(MIPS)
+#if defined(USG) && !defined(MIPS) && !defined(hpux)
 #include <syms.h>
 /* Use T_INT if we don't have T_VOID.  */
 #ifndef T_VOID


Ian Taylor

Newsgroups: gnu.gcc.bug
From: sscott@hpmail1.fwrdc.rtsg.mot.COM (Steve Scott)
Subject: Not really a bug but....
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 5 Oct 1992 15:42:52 GMT

I am sorry to send you this.  It is not a bug.  It is a generic question.

What I want to know is:  I am having trouble building gdb-4.6 for an HP/UX
425 running HP/UX 8.0.

Is there a good newsgroup/mailing list/individual/etc. to send questions like:

"I'm trying to build gdb-4.6 on an HP425 under HP/UX 8.0 and I need patches,
etc."?

Thanks,

-- 
+------------------------------------------------------------------------------+
| Steve Scott                                | Internet: sscott@mot.com        |
| Fort Worth Research and Development Center | UUCP:     uunet!motcid!sscott   |
| Cellular Infrastructure Group              | Internal: TX14/1D               |
| Radio Telephone Systems Group              | Voice:    (817) 232-6317        |
| Motorola, Inc.                             | Fax:      (817) 232-6148        |
|               The opinions contained herein are STRICTLY my own              |
+------------------------------------------------------------------------------+

Newsgroups: gnu.gcc.bug
From: steve%eowyn@gte.com (Steve Preston)
Subject: stdarg/varargs and the v?printf's on HP700
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 6 Oct 1992 14:40:47 GMT

HP9000/720 HPUX 8.07 gcc 2.2.2 (configured for hppa1.1-hp-hpux)

This is really HP's fault, I would guess.

The GNU C compiler defines its own version of stdarg/varargs data
structures, defining the type va_list as a structure of pointers,
thusly:

typedef struct
{
  char *__va_stack_start;	/* Real start of stack args. */
  char *__va_int;		/* Pointer to the general register */
				/* args and stack. */
  char *__va_float;		/* Pointer to the fp register args.  */
  char *__va_double;
} va_list;


In the HPUX headers, the v?printf's are declared to take the type
__va_list which is typedef'ed as a pointer to double.  So any calls to
v?printf either cause a compile error or fail badly at runtime.

I have experimentally determined that one should pass the __va_int
member to v?printf, (cast as a (double *) or (__va_list) to suppress a
warning, if desired).

This perhaps could be fixed by including a set of macros such as

  #define vprintf(a,b) vprintf(a,(__va_list)(b).__va_int)

to the gnu include files.  Except that would interfere with the
declaration of vprintf in stdio.h.

A better fix would be to write vprintf et.al., using _doprnt, which
HP's libc apparently contains, to do the work.

--
Steve Preston (scp2@gte.com)

Newsgroups: gnu.gcc.bug
From: hitchens@okfest.unt.dec.com
Subject: vms-gcc 2.2.2 has only a few function prototypes.
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 08:56:14 GMT

Hi,

the vms version of gcc 2.2.2 has only a few function prototypes. I picked it
up from mango.rsmas.miami.edu. stdio.h hasn't even got one for printf !
Is this correct ?

I had a much earlier version that had full function prototypes.

regards Francis J. Hitchens.

Newsgroups: gnu.gcc.bug
From: pardo@cs.washington.edu (David Keppel)
Subject: gcc 2.2.2 warning on statically unreachable code
Organization: Computer Science & Engineering, U. of Washington, Seattle
Distribution: gnu
Date: Tue, 6 Oct 1992 20:58:52 GMT

GCC 2.2.2 emits a warning on code that is statically unreachable.  I'm
not sure if this is a bug or merely the way things are; at any rate,
the warning is printed whether or not `-W*' flags are given.

Input:

	  int
	tst (int m, int a, int b)
	{
	  return (1 ? (a) : ((a) << (0) | (b) >> (32)));
	}

Note that `1' is always true, so the second alternative is never
reached, thus `b >> 32' is never reached.

Repeat-by:

% /uns/trial/bin/gcc -v -c gcc-warning.c
Reading specs from /uns/trial/lib/gcc-lib/decstation/2.2.2/specs
gcc version 2.2.2
 /uns/trial/lib/gcc-lib/decstation/2.2.2/cpp -lang-c -v -undef -D__GNUC__=2 -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 -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C gcc-warning.c /usr

/tmp/cca22589.i
GNU CPP version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix
 /uns/trial/lib/gcc-lib/decstation/2.2.2/cc1 /usr/tmp/cca22589.i -quiet -dumpbase gcc-warning.c -version -o /usr/tmp/cca22589.s
GNU C version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by CC.
gcc-warning.c: In function `tst':
gcc-warning.c:5: warning: shift count exceeds width of value shifted
 as -nocpp -EL -v -o gcc-warning.o /usr/tmp/cca22589.s
/usr/lib/cmplrs/cc/as0 -v -G 8 -EL -g0 -O1 /usr/tmp/cca22589.s -o /tmp/ctmaa22592 -t /tmp/ctmsta22592 
as0: tst 
0.0u 0.0s 0:00 20% 61+64k 0+6io 5pf+0w
/usr/lib/cmplrs/cc/as1 -v -G 8 -p0 -EL -g0 -O1 /tmp/ctmaa22592 -o gcc-warning.o -t /tmp/ctmsta22592 
as1: tst 
0.0u 0.0s 0:00 29% 80+70k 0+3io 8pf+0w
 /uns/trial/lib/gcc-lib/decstation/2.2.2/mips-tfile -v -o gcc-warning.o /usr/tmp/cca22589.s
mips-tfile version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix


Newsgroups: gnu.gcc.bug
From: bob@snuffy.dracut.ma.US (Bob Smith)
Subject: cc1 dies with signal 11
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 27 Sep 1992 02:21:13 GMT

Hello,

I ran into a problem building xview3 with gcc-1.41 that I've finally
isolated to the following condition.

When using -fpcc-struct-return, and compiling a piece of code that calls
a function via a pointer that returns a structure, cc1 dies with a signal
11 (SEGV).

Here's a sample piece of code:

----- cut here -----
#include <stdio.h>

struct buffer {
    int a;
    int b;
} _buffer;

struct buffer set_buf();

main()
{
    foo(set_buf);
}

foo(f)
struct buffer (*f)();
{
    struct buffer d;

    d = f();                        /* <- cc1 dies with a SEGV here */
    printf("%d %d\n", d.a, d.b);
}

struct buffer
set_buf()
{
    struct buffer d;

    d.a = 1;
    d.b = 2;
    return d;
}
----- cut here -----

Not using -fpcc-struct-return in this example will let it compile
normally.  But if you know of another work-around, that'd be great...

Thanks, and have a good day!  AND THANKS for such a nice compiler!

-- 
 \ Bob Smith               \ mx: bob@snuffy.dracut.ma.us
  \ 1215 Pawtucket Blvd. #4 \ uucp: ...{ulowell|wang|wybbs}!snuffy!bob
   \ Lowell, MA. 01854       \ office && voice mail: +1 508 670-6712

Newsgroups: gnu.gcc.bug
From: sl25@emu.pmms.cam.ac.uk (Steve Linton)
Subject: Structure passing bug
Organization: Cambridge University DPMMS
Distribution: gnu
Date: Wed, 30 Sep 1992 06:35:19 GMT

A bug seems sometimes to occurr when passing a alrge structure as an argument. 
For example the following does not suceed on a Sun4 under gcc 2.1 or 2.2.2,
at any optimization level.


struct a {int b[7];};

void f(struct a x)
{
  int i;
  for (i=0; i < 7; i++)
    printf("%d\t",x.b[i]);
  putc('\n');
}

main()
{
  struct a y;
  int i;
  for (i = 0; i < 7; i++)
    y.b[i] = i;
  f(y);
}

Under gdb, the argument passed to f appears as 

(gdb) next
17        f(y);
(gdb) print y
$1 = {b = {0, 1, 2, 3, 4, 5, 6}}
(gdb) step
f (x={b = {285216903, 8252, 8256, -16777207, 9, -16777207, -132531200}})
    at test.c:6
6         for (i=0; i < 7; i++)

Is this a known problem? Is there a fix?

	Please reply by mail 

		Steve Linton

Newsgroups: gnu.gcc.bug
From: klaiber@cs.washington.edu (Alexander Klaiber)
Subject: Sun-4/SPARC stack frame bug
Organization: Computer Science & Engineering, U. of Washington, Seattle
Distribution: gnu
Date: Tue, 29 Sep 1992 16:17:19 GMT

Machine:	Sun-4/Sparc
OS:		SunOS 4.1.2
Compiler:	gcc-2.2.2 -g


In the code below, the allocation of the array {foo} completely messes up
the stack frame, the program dumps core.
NOTE: This seems specific to the Sun; the same program ran fine on a DECstation.

    void
    test(int n) {
	int i,j;
	double foo[n];		<======== this causes trouble
	for (i=0; i<n; ++i) {
	    foo[i] = 0.0;
	}
    }

    main() {
	test(10000);
    }


[entiat - 24] % 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.5, Copyright 1992 Free Software Foundation, Inc...
(gdb) b test
Breakpoint 1 at 0x2298: file test.c, line 3.
(gdb) run
Starting program: /tmp_mnt/homes/fish/klaiber/gcc/a.out 

Breakpoint 1, test (n=10000) at test.c:3
3	    int i,j;
(gdb) where
#0  test (n=10000) at test.c:3
#1  0x2330 in main () at test.c:12
(gdb) n

Program received signal 4, Illegal instruction		<================
0x22c8 in test (n=???) at test.c:3
3	    int i,j;
(gdb) where
#0  0x22c8 in test (n=???) at test.c:3

Newsgroups: gnu.gcc.bug
From: michael@stb.INfo.COM (Michael Gersten)
Subject: bug in 2.2.2?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sat, 3 Oct 1992 18:07:00 GMT

In optabs.c, routine expand_binop(), is code that looks like

      if (! (*insn_operand_predicate[icode][1]) (xop0, mode0))
	xop0 = copy_to_mode_reg (mode0, xop0);

Note that this calls the specified predicate, even if the predicate
was "", i.e., no restriction on this one. This turns into a call to
address 0.

Is this an error in my md? Or is this a gcc problem?

Here's the stuff from md:

(define_insn "addsi3"
        [ (set (match_operand:SI 0 "general_operand" "=r")
                (plus (match_operand:SI 1 "" "%0")
                        (match_operand:SI 2 "mode_RD_operand" "g"))
        )]
        ""
        "*
        { return make2Ins (\"DA\", MR|MD|MDX); }"
)
--
		Michael Gersten		michael@stb.info.com
HELLO! I'm a signature virus! Join in the fun and copy me into yours!
ex:.-1,. w $HOME/.signature

Newsgroups: gnu.gcc.bug
From: ojr@itk.unit.NO
Subject: Bug in handling erronous C++ code ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 29 Sep 1992 17:20:08 GMT

Following short program causes cpp1 to dump core.

--------------------------------
class Time;
class TimeNote;

class SvTime
{
public:
    static TimeNote *time_events = 0;
};

SvTime CurrentTime = {0};
-----------------------------------
Error message etc:

gcc -v ini_bug.cc
Reading specs from /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cpp -lang-c++ -v -undef -D__GNU
C__=2 -D__GNUG__=2 -D__cplusplus -Dsparc -Dsun -Dunix -D__sparc__ -D__sun__ -D__
unix__ -D__sparc -D__sun -D__unix ini_bug.cc /usr/tmp/cca06966.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sparc-sun-sunos4.1/2.2.2/cc1plus /usr/tmp/cca06966.i -qu
iet -dumpbase ini_bug.cc -version -o /usr/tmp/cca06966.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
gcc: Internal compiler error: program cc1plus got fatal signal 11



Newsgroups: gnu.gcc.bug
From: thayer@moose.cs.columbia.edu (Charles Thayer)
Subject: small bug
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 30 Sep 1992 06:38:17 GMT

One of our students pointed this out to me:

[thayer:0] BashER> cat > foo.c
main() {
int offset;
char buf[offset]="";
}
[thayer:0] BashER> g++ foo.c
/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6
[thayer:1] BashER> g++ -v foo.c
Reading specs from /usr/local/lib/gcc-lib/sun4/2.2.2/specs
gcc version 2.2.2
 /usr/local/lib/gcc-lib/sun4/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 foo.c /usr/tmp/cca22327.i
GNU CPP version 2.2.2 (sparc)
 /usr/local/lib/gcc-lib/sun4/2.2.2/cc1plus /usr/tmp/cca22327.i -quiet -dumpbase foo.cc -version -o /usr/tmp/cca22327.s
GNU C++ version 2.2.2 (sparc) compiled by GNU C version 2.2.2.
/usr/local/bin/gcc: Internal compiler error: program cc1plus got fatal signal 6

Newsgroups: gnu.gcc.bug
From: sm@cvedc.prime.com (scott machaffie)
Subject: Re: gcc v2.2.2 unsigned prototype bug
Keywords: unsigned prototypes
Organization: Computervision R&D, Beaverton OR
Distribution: gnu
Date: Mon, 28 Sep 1992 13:57:09 GMT

sm@cvedc.prime.com (scott machaffie) writes:

>The following (ANSI-legal, according to my understanding of ANSI) code
>generates an error message in gcc2.2.2:

>void foo(unsigned int, unsigned int, unsigned int, unsigned long);

>void foo(uchar_error, ushort_error, uint_okay, ulong_okay)
>unsigned char   uchar_error;
>unsigned short  ushort_error;
>unsigned int    uint_okay;
>unsigned long   ulong_okay;
>{
>	return;
>}

>gcc generates an error message for "uchar_error" and "ushort_error".

Actually, this is correct (after re-reading K&RII).  However, the following
prototype should generate a warning message when used with the function
above, but doesn't:

void foo(unsigned char, unsigned short, unsigned int, unsigned long);

Scott MacHaffie

Newsgroups: gnu.gcc.bug
From: meissner@osf.ORG
Subject: DECstation lui vs. li usage
Organization: GNUs Not Usenet
Distribution: gnu
Date: Sun, 27 Sep 1992 19:41:19 GMT

| gcc 2.2.2 on a decstation
| 
| The basic question is:  why does this:
| 
| 	li	$4,10000000
| 
| become this:
| 
|         lui     $4,(0x00980000)>>16     # Here's the source of my question.
|         ori     $4,$4,0x967f            # Why's it doing this instead of
| 
| when I use -O -fschedule-insns?  And, is it a bug?  (And there's one more
| teeny thing at the end about using 'slt...beq' instead of 'bne'.)

No, this is not a bug.  It takes two instructions to load 1000000
(decimal) into a register.  When you do -fschedule-insns (and
-fdelayed-branch), it will split insns that the machine says are
really several instructions into their component parts, so that each
instruction can be scheduled.  The reason you don't do the split
earlier (such as in the recognition phase), is it gives better code
generation to the higher level optimization phases to have a slightly
more general machine, than the real machine (where to draw the line is
an art).  Also, for the specific case mentioned, the backend is
required to have an insn that puts any arbitary integer constant into
a register.

As to why use 'lui' instead of the macro 'li', it was to avoid a bug
in GAS (since fixed) on the OSF/1 reference port, which did not map
li's of a number with just the upper bits set into a lui instruction.

| #
| #   This way would save us one 'slt' at each iteration, but it's
| #    hard for gcc to figure out that the loop is actually a != instead
| #    of a <.  (I wouldn't bring it up, but MIPS cc does this.)
| #	.set	noreorder
| #	.set	nomacro
| #	bne	#3,$4,$L5
| #	.set	macro
| #	.set	reorder

It's problem something to think about for loop induction.

--
Michael Meissner	email: meissner@osf.org		phone: 617-621-8861
Open Software Foundation, 11 Cambridge Center, Cambridge, MA, 02142

You are in a twisty little passage of standards, all conflicting.

Newsgroups: gnu.gcc.bug