Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Nickolai Dobrynin]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Nickolai Dobrynin <dobrynin@miller.cs.uwm.edu>
To: Paolo Carlini <pcarlini@unitus.it>
Cc: <gcc-gnats@gcc.gnu.org>, <gcc-prs@gcc.gnu.org>, <dobrynin@bigfoot.com>,
   <gcc-bugs@gcc.gnu.org>, Mark Mitchell <mark@codesourcery.com>,
   Nathan Sidwell <nathan@codesourcery.com>
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates
 to zero at compile time
Date: Tue, 2 Jul 2002 15:52:27 -0500 (CDT)

 Hello!
 
 Actually, the original example from the "Generative Programming" book
 looked like this:
 
 #include <iostream>
 using namespace std;
 
 template<int n>
 struct Fib
 { enum { RET = Fib<n-1>::RET + Fib<n-2>::RET };
 };
 
 template<>
 struct Fib<0>
 { enum { RET = 0 };
 };
 
 template<>
 struct Fib<1>
 { enum { RET = 1 };
 };
 
 void main()
 { cout << Fib<8>::RET << endl;
 }
 
 -- which, evidently, is not identical to what I was submitting in my
 original message. After eliminating the "enum hack" (an optional step),
 i.e. replacing enum with const static int,
 
 #include <iostream>
 using namespace std;
 
 template<int n>
 struct Fib { const static int RET = Fib<n-1>::RET + Fib<n-2>::RET; };
 
 struct Fib<0> { const static int RET = 0; };
 struct Fib<1> { const static int RET = 1; };
 
 int main()
 {
   cout << Fib<40>::RET << endl;
 
 
   return 0;
 }
 
 this will indeed produce a valid output.
 
 I just think of it as being totally counter intuitive that the same nifty
 feature is not valid (is NO LONGER valid, would be a better way to say it)
 on non-constant initializers.
 
 So, would indeed this be possible to restore the behavior of 2.95.x or it
 would come in conflict with something else? Any opinions on that?
 
 
 Regards,
 
 Nickolai
 
 
 PS  Is it a normal behavior that the option -ftemplate-depth-... is no
 longer needed in order for the example above to compile properly?
 
 
 On Tue, 2 Jul 2002, Paolo Carlini wrote:
 
 > Hi,
 >
 > from a very practical point of view, would be difficult to restore the
 > behaviour of 2.95.x? Note that Intel and Comeau adopts that "particular"
 > initialization order and the current "equivalent" one ;-) breaks a whole
 > body of literature on template metaprogramming...
 >
 > Ciao, Paolo.
 >
 > http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7181
 >
 >
 >
 
 

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Paolo Carlini]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Paolo Carlini <pcarlini@unitus.it>
To: Nickolai Dobrynin <dobrynin@miller.cs.uwm.edu>
Cc: gcc-gnats@gcc.gnu.org,  gcc-prs@gcc.gnu.org,  dobrynin@bigfoot.com, 
 gcc-bugs@gcc.gnu.org
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates
 to zero at compile time
Date: Tue, 02 Jul 2002 23:17:19 +0200

 Nickolai Dobrynin wrote:
 
 >I just think of it as being totally counter intuitive that the same nifty
 >feature is not valid (is NO LONGER valid, would be a better way to say it)
 >on non-constant initializers.
 >
 >So, would indeed this be possible to restore the behavior of 2.95.x or it
 >would come in conflict with something else? Any opinions on that?
 >
 Nicolai, first thanks for your message from which I have learned much 
 about the issue at hand. On the other hand, I think that Mark's answer 
 stands: if the standard does /not/ prescribe a particular ordering this 
 cannot be considered a bug and, moreover, yourself proved that there is 
 a way (thanks, once more) to do this kind of tricks which does /not/ 
 relies on not well-defined behavior. The latter two points imply that 
 most probably the old behaviour will not be restored very soon ;-)
 
 >PS  Is it a normal behavior that the option -ftemplate-depth-... is no
 >longer needed in order for the example above to compile properly?
 >
 Yes. Currently the default max depth is 500:
 
 2002-01-10  Jakub Jelinek  <jakub@redhat.com>
 
     * decl2.c (max_tinst_depth): Increase default limit to 500.
 
 Ciao,
 Paolo.
 
 

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Paolo Carlini]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Paolo Carlini <pcarlini@unitus.it>
To: Mark Mitchell <mark@codesourcery.com>
Cc: "gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>, "gcc-prs@gcc.gnu.org"
 <gcc-prs@gcc.gnu.org>, "dobrynin@bigfoot.com" <dobrynin@bigfoot.com>, "gcc-bugs@gcc.gnu.org"
 <gcc-bugs@gcc.gnu.org>, Nathan Sidwell <nathan@codesourcery.com>
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates
 to zero at compile time
