Bug Report

[cuse <deanh@iphone-e.windata.com>]

The GCC version: 2.95.2
The System type: Suse 6.3
All options: default
The output:
stage1/xgcc -Bstage1/ -B/usr/local/i586-pc-linux-gnu/bin/ -c 
-DIN_GCC     -O2 -
g -O2  -DHAVE_CONFIG_H    -I. -I/home/deanh/gcc-2.95.2/gcc
-I/home/deanh/gcc-2.9
5.2/gcc/config -I/home/deanh/gcc-2.95.2/gcc/../include
/home/deanh/gcc-2.95.2/gc
c/flow.c
xgcc: Internal compiler error: program cc1 got fatal signal 4
make[2]: *** [flow.o] Error 1
make[2]: Leaving directory `/home/deanh/gcc-obj/gcc'
make[1]: *** [bootstrap] Error 2
make[1]: Leaving directory `/home/deanh/gcc-obj/gcc'
make: *** [bootstrap] Error 2
root@iphone-e:/home/deanh/gcc-obj >
>From mark@codesourcery.com Fri Mar 17 15:04:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: Nathan Sidwell <nathan@codesourcery.com>
Cc: gcc-bugs@gcc.gnu.org, Jason Merrill <jason@cygnus.com>
Subject: Your patch
Date: Fri, 17 Mar 2000 15:04:00 -0000
Message-id: <20000317151139A.mitchell@codesourcery.com>
X-SW-Source: 2000-03/msg00784.html
Content-length: 2220

  2000-03-17  Nathan Sidwell  <nathan@codesourcery.com>

	* typeck.c (require_complete_type): Don't assume size_zero_node.
	(complete_type_or_else): Likewise.

This patch broke the following small test-case:

  template <class T>
  struct S
  {
    int x[0];
  };

  template struct S<int>;

The bug is that we're trying to use a zero size to indicate both an
incomplete partial instantiation and a legitimate zero-sized entity
(namely an array with no elements.)  Once again, we see how extensions
can bite us.  

The zero-sized array extension has certainly caused far more trouble
in C++ land than it merits.  In C++, you can ever overload operator
new for a structure to automatically allocate the right number of
elements.  For example:

  struct S {
    int x[1];

    void* operator new (int n, size_t s) {
      return ::operator new (s + (n - 1) * sizeof (int));
    }
  };

  new (2) S; // Creates an S where x has room for two elements.

You have to do this anyhow, if you expect dynamic allocation to work,
and it doesn't make sense to allocate these objects in any way that's
not dynamic.  So, the only argument for keeping this extension is
compatibility with GNU C.  But, you can always compile GNU C programs
with GNU C, so for this to matter, you're taking little bits of GNU C
programs and putting them in your C++ programs.  That doesn't work in
general anyhow, and I see no reason to support this particular
anomalous behavior.

In addition, there are all kinds of nasty issues about template
instantiation where zero-sized arrays are concerned; fundamentally,
you can't provide zero-sized arrays as an extension without changing
the meaning of conforming programs.

I think we should just remove this extension, in C++.  But, if Jason
objects, then, Nathan, we need to find a way to separate the two kinds
of zeroness.  I think integer_zero_node was used instead of
size_zero_node exactly for this reason.  Nathan, why did Kenner's
change result in incomplete types having zero-sized, but not
size_zero_node, types for their size?  Jason, do you object to
removing this extension?

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
>From martin@loewis.home.cs.tu-berlin.de Fri Mar 17 15:57:00 2000
From: "Martin v. Loewis" <martin@loewis.home.cs.tu-berlin.de>
To: mark@codesourcery.com
Cc: nathan@codesourcery.com, gcc-bugs@gcc.gnu.org, jason@cygnus.com
Subject: Re: Your patch
Date: Fri, 17 Mar 2000 15:57:00 -0000
Message-id: <200003172353.AAA25005@loewis.home.cs.tu-berlin.de>
References: <20000317151139A.mitchell@codesourcery.com>
X-SW-Source: 2000-03/msg00785.html
Content-length: 475

> I think we should just remove this extension, in C++.

That would be certainly a good idea. However, please note that C99
introduces a new feature, namely flexible array members:

struct S{
  int count;
  int fields[];
};

So I think g++ *will* have to support this feature of C99, perhaps
only in contexts where it was well-formed C99. If you remove
zero-sized arrays now, it might be worthwhile considering how flexible
array members can be implemented.

