Bug 14545 - [3.4/4.0 Regression] Cannot compile pooma-gcc (regression)
Summary: [3.4/4.0 Regression] Cannot compile pooma-gcc (regression)
Status: RESOLVED FIXED
Alias: None
Product: gcc
Classification: Unclassified
Component: c++ (show other bugs)
Version: 3.4.0
: P1 critical
Target Milestone: 3.4.0
Assignee: Giovanni Bajo
URL:
Keywords: ice-on-valid-code, monitored, patch
: 14605 (view as bug list)
Depends on:
Blocks: 14579
  Show dependency treegraph
 
Reported: 2004-03-12 06:29 UTC by Peter Schmid
Modified: 2004-10-30 21:11 UTC (History)
5 users (show)

See Also:
Host: i686-pc-linux-gnu
Target: i686-pc-linux-gnu
Build: i686-pc-linux-gnu
Known to work: 3.3.1
Known to fail: 3.4.0 4.0.0
Last reconfirmed: 2004-03-14 03:45:32


Attachments
Bzip2 compressed preprocessed source file DataBrowser.cmpl.ii (145.26 KB, application/octet-stream)
2004-03-12 06:32 UTC, Peter Schmid
Details

Note You need to log in before you can comment on or make changes to this bug.
Description Peter Schmid 2004-03-12 06:29:11 UTC
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
Comment 1 Peter Schmid 2004-03-12 06:32:04 UTC
Created attachment 5903 [details]
Bzip2 compressed preprocessed source file DataBrowser.cmpl.ii
Comment 2 Andrew Pinski 2004-03-12 06:42:23 UTC
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
Comment 3 Peter Schmid 2004-03-13 23:41:05 UTC
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. 
 
Comment 4 Andrew Pinski 2004-03-14 03:45:31 UTC
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.
Comment 5 Giovanni Bajo 2004-03-15 13:41:04 UTC
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?
Comment 6 Giovanni Bajo 2004-03-15 16:58:26 UTC
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.
Comment 7 Andrew Pinski 2004-03-16 15:20:40 UTC
*** Bug 14605 has been marked as a duplicate of this bug. ***
Comment 8 Giovanni Bajo 2004-03-17 01:19:57 UTC
Patch posted, waiting for review:
http://gcc.gnu.org/ml/gcc-patches/2004-03/msg01265.html
Comment 9 Mark Mitchell 2004-03-17 01:34:39 UTC
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?

Comment 10 Giovanni Bajo 2004-03-18 01:12:22 UTC
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>;


Comment 11 Wolfgang Bangerth 2004-03-18 14:04:07 UTC
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> (); 
--------------------- 
 
:-) 
Comment 12 Giovanni Bajo 2004-03-18 14:42:46 UTC
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


Comment 13 Wolfgang Bangerth 2004-03-18 15:08:59 UTC
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. 
Comment 14 Mark Mitchell 2004-03-18 15:19:11 UTC
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.

Comment 15 Wolfgang Bangerth 2004-03-18 15:30:56 UTC
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. 
Comment 16 Giovanni Bajo 2004-03-18 15:31:49 UTC
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>;


Comment 17 Mark Mitchell 2004-03-18 15:48:46 UTC
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!

Comment 18 Wolfgang Bangerth 2004-03-18 15:53:11 UTC
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. 
Comment 19 GCC Commits 2004-03-19 09:59:09 UTC
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

Comment 20 GCC Commits 2004-03-19 11:41:50 UTC
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

Comment 21 Giovanni Bajo 2004-03-19 11:42:32 UTC
Fixed for GCC 3.4.0 and 3.5.0. Thanks for your report!