Bug 8164

Summary: [3.3 regression] ICE when using different const expressions as template parameter
Product: gcc Reporter: schnoerr
Component: c++Assignee: Mark Mitchell <mmitchel>
Severity: normal CC: gcc-bugs, lerdsuwa, reichelt
Priority: P3 Keywords: ice-on-valid-code, monitored
Version: 3.2   
Target Milestone: 3.3.1   
Host: Target:
Build: Known to work:
Known to fail: Last reconfirmed: 2003-07-10 14:17:10
Attachments: bug2.cc

Description schnoerr 2002-10-07 10:16:01 UTC
g++ bug2.cc -o bug2 -Wall
bug2.cc: In member function `void Test<Rank>::dat_embrace(Test<LowRank>&)':
bug2.cc:32: internal error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://www.gnu.org/software/gcc/bugs.html> for instructions.

in method dat_embrace, the template-rank-parameters are 
checked by a compile-time assert.
It works well for Rank, but fails for LowRank

gcc version 3.2 20020818 (prerelease)

@PC169/.../testThreads$ gcc -v
Reading specs from /bin/../lib/gcc-lib/i686-pc-cygwin/3.2/specs
Configured with: /netrel/src/gcc-3.2-1/configure --enable-languages=c,c++,f77,ja
va --enable-libgcj --enable-threads=posix --with-system-zlib --enable-nls --with
out-included-gettext --enable-interpreter --disable-sjlj-exceptions --disable-ve
rsion-specific-runtime-libs --enable-shared --build=i686-pc-linux --host=i686-pc
-cygwin --target=i686-pc-cygwin --enable-haifa --prefix=/usr --exec-prefix=/usr
--sysconfdir=/etc --libdir=/usr/lib --includedir=/nonexistent/include --libexecd
Thread model: posix
gcc version 3.2 20020818 (prerelease)
Comment 1 schnoerr 2002-10-07 10:16:01 UTC
Prove template parameter LowRank at runtime rather than at compile-time
Comment 2 Kriang Lerdsuwanakij 2002-10-27 06:43:04 UTC
State-Changed-From-To: open->analyzed
State-Changed-Why: Confirmed.
Comment 3 Volker Reichelt 2002-11-05 19:05:27 UTC
From: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
To: schnoerr@mailzone.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org,
Subject: Re: c++/8164: internal error: segmentation fault
Date: Tue, 5 Nov 2002 19:05:27 +0100

 the problem can be reduced to the following code snippet (which looks
 legal to me):
 -------------------------------snip here-------------------------
 template <bool> struct A {};
 template <bool> struct B
   void foo()
     const int i=0;
     typedef A< i<=1 > C;
     typedef A< i<=2 > C;
 -------------------------------snip here-------------------------
 gcc 2.95.x rejects the code with an error message.
 gcc 3.0.x, the 3.2 branch and mainline produce an ICE.

Comment 4 Volker Reichelt 2003-01-15 14:53:32 UTC
From: Volker Reichelt <reichelt@igpm.rwth-aachen.de>
To: schnoerr@mailzone.com, gcc-gnats@gcc.gnu.org, gcc-bugs@gcc.gnu.org
Subject: Re: c++/8164: ICE when using different const expressions as template parameter
Date: Wed, 15 Jan 2003 14:53:32 +0100

 Just for the record,
 the ICE is gone on mainline, but we still have an error message
 which leaves us with a rejects-legal bug:
 PR8164.cc: In member function `void B<<anonymous> >::foo()':
 PR8164.cc:14: error: conflicting types for `typedef struct A<(i <= 2)> C'
 PR8164.cc:13: error: previous declaration as `typedef struct A<(i <= 1)> C'
Comment 5 Wolfgang Bangerth 2003-06-17 20:16:58 UTC
I don't know whether the code should be accepted, but just for the record:
isn't it the case that the condition i<=2 is somehow mangled into the
name of the class, i.e. not only the truth value but the expression? If this
is the case, then the two types may be the same but will have different
names, which would make things a little awkward.

Just a very uninformed opinion,
Comment 7 CVS Commits 2003-07-11 08:54:03 UTC
Subject: Bug 8164

CVSROOT:	/cvs/gcc
Module name:	gcc
Changes by:	mmitchel@gcc.gnu.org	2003-07-11 08:53:59

Modified files:
	gcc/testsuite  : ChangeLog 
Added files:
	gcc/testsuite/g++.dg/template: nontype2.C 

Log message:
	PR c++/8164
	* decl.c (duplicate_decls): Avoid mangling names unnecessarily.
	PR c++/8164
	* g++.dg/template/nontype2.C: New test.
	PR c++/10558
	* g++.dg/parse/template8.C: New test.


Comment 8 Mark Mitchell 2003-07-11 08:54:41 UTC
Fixed in GCC 3.3.1, GCC 3.4.