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

["nerge at informatik dot uni-hamburg.de" <gcc-bugzilla@gcc.gnu.org>]

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.