From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26724 invoked by alias); 15 Apr 2007 19:20:34 -0000 Received: (qmail 26620 invoked by uid 48); 15 Apr 2007 19:20:24 -0000 Date: Sun, 15 Apr 2007 19:20:00 -0000 Message-ID: <20070415192024.26619.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/31298] Uninitialized variable in f951 (in read_module) In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "burnus at gcc dot gnu dot org" 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: 2007-04/txt/msg01069.txt.bz2 ------- Comment #4 from burnus at gcc dot gnu dot org 2007-04-15 20:20 ------- Created an attachment (id=13369) --> (http://gcc.gnu.org/bugzilla/attachment.cgi?id=13369&action=view) Updated patch This patch handles almost everything except of operator() => operator(.user.) where could be e.g. ".gt." or "-" or ... One probably needs also a check whether the user operator is an unary or binary operator, which should match the intrinsic operator. Difference to previous patch: allow: "use mod, only: assignment(=)" disallow: "use mod, only: assignment(=) => operator(.user.) (Before the former one was rejected and the latter accepted.) As collateral damage it seems to fix PR 29876. (At least I get a proper error message with this patch and no error message for .none. without this patch [which is different to the reported behaviour.]) -- burnus at gcc dot gnu dot org changed: What |Removed |Added ---------------------------------------------------------------------------- Attachment #13312|0 |1 is obsolete| | http://gcc.gnu.org/bugzilla/show_bug.cgi?id=31298