From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 27036 invoked by alias); 21 Apr 2002 12:46:41 -0000 Mailing-List: contact gcc-help@gcc.gnu.org; run by ezmlm Precedence: bulk List-Archive: List-Post: List-Help: Sender: gcc-owner@gcc.gnu.org Received: (qmail 27005 invoked from network); 21 Apr 2002 12:46:39 -0000 Received: from unknown (HELO laptop.moene.indiv.nluug.nl) (195.109.255.217) by sources.redhat.com with SMTP; 21 Apr 2002 12:46:39 -0000 Received: from local ([127.0.0.1] helo=moene.indiv.nluug.nl) by laptop.moene.indiv.nluug.nl with esmtp (Exim 3.12 #1 (Debian)) id 16zGk3-000829-00; Sun, 21 Apr 2002 14:46:55 +0200 Message-ID: <3CC2B4BC.C1710C88@moene.indiv.nluug.nl> Date: Sun, 21 Apr 2002 07:06:00 -0000 From: Toon Moene Organization: Moene Computational Physics, Maartensdijk, The Netherlands X-Accept-Language: en MIME-Version: 1.0 To: John David Anglin CC: gcc@gcc.gnu.org, mark@codesourcery.com Subject: Re: GCC 3.1 Prerelease References: <200204210308.g3L38jAi022753@hiauly1.hia.nrc.ca> Content-Type: text/plain; charset=us-ascii Content-Transfer-Encoding: 7bit X-SW-Source: 2002-04/txt/msg01040.txt.bz2 John David Anglin wrote: > Fortran: > > PR6138: Incorrect access of interger*1 variables on PA. > > This is a regression from 3.0.x, and it also affects powerpc. In my opinion, > it is a verious serious bug affecting many programs and should be fixed > before the 3.1 release. The problem is in the front-end, in code that > I am not familiar with. This and PR Fortran/6304 are indeed the only Fortran *regressions* I'm aware of. Whether this one affects a lot of people is open to debate: In my experience not many are using the INTEGER*1 extension (mostly because its support in g77 is not complete). I'm not entirely sure it's a bug in the frontend; however, in the four hours I spent on it yesterday I was unable to find a C equivalent for the following, minimal, example of the problem: integer*2 j integer*1 k j = -9 k = j if (k .ne. j) call abort print*,j end [ The `print*,j' line is necessary because it forces gcc to store j on the stack - which leads to the access error. ] The problem is hard to track down - already the .f.00.rtl dump is wrong when optimizing (another hint that it might be a bug in the frontend - however, that means that we have to explain how the frontend can generate different RTL based on optimization flags) ... Affects powerpc and hppa. Hope this helps, -- Toon Moene - mailto:toon@moene.indiv.nluug.nl - phoneto: +31 346 214290 Saturnushof 14, 3738 XG Maartensdijk, The Netherlands Maintainer, GNU Fortran 77: http://gcc.gnu.org/onlinedocs/g77_news.html Join GNU Fortran 95: http://g95.sourceforge.net/ (under construction)