This is GCC Bugzilla
This is GCC Bugzilla Version 2.20+
View Bug Activity | Format For Printing | Clone This Bug
I cannot compile the file src/DataBrowser/DataBrowser.cmpl.cpp from pooma-gcc any more. Earlier gcc 3.4 snapshoths had no problems compiling it. g++ -v -c /home/peter/zuhause/home/trans/c++/pooma-gcc/src/DataBrowser/ DataBrowser.cmpl.cpp -o /home/peter/zuhause/home/trans/c++/pooma-gcc/src/ DataBrowser/LINUXgcc/DataBrowser.cmpl.o -ftemplate-depth-60 -Drestrict=__restrict__ -DNOPAssert -DNOCTAssert -I/home/peter/zuhause/home/ trans/c++/pooma-gcc/src -I/home/peter/zuhause/home/trans/c++/pooma-gcc/lib/ LINUXgcc Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Configured with: ../gcc/configure --enable-threads=posix --enable-languages=c,c ++,f77,objc --enable-__cxa_atexit --enable-libstdcxx-debug Thread model: posix gcc version 3.4.0 20040312 (prerelease) /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.0/cc1plus -quiet -v -I/home/ peter/zuhause/home/trans/c++/pooma-gcc/src -I/home/peter/zuhause/home/trans/c+ +/pooma-gcc/lib/LINUXgcc -D_GNU_SOURCE -Drestrict=__restrict__ -DNOPAssert -DNOCTAssert /home/peter/zuhause/home/trans/c++/pooma-gcc/src/DataBrowser/ DataBrowser.cmpl.cpp -quiet -dumpbase DataBrowser.cmpl.cpp -mtune=pentiumpro -auxbase-strip /home/peter/zuhause/home/trans/c++/pooma-gcc/src/DataBrowser/ LINUXgcc/DataBrowser.cmpl.o -version -ftemplate-depth-60 -o /tmp/ccZ1UkPd.s ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/lib/gcc/ i686-pc-linux-gnu/3.4.0/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /home/peter/zuhause/home/trans/c++/pooma-gcc/src /home/peter/zuhause/home/trans/c++/pooma-gcc/lib/LINUXgcc /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0 /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/ i686-pc-linux-gnu /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/ backward /usr/local/include /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/include /usr/include End of search list. GNU C++ version 3.4.0 20040312 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 3.4.0 20040312 (prerelease). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64274 In file included from /home/peter/zuhause/home/trans/c++/pooma-gcc/src/Domain/ Domain.h:63, from /home/peter/zuhause/home/trans/c++/pooma-gcc/src/Domain/ Interval.h:57, from /home/peter/zuhause/home/trans/c++/pooma-gcc/src/Layout/ INode.h:53, from /home/peter/zuhause/home/trans/c++/pooma-gcc/src/Layout/ SparseTileLayout.h:63, from /home/peter/zuhause/home/trans/c++/pooma-gcc/src/Engine/ IsValidLocation.h:55, from /home/peter/zuhause/home/trans/c++/pooma-gcc/src/Array/ PrintArray.h:57, from /home/peter/zuhause/home/trans/c++/pooma-gcc/src/ DataBrowser/DataBrowser.cmpl.cpp:30: /home/peter/zuhause/home/trans/c++/pooma-gcc/src/Domain/DomainBase.h: In member function `typename DT::AskDomain_t DomainBase<DT>::firsts() const': /home/peter/zuhause/home/trans/c++/pooma-gcc/src/Domain/DomainBase.h:215: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions
Created an attachment (id=5903) [edit] Bzip2 compressed preprocessed source file DataBrowser.cmpl.ii
This is a regression from 3.3.1. Here is the back trace: #0 value_dependent_expression_p (expression=0x0) at /home/gates/pinskia/src/gnu/gcc/src/gcc/ cp/pt.c:11755 #1 0x0808edbb in fold_non_dependent_expr (expr=0x406d5794) at /home/gates/pinskia/src/gnu/ gcc/src/gcc/cp/pt.c:3134 #2 0x080e65de in cp_parser_initializer_clause (parser=0x4028bac0, non_constant_p=0xbffebf87) at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:11537 #3 0x080f000c in cp_parser_init_declarator (parser=0x4028bac0, decl_specifiers=0x406d54ec, prefix_attributes=0x0, function_definition_allowed_p=false, member_p=false, declares_class_or_enum=0, function_definition_p=0xbffebfb7) at /home/gates/pinskia/src/gnu/gcc/ src/gcc/cp/parser.c:11489 #4 0x080ea854 in cp_parser_simple_declaration (parser=0x4028bac0, function_definition_allowed_p=false) at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:6575 #5 0x080ea9c8 in cp_parser_block_declaration (parser=0x4028bac0, statement_p=true) at /home/ gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:6491 #6 0x080eaf63 in cp_parser_statement (parser=0x4028bac0, in_statement_expr_p=false) at /home/ gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:6199 #7 0x080eb58b in cp_parser_compound_statement (parser=0x4028bac0, in_statement_expr_p=false) at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:5741 #8 0x080ef780 in cp_parser_ctor_initializer_opt_and_function_body (parser=0x4028bac0) at /home/ gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:11429 #9 0x080efa7f in cp_parser_function_definition_after_declarator (parser=0x4028bac0, inline_p=true) at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:14288 #10 0x080e990a in cp_parser_type_specifier (parser=0x4028bac0, flags=Variable "flags" is not available.) at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:14679 #11 0x080ea49e in cp_parser_decl_specifier_seq (parser=0x4028bac0, flags=CP_PARSER_FLAGS_OPTIONAL, attributes=0xbffec1b0, declares_class_or_enum=0xbffec1b4) at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:6805 #12 0x080f02e1 in cp_parser_single_declaration (parser=0x4028bac0, member_p=false, friend_p=0xbffec1eb) at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:14413 #13 0x080e8241 in cp_parser_template_declaration_after_export (parser=0x4028bac0, member_p=false) at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:14352 #14 0x080f0a81 in cp_parser_declaration (parser=0x4028bac0) at /home/gates/pinskia/src/gnu/gcc/ src/gcc/cp/parser.c:6385 #15 0x080f0c1f in cp_parser_declaration_seq_opt (parser=0x8479de6) at /home/gates/pinskia/src/ gnu/gcc/src/gcc/cp/parser.c:6309 #16 0x080f0deb in c_parse_file () at /home/gates/pinskia/src/gnu/gcc/src/gcc/cp/parser.c:2383 #17 0x0817a975 in c_common_parse_file (set_yydebug=138911206) at /home/gates/pinskia/src/ gnu/gcc/src/gcc/c-opts.c:1248 #18 0x083ae940 in toplev_main (argc=138911206, argv=0xbffec384) at /home/gates/pinskia/src/ gnu/gcc/src/gcc/toplev.c:1575 #19 0x0817e35e in main (argc=138911206, argv=0x8479de6) at /home/gates/pinskia/src/gnu/gcc/ src/gcc/main.c:35
Here is a reduced version of the testcase: source code t.C t.C class NoInit {}; template<class DT> class DomainBase { public: typedef typename DT::AskDomain_t AskDomain_t; typedef typename DT::Domain_t Domain_t; inline Domain_t &unwrap() { return *static_cast<Domain_t *>(this); } const Domain_t &unwrap() const { return *static_cast<Domain_t *>(const_cast<DomainBase<DT> *>(this)); } AskDomain_t firsts() const { AskDomain_t retval = NoInit(); int i = 1; retval[i] = unwrap()[i].first(); return retval; } }; The initialisation with NoInit() is responsible for the ice. When I remove the unwrap functions and the Domain_t typedef the code still ices. I have no idea whether the code is then still legal, though. g++ -v -c t.C Reading specs from /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/specs Configured with: ../gcc/configure --enable-threads=posix --enable-languages=c,c ++,f77,objc --enable-__cxa_atexit --enable-libstdcxx-debug Thread model: posix gcc version 3.4.0 20040313 (prerelease) /usr/local/libexec/gcc/i686-pc-linux-gnu/3.4.0/cc1plus -quiet -v -D_GNU_SOURCE t.C -quiet -dumpbase t.C -mtune=pentiumpro -auxbase t -version -o /tmp/ ccGy3M7a.s ignoring nonexistent directory "NONE/include" ignoring nonexistent directory "/usr/local/lib/gcc/ i686-pc-linux-gnu/3.4.0/../../../../i686-pc-linux-gnu/include" #include "..." search starts here: #include <...> search starts here: /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0 /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/ i686-pc-linux-gnu /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/../../../../include/c++/3.4.0/ backward /usr/local/include /usr/local/lib/gcc/i686-pc-linux-gnu/3.4.0/include /usr/include End of search list. GNU C++ version 3.4.0 20040313 (prerelease) (i686-pc-linux-gnu) compiled by GNU C version 3.4.0 20040313 (prerelease). GGC heuristics: --param ggc-min-expand=64 --param ggc-min-heapsize=64274 t.C: In member function `typename DT::AskDomain_t DomainBase<DT>::firsts() const': t.C:18: internal compiler error: Segmentation fault Please submit a full bug report, with preprocessed source if appropriate. See <URL:http://gcc.gnu.org/bugs.html> for instructions.
Confirmed with the shorter testcase, I almost think it was caused by: 2004-03-09 Giovanni Bajo <giovannibajo@gcc.gnu.org> PR c++/14448 * parser.c (cp_parser_initializer_clause): Fold initializer if it is non-dependent. * pt.c (tsubst_copy_and_build): Handle NOP_EXPRs.
Redux: ---------------------------------------------- struct A {}; template <class T> struct B { void foo() { A retval = A(); } }; ---------------------------------------------- Exposed by my patch, as Andrew noticed. I'm looking into it. Meanwhile, this is very serious and I think it is a showstopper. Mark, can I target this to 3.4.0?
This is very similar to c++/14550, we just need to notice that a constructor call in functional cast form is not an integral constant expression. I'm updating my patch to reflect Mark's today change to cp_parser_non_integral_constant_expression and I will submit the patch as soon as testing finishes.
*** Bug 14605 has been marked as a duplicate of this bug. ***
Patch posted, waiting for review: http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01265.html
Subject: Re: [3.4/3.5 Regression] Cannot compile pooma-gcc (regression) giovannibajo at libero dot it wrote: >------- Additional Comments From giovannibajo at libero dot it 2004-03-17 01:19 ------- >Patch posted, waiting for review: >http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01265.html > > Thanks. Actually, I disagree that we should build TARGET_EXPRs in templates. We should defer building these kinds of complex tree structures until instantiation time. Indeed, I think you should just check "!type_dependent_expression_p (type) && !INTEGRAL_OR_ENUMERATION_TYPE_P (type)". I can't remember if that's *quite* right; it might be that casts to floating-point types should also be allowed. You'll have to check the standard for that. Would you mind trying that approach please?
Subject: Re: [3.4/3.5 Regression] Cannot compile pooma-gcc (regression) mark at codesourcery dot com wrote: >> Patch posted, waiting for review: >> http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01265.html >> > Indeed, I think you should just check "!type_dependent_expression_p > (type) && !INTEGRAL_OR_ENUMERATION_TYPE_P (type)". I can't remember > if that's *quite* right; it might be that casts to floating-point types > should also be allowed. You'll have to check the standard for that. > Would you mind trying that approach please? This patch implements your suggestion. I checked the standard and you are right, only casts to integral or enumeration types are allowed in integral constant expressions. The patch was tested on i686-pc-linux-gnu with no new regressions, OK for 3.4 and mainline? Giovanni Bajo 2004-03-16 Giovanni Bajo <giovannibajo@gcc.gnu.org> PR c++/14545 * parser.c (cp_parser_functional_cast): A cast to anything but integral or enumaration type is not an integral constant expression. 2004-03-16 Giovanni Bajo <giovannibajo@gcc.gnu.org> PR c++/14545 * g++.dg/parse/template15.C: New test. Index: parser.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cp/parser.c,v retrieving revision 1.183 diff -c -3 -p -r1.183 parser.c *** parser.c 16 Mar 2004 22:17:59 -0000 1.183 --- parser.c 18 Mar 2004 01:04:57 -0000 *************** static tree *** 14477,14488 **** cp_parser_functional_cast (cp_parser* parser, tree type) { tree expression_list; expression_list = cp_parser_parenthesized_expression_list (parser, false, /*non_constant_p=*/NULL); ! return build_functional_cast (type, expression_list); } /* Save the tokens that make up the body of a member function defined --- 14477,14499 ---- cp_parser_functional_cast (cp_parser* parser, tree type) { tree expression_list; + tree cast; expression_list = cp_parser_parenthesized_expression_list (parser, false, /*non_constant_p=*/NULL); ! cast = build_functional_cast (type, expression_list); ! /* [expr.const]/1: In an integral constant expression "only type ! conversions to integral or enumeration type can be used". */ ! if (cast != error_mark_node && !type_dependent_expression_p (type) ! && !INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (type))) ! { ! if (cp_parser_non_integral_constant_expression ! (parser, "a call to a constructor")) ! return error_mark_node; ! } ! return cast; } /* Save the tokens that make up the body of a member function defined // { dg-do compile } // Contributed by: Peter Schmid // <schmid at snake dot iap dot physik dot tu-darmstadt dot de> // PR c++/14545: constructor calls are not integer constant expressions struct A1 { A1(); }; struct A2 { }; template <class T> struct B { void foo() { A1(); A1 a1 = A1(); A2(); A2 a2 = A2(); } }; template struct B<void>;
I just happened to find the same bug in my code, and after reduction I found this, probably shortest possible, code snippet: --------------------- template <int> void f() { int i = int(); } template void f<1> (); --------------------- :-)
Subject: Re: [3.4/3.5 Regression] Cannot compile pooma-gcc (regression) bangerth at dealii dot org wrote: > I just happened to find the same bug in my > code, and after reduction I found this, probably > shortest possible, code snippet: > --------------------- > template <int> void f() { int i = int(); } > template void f<1> (); > --------------------- Actually, this is not fixed by my patch, I'm updating it right now. Thanks for the reduction. Giovanni Bajo
Oh, hell. I was just posting this as an amusement for everyone, because it is so _really_ short. How can we _not_ get this right? This whole business with non-dependent initializers has run somehow out of control given how late we are in the release cycle. We must have had at least a dozen different reports about this problem. Has anyone considered reverting the patch that introduced this instability? We seem to be stomping out fires that keep popping up everywhere... W.
Subject: Re: [3.4/3.5 Regression] Cannot compile pooma-gcc (regression) bangerth at dealii dot org wrote: >------- Additional Comments From bangerth at dealii dot org 2004-03-18 15:08 ------- >Oh, hell. I was just posting this as an amusement for everyone, because >it is so _really_ short. How can we _not_ get this right? > >This whole business with non-dependent initializers has run somehow >out of control given how late we are in the release cycle. We must have >had at least a dozen different reports about this problem. Has anyone >considered reverting the patch that introduced this instability? We seem >to be stomping out fires that keep popping up everywhere... > > Yes, I've been considering reverting that patch. However, some of the problems we've found would have arisen in other contexts as well; that's just where they happened so show up. Falsely assuming that something is an integral constant-expression (which has been the source of several of the bugs) could result in many other problems as well. I hope to look at this some more today.
OK, very good. BTW, this bug has as target 3.4.1. I really think we should have this fixed for 3.4.0, or we'll get dozens of reports... W.
Subject: Re: [3.4/3.5 Regression] Cannot compile pooma-gcc (regression) bangerth at dealii dot org wrote: > This whole business with non-dependent initializers has run somehow > out of control given how late we are in the release cycle. We must > have had at least a dozen different reports about this problem. Has anyone > considered reverting the patch that introduced this instability? We > seem to be stomping out fires that keep popping up everywhere... The patch just helps finding latent problems, really. It's not that the patch was not complete or instable, it just somehow helps uncovering problems with our detection of constant expressions. Plus, we're making big progress, because now it's always possible to use const locals as template arguments while before it was failing very often. Anyway, this is the updated patch, and I'm running the regression test right now. OK for mainline and 3.4 if it passes? Giovanni Bajo 2004-03-16 Giovanni Bajo <giovannibajo@gcc.gnu.org> PR c++/14545 * parser.c (cp_parser_functional_cast): A cast to anything but integral or enumaration type is not an integral constant expression. * pt.c (value_dependent_expression_p): Handle cast expressions without operands (such as "int()"). 2004-03-16 Giovanni Bajo <giovannibajo@gcc.gnu.org> PR c++/14545 * g++.dg/parse/template15.C: New test. Index: parser.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cp/parser.c,v retrieving revision 1.183 diff -c -3 -p -r1.183 parser.c *** parser.c 16 Mar 2004 22:17:59 -0000 1.183 --- parser.c 18 Mar 2004 01:04:57 -0000 *************** static tree *** 14477,14488 **** cp_parser_functional_cast (cp_parser* parser, tree type) { tree expression_list; expression_list = cp_parser_parenthesized_expression_list (parser, false, /*non_constant_p=*/NULL); ! return build_functional_cast (type, expression_list); } /* Save the tokens that make up the body of a member function defined --- 14477,14499 ---- cp_parser_functional_cast (cp_parser* parser, tree type) { tree expression_list; + tree cast; expression_list = cp_parser_parenthesized_expression_list (parser, false, /*non_constant_p=*/NULL); ! cast = build_functional_cast (type, expression_list); ! /* [expr.const]/1: In an integral constant expression "only type ! conversions to integral or enumeration type can be used". */ ! if (cast != error_mark_node && !type_dependent_expression_p (type) ! && !INTEGRAL_OR_ENUMERATION_TYPE_P (TREE_TYPE (type))) ! { ! if (cp_parser_non_integral_constant_expression ! (parser, "a call to a constructor")) ! return error_mark_node; ! } ! return cast; } /* Save the tokens that make up the body of a member function defined Index: pt.c =================================================================== RCS file: /cvs/gcc/gcc/gcc/cp/pt.c,v retrieving revision 1.840 diff -c -3 -p -r1.840 pt.c *** pt.c 16 Mar 2004 22:18:05 -0000 1.840 --- pt.c 18 Mar 2004 14:43:40 -0000 *************** value_dependent_expression_p (tree expre *** 11776,11785 **** || TREE_CODE (expression) == REINTERPRET_CAST_EXPR || TREE_CODE (expression) == CAST_EXPR) { ! if (dependent_type_p (TREE_TYPE (expression))) return true; /* A functional cast has a list of operands. */ expression = TREE_OPERAND (expression, 0); if (TREE_CODE (expression) == TREE_LIST) { do --- 11776,11796 ---- || TREE_CODE (expression) == REINTERPRET_CAST_EXPR || TREE_CODE (expression) == CAST_EXPR) { ! tree type = TREE_TYPE (expression); ! if (dependent_type_p (type)) return true; /* A functional cast has a list of operands. */ expression = TREE_OPERAND (expression, 0); + if (!expression) + { + /* If there are no operands, it must be an expression such + as "int()". This should not happen for aggregate types + because it would form non-constant expressions. */ + my_friendly_assert (INTEGRAL_OR_ENUMERATION_TYPE_P (type), + 20040318); + + return false; + } if (TREE_CODE (expression) == TREE_LIST) { do // { dg-do compile } // Contributed by: Peter Schmid // <schmid at snake dot iap dot physik dot tu-darmstadt dot de> // PR c++/14545: constructor calls are not integer constant expressions struct A1 { A1(); }; struct A2 { }; template <class T> struct B { void foo() { A1(); A1 a1 = A1(); A2(); A2 a2 = A2(); int(); int a3 = int(); float(); float a4 = float(); } }; template struct B<void>;
Subject: Re: [3.4/3.5 Regression] Cannot compile pooma-gcc (regression) giovannibajo at libero dot it wrote: >------- Additional Comments From giovannibajo at libero dot it 2004-03-18 15:31 ------- >Subject: Re: [3.4/3.5 Regression] Cannot compile pooma-gcc (regression) > >bangerth at dealii dot org wrote: > > > >>This whole business with non-dependent initializers has run somehow >>out of control given how late we are in the release cycle. We must >>have had at least a dozen different reports about this problem. Has anyone >>considered reverting the patch that introduced this instability? We >>seem to be stomping out fires that keep popping up everywhere... >> >> > >The patch just helps finding latent problems, really. It's not that the patch >was not complete or instable, it just somehow helps uncovering problems with >our detection of constant expressions. Plus, we're making big progress, because >now it's always possible to use const locals as template arguments while before >it was failing very often. > > Right. The follow-on patches that we've been making have definitely been fixing bugs; we'd want them independently of the initializer patch. >Anyway, this is the updated patch, and I'm running the regression test right >now. OK for mainline and 3.4 if it passes? > Yes, this patch looks good. Thanks!
Please don't get me wrong -- I certainly appreciate you efforts to make us get closer to conformance. I was just concerned with us trading rare rejects-valid on code for which we don't get a whole lot of reports, with a significant number of ice-on-valid on really common code. That would be alright for mainline, and I was just asking what to do for the upcoming release. I don't want this to be understood as compaining. That being said, you seem to get somewhere with the fixes, so let's just wait and see whether we get more reports. Thanks W.
Subject: Bug 14545 CVSROOT: /cvs/gcc Module name: gcc Changes by: giovannibajo@gcc.gnu.org 2004-03-19 09:58:51 Modified files: gcc/cp : ChangeLog parser.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: template15.C Log message: PR c++/14545 * parser.c (cp_parser_functional_cast): A cast to anything but integral or enumaration type is not an integral constant expression. * pt.c (value_dependent_expression_p): Handle cast expressions without operands (such as "int()"). PR c++/14545 * g++.dg/parse/template15.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&r1=1.4003&r2=1.4004 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&r1=1.185&r2=1.186 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&r1=1.841&r2=1.842 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&r1=1.3617&r2=1.3618 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/template15.C.diff?cvsroot=gcc&r1=NONE&r2=1.1
Subject: Bug 14545 CVSROOT: /cvs/gcc Module name: gcc Branch: gcc-3_4-branch Changes by: giovannibajo@gcc.gnu.org 2004-03-19 11:41:32 Modified files: gcc/cp : ChangeLog parser.c pt.c gcc/testsuite : ChangeLog Added files: gcc/testsuite/g++.dg/parse: template15.C Log message: PR c++/14545 * parser.c (cp_parser_functional_cast): A cast to anything but integral or enumaration type is not an integral constant expression. * pt.c (value_dependent_expression_p): Handle cast expressions without operands (such as "int()"). PR c++/14545 * g++.dg/parse/template15.C: New test. Patches: http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3892.2.85&r2=1.3892.2.86 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/parser.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.157.2.24&r2=1.157.2.25 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/cp/pt.c.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.816.2.19&r2=1.816.2.20 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/ChangeLog.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=1.3389.2.150&r2=1.3389.2.151 http://gcc.gnu.org/cgi-bin/cvsweb.cgi/gcc/gcc/testsuite/g++.dg/parse/template15.C.diff?cvsroot=gcc&only_with_tag=gcc-3_4-branch&r1=NONE&r2=1.1.2.1
Fixed for GCC 3.4.0 and 3.5.0. Thanks for your report!