[Bug c++/65042] New: gcc5 has a template depth problem that was fine in gcc4

[Bug c++/65042] New: gcc5 has a template depth problem that was fine in gcc4

[karl at kleinpaste dot org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042

            Bug ID: 65042
           Summary: gcc5 has a template depth problem that was fine in
                    gcc4
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: c++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: karl at kleinpaste dot org

Created attachment 34740
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34740&action=edit
class description employing layered string- and int-indexed maps-within-maps

Attached is modulecache.hh, part of Xiphos, which was recently involved in a
Fedora gcc5 mass rebuild test for upcoming Fedora 22.  This file exhibits a
template complaint regarding nested std::map usage.  The nesting provides an
intuitive access to data content by allowing subscripting at any map level to
obtain all subordinate content.

The plain fact is that this code has been compiling in gcc4 since approximately
2008.  It was then found that using -ftemplate-depth=128 makes the gcc5
compilation survive, but I don't see why this should be necessary, considering
that the code has been fine for 7 years preceding, without use of any such
modifiers.  Has the default depth limit changed in gcc5?

FYI recommended to file this report by an involved Fedora engineer; I am Xiphos
project admin.

In file included from /usr/include/c++/5.0.0/map:60:0,
                 from ../src/main/modulecache.hh:45,
                 from ../src/main/modulecache.cc:30:
/usr/include/c++/5.0.0/bits/stl_tree.h: In instantiation of 'void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_destroy_node(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type) [with _Key = int; _Val = std::pair<const int,
ModuleCache::CacheVerse>; _KeyOfValue = std::_Select1st<std::pair<const int,
ModuleCache::CacheVerse> >; _Compare = std::less<int>; _Alloc =
std::allocator<std::pair<const int, ModuleCache::CacheVerse> >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node<std::pair<const int, ModuleCache::CacheVerse> >*]':
/usr/include/c++/5.0.0/bits/stl_tree.h:562:17:   required from 'void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_drop_node(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type) [with _Key = int; _Val = std::pair<const int,
ModuleCache::CacheVerse>; _KeyOfValue = std::_Select1st<std::pair<const int,
ModuleCache::CacheVerse> >; _Compare = std::less<int>; _Alloc =
std::allocator<std::pair<const int, ModuleCache::CacheVerse> >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node<std::pair<const int, ModuleCache::CacheVerse> >*]'
/usr/include/c++/5.0.0/bits/stl_tree.h:1493:16:   required from 'void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_erase(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type) [with _Key = int; _Val = std::pair<const int,
ModuleCache::CacheVerse>; _KeyOfValue = std::_Select1st<std::pair<const int,
ModuleCache::CacheVerse> >; _Compare = std::less<int>; _Alloc =
std::allocator<std::pair<const int, ModuleCache::CacheVerse> >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node<std::pair<const int, ModuleCache::CacheVerse> >*]'
/usr/include/c++/5.0.0/bits/stl_tree.h:859:17:   required from
'std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::~_Rb_tree() [with
_Key = int; _Val = std::pair<const int, ModuleCache::CacheVerse>; _KeyOfValue =
std::_Select1st<std::pair<const int, ModuleCache::CacheVerse> >; _Compare =
std::less<int>; _Alloc = std::allocator<std::pair<const int,
ModuleCache::CacheVerse> >]'
/usr/include/c++/5.0.0/bits/stl_map.h:96:11:   required from 'void
__gnu_cxx::new_allocator<_Tp>::destroy(__gnu_cxx::new_allocator<_Tp>::pointer)
[with _Tp = std::pair<const int, std::map<int, ModuleCache::CacheVerse> >;
__gnu_cxx::new_allocator<_Tp>::pointer = std::pair<const int, std::map<int,
ModuleCache::CacheVerse> >*]'
/usr/include/c++/5.0.0/bits/stl_tree.h:521:9:   required from 'void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_destroy_node(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type) [with _Key = int; _Val = std::pair<const int,
std::map<int, ModuleCache::CacheVerse> >; _KeyOfValue =
std::_Select1st<std::pair<const int, std::map<int, ModuleCache::CacheVerse> >
>; _Compare = std::less<int>; _Alloc = std::allocator<std::pair<const int,
std::map<int, ModuleCache::CacheVerse> > >; std::_Rb_tree<_Key, _Val,
_KeyOfValue, _Compare, _Alloc>::_Link_type = std::_Rb_tree_node<std::pair<const
int, std::map<int, ModuleCache::CacheVerse> > >*]'
/usr/include/c++/5.0.0/bits/stl_tree.h:562:17:   [ skipping 14 instantiation
contexts, use -ftemplate-backtrace-limit=0 to disable ]
/usr/include/c++/5.0.0/bits/stl_tree.h:521:9:   required from 'void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_destroy_node(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type) [with _Key = const std::basic_string<char>; _Val =
std::pair<const std::basic_string<char>, std::map<int, std::map<int,
std::map<int, std::map<int, ModuleCache::CacheVerse> > > > >; _KeyOfValue =
std::_Select1st<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >;
_Compare = std::less<const std::basic_string<char> >; _Alloc =
std::allocator<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >*]'
/usr/include/c++/5.0.0/bits/stl_tree.h:562:17:   required from 'void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_drop_node(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type) [with _Key = const std::basic_string<char>; _Val =
std::pair<const std::basic_string<char>, std::map<int, std::map<int,
std::map<int, std::map<int, ModuleCache::CacheVerse> > > > >; _KeyOfValue =
std::_Select1st<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >;
_Compare = std::less<const std::basic_string<char> >; _Alloc =
std::allocator<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >*]'
/usr/include/c++/5.0.0/bits/stl_tree.h:1493:16:   required from 'void
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_M_erase(std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare,
_Alloc>::_Link_type) [with _Key = const std::basic_string<char>; _Val =
std::pair<const std::basic_string<char>, std::map<int, std::map<int,
std::map<int, std::map<int, ModuleCache::CacheVerse> > > > >; _KeyOfValue =
std::_Select1st<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >;
_Compare = std::less<const std::basic_string<char> >; _Alloc =
std::allocator<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >;
std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::_Link_type =
std::_Rb_tree_node<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >*]'
/usr/include/c++/5.0.0/bits/stl_tree.h:859:17:   required from
'std::_Rb_tree<_Key, _Val, _KeyOfValue, _Compare, _Alloc>::~_Rb_tree() [with
_Key = const std::basic_string<char>; _Val = std::pair<const
std::basic_string<char>, std::map<int, std::map<int, std::map<int,
std::map<int, ModuleCache::CacheVerse> > > > >; _KeyOfValue =
std::_Select1st<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >;
_Compare = std::less<const std::basic_string<char> >; _Alloc =
std::allocator<std::pair<const std::basic_string<char>, std::map<int,
std::map<int, std::map<int, std::map<int, ModuleCache::CacheVerse> > > > > >]'
/usr/include/c++/5.0.0/bits/stl_map.h:163:14:   required from 'std::map<_Key,
_Tp, _Compare, _Alloc>::map() [with _Key = const std::basic_string<char>; _Tp =
std::map<int, std::map<int, std::map<int, std::map<int,
ModuleCache::CacheVerse> > > >; _Compare = std::less<const
std::basic_string<char> >; _Alloc = std::allocator<std::pair<const
std::basic_string<char>, std::map<int, std::map<int, std::map<int,
std::map<int, ModuleCache::CacheVerse> > > > > >]'
../src/main/modulecache.cc:34:23:   required from here
/usr/include/c++/5.0.0/bits/stl_tree.h:521:22: fatal error: template
instantiation depth exceeds maximum of 25 (use -ftemplate-depth= to increase
the maximum)
       { get_allocator().destroy(__p->_M_valptr()); }
                      ^

