From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 16017 invoked by alias); 11 Jun 2009 02:25:26 -0000 Received: (qmail 15914 invoked by uid 48); 11 Jun 2009 02:25:13 -0000 Date: Thu, 11 Jun 2009 02:25:00 -0000 Message-ID: <20090611022513.15913.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug libfortran/40330] [4.4, 4.5 Regression] incorrect IO In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jvdelisle 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: 2009-06/txt/msg00691.txt.bz2 ------- Comment #26 from jvdelisle at gcc dot gnu dot org 2009-06-11 02:25 ------- CP2K still fails. However, I think I have discovered the root cause. String constants in formats are saved in the fnode at sting.p which is a pointer. When we use cached parsed string data, those constant strings are net getting copied and saved along with the parsed format. That "constant" string is used by write_constant_string in transfer.c. This is an issue with the concept because the constant string can vary with each invocation of the IO statement, as is the case with CP2k, and it is freed at the end of each IO operation. The benefit of caching is lost if we have to reparse to find the strings This leaves the possibility of disabling the caching if a FMT_STRING token is found while parsing the format the first time. I am going to suggest we revert format caching from 4.4 right away and probably 4.5 if some better idea does not pop into my head. -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=40330