Regards,
Martin
>From mark@codesourcery.com Fri Mar 17 16:11:00 2000
From: Mark Mitchell <mark@codesourcery.com>
To: martin@loewis.home.cs.tu-berlin.de
Cc: nathan@codesourcery.com, gcc-bugs@gcc.gnu.org, jason@cygnus.com
Subject: Re: Your patch
Date: Fri, 17 Mar 2000 16:11:00 -0000
Message-id: <20000317161830Z.mitchell@codesourcery.com>
References: <20000317151139A.mitchell@codesourcery.com> <200003172353.AAA25005@loewis.home.cs.tu-berlin.de>
X-SW-Source: 2000-03/msg00786.html
Content-length: 691

>>>>> "Martin" == Martin v Loewis <martin@loewis.home.cs.tu-berlin.de> writes:

    Martin> So I think g++ *will* have to support this feature of C99,

Well, that depends on the C++ committee, but it does seem quite
possible.

    Martin> perhaps only in contexts where it was well-formed C99. If
    Martin> you remove zero-sized arrays now, it might be worthwhile
    Martin> considering how flexible array members can be implemented.

This is a good point.  I'm not withdrawing my proposal to remove the
extension, but I would like to understand Nathan's change better.

--
Mark Mitchell                   mark@codesourcery.com
CodeSourcery, LLC               http://www.codesourcery.com
>From mrs@windriver.com Fri Mar 17 16:27:00 2000
From: Mike Stump <mrs@windriver.com>
To: mark@codesourcery.com, martin@loewis.home.cs.tu-berlin.de
Cc: gcc-bugs@gcc.gnu.org, jason@cygnus.com, nathan@codesourcery.com
Subject: Re: Your patch
Date: Fri, 17 Mar 2000 16:27:00 -0000
Message-id: <200003180026.QAA24790@kankakee.wrs.com>
X-SW-Source: 2000-03/msg00787.html
Content-length: 801

> From: Mark Mitchell <mark@codesourcery.com>
> Date: Fri, 17 Mar 2000 16:18:30 -0800

>     Martin> So I think g++ *will* have to support this feature of C99,

> Well, that depends on the C++ committee, but it does seem quite
> possible.

Nay...  :-) If something in a later C standard just plugs into C++,
then it'll just be added, if it doesn't, then we should route the
concern to the two committees and let them sort it out.  If we want to
be more proactive, we should sort it out based upon what we like, and
what our users like, and implement that, see how well it works, and
propose that to the two committees with our experience with it.

Remember, in an ideal world, they just standardize what _we_ come up
with.  :-)  The only trick, is to come up with the right answer in the
first place.
>From jason@cygnus.com Fri Mar 17 16:41:00 2000
From: Jason Merrill <jason@cygnus.com>
To: Mark Mitchell <mark@codesourcery.com>
Cc: Nathan Sidwell <nathan@codesourcery.com>, gcc-bugs@gcc.gnu.org
Subject: Re: Your patch
Date: Fri, 17 Mar 2000 16:41:00 -0000
Message-id: <u94sa5hzz3.fsf@yorick.cygnus.com>
References: <20000317151139A.mitchell@codesourcery.com>
X-SW-Source: 2000-03/msg00788.html
Content-length: 149

I'm opposed to removing this extension; we want to be able to use GNU C
headers.

Would it work to just change size_zero_node to bitsizetype?

Jason
>From nomura@netapp.com Fri Mar 17 17:05:00 2000
From: Kevin Nomura <nomura@netapp.com>
To: gcc-bugs@gcc.gnu.org
Subject: -x assembler-with-cpp problem on alpha-osf hosts
Date: Fri, 17 Mar 2000 17:05:00 -0000
Message-id: <38D2D6C5.4BAE847E@netapp.com>
X-SW-Source: 2000-03/msg00789.html
Content-length: 4685

     The GCC version: 2.95.1
     The system type: OSF1 V4.0 1229 alpha or similar
     All options you passed to the compiler: gcc -x assembler-with-cpp
-s a.s  -c
     Preprocessed output of the source file that caused the compiler
error, even if the source code can be downloaded from
     elsewhere

File a.s:
============================================
#define ENTRY(x)                .globl x; .ent x; x:
ENTRY(rpcc64)
        rpcc    $0
        ret