[Bug c++/65042] gcc5 has a template depth problem that was fine in gcc4

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |jakub at gcc dot gnu.org

--- Comment #1 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Please provide preprocessed source (see http://gcc.gnu.org/bugs/ for details
how).

[Bug c++/65042] gcc5 has a template depth problem that was fine in gcc4

[mcepl at cepl dot eu]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042

--- Comment #2 from Matěj Cepl <mcepl at cepl dot eu> ---
Created attachment 34741
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=34741&action=edit
preprocessed file
>From gcc-bugs-return-477051-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Feb 12 18:10:40 2015
Return-Path: <gcc-bugs-return-477051-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29816 invoked by alias); 12 Feb 2015 18:10:40 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 29681 invoked by uid 55); 12 Feb 2015 18:10:33 -0000
From: "jakub at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug debug/55541] [4.8/4.9/5 Regression] unable to see local variables due extra lexical block was generated
Date: Thu, 12 Feb 2015 18:10:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: debug
X-Bugzilla-Version: 4.6.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jakub at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-55541-4-mxW7I8GQBL@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-55541-4@http.gcc.gnu.org/bugzilla/>
References: <bug-55541-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2015-02/txt/msg01384.txt.bz2
Content-length: 1100

https://gcc.gnu.org/bugzilla/show_bug.cgi?idU541