Date: Tue, 02 Jul 2002 22:44:41 +0200

 Mark Mitchell wrote:
 
 > --On Tuesday, July 02, 2002 10:28:13 PM +0200 Paolo Carlini 
 > <pcarlini@unitus.it> wrote:
 >
 >> Hi,
 >>
 >> from a very practical point of view, would be difficult to restore the
 >> behaviour of 2.95.x? Note that Intel and Comeau adopts that "particular"
 >> initialization order and the current "equivalent" one ;-) breaks a whole
 >> body of literature on template metaprogramming...
 >
 >
 > Perhaps.  It may also be that picking one order makes this example work,
 > but some similar example fail.
 
 Thanks for your feedback. This one of yours is an important point, 
 indeed. Anyone attempting to restore the old behaviour should first 
 prove that it's really the "best" one in some non trivial sense. I had 
 always believed it is, but...
 
 Thanks again,
 Paolo.
 

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Mark Mitchell]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Mark Mitchell <mark@codesourcery.com>
To: Paolo Carlini <pcarlini@unitus.it>,
   "gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>,
   "gcc-prs@gcc.gnu.org" <gcc-prs@gcc.gnu.org>,
   "dobrynin@bigfoot.com" <dobrynin@bigfoot.com>,
   "gcc-bugs@gcc.gnu.org" <gcc-bugs@gcc.gnu.org>,
   Nathan Sidwell <nathan@codesourcery.com>
Cc:  
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates
 to zero at compile time
Date: Tue, 02 Jul 2002 13:33:06 -0700

 --On Tuesday, July 02, 2002 10:28:13 PM +0200 Paolo Carlini 
 <pcarlini@unitus.it> wrote:
 
 > Hi,
 >
 > from a very practical point of view, would be difficult to restore the
 > behaviour of 2.95.x? Note that Intel and Comeau adopts that "particular"
 > initialization order and the current "equivalent" one ;-) breaks a whole
 > body of literature on template metaprogramming...
 
 Perhaps.  It may also be that picking one order makes this example work,
 but some similar example fail.
 
 Certainly, you are welcome to contribute a patch.  If it isn't
 particularly ugly, and doesn't break conformance, I'd be in favor of
 accepting it.
 
 But, it's not a high priority for me -- and I'm focusing my GCC time on
 high-priority bugs and the new parser.
 
 -- 
 Mark Mitchell                mark@codesourcery.com
 CodeSourcery, LLC            http://www.codesourcery.com

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Paolo Carlini]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Paolo Carlini <pcarlini@unitus.it>
To: gcc-gnats@gcc.gnu.org,  gcc-prs@gcc.gnu.org,  dobrynin@bigfoot.com, 
 gcc-bugs@gcc.gnu.org, Mark Mitchell <mark@codesourcery.com>, Nathan Sidwell
 <nathan@codesourcery.com>
Cc:  
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates
 to zero at compile time
Date: Tue, 02 Jul 2002 22:28:13 +0200

 Hi,
 
 from a very practical point of view, would be difficult to restore the 
 behaviour of 2.95.x? Note that Intel and Comeau adopts that "particular" 
 initialization order and the current "equivalent" one ;-) breaks a whole 
 body of literature on template metaprogramming...
 
 Ciao, Paolo.
 
 http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7181 
 
 

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Mark Mitchell]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Mark Mitchell <mark@codesourcery.com>
To: Nathan Sidwell <nathan@codesourcery.com>,
   "mmitchel@gcc.gnu.org" <mmitchel@gcc.gnu.org>,
   "dobrynin@bigfoot.com" <dobrynin@bigfoot.com>,
   "gcc-bugs@gcc.gnu.org" <gcc-bugs@gcc.gnu.org>,
   "gcc-prs@gcc.gnu.org" <gcc-prs@gcc.gnu.org>,
   "nobody@gcc.gnu.org" <nobody@gcc.gnu.org>,
   "gcc-gnats@gcc.gnu.org" <gcc-gnats@gcc.gnu.org>
Cc:  
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates
 to  zero at compile time
