[Bug fortran/57733] New: pointer assignment internal compiler error

[Bug fortran/57733] New: pointer assignment internal compiler error

[nerge at informatik dot uni-hamburg.de]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57733

            Bug ID: 57733
           Summary: pointer assignment internal compiler error
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: nerge at informatik dot uni-hamburg.de

Created attachment 30388
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30388&action=edit
minimal example

pointer assignment within function crashes:

function arguments: pointer and allocatable array
- array will be allocated in function 
- afterwards the array will be assigned to the pointer and this crashes with at
least gcc 4.6.3, 4.7.1, 4.8.1, and 4.9:

pointer_test_gfortran.f90: In function ‘test_dyn_coor_3_3d’:
pointer_test_gfortran.f90:80:0: internal compiler error: Segmentation fault
 ptr%x => array%x%x
 ^
libbacktrace could not find executable to open

- minimal example is attached

- the assignment of the array to a local pointer works well
>From gcc-bugs-return-425292-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 27 12:32:29 2013
Return-Path: <gcc-bugs-return-425292-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 30164 invoked by alias); 27 Jun 2013 12:32:28 -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 30071 invoked by uid 55); 27 Jun 2013 12:32:19 -0000
From: "sgunderson at bigfoot dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)
Date: Thu, 27 Jun 2013 12:32:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sgunderson at bigfoot dot com
X-Bugzilla-Status: UNCONFIRMED
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: <bug-57623-4-GkHeCxGn6n@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57623-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57623-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01671.txt.bz2
Content-length: 825

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623

--- Comment #10 from sgunderson at bigfoot dot com ---
On Thu, Jun 27, 2013 at 12:27:02PM +0000, jakub at gcc dot gnu.org wrote:
> Then please provide preprocessed testcase for it (plus command line options). 
> Because I'm really curious how it could have been matched.

Sorry, the code is a) not so easy to make public right now, and b) this
particular edit has been lost in the mists of time (like I said, I wrote it
slightly differently and then it was gone). But the scrollback in my terminal
still has this for “proof”:

