From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 14891 invoked by alias); 20 Mar 2012 09:11:39 -0000 Received: (qmail 14877 invoked by uid 22791); 20 Mar 2012 09:11:37 -0000 X-SWARE-Spam-Status: No, hits=-2.9 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00 X-Spam-Check-By: sourceware.org Received: from localhost (HELO gcc.gnu.org) (127.0.0.1) by sourceware.org (qpsmtpd/0.43rc1) with ESMTP; Tue, 20 Mar 2012 09:11:15 +0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/52606] Confusing diagnostics for long identifiers Date: Tue, 20 Mar 2012 09:18:00 -0000 X-Bugzilla-Reason: CC X-Bugzilla-Type: changed X-Bugzilla-Watch-Reason: None X-Bugzilla-Product: gcc X-Bugzilla-Component: fortran X-Bugzilla-Keywords: X-Bugzilla-Severity: enhancement X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: ASSIGNED X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Changed-Fields: CC Message-ID: In-Reply-To: References: X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated Content-Type: text/plain; charset="UTF-8" MIME-Version: 1.0 Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Id: List-Archive: List-Post: List-Help: Sender: gcc-bugs-owner@gcc.gnu.org X-SW-Source: 2012-03/txt/msg01575.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52606 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- CC| |burnus at gcc dot gnu.org --- Comment #4 from Tobias Burnus 2012-03-20 09:10:13 UTC --- (In reply to comment #3) > Finally, before attacking static GFC_MAX_SYMBOL_LEN buffers, I suggest getting > rid of static buffers of GFC_MAX_MANGLED_SYMBOL_LEN size. We should get rid of > that macro altogether. Also, FWIW, the value for that macro is too small at > the moment, as it's easy to construct examples were the mangled name exceeds > that value. See e.g. PR 51802 for inspiration. ;-) Indeed, one can construct examples which exceed the length: Namely module procedures or module variables. The problem is that GFC_MAX_MANGLED_SYMBOL_LEN allows for GFC_MAX_SYMBOL_LEN*2+4 = 130 characters but one has the prefix "__" plus "_MOD_" which is not 4 but 7 characters long. Thus, if one goes to the limit, one can create symbols which have the same mangled name. Though, using both the maximal length for the module name and for the symbol name is a very constructed example. On the other hand, PR 51802 does not inspire at all: That PR is about polymorphism-related names. And those are hashed if they don't fit. Example module Very_long_module_name_having_a_length_of_63_characters_really_x contains subroutine an_extremely_long_subroutine_name_which_looks_rather_ugly123456 contains subroutine an_extremely_long_internal_subroutine_name_which_looks_ugly type plus_a_very_very_very_long_type_name_of_almost_the_same_length end type class(plus_a_very_very_very_long_type_name_of_almost_the_same_length), & allocatable :: t end subroutine end subroutine end module According to "nm", one then gets the following symbols - the last one should end in "123456" but only ends in "123". __very_long_module_name_having_a_length_of_63_characters_really_x_MOD___copy_1169DDF __very_long_module_name_having_a_length_of_63_characters_really_x_MOD___def_init_1169DDF __very_long_module_name_having_a_length_of_63_characters_really_x_MOD___vtab_1169DDF __very_long_module_name_having_a_length_of_63_characters_really_x_MOD_an_extremely_long_subroutine_name_which_looks_rather_ugly123