Date: Tue, 02 Jul 2002 13:08:21 -0700

 --On Tuesday, July 02, 2002 08:42:23 PM +0100 Nathan Sidwell 
 <nathan@codesourcery.com> wrote:
 
 > mmitchel@gcc.gnu.org wrote:
 >>
 >> Synopsis: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero
 >> at compile time
 >>
 >> State-Changed-From-To: analyzed->closed
 >> State-Changed-By: mmitchel
 >> State-Changed-When: Tue Jul  2 11:31:51 2002
 >> State-Changed-Why:
 >>     This code does not have well-defined behavior.
 > How have you come to this conclusion? The last sentance of
 > [14.7.1]/1 indicates that we must instantiate the definition of
 > Foo<N>::value. I see nothing in [3.6.2] or [3.8] which disallows it.
 >
 > Or are you saying this is a case of [14.7.3]/7?\
 
 The standard doesn't specifies that the point of instantiation for the
 various static data members is "the same".  It doesn't say which one
 gets instantiated first.  Nor, according to John, does it say which one
 gets initialized first.
 
 So, I think the standard says "all those things get instantiated and
 initialized in some order" -- but not which order, similar to the
 example in 3.6.2.
 
 These are dynamic initializations; the initializers are not constant
 expressions.
 
 -- 
 Mark Mitchell                mark@codesourcery.com
 CodeSourcery, LLC            http://www.codesourcery.com

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Nathan Sidwell]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Nathan Sidwell <nathan@codesourcery.com>
To: mmitchel@gcc.gnu.org, dobrynin@bigfoot.com, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to 
 zero at compile time
Date: Tue, 02 Jul 2002 20:42:23 +0100

 mmitchel@gcc.gnu.org wrote:
 > 
 > Synopsis: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time
 > 
 > State-Changed-From-To: analyzed->closed
 > State-Changed-By: mmitchel
 > State-Changed-When: Tue Jul  2 11:31:51 2002
 > State-Changed-Why:
 >     This code does not have well-defined behavior.
 How have you come to this conclusion? The last sentance of
 [14.7.1]/1 indicates that we must instantiate the definition of Foo<N>::value.
 I see nothing in [3.6.2] or [3.8] which disallows it.
 
 Or are you saying this is a case of [14.7.3]/7?
 
 nathan
 
 -- 
 Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[mmitchel]

Synopsis: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

State-Changed-From-To: analyzed->closed
State-Changed-By: mmitchel
State-Changed-When: Tue Jul  2 11:31:51 2002
State-Changed-Why:
    This code does not have well-defined behavior.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7181

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Paolo Carlini]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Paolo Carlini <pcarlini@unitus.it>
To: Nathan Sidwell <nathan@codesourcery.com>
Cc: paolo@gcc.gnu.org,  dobrynin@bigfoot.com,  gcc-bugs@gcc.gnu.org, 
 gcc-prs@gcc.gnu.org,  nobody@gcc.gnu.org,  gcc-gnats@gcc.gnu.org
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates
 to  zero at compile time
Date: Mon, 01 Jul 2002 23:58:26 +0200

 Nathan Sidwell wrote:
 
 >paolo@gcc.gnu.org wrote:
 >  
 >
 >>Synopsis: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at
 >>    
 >>
 >FYI, this is broken in 2.96RH too, so is quite old. The static initializers
 >are emitted in the wrong order so we initialize foo<n> before foo<n-1>. doh!
 >  
 >
 Thanks for your feedback.
 You agree, I suppose, that is quite embarassing that g++ is no longer 
 able to correctly compile the textbook example of template 
 metaprogramming :-(
 
 Paolo.
 
 

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[Nathan Sidwell]

The following reply was made to PR c++/7181; it has been noted by GNATS.

From: Nathan Sidwell <nathan@codesourcery.com>
To: paolo@gcc.gnu.org, dobrynin@bigfoot.com, gcc-bugs@gcc.gnu.org,
   gcc-prs@gcc.gnu.org, nobody@gcc.gnu.org, gcc-gnats@gcc.gnu.org
Cc:  
Subject: Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to 
 zero at compile time
Date: Mon, 01 Jul 2002 22:50:53 +0100

 paolo@gcc.gnu.org wrote:
 > 
 > Synopsis: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at
 FYI, this is broken in 2.96RH too, so is quite old. The static initializers
 are emitted in the wrong order so we initialize foo<n> before foo<n-1>. doh!
 
 nathan
 
 -- 
 Dr Nathan Sidwell   ::   http://www.codesourcery.com   ::   CodeSourcery LLC
          'But that's a lie.' - 'Yes it is. What's your point?'
 nathan@codesourcery.com : http://www.cs.bris.ac.uk/~nathan/ : nathan@acm.org

Re: c++/7181: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

[paolo]

Synopsis: foo<n>::bar = foo<n-1>::bar + foo<n-2>::bar evaluates to zero at compile time

State-Changed-From-To: open->analyzed
State-Changed-By: paolo
State-Changed-When: Mon Jul  1 14:20:05 2002
State-Changed-Why:
    Confirmed on i686-pc-linux-gnu for both 3.1.1 and 3.2,
    regression from 2.95.x.

http://gcc.gnu.org/cgi-bin/gnatsweb.pl?cmd=view%20audit-trail&database=gcc&pr=7181