sesse@gruessi:~/addie$ g++-4.8 -O2 -march=native -o addie addie.cc 
/tmp/ccJweT2R.s: Assembler messages:
/tmp/ccJweT2R.s:82: Error: operand size mismatch for `bzhi'

Sorry I couldn't be more helpful. :-)

/* Steinar */
>From gcc-bugs-return-425293-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 27 12:34:09 2013
Return-Path: <gcc-bugs-return-425293-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 31634 invoked by alias); 27 Jun 2013 12:34:09 -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 31571 invoked by uid 55); 27 Jun 2013 12:34:07 -0000
From: "sgunderson at bigfoot dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/57623] BEXTR intrinsic has memory operands switched around (fails to compile code)
Date: Thu, 27 Jun 2013 12:34:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: target
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: sgunderson at bigfoot dot com
X-Bugzilla-Status: UNCONFIRMED
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: <bug-57623-4-72RySrHwk4@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57623-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57623-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2013-06/txt/msg01672.txt.bz2
Content-length: 577

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57623

--- Comment #11 from sgunderson at bigfoot dot com ---
On Thu, Jun 27, 2013 at 12:32:18PM +0000, sgunderson at bigfoot dot com wrote:
> Sorry, the code is a) not so easy to make public right now, and b) this
> 
> particular edit has been lost in the mists of time (like I said, I wrote it
> 
> slightly differently and then it was gone). But the scrollback in my termin
> al
> 
> still has this for “proof”:

Hah, I reproduced it. I'll try to distill it down to a small test case.

/* Steinar */
>From gcc-bugs-return-425294-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Jun 27 12:38:38 2013
Return-Path: <gcc-bugs-return-425294-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 1603 invoked by alias); 27 Jun 2013 12:38: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 1553 invoked by uid 48); 27 Jun 2013 12:38:34 -0000
From: "matz at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/57723] Missed optimization: recursion around empty function
Date: Thu, 27 Jun 2013 12:38:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: tree-optimization
X-Bugzilla-Version: 4.9.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: minor
X-Bugzilla-Who: matz at gcc dot gnu.org
X-Bugzilla-Status: UNCONFIRMED
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: <bug-57723-4-RCfhGZO14p@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-57723-4@http.gcc.gnu.org/bugzilla/>
References: <bug-57723-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: 2013-06/txt/msg01673.txt.bz2
Content-length: 2246

http://gcc.gnu.org/bugzilla/show_bug.cgi?idW723

--- Comment #8 from Michael Matz <matz at gcc dot gnu.org> ---
(In reply to petschy from comment #7)
> Is it a plausible assumption that if a function is not marked as 'noreturn'
> and the loop doesn't change the program's state then the loop could be
> optimized away?

It's not unplausible, but still wrong, see below.  GCC optimizes empty
loops only away if the functions containing them are marked pure or const (the
argument being that an infinite loop is in itself a side-effect observable from
outside).  This could be extended to also do that for functions without the
noreturn attribute.

But it would be a relatively large change in semantics.  That is because
noreturn attributes are optional; functions that don't return aren't
required to be so marked, so in practice a missing noreturn attribute
doesn't mean anything.  So, when GCC starts to remove infinite loops in
functions missing it (in practice most functions) this might change behaviour
(which you already can have with the unsafe-loop-optimization flag).

The problem lies with multi-threaded programs.  A function containing
an infinite loop could be stopped from a different thread.  While I'll
happily admit that this is a quite unlikely behaviour, you can construct
a valid program that will break with infinite-loop removal.

So it seems that if any other attribute should trigger this in addition
to const/pure (which have other effects of course), it would have to
be a new one, with positive meaning, ala "this-function-does-return".

I'm not aware of anyone sufficiently motivated to work on this.  Perhaps
you are, if so, look for finite_loop_p() in tree-ssa-loop-niter.c for
the place to lookup the new attribute, and builtin-attrs.def for the place
to define a new attribute.

> Cases:
> - the loop terminates, but the state is not changed, NOP
> - the loop does not terminate (in this case a cycle of the Node's), but the
> function should return (no noreturn attr), so this is probably a bug in the
> prg
>
> I can't think of any cases right now for the second point where that would
> be the desired behaviour of the program, instead of a bug. Please comment on
> this.

See the multi-threading example.

[Bug fortran/57733] pointer assignment internal compiler error

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57733

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-06-27
     Ever confirmed|0                           |1

--- Comment #1 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Confirmed, the backtrace is

Program received signal SIGSEGV, Segmentation fault.
0x0000000100109630 in gfc_trans_pointer_assignment (expr1=<value optimized
out>, expr2=<value optimized out>)
    at ../../_clean/gcc/fortran/trans-expr.c:6551
warning: Source file is more recent than executable.
6551              gfc_add_modify (&lse.post, GFC_DECL_SPAN(decl), tmp);
(gdb) bt
#0  0x0000000100109630 in gfc_trans_pointer_assignment (expr1=<value optimized
out>, expr2=<value optimized out>)
    at ../../_clean/gcc/fortran/trans-expr.c:6551
#1  0x00000001000caa87 in trans_code (code=<value optimized out>, cond=<value
optimized out>) at ../../_clean/gcc/fortran/trans.c:1543
#2  0x00000001000f5cb4 in gfc_generate_function_code (ns=<value optimized out>)
at ../../_clean/gcc/fortran/trans-decl.c:5479
#3  0x00000001000f5b08 in gfc_generate_function_code (ns=<value optimized out>)
at ../../_clean/gcc/fortran/trans-decl.c:4612
#4  0x000000010008609c in gfc_parse_file () at
../../_clean/gcc/fortran/parse.c:4509
#5  0x00000001000c6006 in gfc_be_parse_file () at
../../_clean/gcc/fortran/f95-lang.c:189
#6  0x000000010078b844 in compile_file () at ../../_clean/gcc/toplev.c:544
#7  0x000000010078d939 in toplev_main (argc=2, argv=0x7fff5fbfd920) at
../../_clean/gcc/toplev.c:1872
#8  0x0000000100009a94 in start (pc=<value optimized out>, bases=0x0) at
../../../_clean/libgcc/config/unwind-dw2-fde-darwin.c:272

[Bug fortran/57733] pointer assignment internal compiler error

[mikael at gcc dot gnu.org]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57733

Mikael Morin <mikael at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |mikael at gcc dot gnu.org

--- Comment #2 from Mikael Morin <mikael at gcc dot gnu.org> ---
Dup of PR34640?

[Bug fortran/57733] pointer assignment internal compiler error

[dominiq at lps dot ens.fr]

http://gcc.gnu.org/bugzilla/show_bug.cgi?id=57733

Dominique d'Humieres <dominiq at lps dot ens.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|---                         |DUPLICATE

--- Comment #3 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Dup of PR34640?

I think you are right.

*** This bug has been marked as a duplicate of bug 34640 ***