This is the mail archive of the gcc-bugs@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

[Internal Compiler Error 2.95.2] Partially Bracketed Array Initialization


Hi,

An array initializer without properly bracketing each array item crashes
g++ , a self-contained crashing example file attached.

Our original code compiled quite well under gcc-2.7.2 (Suse linux 5.1
SMP libc),  egcs-2.91.66 (Redhat 6.1 SMP, glibc) , and gcc 2.8.1 (Sparc
Solaris 2.7), even Dec cxx DUX4.
However, gcc 2.95.2 complained about partially bracketd aggregate on
array initilizer items that are not properly bracketed, for instance:
typedef __bonkStruct {
    char *foo;
    char *bar;
} bonkStruct;

bonkStruct blahArray[] ] {
    "1-1", "1-2",
    "2-1", "2-2"
};
That was ok even with the warnings, because the end result program still
ran correctly.


But the next case will crash gcc-2.95.2
class BoomClass
{
};

typedef __boomStruct {
    char *foo;
    BoomClass *ouch;
    char *bar;
} bommStruct;

boomClass bang;

boomStruct boomArray[] = {
    "1-1", &bang, "1-3",
    "2-1", &bang, "2-3"
};

gcc simply reports an internal error, and asks for bug report. The
example code attached crashes 2.95.2 (Suse 5.1 I686) but not
egcs-2.91.66 (RedHat 6.1 I686)

If the boomArray were properly bracketed, gcc goes just fine.
boomStruct noBoomArray [] = {
    {"1-1", &bang, "1-3"},
    {"2-1", &bang, "2-3"}
};

I guess gcc 2.95.2 should've complained and stoped instead of crashed.

Below is the system environment that produced the crash.


gcc version:
Reading specs from
/usr/local/lib/gcc-lib/i686-pc-linux-gnulibc1/2.95.2/specs
gcc version 2.95.2 19991024 (release)

Command given to gcc:
gcc -c Test.C

Host system:
Suse Linux 5.1, I686 SMP, Libc.

Stock gcc 2.95.2 dowloaded from ftp.gnu.org, no mod. gcc compilation
objects seperated from src. Compiled with "make bootstrap MAKE="gcc -j
2" -j 2.

BTW, the gcc parallel make sometimes over-run itself by trying to
compile files before .../ginclude/* were completely copied to
.../include , so the 2nd forked compilation can't find proper .h files .
But try it again, and it may just work. Guess it's the nature of
parallel compilation unless there are task-sequence provisions in gmake.




Jonah Tsai


class SproutOperator
{
};


typedef struct __operatorDesc {
  char *leftOperand;
  SproutOperator *op;
  char *rightOperand;
  char *result;


} operatorDesc;

SproutOperator junk;

operatorDesc junkRealOpDesc[] = {
  "Junk", &junk, "JunkReal", "Junk"
};


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]