From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 6724 invoked by alias); 13 Feb 2007 09:20:27 -0000 Received: (qmail 6695 invoked by uid 48); 13 Feb 2007 09:20:14 -0000 Date: Tue, 13 Feb 2007 09:20:00 -0000 Message-ID: <20070213092014.6694.qmail@sourceware.org> X-Bugzilla-Reason: CC References: Subject: [Bug fortran/29975] [meta-bugs] ICEs with CP2K In-Reply-To: Reply-To: gcc-bugzilla@gcc.gnu.org To: gcc-bugs@gcc.gnu.org From: "jv244 at cam dot ac dot uk" 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-02/txt/msg01369.txt.bz2 ------- Comment #60 from jv244 at cam dot ac dot uk 2007-02-13 09:20 ------- > When you have a moment, could you confirm that all is now well with trunk, > please? Once again, I am sorry about the breakage. Now I see Daniel's > testcase, I realise that I could easily have devised a test... with 20:20 > hindsight:) Yes, current trunk compiles CP2K again at -O0 (still blocked by PR 30391 at -O1). No need to apologize, I realize that many of the change you make fall into the 'subtle' category and do not pop-up with the normal regtesting. As said before, I'm, unfortunately, used to the fact that even good commercial compilers (say NAG's f95, IBM's xlf90, Intel's ifort) regress on CP2K from time to time. It is very annoying to have to fight compilers, after the computer center upgraded a machine. My hope is that CP2K being freely available (even in a handy single file format, see initial comment) could prevent this from happening. Ultimately, I want to see some runtime regression tester... maybe I should try to get CP2K in a future version of SPEC ... any hints on how to do that ?? -- http://gcc.gnu.org/bugzilla/show_bug.cgi?id=29975