.end rpcc64
============================================

Compile as follows:

[pollux]$ gcc -x assembler-with-cpp -s a.s  -c -v
Reading specs from
/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/specs
gcc version 2.95.1 19990816 (release)
 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/cpp -lang-asm -v -$
-Dunix -D__osf__ -D_LONGLONG -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__
-D__osf__ -D_LONGLONG -D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix
-D__SYSTYPE_BSD -Asystem(unix) -Asystem(xpg4) -D__ASSEMBLER__
-D__LANGUAGE_C__ -D__LANGUAGE_C -DLANGUAGE_C -Acpu(alpha)
-Amachine(alpha) -D__alpha -D__alpha__ -D__alpha_ev5__ -Acpu(ev5)
-D__alpha_bwx__ -Acpu(bwx) a.s /tmp/ccRHOnRA.s
GNU CPP version 2.95.1 19990816 (release)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/../../../../alphaev56-dec-osf4.0d/include

 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/include
 /usr/include
End of search list.
The following default directories have been omitted from the search
path:
 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/../../../../include/g++-3

End of omitted list.
 as -g -nocpp -O0 -o a.o /tmp/ccRHOnRA.s
 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/mips-tfile -v -o
a.o a.s
mips-tfile version 2.95.1 19990816 (release)
mips-tfile, a.s:5 .end directive without a preceding .ent directive
line:   .end rpcc64

=========================================

Note the syntax errors at the bottom of the preceding output; these
would not occur if the file were named ".S" (which implies preprocessing
just as "-x assembler-with-cpp" does).

Here is my analysis of the problem.  The file requires preprocessing,
but the name (which I am not at liberty to change) is ".s" rather than
".S".  So I specify "-x assembler-with-cpp" to have preprocessing
applied to the file.  As the -v output shows, the preprocessor is run,
followed by the assembler, so far so good.

Then the "mips-tfile" utility is run.  This is apparently some
post-assembly tool run on systems that use ECOFF.  mips-tfile takes the
object file (just produced from as) as one argument and the .s file as
the other argument.  The problem is that the original .s file is given
to mips-tfile instead of the preprocessed .s file in /tmp/ccRHOnRA.s.
This exposes preprocessing directives to mips-tfile that it is not
equipped to handle and results in syntax errors.

If gcc is invoked on a ".S" file, then "as" followed by mips-tfile are
invoked just as they are with "-x assembler-with-cpp", except mips-tfile
is supplied with the preprocessed assembly file.  This works correctly.
My understanding is the two scenarios should be equivalent, so we need
to make "-x assembler-with-cpp" pass in the preprocessed name the same
way that a source file named ".S" arranges to happen.  The ".S" path is
illustrated below:

==========================================

[pollux]$ gcc  -s b.S  -c -v
Reading specs from
/usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/specs
gcc version 2.95.1 19990816 (release)
 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/cpp -lang-asm -v -$
-Dunix -D__osf__ -D_LONGLONG -DSYSTYPE_BSD -D_SYSTYPE_BSD -D__unix__
-D__osf__ -D_LONGLONG -D__SYSTYPE_BSD__ -D_SYSTYPE_BSD -D__unix
-D__SYSTYPE_BSD -Asystem(unix) -Asystem(xpg4) -D__ASSEMBLER__
-D__LANGUAGE_ASSEMBLY__ -D__LANGUAGE_ASSEMBLY -DLANGUAGE_ASSEMBLY
-Acpu(alpha) -Amachine(alpha) -D__alpha -D__alpha__ -D__alpha_ev5__
-Acpu(ev5) -D__alpha_bwx__ -Acpu(bwx) b.S /tmp/ccQ0E1FL.s
GNU CPP version 2.95.1 19990816 (release)
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/include
 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/../../../../alphaev56-dec-osf4.0d/include

 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/include
 /usr/include
End of search list.
The following default directories have been omitted from the search
path:
 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/../../../../include/g++-3

End of omitted list.
 as -g -nocpp -O0 -o b.o /tmp/ccQ0E1FL.s
 /usr/local/lib/gcc-lib/alphaev56-dec-osf4.0d/2.95.1/mips-tfile -v -o
b.o /tmp/ccQ0E1FL.s
mips-tfile version 2.95.1 19990816 (release)
[pollux]$