[Bug fortran/57697] New: Segfault with defined assignment for components during intrinsic assignment

[Bug fortran/57697] New: Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

            Bug ID: 57697
           Summary: Segfault with defined assignment for components during
                    intrinsic assignment
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Keywords: wrong-code
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: burnus at gcc dot gnu.org

Found with ForTrilinos's ForTrilinos_ADT_3D_Burgers_6th_Pade example.

For the code:
  function new_scalar_field(initial,comm) result(this)
    ...
    if (.not. allocated(map)) then
      map = Epetra_Map(NumGlobalElements,NumMyElements,IndexBase,comm)

gfortran generates the code:

  static struct epetra_map * _F.DA104 = 0B;
  static struct universal _F.DA105;
  ...
        if (map == 0B)
          {
            {
              static integer(kind=4) C.5077 = 1;
              static integer(kind=4) C.5076 = 4096;

              if (_F.DA104 != 0B) goto L.249;
              _F.DA104 = (struct epetra_map *) __builtin_malloc (56);
              L.249:;
              *_F.DA104 = create_linear (&C.5076, &nummyelements, &C.5077,
                           (struct __class_fepetra_comm_Epetra_comm *) comm);
            }
            _F.DA105 = map->epetra_blockmap.universal;
            if (map != 0B) goto L.251;
            map = (struct epetra_map *) __builtin_malloc (56);
            L.251:;
            *map = *_F.DA104;

Note that the assignment to "_F.DA105" dereferences "map", which is known to be
NULL!

[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #1 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Created attachment 30353
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=30353&action=edit
Test case

[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment

[dominiq at lps dot ens.fr]

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

--- Comment #2 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> Created attachment 30353 [details]
> Test case

Should not this go to PR57696?

[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #3 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #2)
> Should not this go to PR57696?

No. The examples are similar, but they expose rather different bugs.

PR57696 has already a test case and the problem there is that no defined
assignment is done for an allocatable component. -> Wrong code as the defined
assignment is not invoked.

This PR (and attachment 30353) is about an unallocated allocatable LHS, where
for a component defined assignment is used. -> Wrong code as it segfaults at
run time.

[Bug fortran/57697] Segfault with defined assignment for components during intrinsic assignment

[dominiq at lps dot ens.fr]

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

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 #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(In reply to Tobias Burnus from comment #3)
> > Should not this go to PR57696?
>
> No. The examples are similar, but they expose rather different bugs.

So confirmed.

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |janus at gcc dot gnu.org
            Summary|Segfault with defined       |[OOP] Segfault with defined
                   |assignment for components   |assignment for components
                   |during intrinsic assignment |during intrinsic assignment

--- Comment #5 from janus at gcc dot gnu.org ---
Related to PR 57696 and PR 46897, obviously.

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #6 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Submitted patch: http://gcc.gnu.org/ml/fortran/2013-09/msg00016.html

As follow up, one should check whether arrays (lhs unallocated, same shape,
different shape) are correctly handled.

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Sun Sep 15 10:54:10 2013
New Revision: 202601

URL: http://gcc.gnu.org/viewcvs?rev=202601&root=gcc&view=rev
Log:
2013-09-15  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        * resolve.c (generate_component_assignments): Handle unallocated
        LHS with defined assignment of components.

2013-09-15  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        * gfortran.dg/defined_assignment_10.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_10.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Mon Sep 16 06:42:02 2013
New Revision: 202609

URL: http://gcc.gnu.org/viewcvs?rev=202609&root=gcc&view=rev
Log:
2013-09-16  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        * resolve.c (generate_component_assignments): Correctly handle
        * the
        case that the LHS is not allocated.

2013-09-16  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        * gfortran.dg/defined_assignment_10.f90: Comment print
        * statement.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_10.f90

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #9 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Wed Sep 18 22:19:03 2013
New Revision: 202725

URL: http://gcc.gnu.org/viewcvs?rev=202725&root=gcc&view=rev
Log:
2013-09-18  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        * gfortran.dg/defined_assignment_11.f90: New.


Added:
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_11.f90
Modified:
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #1: Type: text/plain; charset="UTF-8", Size: 8021 bytes --]

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

--- Comment #10 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Still doesn't correctly work as the following code shows:

        if (_F.DA0 == 0B)
            _F.DA0 = left;
        …
    finally
      {
        if (left != 0B)
            __builtin_free ((void *) left);
        if (_F.DA0 != 0B)
            __builtin_free ((void *) _F.DA0);

Which causes a double free!

module m0
  implicit none
  type component
    integer :: i = 42
  contains
    procedure :: assign0
    generic :: assignment(=) => assign0
  end type
  type parent
    type(component) :: foo
  end type
contains
  elemental subroutine assign0(lhs,rhs)
    class(component), intent(INout) :: lhs
    class(component), intent(in) :: rhs
    lhs%i = 20
  end subroutine
end module

program main
  use m0
  implicit none
  block
    type(parent), allocatable :: left
    type(parent) :: right
    print *, right%foo
    left = right
    print *, left%foo
    if (left%foo%i /= 20) call abort()
  end block
end
>From gcc-bugs-return-430150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 19 07:07:00 2013
Return-Path: <gcc-bugs-return-430150-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 7422 invoked by alias); 19 Sep 2013 07:06:59 -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 7381 invoked by uid 48); 19 Sep 2013 07:06:54 -0000
From: "vincenzo.innocente at cern dot ch" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug tree-optimization/58472] New: gomp4: ICE in in vectorizable_store, at tree-vect-stmts.c:4192
Date: Thu, 19 Sep 2013 07:06:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
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: normal
X-Bugzilla-Who: vincenzo.innocente at cern dot ch
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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter
Message-ID: <bug-58472-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-09/txt/msg01390.txt.bz2
Content-length: 1093

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

            Bug ID: 58472
           Summary: gomp4: ICE in in vectorizable_store, at
                    tree-vect-stmts.c:4192
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: tree-optimization
          Assignee: unassigned at gcc dot gnu.org
          Reporter: vincenzo.innocente at cern dot ch

#include<cmath>
float a[1024];
float b[1024];

float sumO1() {
  auto s = 0.f;
#pragma omp simd reduction(+:s)
  for (auto i=0U;i<1024;++i) {
    s += a[i]*b[i];
  }
  return s;
}

pb-d-128-141-131-26:vectorize innocent$ c++ -std=c++11 -O2  
-ftree-vectorizer-verbose=1 -S omp4.cc -fopenmp
omp4.cc:9:13: note: loop vectorized
omp4.cc: In function ‘float sumO1()’:
omp4.cc:5:7: internal compiler error: in vectorizable_store, at
tree-vect-stmts.c:4192
 float sumO1() {
       ^

omp4.cc:5:7: internal compiler error: Abort trap: 6
c++: internal compiler error: Abort trap: 6 (program cc1plus)
Abort trap: 6
>From gcc-bugs-return-430151-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Sep 19 07:28:31 2013
Return-Path: <gcc-bugs-return-430151-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27127 invoked by alias); 19 Sep 2013 07:28:30 -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 27069 invoked by uid 48); 19 Sep 2013 07:28:26 -0000
From: "chris at bubblescope dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/58437] [4.7/4.8/4.9 Regression] Sorting value in reverse order is much slower compare to gcc44
Date: Thu, 19 Sep 2013 07:28:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: 4.8.1
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: chris at bubblescope dot net
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.7.4
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: attachments.created
Message-ID: <bug-58437-4-PhzrilGqMj@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58437-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58437-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-09/txt/msg01391.txt.bz2
Content-length: 2149

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

--- Comment #13 from Chris Jefferson <chris at bubblescope dot net> ---
Created attachment 30861
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id0861&actioníit
Sort patch

Wow, this an embarrassing bug to get through testing. Obviously not enough
profiling done!

This patch (I hope) gets performance back to g++-4.4 levels, and in my
experiments slightly (but not noticeably) better. I would be interested in
anyone trying out this patch on their own data.

For the interested, here is a description of the bug. I will assume you
understand quicksort!

Quicksort requires taking a pivot, then partitioning the array by that pivot.
Getting O(n log n) behaviour requires that you choose a "good" pivot. Like most
people, in g++ we choose the median of the first, middle, and last value in the
array as the pivot.

In the C++03 world, after we chose the pivot we took a copy of it. In C++11, we
cannot copy values in std::sort any more, only move and swap.

Trying to keep track of the pivot as it moves around during the partitioning is
horrible and inefficient. So, I had the "bright idea" to do swap(*first,
*pivot). Now the pivot is at the first location in the array, and we can just
partition [first+1, end) and the partitioning is fine. See the mistake yet?

The bug comes when we recursively partition the first cell. We again choose the
median from the first, mid and last of this cell, but *first is always the
biggest thing in the cell (as we pivoted on it one level above), meaning our
median calculation is unbalanced and often chooses terrible values, leading to
us often hitting the O(n^2) behaviour of quicksort (actually we technically get
o(n log n), as we switch to heapsort when things are going badly, but the time
is still bad).

There are a selection of ways of fixing this. This patch switches the median
calculation from considering then first, mid, last locations to on first+1,
mid, last-1 (there is no reason in this bug to consider last-1 instead of last,
but I thought it wouldn't do any harm, and might avoid other issues of
accidentally choosing a bad pivot.

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[dominiq at lps dot ens.fr]

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

--- Comment #11 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The test gfortran.dg/defined_assignment_11.f90 fails on x86_64-apple-darwin10:

Program received signal SIGSEGV: Segmentation fault - invalid memory reference.

Valgrind reports

==30916== Invalid read of size 4
==30916==    at 0x1000021EF: MAIN__ (defined_assignment_11_db.f90:40)
==30916==    by 0x100002C5B: main (defined_assignment_11_db.f90:35)
==30916==  Address 0x0 is not stack'd, malloc'd or (recently) free'd

It is probably related to comment #10.

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #12 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Dominique d'Humieres from comment #11)
> The test gfortran.dg/defined_assignment_11.f90 fails on
> x86_64-apple-darwin10:
> ==30916== Invalid read of size 4
> ==30916==    at 0x1000021EF: MAIN__ (defined_assignment_11_db.f90:40)
> 
> It is probably related to comment #10.

It shouldn't. The problem of comment 10 only occurs when "left" is deallocated
- and there is no end-of-scope deallocation in defined_assignment_11.f90 as
variables in MAIN have implicitly the SAVE attribute.

What's the difference between defined_assignment_11_db.f90 and
defined_assignment_11.f90?

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[dominiq at lps dot ens.fr]

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

--- Comment #13 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> What's the difference between defined_assignment_11_db.f90 and 
> defined_assignment_11.f90?

In defined_assignment_11_db.f90 the print statements have been uncommented.

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[dominiq at lps dot ens.fr]

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

--- Comment #14 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
(In reply to Dominique d'Humieres from comment #11)
> The test gfortran.dg/defined_assignment_11.f90 fails on
> x86_64-apple-darwin10:

This is due to some patch I have in my working tree: the test passes for clean
trees (w/wo --enable-checking=release), see

http://gcc.gnu.org/ml/gcc-testresults/2013-09/msg01613.html

I'll try to figure out which one of the several patches I have applied is
responsible for the failure.

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #15 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Wed Sep 25 19:54:12 2013
New Revision: 202922

URL: http://gcc.gnu.org/viewcvs?rev=202922&root=gcc&view=rev
Log:
2013-09-25  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        PR fortran/58469
        * resolve.c (generate_component_assignments): Avoid double free
        at runtime and freeing a still-being used expr.

2013-09-25  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        PR fortran/58469
        * gfortran.dg/defined_assignment_8.f90: New.
        * gfortran.dg/defined_assignment_9.f90: New.

Added:
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_8.f90
    trunk/gcc/testsuite/gfortran.dg/defined_assignment_9.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/resolve.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #16 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Fri Oct  4 16:25:55 2013
New Revision: 203207

URL: http://gcc.gnu.org/viewcvs?rev=203207&root=gcc&view=rev
Log:
2013-10-04  Tobias Burnus  <burnus@net-b.de>

        Backport from mainline
        2013-09-25  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        PR fortran/58469
        * resolve.c (generate_component_assignments): Avoid double free
        at runtime and freeing a still-being used expr.


2013-10-04  Tobias Burnus  <burnus@net-b.de>

        Backport from mainline
        2013-09-25  Tobias Burnus  <burnus@net-b.de>

        PR fortran/57697
        PR fortran/58469
        * gfortran.dg/defined_assignment_8.f90: New.
        * gfortran.dg/defined_assignment_9.f90: New.


Added:
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/defined_assignment_10.f90
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/defined_assignment_11.f90
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/defined_assignment_8.f90
    branches/gcc-4_8-branch/gcc/testsuite/gfortran.dg/defined_assignment_9.f90
Modified:
    branches/gcc-4_8-branch/gcc/fortran/ChangeLog
    branches/gcc-4_8-branch/gcc/fortran/resolve.c
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

--- Comment #17 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Author: burnus
Date: Fri Oct  4 16:54:55 2013
New Revision: 203208

URL: http://gcc.gnu.org/viewcvs?rev=203208&root=gcc&view=rev
Log:
Correct ChangeLog for PR fortran/57697

Modified:
    branches/gcc-4_8-branch/gcc/testsuite/ChangeLog

[Bug fortran/57697] [OOP] Segfault with defined assignment for components during intrinsic assignment

[burnus at gcc dot gnu.org]

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

Tobias Burnus <burnus at gcc dot gnu.org> changed:

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

--- Comment #18 from Tobias Burnus <burnus at gcc dot gnu.org> ---
Close as FIXED.  The patchset has been committed to the trunk (4.9) and
backported to the 4.8 branch.