From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 19236 invoked by alias); 10 Apr 2012 10:03:36 -0000 Received: (qmail 19223 invoked by uid 22791); 10 Apr 2012 10:03:35 -0000 X-SWARE-Spam-Status: No, hits=-4.3 required=5.0 tests=ALL_TRUSTED,AWL,BAYES_00,KHOP_THREADED 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, 10 Apr 2012 10:03:22 +0000 From: "burnus at gcc dot gnu.org" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/52916] [4.8 Regression] 481.wrf in SPEC CPU 2006 failed to build Date: Tue, 10 Apr 2012 10:03: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: wrong-code X-Bugzilla-Severity: normal X-Bugzilla-Who: burnus at gcc dot gnu.org X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: 4.8.0 X-Bugzilla-Changed-Fields: Keywords CC Target Milestone 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-04/txt/msg00601.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=52916 Tobias Burnus changed: What |Removed |Added ---------------------------------------------------------------------------- Keywords| |wrong-code CC| |burnus at gcc dot gnu.org Target Milestone|--- |4.8.0 --- Comment #2 from Tobias Burnus 2012-04-10 10:02:13 UTC --- That's probably due to my patch for PR 40973 / PR 52751 (Rev. 186223). That patch marked functions/subroutines and variables from MODULES as TREE_PUBLIC() = 0, if they have the PRIVATE attribute and no C-binding name. That will definitely fail if one accesses the procedures directly, e.g. from C via "__moduleName_MOD_subroutine ();". The question is whether 481.wrf does so (probably not). However, I fail to see how it could otherwise encounter the problem. As I do not have access to SPEC CPU, I would be happy if someone could provide more information. (Best would be a test case.) As a first step: Are the missing symbols procedures or (global) variables? Or both?