public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/61775] New: Allocatable array initialized by implied-do loop array constructor gives invalid memory reference
@ 2014-07-10 17:02 robert.rosenberg at nrl dot navy.mil
2014-07-10 20:29 ` [Bug fortran/61775] " kargl at gcc dot gnu.org
` (4 more replies)
0 siblings, 5 replies; 6+ messages in thread
From: robert.rosenberg at nrl dot navy.mil @ 2014-07-10 17:02 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61775
Bug ID: 61775
Summary: Allocatable array initialized by implied-do loop array
constructor gives invalid memory reference
Product: gcc
Version: 4.9.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: robert.rosenberg at nrl dot navy.mil
Created attachment 33104
--> https://gcc.gnu.org/bugzilla/attachment.cgi?id=33104&action=edit
initializes allocatable array with implied-do loop array constructor
Received an 'invalid memory reference' run time error from gfortran code that
initializes an allocatable array with an implied-do loop array constructor.
Runs fine for Intel and Cray compilers, but fails for both GNU and PGI
compilers.
program pi
real , allocatable :: x(:)
integer :: n
n = 10000
x = [ (i,i=1,n) ]
print*,x(n)
end
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference
2014-07-10 17:02 [Bug fortran/61775] New: Allocatable array initialized by implied-do loop array constructor gives invalid memory reference robert.rosenberg at nrl dot navy.mil
@ 2014-07-10 20:29 ` kargl at gcc dot gnu.org
2014-07-10 20:34 ` kargl at gcc dot gnu.org
` (3 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: kargl at gcc dot gnu.org @ 2014-07-10 20:29 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61775
kargl at gcc dot gnu.org changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |kargl at gcc dot gnu.org
--- Comment #1 from kargl at gcc dot gnu.org ---
Whatever the issue was, it appears to be fixed in HEAD.
troutmask:sgk[205] gfc4x -o z h.f90
troutmask:sgk[206] ./z
10000.0000
troutmask:sgk[207] gfc49 -o z h.f90
troutmask:sgk[208] ./z
Program received signal SIGSEGV: Segmentation fault - invalid memory reference.
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference
2014-07-10 17:02 [Bug fortran/61775] New: Allocatable array initialized by implied-do loop array constructor gives invalid memory reference robert.rosenberg at nrl dot navy.mil
2014-07-10 20:29 ` [Bug fortran/61775] " kargl at gcc dot gnu.org
@ 2014-07-10 20:34 ` kargl at gcc dot gnu.org
2014-07-10 20:37 ` dominiq at lps dot ens.fr
` (2 subsequent siblings)
4 siblings, 0 replies; 6+ messages in thread
From: kargl at gcc dot gnu.org @ 2014-07-10 20:34 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61775
--- Comment #2 from kargl at gcc dot gnu.org ---
(In reply to kargl from comment #1)
> Whatever the issue was, it appears to be fixed in HEAD.
>
> troutmask:sgk[205] gfc4x -o z h.f90
> troutmask:sgk[206] ./z
> 10000.0000
> troutmask:sgk[207] gfc49 -o z h.f90
> troutmask:sgk[208] ./z
>
> Program received signal SIGSEGV: Segmentation fault - invalid memory
> reference.
I take it back. It is broken with optimizations.
troutmask:sgk[213] gfc4x -o z -O -fcheck=all h.f90 && ./z
At line 6 of file h.f90
Fortran runtime error: Index '10000' of dimension 1 of array 'x' above upper
bound of 1
Segmentation fault (core dumped)
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference
2014-07-10 17:02 [Bug fortran/61775] New: Allocatable array initialized by implied-do loop array constructor gives invalid memory reference robert.rosenberg at nrl dot navy.mil
2014-07-10 20:29 ` [Bug fortran/61775] " kargl at gcc dot gnu.org
2014-07-10 20:34 ` kargl at gcc dot gnu.org
@ 2014-07-10 20:37 ` dominiq at lps dot ens.fr
2014-07-11 20:38 ` mikael at gcc dot gnu.org
2014-07-12 11:44 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-07-10 20:37 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61775
Dominique d'Humieres <dominiq at lps dot ens.fr> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|UNCONFIRMED |NEW
Last reconfirmed| |2014-07-10
Ever confirmed|0 |1
--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Whatever the issue was, it appears to be fixed in HEAD.
I don't think so. Could you run the test with -fsanitize=address. On
x86_64-apple-darwin13 r212433, I get at run time:
=================================================================
==4401==ERROR: AddressSanitizer: heap-buffer-overflow on address 0x60200000e014
at pc 0x1064f08c1 bp 0x7fff597100e0 sp 0x7fff597100d8
WRITE of size 4 at 0x60200000e014 thread T0
#0 0x1064f08c0
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x1000018c0)
#1 0x1064f0d19
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001d19)
#2 0x7fff922ef5fc (/usr/lib/system/libdyld.dylib+0x35fc)
0x60200000e014 is located 0 bytes to the right of 4-byte region
[0x60200000e010,0x60200000e014)
allocated by thread T0 here:
#0 0x10652a4c9 (/opt/gcc/gcc4.10p-212433/lib/libasan.1.dylib+0x314c9)
#1 0x1064f0846
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001846)
#2 0x1064f0d19
(/Users/dominiq/Documents/Fortran/g95bench/win/f90/bug/a.out+0x100001d19)
#3 0x7fff922ef5fc (/usr/lib/system/libdyld.dylib+0x35fc)
SUMMARY: AddressSanitizer: heap-buffer-overflow ??:0 ??
Shadow bytes around the buggy address:
0x1c0400001bb0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400001bc0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400001bd0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400001be0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
0x1c0400001bf0: fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa fa
=>0x1c0400001c00: fa fa[04]fa fa fa 06 fa fa fa 06 fa fa fa 05 fa
0x1c0400001c10: fa fa 00 fa fa fa 00 00 fa fa 03 fa fa fa 00 02
0x1c0400001c20: fa fa 00 07 fa fa 00 fa fa fa 00 00 fa fa 00 00
0x1c0400001c30: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
0x1c0400001c40: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
0x1c0400001c50: fa fa 00 00 fa fa 00 00 fa fa 00 00 fa fa 00 00
Shadow byte legend (one shadow byte represents 8 application bytes):
Addressable: 00
Partially addressable: 01 02 03 04 05 06 07
Heap left redzone: fa
Heap right redzone: fb
Freed heap region: fd
Stack left redzone: f1
Stack mid redzone: f2
Stack right redzone: f3
Stack partial redzone: f4
Stack after return: f5
Stack use after scope: f8
Global redzone: f9
Global init order: f6
Poisoned by user: f7
Container overflow: fc
ASan internal: fe
==4401==ABORTING
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference
2014-07-10 17:02 [Bug fortran/61775] New: Allocatable array initialized by implied-do loop array constructor gives invalid memory reference robert.rosenberg at nrl dot navy.mil
` (2 preceding siblings ...)
2014-07-10 20:37 ` dominiq at lps dot ens.fr
@ 2014-07-11 20:38 ` mikael at gcc dot gnu.org
2014-07-12 11:44 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: mikael at gcc dot gnu.org @ 2014-07-11 20:38 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61775
Mikael Morin <mikael at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
CC| |mikael at gcc dot gnu.org
--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> ---
This seems to fix it here (not heavily tested):
Index: trans-expr.c
===================================================================
--- trans-expr.c (révision 209169)
+++ trans-expr.c (copie de travail)
@@ -7932,9 +7932,7 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr
/* Walk the lhs. */
lss = gfc_walk_expr (expr1);
- if (gfc_is_reallocatable_lhs (expr1)
- && !(expr2->expr_type == EXPR_FUNCTION
- && expr2->value.function.isym != NULL))
+ if (gfc_is_reallocatable_lhs (expr1))
lss->is_alloc_lhs = 1;
rss = NULL;
if (lss != gfc_ss_terminator)
>From gcc-bugs-return-456142-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Jul 11 21:17:39 2014
Return-Path: <gcc-bugs-return-456142-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 29227 invoked by alias); 11 Jul 2014 21:17:38 -0000
Mailing-List: contact gcc-bugs-help@gcc.gnu.org; run by ezmlm
Precedence: bulk
List-Id: <gcc-bugs.gcc.gnu.org>
List-Archive: <http://gcc.gnu.org/ml/gcc-bugs/>
List-Post: <mailto:gcc-bugs@gcc.gnu.org>
List-Help: <mailto:gcc-bugs-help@gcc.gnu.org>
Sender: gcc-bugs-owner@gcc.gnu.org
Delivered-To: mailing list gcc-bugs@gcc.gnu.org
Received: (qmail 28850 invoked by uid 48); 11 Jul 2014 21:17:27 -0000
From: "jason at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/61288] valgrind finds problem in build_conditional_expr_1
Date: Fri, 11 Jul 2014 21:17:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: c++
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jason at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: jason at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status
Message-ID: <bug-61288-4-rmVjqUSpjd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-61288-4@http.gcc.gnu.org/bugzilla/>
References: <bug-61288-4@http.gcc.gnu.org/bugzilla/>
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: 2014-07/txt/msg00733.txt.bz2
Content-length: 294
https://gcc.gnu.org/bugzilla/show_bug.cgi?ida288
Jason Merrill <jason at gcc dot gnu.org> changed:
What |Removed |Added
----------------------------------------------------------------------------
Status|NEW |ASSIGNED
^ permalink raw reply [flat|nested] 6+ messages in thread* [Bug fortran/61775] Allocatable array initialized by implied-do loop array constructor gives invalid memory reference
2014-07-10 17:02 [Bug fortran/61775] New: Allocatable array initialized by implied-do loop array constructor gives invalid memory reference robert.rosenberg at nrl dot navy.mil
` (3 preceding siblings ...)
2014-07-11 20:38 ` mikael at gcc dot gnu.org
@ 2014-07-12 11:44 ` dominiq at lps dot ens.fr
4 siblings, 0 replies; 6+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-07-12 11:44 UTC (permalink / raw)
To: gcc-bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61775
--- Comment #5 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(In reply to comment #4)
> This seems to fix it here (not heavily tested): ...
Confirmed, regtested without regression and no obvious problem with my other
tests.
^ permalink raw reply [flat|nested] 6+ messages in thread
end of thread, other threads:[~2014-07-12 11:44 UTC | newest]
Thread overview: 6+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2014-07-10 17:02 [Bug fortran/61775] New: Allocatable array initialized by implied-do loop array constructor gives invalid memory reference robert.rosenberg at nrl dot navy.mil
2014-07-10 20:29 ` [Bug fortran/61775] " kargl at gcc dot gnu.org
2014-07-10 20:34 ` kargl at gcc dot gnu.org
2014-07-10 20:37 ` dominiq at lps dot ens.fr
2014-07-11 20:38 ` mikael at gcc dot gnu.org
2014-07-12 11:44 ` dominiq at lps dot ens.fr
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).