HDTenEightyP/NetNews huggingface dataset:
From: leisner@wrc.xerox.COM (Marty Leisner 311/? x?)
Subject: indent 1.5 - troff option
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Thu, 20 Aug 1992 13:08:12 GMT

I'm working on grinding listings...

Indent 1.4 had problems, so I got 1.5 -- appears forget about the -troff option...

I just got indent 1.5 up and running...the man page and the tex manual don't have a 
troff option defined...

It appears the manual changed without updating the version.   I'm printing edition
0.02, Version 1.3, May 1992 in the texinfo file...

Looking at the texinfo manual source (I'm not texliterate, so I'm just guessing):
@ignore
This is intentionally undocumented because
1.  Although GNU now has groff, it would be better to use TeX.

2.  The output of indent -troff looks awful, so we have heard.  Perhaps
    it would be reasonable to use this as a starting point to printing a
    program.

If you are printing your program, you may wish to use the @samp{-troff}
option to produce output suitable for processing by the @code{troff}
program.  When the @samp{-troff} option is specified, if the output file
is not specified, the default is standard output, rather than formatting
in place.
@end ignore

@c Ignore the following since it is not supported.  When someone
@c rewrites this program, an effort could be made to generate TeX.
@c
@c item -troff
@c Format the program for printing with @code{troff}.  Use of this option
@c is not suggested.
@c  xref   Miscellaneous options
@c 
@c

I guess this means forget about the troff option (maybe a good idea, it doesn't
appear to work well).  

What's a good way to grind listings?  I want to use the psmulti package to produce
n-up output, so I need to use an output driver which users adobe's document structuring
conventions...groff does, I'm using dvitps which doesn't...

I ran vgrind on SunOS 4.1.1 and it doesn't appear to do anything useful
(I ran vgrind -f file | groff -mindent - | lpr ) except put the output into italics...

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

Newsgroups: gnu.utils.bug
From: bothner@cygnus.com
Subject: Re: how to make "make" variables override sub-make variables
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 08:23:52 GMT