--- Comment #13 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Author: jakub
Date: Thu Feb 12 18:09:59 2015
New Revision: 220650

URL: https://gcc.gnu.org/viewcvs?rev"0650&root=gcc&view=rev
Log:
    PR debug/55541
    * cp-tree.h (BLOCK_OUTER_CURLY_BRACE_P): Define.
    * decl.c (poplevel): If functionbody, try not to create an extra
    BLOCK for function body and use subblocks as that, if it is non-NULL
    and doesn't have siblings.  Set BLOCK_OUTER_CURLY_BRACE_P flag.
    (outer_curly_brace_block): Use BLOCK_OUTER_CURLY_BRACE_P flag.

    * g++.dg/debug/dwarf2/localclass3.C: Adjust for the extraneous
    DW_TAG_lexical_block removal.
    * g++.dg/debug/dwarf2/redeclaration-1.C: Likewise.
    * g++.dg/guality/pr55541.C: New test.

Added:
    trunk/gcc/testsuite/g++.dg/guality/pr55541.C
Modified:
    trunk/gcc/cp/ChangeLog
    trunk/gcc/cp/cp-tree.h
    trunk/gcc/cp/decl.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/g++.dg/debug/dwarf2/localclass3.C
    trunk/gcc/testsuite/g++.dg/debug/dwarf2/redeclaration-1.C

[Bug c++/65042] gcc5 has a template depth problem that was fine in gcc4

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042

Marek Polacek <mpolacek at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mpolacek at gcc dot gnu.org

--- Comment #3 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Note that the package explicitly uses -ftemplate-depth=25 (without that the .ii
files compiles fine).  So maybe just some changes in libstdc++ that trigger the
limit?

[Bug c++/65042] gcc5 has a template depth problem that was fine in gcc4

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042

--- Comment #4 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
What command line options are used?
With explicit -ftemplate-depth=25 (or even 27) it indeed fails, succeeds with
28, but the default is 900 AFAIK.  Have those command line options changed in
any way since the compilation with the older g++?

[Bug libstdc++/65042] gcc5 has a template depth problem that was fine in gcc4

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |redi at gcc dot gnu.org
          Component|c++                         |libstdc++

--- Comment #5 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Verified that even with 2.5 years old cc1plus we still trigger the
instantiation limit, so it indeed is some changes in libstdc++.  Guess you can
try -ftemplate-depth=20 etc. in 4.9 to see how close to the limit you were
before.

[Bug libstdc++/65042] gcc5 has a template depth problem that was fine in gcc4

[mpolacek at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042

--- Comment #6 from Marek Polacek <mpolacek at gcc dot gnu.org> ---
Yeah, the default is 900.   (C++11 recommends 1024 AFAIK.)

>From what I can see they used
/usr/lib64/ccache/g++ -v -save-temps -g3 -O0 -DDEBUG -ftemplate-depth-25
-DHAVE_CONFIG_H -pthread -Idefault/src/main -I../src/main -Idefault -I..
-Idefault/src -I../src -I/usr/include/dbus-1.0 -I/usr/lib64/dbus-1.0/include
-I/usr/include/glib-2.0 -I/usr/lib64/glib-2.0/include -I/usr/include/gconf/2
-I/usr/include/libgsf-1 -I/usr/include/libglade-2.0
-I/usr/include/webkitgtk-1.0 -I/usr/include/libsoup-2.4 -I/usr/include/libxml2
-I/usr/include/gtk-2.0 -I/usr/lib64/gtk-2.0/include -I/usr/include/pango-1.0
-I/usr/include/atk-1.0 -I/usr/include/cairo -I/usr/include/pixman-1
-I/usr/include/libdrm -I/usr/include/gdk-pixbuf-2.0 -I/usr/include/libpng16
-I/usr/include/harfbuzz -I/usr/include/freetype2 -I/usr/include/sword
-I/usr/include/biblesync/bibleysnc -I/usr/include/uuid
../src/main/modulecache.cc -c -o default/src/main/modulecache_1.o

I don't know if those command-line options have changed.

[Bug libstdc++/65042] gcc5 has a template depth problem that was fine in gcc4

[redi at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65042

--- Comment #7 from Jonathan Wakely <redi at gcc dot gnu.org> ---
Trying to use the standard library with such a tiny limit is simply not going
to work. If it worked previously you got lucky, but if you need to raise the
limit now then that's what you need to do.

What's the purpose of enforcing such a tiny limit anyway?