From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: (qmail 26818 invoked by alias); 2 Sep 2013 17:53:31 -0000 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 Received: (qmail 26778 invoked by uid 48); 2 Sep 2013 17:53:27 -0000 From: "dominiq at lps dot ens.fr" To: gcc-bugs@gcc.gnu.org Subject: [Bug fortran/58270] Wrong code while accessing array elements in a global structure Date: Mon, 02 Sep 2013 17:53: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-Version: 4.6.4 X-Bugzilla-Keywords: X-Bugzilla-Severity: critical X-Bugzilla-Who: dominiq at lps dot ens.fr X-Bugzilla-Status: WAITING X-Bugzilla-Priority: P3 X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org X-Bugzilla-Target-Milestone: --- X-Bugzilla-Flags: X-Bugzilla-Changed-Fields: Message-ID: In-Reply-To: References: Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: 7bit X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/ Auto-Submitted: auto-generated MIME-Version: 1.0 X-SW-Source: 2013-09/txt/msg00088.txt.bz2 http://gcc.gnu.org/bugzilla/show_bug.cgi?id=58270 --- Comment #17 from Dominique d'Humieres --- > I cannot agree with you. You are interpreting the code that may access the > array beyond declared bounds as invalid, which is simply not true. 6.5 Use of data objects ... The value of a subscript in an array element shall be within the bounds for its dimension. where the "shall" means (as elsewhere in the standard) that it is the coder responsibility to honor the constraint at run time. > As you pointed it out before, unnamed common block may be declared larger > elsewhere, so writing the dmem array beyond its first element may be a design > decision and therefore may be perfectly legal. As above this is a wrong assumption: the design decision must be standard conforming. When you write "common dmem(1)" you tell the compiler that 'dmem' has only one element. > The compiler has no clue about real size of unnamed common while compiling > buggy.f and bounds checking is optional. When you write "common dmem(1)" you tell the compiler that 'dmem' has only one element. > I would also like to point it out that interpreting things this way > you do, This is not my interpretation, it is what the Fortran standard says. > you exclude some older FORTRAN77 software (for example: quantum chemistry > GAMESS), in which the lack of dynamic memory allocation was overcome using > the trick we are discussing here (mixing with C was needed). Well, I have used safer tricks to overcome the limitation. > BTW, change the size of dmem to 2 in buggy.f and things start to work > correctly, although "out of bounds" memory accesses still do happen. > The problem occurs only if dmem is of size 1. Because only for size 1 the optimizer can infer that valid uses will provide the (1,1,1) triplet. > Of course you (developers) may decide to ignore this problem anyway, > so if you do so, feel free to close this bug. I'm not going to reopen > it again, because I'm out of arguments. I'm also not competent enough > to tamper with the compiler. What you can do is to look at the GCC manual and try to find the optimization pass than enable the optimization you don't like and disable it. Note that most optimizations are not part of the gfortran front-end.