> Is there (or shouldn't there be) an easy way to let top-level make
> variables override the values specified in sub-makefiles

Doing it manually is easy.  In Cygnus Makefile, we typically do:

FLAGS_TO_PASS = CC=$(CC) BINDIR=$(BINDIR) ...

do_foo:
	cd foo; $(MAKE) $(FLAGS_TO_PASS) all

	--Per Bothner
Cygnus Support     bothner@cygnus.com

Newsgroups: gnu.utils.bug
From: gnu@cygnus.com
Subject: GNU fileutils v3.2.3 alter pathnames by removing trailing slashes
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 05:45:45 GMT

The file utilities (cp, mv, etc) eliminate some errors by always removing
trailing slashes from file names.  However, these errors should be caught,`
not ignored.  For example, in the command:

	cp foo bar/

the intention of the user is that if "bar" is a directory, the file
bar/foo is created.  But if "bar" is not a directory, rather than
producing a copy of foo called "bar", an error should be produced.
This is a simple way to protect yourself against typos in copying
files into directories.

Instead, the GNU fileutils produce a file called "bar", without any warning
or error.

My guess is that somebody tried using the GNU fileutils under "bash"
with filename completion, and had some minor problem because bash
inserts a / at the end of a path if the last part of the name is a
directory.  (Some part of the fileutils probably assumed that there
would be no trailing slashes in names.)

The Unix kernel properly handles names containing multiple leading,
internal, and trailing slashes.  The Unix file utilities also handle
these pathnames.  We pride ourselves on doing better in the GNU system
than in the Unix system -- removing limitations, and doing better
error checking.  If a user specifies a pathname which cannot be
resolved, an error should be reported.

The fix is not indiscriminate bashing of trailing slashes, as
currently implemented.  The fix is to remove the generic truncation of
trailing slashes, then to fix whatever minor bugs prevent the use of
pathnames containing trailing slashes.

	John Gilmore

Newsgroups: gnu.utils.bug
From: jla@lucid.com (Joseph Arceneaux)
Subject: indent 1.5 - troff option
Reply-To: jla@ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 16:40:30 GMT

The "-troff" option is not reccomended for GNU indent.  Perhaps
someone would like to rewrite indent and make it do nice things like
support other languages, and output TeX.

Currently, I do not know of a good, automated way to produce ground
code for print.  I hand-formatted my code by hand, using TeX, when
I've needed to do this.

Newsgroups: gnu.utils.bug
From: pinard@icule.UUCP (Francois Pinard)
Subject: Autoconf and duplicated function tests
Reply-To: pinard@iro.umontreal.ca
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 19 Aug 1992 17:55:44 GMT

Hi, people.  In one application, my configure.in contains:

	AC_HAVE_FUNCS(strstr)
	AC_REPLACE_FUNCS(strstr)

I wonder if the double check generated in configure by autoconf could
be avoided.  Once AC_HAVE_FUNCS knows for some function, the test does
not need to be done again for AC_REPLACE_FUNCS.

Here is the logic behind this particular usage.  The AC_REPLACE_FUNCS
is for providing a replacement strstr if the standard library does not
contain it, it just plays with the Makefile variable LIBOBJS.  The
AC_HAVE_FUNCS determination is transmitted, via DEFS, to the module
calling strstr, which uses it the following way:

	#ifdef USG
	#include <string.h>
	#else
	#include <strings.h>
	#endif
	#ifndef HAVE_STRSTR
	const char *strstr ();
	#endif

If the system already offers strstr, <string.h> or <strings.h> will
declare it, and my own definition will fatally conflict.

-- 
Franc,ois Pinard        ``Vivement GNU!''        pinard@iro.umontreal.ca
(514) 588-4656                                    ...!uunet!iros1!pinard
Consider joining the League for Programming Freedom.  Email for details!

Newsgroups: gnu.utils.bug
From: jla@lucid.com (Joseph Arceneaux)
Subject: indent 1.5 -- installing man pages
Reply-To: jla@ai.mit.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 16:44:45 GMT

The included man page was donated by a user, but is not supported.
GNU uses texinfo for documentation purposes.
From: tpopovic@us.oracle.COM (Tom Popovich)
Newsgroups: gnu.utils.bug
Subject: gnu find-3.7
Date: 19 Aug 92 01:19:54 GMT
Distribution: gnu
Organization: GNUs Not Usenet

In lib/fnmatch.h, I added ASSUME_STDC to support machines that act
like and ansi-C compiler but dont define __STDC__  This happens on
system 5r4


#if defined (__cplusplus) || (defined (__STDC__) && __STDC__) || defined (ASSUME_STDC)
#undef  __P
...
Newsgroups: gnu.utils.bug
From: watt@blazng.enet.DEc.COM (Gill Watt)
Subject: gnu indent feature (undocumented)
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 14:35:07 GMT

howdy,

I've noticed the following unusually behavior with gnu-indent.  It
has done this in versions 1.4 and 1.5.

The unusual case:
-----------------------------------------------

void main(int argc, char *argv[])
{
    switch (argc)
    {
	    case 0 :
	    printf("hello world");
	    break;
	case 1:
	    printf("hello world");
	    break;
	case 2:
	    printf("hello world");
	    break;
	case 3:
	    printf("hello world");
	    break;
	case 4:
	    printf("hello world");
	    break;
	default:
	    break;
    }
}


A very similar case that works correctly:
-----------------------------------------------

void main(int argc, char *argv[])
{

    printf("goodbye world");

    switch (argc)
    {
	case 0:
	    printf("hello world");
	    break;
	case 1:
	    printf("hello world");
	    break;
	case 2:
	    printf("hello world");
	    break;
	case 3:
	    printf("hello world");
	    break;
	case 4:
	    printf("hello world");
	    break;
	default:
	    break;
    }
}

I run with the following .indent.pro file:

 -bad -bap -bbb -nbc -bl -bli0 -c40 -cd40 -cdb -nce 
 -cli4 -cp1 -cs -bs -d0 -di0 -fc1 -fca -i4 -ip6 -l79 -lp -npcs -npsl 
 -sc -nsob -nss -ts8 -nv

Great program.  Thanks.

-Gill



Newsgroups: gnu.utils.bug
From: leisner@wrc.xerox.COM (Marty Leisner 311/? x?)
Subject: indent 1.5 -- installing man pages
Reply-To: leisner.henr801c@xerox.com
Organization: Xerox
Distribution: gnu
Date: Thu, 20 Aug 1992 12:31:37 GMT

I just installed indent 1.5.

It doesn't seem to have a way to install the manpage in the makefile.

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

Newsgroups: gnu.utils.bug
From: asmith@synoptics.com (Andrew Smith)
Subject: binutils-beta-1.94 M68k opcode disassembly
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 03:40:09 GMT

The file binutils-beta-1.94/binutils/m68k-pinsn.c has some problems with
exotic 68k opcodes.

1. It has no support for "P", "Y", "X", "W" and "Z" operand types (used by PMMU)

2. It searches the opcode table sequentially i.e. alphabetically, looking for
an opcode which matches the supplied hex opcode. This results in it finding
the floating point instructions Fxxxx before the pmmu ones Pxxxx and displaying
PMMU opcodes as "Fxxxx (cpid=0)" rather than as "unknown" which would be more
useful. Thus, even if you add support for Pxxx opcodes, they will not be found
unless they are placed out of order, before the Fxxx opcode descriptions in "m68k.h".
Is there more correct way of fixing this general problem than just rearranging 
"m68k.h"? It will occur anywhere where there are several alternative decodings
of an opcode.

Andrew Smith
Distributed Network Systems
SynOptics Communications Inc.

Newsgroups: gnu.utils.bug
From: snoopy@sopwith.UUCP (Snoopy)
Subject: Flex on Tek 6130?
Organization: The Daisy Hill Puppy Farm
Distribution: gnu
Date: Fri, 14 Aug 1992 19:40:37 GMT

Has anyone ported flex to the Tek 6130?  UTek's lex doesn't
seem to like scan.l:

lex -is scan.l
lex : Unknown option i
lex : Unknown option s
89: (Warning) Invalid request %x SECT2 SECT2PROLOG SECT3 CODEBLOCK PICKUPDEF SC CARETISBOL NUM QUOTE
90: (Warning) Invalid request %x FIRSTCCL CCL ACTION RECOVER BRACEERROR C_COMMENT ACTION_COMMENT
91: (Warning) Invalid request %x ACTION_STRING PERCENT_BRACE_ACTION USED_LIST CODEBLOCK_2 XLATION
153: (Warning) Executable statements should occur right after %
154: (Warning) Executable statements should occur right after %
lex : syntax error : Request does not apply (sys25)
162: (Warning) Executable statements should occur right after %
167: (Warning) Executable statements should occur right after %
173: (Warning) Executable statements should occur right after %
174: (Warning) Executable statements should occur right after %
175: (Warning) Executable statements should occur right after %
196: (Warning) Executable statements should occur right after %
197: (Warning) Executable statements should occur right after %
199: (Warning) Executable statements should occur right after %
208: (Warning) Executable statements should occur right after %
210: (Warning) Executable statements should occur right after %
216: (Warning) Executable statements should occur right after %
217: (Warning) Executable statements should occur right after %
222: (Warning) Executable statements should occur right after %
223: (Warning) Executable statements should occur right after %
224: (Warning) Executable statements should occur right after %
234: (Warning) Executable statements should occur right after %
236: (Warning) Executable statements should occur right after %
240: (Warning) Executable statements should occur right after %
242: (Warning) Executable statements should occur right after %
254: (Warning) Executable statements should occur right after %
255: (Warning) Executable statements should occur right after %
259: (Warning) Executable statements should occur right after %
260: (Warning) Executable statements should occur right after %
267: (Warning) Executable statements should occur right after %
268: (Warning) Executable statements should occur right after %
269: (Warning) Executable statements should occur right after %
270: (Warning) Executable statements should occur right after %
280: (Warning) Executable statements should occur right after %
281: (Warning) Executable statements should occur right after %
287: (Warning) Executable statements should occur right after %
291: (Error) Non-terminated string or character constant
*** Error code 1

Stop.

    _____
   /_____\   Snoopy			  The government is not your mommy.
  /_______\   
    |___|    cse.ogi.edu!sopwith!snoopy
    |___|    {ares,illian,loop,parsely,qiclab,sequent,techbook}!sopwith!snoopy

Newsgroups: gnu.utils.bug
From: karl@claude.cs.umb.edu (Karl Berry)
Subject: indent 1.5 realclean
Reply-To: karl@cs.umb.edu
Organization: GNUs Not Usenet
Distribution: gnu
Date: Tue, 11 Aug 1992 17:58:01 GMT

In GNU indent 1.5, make realclean does not remove indent.info.
Also, TAGS should probably be removed as part of realclean, not clean,
judging from the coding standards.
From: sondeen@isi.edu (Jeff Sondeen)
Newsgroups: gnu.utils.bug
Subject: how to make "make" variables override sub-make variables
Keywords: nn
Date: 12 Aug 92 01:32:25 GMT
Reply-To: Jeff Sondeen <sondeen@isi.edu>
Distribution: gnu
Organization: USC-Information Sciences Institute

Is there (or shouldn't there be) an easy way to let top-level make
variables override the values specified in sub-makefiles; for example:
BINDIR.  I tried setting MAKEFLAGS but it doesn't work; that is,

MAKEFLAGS= BINDIR=/my/bin/dir

is interpreted as a "-B" switch or something.

I saw the trick that groff-1.05 uses in it's top-level makefile but I was
hoping for something easier, like a new switch for make.

Thanks,
--
/jeff

Life and love are as deep [as your] eyes are wide... -Rush
Newsgroups: gnu.gcc.bug
From: sysnet@cent1.lancs.ac.uk (The Postmaster)
Subject: Building GCC 2.2.2 on Dynix/ptx
Organization: GNUs Not Usenet
Distribution: gnu
Date: Wed, 12 Aug 1992 13:31:03 GMT

Can anyone give me a recipe for how to build GCC 2.2.2 on a Sequent Symmetry
running Dynix/ptx 1.3, please? I'm not having much luck using the existing
i386/SystemV.3 configuration.

Reply by mail direct, please, as I don't subscribe to this list.

Thanks in advance for any help

Alan

-- 

+----------------------------------------------------------------------------+
| LANCASTER UNIVERSITY POSTMASTER                              Alan Phillips |
|----------------------------------------------------------------------------|
| Computer Centre, Lancaster University, Lancaster LA1 4YW, UK               |
| Phone: 0524-65201 x 3672                                                   |
|                                                                            |
| "Where am I?"                                                              |
| "In The Village...."                                                       |
|----------------------------------------------------------------------------|
|JANET :postmaster@uk.ac.lancaster | INTERNET: postmaster@lancaster.ac.uk    |
|BITNET:postmaster@lancaster.ac.uk | UUCP    : postmaster%lancaster@uknet    |
+----------------------------------------------------------------------------+

Newsgroups: gnu.gcc.bug
From: gsk@carrara.bos.marble.com (Geoffrey S. Knauth)
Subject: GNU CC 2.2.2, gcc.info, line 291-2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 21 Aug 1992 10:29:25 GMT

Lines 291-2 (#2-3 below) need some minor editing.  cp-decl.c appears twice.

     The source files for parsing C++ are `cp-parse.y', `cp-class.c',
     `cp-cvt.c',
     `cp-decl.c', `cp-decl.c', `cp-decl2.c', `cp-dem.c', `cp-except.c',
     `cp-expr.c', `cp-init.c', `cp-lex.c', `cp-method.c', `cp-ptree.c',
     `cp-search.c', `cp-tree.c', `cp-type2.c', and `cp-typeck.c', along
     with header files `cp-tree.def', `cp-tree.h', and `cp-decl.h'.


Newsgroups: gnu.gcc.bug
From: eggert@twinsun.COM (Paul Eggert)
Newsgroups: gnu.gcc.bug
Subject: GCC 2.2.2 does not warn about partly bracketed initializers
Date: 12 Aug 92 01:42:39 GMT
Distribution: gnu
Organization: GNUs Not Usenet

GCC 2.2.2 (Sparc, SunOS 4.1.2) does not warn about partly bracketed
initializers.  For example, in the following program, GCC does not
have an option to warn about the missing braces around `1,2':

	struct s { int f, g; };
	struct t { struct s h; int i; };
	struct t x = { 1, 2, 3 };

This is a nice warning to have because it catches some common typographical
errors.  This warning is also listed as a common warning in the ANSI C
standard (Appendix E).  Here's a patch that generates this warning when the -W
option is used.

Wed Aug 12 01:23:10 1992  Paul Eggert  (eggert@twinsun.com)

	* c-typeck.c (process_init_constructor): Warn about partly
	bracketed initializers.

===================================================================
RCS file: c-typeck.c,v
retrieving revision 2.2.2.4
diff -c -r2.2.2.4 c-typeck.c
*** c-typeck.c	1992/08/07 22:38:54	2.2.2.4
--- c-typeck.c	1992/08/12 01:23:10
***************
*** 4825,4831 ****
       no matter how the data was given to us.  */
  
    if (elts)
!     tail = *elts;
    else
      tail = CONSTRUCTOR_ELTS (init);
  
--- 4825,4835 ----
       no matter how the data was given to us.  */
  
    if (elts)
!     {
!       if (extra_warnings)
! 	warning ("aggregate has a partly bracketed initializer");
!       tail = *elts;
!     }
    else
      tail = CONSTRUCTOR_ELTS (init);
  
===================================================================
RCS file: invoke.texi,v
retrieving revision 2.2.2.2
diff -c -r2.2.2.2 invoke.texi
*** invoke.texi	1992/08/07 22:38:54	2.2.2.2
--- invoke.texi	1992/08/12 01:23:10
***************
*** 623,628 ****
--- 623,639 ----
  A storage-class specifier like @code{static} appears other than
  at the beginning of a declaration.  According to the C Standard,
  this usage is obsolescent.
+ 
+ @item
+ An aggregate has a partly bracketed initializer.
+ For example, the following code would evoke such a warning,
+ because braces are missing around the initializer for @samp{x.h}:
+ 
+ @example
+ struct s @{ int f, g; @};
+ struct t @{ struct s h; int i; @};
+ struct t x = @{ 1, 2, 3 @};
+ @end example
  @end itemize
  
  @item -Wimplicit
Newsgroups: gnu.gcc.bug
From: fletch@vnet.ibm.com (Andrew L. Gross)
Subject: Problem making gcc-2.2.2
Organization: GNUs Not Usenet
Distribution: gnu
Date: Mon, 17 Aug 1992 23:08:34 GMT

  I am having a problem making gcc version 2.2.2 on an RS/6000.

  The problem arises after I configure it for rs6000-ibm-aix and
do a make LANGUAGES=c.

  It goes for a while and I get the following error:


_muldi3
Assembler:
/tmp/ccOS8CZt.s: line 25: Error In Syntax
The error code from the last failed command is 1.

Make Quitting.



  Any help or suggestions would be greatly appreciated.


                               Thanks,
                                 Andy

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

Andrew L. Gross                             ADSTAR
Internet: fletch@vnet.ibm.com               63S/071-2
Phone: (602) 799-3459                       9000 S. Rita Road
Tie Line:    321-3459                       Tucson, AZ  85744

Newsgroups: gnu.gcc.bug
From: quanstro@stolaf.edu (goon)
Subject: wierdness with gcc cpp
Organization: St. Olaf College, Northfield, MN USA
Distribution: gnu
Date: Mon, 17 Aug 1992 00:33:39 GMT

Cpp reports an error in a line that does not exist!

I am not sure what is causing this (I really don't have time to beat
on gcc myself as I am my own C compiler "for fun"). Anyway, here's the
info that gcc gave me

gcc -pg -ggdb -Wall -Wshadow -Wwrite-strings -c y.tab.c
parse.y:211: macro `mklist' used with too many (3) args
parse.y:248: unterminated macro call
parse.y:1003: macro `mkleaf' used with only 2 args
*** Error code 1
; wc -l parse.y
     490 parse.y
; gcc -v
Reading specs from /usr/local/lib/gcc-lib/sun4-sunos4.1.1/2.1/specs
gcc version 2.1

Newsgroups: gnu.gcc.bug
From: hofmann@cs.uiuc.edu (J. Scott Hofmann)
Subject: gcc doesn't warn about unreachable code
Reply-To: hofmann@cs.uiuc.edu (J. Scott Hofmann)
Organization: Delta group, Dept. of Comp. Sci., University of Illinois at U-C
Distribution: gnu
Date: Tue, 11 Aug 1992 20:59:04 GMT

   In the following short program I have a line which is never reached. gcc
rightly omits the line from the .s file, but does not print a warning that
it is omitting some code, even with -Wall -pedantic.

/* Demonstrate a problem in gcc. Note that printf("two\n") will never be
 * reached.
 */
#include <stdio.h>

void main(void) {
  int i;

  for (i = 1; i < 10; i++) {
    printf("i = %d\n", i);
    continue;
    printf("two\n");
  }
  printf("three\n");
}

                                                       scott

-- 
-------------------------------------------------------------------------------
J. Scott Hofmann                        | "Yes, I am competely loopy."
hofmann@cs.uiuc.edu (NeXTmail accepted) |       -John Cleese
Epoch development team, UIUC            |

Newsgroups: gnu.gcc.bug
From: victor@watson.ibm.com (Victor Miller)
Subject: fatal signal 6 with long long
Reply-To: victor@watson.ibm.com
Organization: IBM, T.J. Watson Research Center
Distribution: gnu
Date: Thu, 20 Aug 1992 14:36:29 GMT

The program given below produces the following when compiled (version
is 2.2.2 on rs/6000, AIX 3.1.6):

terse4.watson.ibm.com:~victor/nterse: gcc -c longbug.c
gcc: Internal compiler error: program cc1 got fatal signal 6

The program is:

long long x;
double y = 50.0;
int main(int argc, char *argv[]) {
  x=(long long)y;
  return 0;
}

--
		Victor S. Miller
		Bitnet: VICTOR at WATSON
		Internet: victor@watson.ibm.com
		IBM, TJ Watson Research Center
		"Great artists steal; lesser artists borrow" Igor Stravinsky

Newsgroups: gnu.gcc.bug
From: ulm@vsnhd2.cern.ch (Ulrich Mueller)
Subject: gcc 2.2.2 crashes compiling gs25
Organization: GNUs Not Usenet
Distribution: gnu
Date: Thu, 20 Aug 1992 17:06:22 GMT

I just tried to compile ghostscript version 2.5 with gcc version
2.2.2. The compiler crashes when compiling gsmain.c:

gs25$ gcc -c -g -O -v gsmain.c
Reading specs from /usr/gnu/lib/gcc-lib/decstation/2.2.2/specs
gcc version 2.2.2
 /usr/gnu/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__OPTIMIZE__ -g -D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C gsmain.c
 /usr/tmp/cca09172.i
GNU CPP version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix
 /usr/gnu/lib/gcc-lib/decstation/2.2.2/cc1 /usr/tmp/cca09172.i -mgpopt -quiet
 -dumpbase gsmain.c -g -O -version -o /usr/tmp/cca09172.s
GNU C version 2.2.2 [AL 1.1, MM 19] DECstation running ultrix compiled by GNU C
 version 2.1.
pid 9174 (cc1) was killed on an unaligned access, at pc 0x4685f0
gcc: Internal compiler error: program cc1 got fatal signal 10

The problem does only occur if flag "-g" is used.
The machine is a Decstation 5000/200 running Ultrix 4.2a.

--
Ulrich Mueller      Email: ulm@vsnhd1.cern.ch
PPE Division               mulleru@cernvm.cern.ch
CERN                Phone: +41-22-767-8193
CH-1211 Geneva 23   Fax:   +41-22-7850314

Newsgroups: gnu.gcc.bug
From: rms@gnu.ai.mit.edu (Richard Stallman)
Subject: Is "...", instead of ",..." legal ?
Organization: GNUs Not Usenet
Distribution: gnu
Date: Fri, 14 Aug 1992 14:43:53 GMT

There is no US law prohibiting a declaration of the form
    int foo (...);
so it must be legal here.  If you want to know about Australian law,
you'll have to ask an Australian lawyer.

However, perhaps what you really want to know is whether it is valid C.
It is not valid according to ANSI C.  However, GCC will let you write it.



Newsgroups: gnu.gcc.bug