From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 25055 invoked by alias); 3 Mar 2005 22:58:19 -0000 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org Received: (qmail 25029 invoked by alias); 3 Mar 2005 22:58:16 -0000 Date: Thu, 03 Mar 2005 22:58:00 -0000 Message-ID: <20050303225816.25028.qmail@sourceware.org> From: "joseph at codesourcery dot com" To: gcc-bugs@gcc.gnu.org In-Reply-To: <20050303182015.20303.hjl@lucon.org> References: <20050303182015.20303.hjl@lucon.org> Reply-To: gcc-bugzilla@gcc.gnu.org Subject: [Bug c/20303] Can't push more than 16 nested visibility X-Bugzilla-Reason: CC X-SW-Source: 2005-03/txt/msg00434.txt.bz2 List-Id: ------- Additional Comments From joseph at codesourcery dot com 2005-03-03 22:58 ------- Subject: Re: Can't push more than 16 nested visibility On Thu, 3 Mar 2005, pinskia at gcc dot gnu dot org wrote: > This is a documented behavior. Arbitrary limits are still generally undesirable, even when documented. Some limits are very unlikely to be reached by real programs, even computer-generated ones, and genuinely motivated by efficiency. For example, the C front end only supports 268435455 (= 2^28 - 1) nested scopes. If there were a real use for more scopes, or for a very few programs to exceed other such limits motivated by efficiency concerns, we could add a --enable-huge-programs configure option to increase those limits at some performance cost to almost all normal programs. Another limit in a similar situation is the limit of USHRT_MAX parameters to a preprocessor macro. In this case, the limit is reached by real code and I very much doubt (without profiling information to show to the contrary) that there would be any measurable performance difference with using VEC, so we should just do that and get rid of the limit. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=20303