[Bug fortran/65548] New: [5.0 Regression] gfc_conv_procedure_call

[Bug fortran/65548] New: [5.0 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

            Bug ID: 65548
           Summary: [5.0 Regression]  gfc_conv_procedure_call
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juergen.reuter at desy dot de

The following code
{{{
module selectors
  type :: selector_t
     integer, dimension(:), allocatable :: map
     real, dimension(:), allocatable :: weight
   contains
     procedure :: init => selector_init
end type selector_t


contains

  subroutine selector_init (selector, weight)
    class(selector_t), intent(out) :: selector
    real, dimension(:), intent(in) :: weight
    real :: s
    integer :: n, i
    logical, dimension(:), allocatable :: mask
    s = sum (weight)
    allocate (mask (size (weight)), source = weight /= 0)
    n = count (mask)
    if (n > 0) then
       allocate (selector%map (n), &
            source = pack ([(i, i = 1, size (weight))], mask))
       allocate (selector%weight (n), &
            source = pack (weight / s, mask))
    else
       allocate (selector%map (1), source = 1)
       allocate (selector%weight (1), source = 0.)
    end if
  end subroutine selector_init

end module selectors
}}}

yields an ICE with gfortran 5.0 trunk:
$ gfortran -c selectors.f90 
selectors.f90:23:0:

             source = pack ([(i, i = 1, size (weight))], mask))
 1
internal compiler error: in gfc_conv_procedure_call, at
fortran/trans-expr.c:5608

selectors.f90:23:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)

My gcc version is r221644 from the trunk, a version from ca. March 4th or 5th
did still work.

[Bug fortran/65548] [5.0 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #1 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Created attachment 35129
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35129&action=edit
Code that triggers the ICE
>From gcc-bugs-return-481536-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 25 03:52:36 2015
Return-Path: <gcc-bugs-return-481536-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 13988 invoked by alias); 25 Mar 2015 03:52:36 -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 13952 invoked by uid 48); 25 Mar 2015 03:52:32 -0000
From: "juergen.reuter at desy dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65548] [5.0 Regression]  gfc_conv_procedure_call
Date: Wed, 25 Mar 2015 07:16: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: juergen.reuter at desy dot de
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-65548-4-Cq6EfQ5UbC@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65548-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65548-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: 2015-03/txt/msg02680.txt.bz2
Content-length: 169

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #2 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I'd also appreciate a short workaround.
>From gcc-bugs-return-481537-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 25 04:24:54 2015
Return-Path: <gcc-bugs-return-481537-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 65211 invoked by alias); 25 Mar 2015 04:24:54 -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 65155 invoked by uid 48); 25 Mar 2015 04:24:50 -0000
From: "jvdelisle at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65541] [5 Regression] namelist regression
Date: Wed, 25 Mar 2015 07:21: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: jvdelisle at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: jvdelisle at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65541-4-WauuaTE67i@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65541-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65541-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: 2015-03/txt/msg02681.txt.bz2
Content-length: 1019

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide541

--- Comment #4 from Jerry DeLisle <jvdelisle at gcc dot gnu.org> ---
This fixes it:

Index: io/write.c
==================================================================--- io/write.c    (revision 221571)
+++ io/write.c    (working copy)
@@ -1704,10 +1704,11 @@
   size_t clen;
   index_type elem_ctr;
   size_t obj_name_len;
-  void * p ;
+  void * p;
   char cup;
   char * obj_name;
   char * ext_name;
+  char * q;
   size_t ext_name_len;
   char rep_buff[NML_DIGITS];
   namelist_info * cmp;
@@ -1745,6 +1746,8 @@
       for (dim_i = len; dim_i < clen; dim_i++)
     {
       cup = toupper ((int) obj->var_name[dim_i]);
+      if (cup == '+')
+        cup = '%';
       write_character (dtp, &cup, 1, 1, NODELIM);
     }
       write_character (dtp, "=", 1, 1, NODELIM);
@@ -1894,6 +1897,9 @@
         }

           ext_name[tot_len] = '\0';
+          for (q = ext_name; *q; q++)
+        if (*q == '+')
+          *q = '%';

           /* Now obj_name.  */

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

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

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

--- Comment #4 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I'd also appreciate a short workaround.

  subroutine selector_init (selector, weight)
    real :: s
    integer :: n, i
    logical, dimension(:), allocatable :: mask
    integer, allocatable :: tmpi(:)
    real, allocatable :: tmpr(:)
    s = sum (weight)
    allocate (mask (size (weight)), source = weight /= 0)
    n = count (mask)
    if (n > 0) then
        allocate(tmpi(n),tmpr(n))
        tmpi = pack ([(i, i = 1, size (weight))], mask)
        tmpr = pack (weight / s, mask)
        allocate (selector%map (n), source = tmpi)
        allocate (selector%weight (n), source = tmpr)
    else
       allocate (selector%map (1), source = 1)
       allocate (selector%weight (1), source = 0.)
    end if
  end subroutine selector_init

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-03-25
                 CC|                            |jakub at gcc dot gnu.org
   Target Milestone|---                         |5.0
            Summary|[5.0 Regression]            |[5 Regression]
                   |gfc_conv_procedure_call     |gfc_conv_procedure_call
     Ever confirmed|0                           |1

--- Comment #3 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
Started with r221621.

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #6 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
A working patch has been submitted at
https://gcc.gnu.org/ml/fortran/2015-03/msg00132.html.

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #7 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Tue Apr  7 14:10:43 2015
New Revision: 221897

URL: https://gcc.gnu.org/viewcvs?rev=221897&root=gcc&view=rev
Log:
    PR fortran/65548
        * gfortran.dg/allocate_with_source_5.f90: New test.

        * trans-stmt.c (gfc_trans_allocate): For intrinsic functions
        use conv_expr_descriptor() instead of conv_expr_reference().


Added:
    trunk/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

vehre at gcc dot gnu.org changed:

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

--- Comment #8 from vehre at gcc dot gnu.org ---
Fixed with r221897.

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

Jürgen Reuter <juergen.reuter at desy dot de> changed:

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

--- Comment #9 from Jürgen Reuter <juergen.reuter at desy dot de> ---
No, I still get an ICE on a slightly different code, will provide a small
example later on, but the code looks like this:
allocate (phs%m_in  (phs%config%n_in), &
    source = phs_config%flv(:phs_config%n_in, 1)%get_mass ())
so the problem might be the call to a TBP of a derived type component which is
an array, where only some components are taken (?)
>From gcc-bugs-return-483238-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 10 07:32:22 2015
Return-Path: <gcc-bugs-return-483238-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 105674 invoked by alias); 10 Apr 2015 07:32:21 -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 105390 invoked by uid 48); 10 Apr 2015 07:32:17 -0000
From: "thorduri at secnorth dot net" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65723] uniform_real_distribution isn't uniform.
Date: Fri, 10 Apr 2015 07:32: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: thorduri at secnorth dot net
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: cc
Message-ID: <bug-65723-4-vhj2Ug3Nfr@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65723-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65723-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: 2015-04/txt/msg00790.txt.bz2
Content-length: 746

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide723

Thordur Bjornsson <thorduri at secnorth dot net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |thorduri at secnorth dot net

--- Comment #3 from Thordur Bjornsson <thorduri at secnorth dot net> ---
(In reply to Jonathan Wakely from comment #1)
> I think this is WONTFIX. If you use from=0, to=2 then it works fine, so use
> those as the distribution parameters and then add 0x1p52 to the result.

I don't see how this works fine. Could you perhaps provide an example ?

See the following gist: https://gist.github.com/thorduri/5b9cc8743e631638cab4

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #10 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> No, I still get an ICE on a slightly different code, will provide
> a small example later on,

Still missing. At the same time could you please audit your code for other
usages of
allocate (..., source=...) or allocate (..., mold=...) in order to avoid an
infinite cycle FIXED->REOPENED-FIXED_>...?

> but the code looks like this:
> allocate (phs%m_in  (phs%config%n_in), &
>     source = phs_config%flv(:phs_config%n_in, 1)%get_mass ())
> so the problem might be the call to a TBP of a derived type component
> which is an array, where only some components are taken (?)

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #11 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Dominique d'Humieres from comment #10)
> > No, I still get an ICE on a slightly different code, will provide
> > a small example later on,
> 
> Still missing. At the same time could you please audit your code for other
> usages of
> allocate (..., source=...) or allocate (..., mold=...) in order to avoid an
> infinite cycle FIXED->REOPENED-FIXED_>...?
> 
> > but the code looks like this:
> > allocate (phs%m_in  (phs%config%n_in), &
> >     source = phs_config%flv(:phs_config%n_in, 1)%get_mass ())
> > so the problem might be the call to a TBP of a derived type component
> > which is an array, where only some components are taken (?)

Working on providing a short code snippet. Just give me another hour or so.
>From gcc-bugs-return-483304-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 10 14:05:40 2015
Return-Path: <gcc-bugs-return-483304-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 104311 invoked by alias); 10 Apr 2015 14:05:40 -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 104218 invoked by uid 48); 10 Apr 2015 14:05:37 -0000
From: "evstupac at gmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65710] [4.9/5 Regression] Thumb1 ICE caused by no register to spill
Date: Fri, 10 Apr 2015 14:05: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: evstupac at gmail dot com
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65710-4-UivccymXkd@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65710-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65710-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: 2015-04/txt/msg00856.txt.bz2
Content-length: 454

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide710

--- Comment #12 from Stupachenko Evgeny <evstupac at gmail dot com> ---
(In reply to Stupachenko Evgeny from comment #8)
> The patch most likely (currently bisecting to get exact commit) caused 15%
> regression on spec2000 164.gzip test compiled with "-Ofast -funroll-loops
> -flto -march=slm -m32 -fPIE -pie".
> (reproducible on Sandybridge).

Confirmed. The commit caused 15% regression on 164.gzip

[Bug fortran/65548] [5 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #12 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Here is the code (cf. below). It ICEs with r221962. 

module phs_base
  type :: flavor_t
   contains
     procedure :: get_mass => flavor_get_mass
  end type flavor_t

  type, abstract :: phs_config_t
     integer :: n_in = 0
     type(flavor_t), dimension(:,:), allocatable :: flv
  end type phs_config_t

  type, abstract :: phs_t
     class(phs_config_t), pointer :: config => null ()
     real, dimension(:), allocatable :: m_in
   contains
     procedure :: base_init => phs_base_init
  end type phs_t

contains

  elemental function flavor_get_mass (flv) result (mass)
    real :: mass
    class(flavor_t), intent(in) :: flv
    mass = 0
  end function flavor_get_mass

  subroutine phs_base_init (phs, phs_config)
    class(phs_t), intent(out) :: phs
    class(phs_config_t), intent(in), target :: phs_config
    phs%config => phs_config
    allocate (phs%m_in  (phs%config%n_in), &
         source = phs_config%flv(:phs_config%n_in, 1)%get_mass ())
  end subroutine phs_base_init

end module phs_base
>From gcc-bugs-return-483334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 10 16:55:34 2015
Return-Path: <gcc-bugs-return-483334-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 61364 invoked by alias); 10 Apr 2015 16:55:34 -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 61268 invoked by uid 48); 10 Apr 2015 16:55:30 -0000
From: "yroux at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65710] [4.9/5 Regression] Thumb1 ICE caused by no register to spill
Date: Fri, 10 Apr 2015 16:55: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: yroux at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.9.3
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65710-4-oZzVgg77oU@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65710-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65710-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: 2015-04/txt/msg00886.txt.bz2
Content-length: 677

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide710

--- Comment #21 from Yvan Roux <yroux at gcc dot gnu.org> ---
(In reply to Jakub Jelinek from comment #19)
> (In reply to Vladimir Makarov from comment #18)
> > (In reply to Jakub Jelinek from comment #15)
> > > To be clear, I think we can postpone fixing the performance issue till 5.2/6.
> > > The reason this is a P1 is #c9, #c10, #c11.  Vlad, can you please have a
> > > look at that?
> >
> > Ok.  I'll be working on it for gcc-4.9.
> >
> > Thanks for the clarification.
>
> #c10 says it happens on the trunk too.

I can't check full validation results right now, but the suggested fix in #c11
seems to fix the issue

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #13 from vehre at gcc dot gnu.org ---
Created attachment 35318
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35318&action=edit
Follow-up patch fixing latest regression.

The attached patch fixes the ICE. 

Juergen, please check and report back, to prevent closed->reopen-cycle.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #14 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to vehre from comment #13)
> Created attachment 35318 [details]
> Follow-up patch fixing latest regression.
> 
> The attached patch fixes the ICE. 
> 
> Juergen, please check and report back, to prevent closed->reopen-cycle.

Will do. Is that relativ also to the 6.0_development trunk? I had an
IT-security enforced OS upgrade meaning I have to recompile my compilers. And I
wanted to check 6.0, but I can also try 5.1 release (as soon as the tarball is
there).
>From gcc-bugs-return-483658-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 15 12:52:42 2015
Return-Path: <gcc-bugs-return-483658-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 12002 invoked by alias); 15 Apr 2015 12:52:42 -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 11959 invoked by uid 48); 15 Apr 2015 12:52:38 -0000
From: "vehre at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
Date: Wed, 15 Apr 2015 12:52: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vehre at gcc dot gnu.org
X-Bugzilla-Status: REOPENED
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: vehre at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65548-4-05SXgQwWCt@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65548-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65548-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: 2015-04/txt/msg01210.txt.bz2
Content-length: 157

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide548

--- Comment #15 from vehre at gcc dot gnu.org ---
That patch is relative to current trunk, meaning 6.0.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> That patch is relative to current trunk, meaning 6.0.

I think it should not matter: the patch should apply on 5.0.1 or 6.0.

Applied on a patched 6.0 tree it works as advertised.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #17 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I applied the patch, and did a make in the built folder. I still get the ICE.
Or do I have to change the file gcc/fortran/trans-stmt.c and do a completely
new built of the gcc/gfortran compiler suite?
>From gcc-bugs-return-483910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 17 16:24:03 2015
Return-Path: <gcc-bugs-return-483910-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 101161 invoked by alias); 17 Apr 2015 16:24:03 -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 100845 invoked by uid 55); 17 Apr 2015 16:23:59 -0000
From: "hjl at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65780] [5/6 Regression] Uninitialized common handling in executables
Date: Fri, 17 Apr 2015 16:24: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: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: hjl at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P1
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65780-4-DDhpNWU4ow@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65780-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65780-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: 2015-04/txt/msg01462.txt.bz2
Content-length: 2380

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide780

--- Comment #37 from hjl at gcc dot gnu.org <hjl at gcc dot gnu.org> ---
Author: hjl
Date: Fri Apr 17 16:23:24 2015
New Revision: 222184

URL: https://gcc.gnu.org/viewcvs?rev"2184&root=gcc&view=rev
Log:
Properly handle uninitialized common symbol

Uninitialized common symbol behavior in executables is target and linker
dependent.  default_binds_local_p_3 is made public and updated to take an
argument to indicate if the linker can guarantee that an uninitialized
common symbol in the executable will still be defined (through COPY
relocation) in the executable.  If common symbol is local to executable,
default_binds_local_p_3 will treat non-external variable as defined
locally.  default_binds_local_p_2 is changed to treat common symbol as
local for non-PIE binaries.

For i386, common symbol is local only for non-PIE binaries.  For x86-64,
common symbol is local only for non-PIE binaries or linker supports copy
reloc in PIE binaries.  If a target treats common symbol as local only
for non-PIE binaries, it can define TARGET_BINDS_LOCAL_P as
default_binds_local_p_2.

gcc/

    PR target/65780
    * output.h (default_binds_local_p_3): New.
    * varasm.c (default_binds_local_p_3): Make it public.  Take an
    argument to indicate if common symbol may be local.  If common
    symbol may be local, treat non-external variable as defined
    locally.
    (default_binds_local_p_2): Pass !flag_pic to default_binds_local_p_3.
    (default_binds_local_p_1): Pass false to default_binds_local_p_3.
    * config/i386/i386.c (ix86_binds_local_p): New.
    (TARGET_BINDS_LOCAL_P): Replace default_binds_local_p_2 with
    ix86_binds_local_p.

gcc/testsuite/

    PR target/65780
    * gcc.dg/pr65780-1.c: New test.
    * gcc.dg/pr65780-2.c: Likewise.
    * gcc.target/i386/pr32219-9.c: Likewise.
    * gcc.target/i386/pr32219-1.c (xxx): Make it initialized common
    symbol.
    * gcc.target/i386/pr64317.c (c): Initialize.

Added:
    trunk/gcc/testsuite/gcc.dg/pr65780-1.c
    trunk/gcc/testsuite/gcc.dg/pr65780-2.c
    trunk/gcc/testsuite/gcc.target/i386/pr32219-9.c
Modified:
    trunk/gcc/ChangeLog
    trunk/gcc/config/i386/i386.c
    trunk/gcc/output.h
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gcc.target/i386/pr32219-1.c
    trunk/gcc/testsuite/gcc.target/i386/pr64317.c
    trunk/gcc/varasm.c

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #18 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I applied the patch, and did a make in the built folder. I still get the ICE.

Did you do "make install"?

> Or do I have to change the file gcc/fortran/trans-stmt.c and do a completely
> new built of the gcc/gfortran compiler suite?

It is always safer to do a clean bootstrap, but it should not be necessary.
When patching gfortran I usually doe "touch gcc/fortran/*" which forces to
rebuild fortran at all stages and rebuild libgfortran.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[jakub at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

Jakub Jelinek <jakub at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|5.0                         |5.2

--- Comment #19 from Jakub Jelinek <jakub at gcc dot gnu.org> ---
GCC 5.1 has been released.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |WAITING

--- Comment #20 from vehre at gcc dot gnu.org ---
Juergen, could you meanwhile check, that the patch fixes the issue?

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #21 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to vehre from comment #20)
> Juergen, could you meanwhile check, that the patch fixes the issue?

Damn, it seems my text didn't get posted. Being in Japan at the moment, and
sometimes not having the best connection. NO, it doesn't fix the issue. The one
I posted yes, but there are two other cases where it fails.
>From gcc-bugs-return-484453-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 23 12:58:06 2015
Return-Path: <gcc-bugs-return-484453-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 126975 invoked by alias); 23 Apr 2015 12:58:05 -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 126009 invoked by uid 48); 23 Apr 2015 12:58:01 -0000
From: "vehre at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/58754] [4.8/4.9/5/6 Regression] ICE on allocating character array with source
Date: Thu, 23 Apr 2015 12:58: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.9.0
X-Bugzilla-Keywords: ice-on-valid-code
X-Bugzilla-Severity: normal
X-Bugzilla-Who: vehre at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: pault at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 4.8.5
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status resolution
Message-ID: <bug-58754-4-7x5XSbWoWb@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-58754-4@http.gcc.gnu.org/bugzilla/>
References: <bug-58754-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: 2015-04/txt/msg02005.txt.bz2
Content-length: 506

https://gcc.gnu.org/bugzilla/show_bug.cgi?idX754
Bug 58754 depends on bug 57456, which changed state.

Bug 57456 Summary: [OOP] CLASS + CHARACTER ALLOCATE with typespec: For arrays, the typespec is ignored
https://gcc.gnu.org/bugzilla/show_bug.cgi?idW456

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

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

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

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #22 from Jürgen Reuter <juergen.reuter at desy dot de> ---
One thing is: 
allocate (foo (0:this%dim-1), source=this%get_integral())
where this is some derived type with integer component dim
and TBP get_integral which is a function 
generic :: get_integral => get_integral_array, get_integral_1
procedure :: get_integral_array
procedure :: get_integral_1

subroutine get_integral_array (this, integral)
  class(t) :: this
  real, intent(out), dimension(:) :: integral
  integral = this%integral
end subroutine get_integral_array
subroutine get_integral_1 (this, integral)
  class(t) :: this
  real, intent(out) :: integral
  integral = this%integral(1)
end subroutine get_integral_1
>From gcc-bugs-return-484455-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 23 13:07:32 2015
Return-Path: <gcc-bugs-return-484455-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15745 invoked by alias); 23 Apr 2015 13:07:31 -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 15683 invoked by uid 48); 23 Apr 2015 13:07:28 -0000
From: "juergen.reuter at desy dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
Date: Thu, 23 Apr 2015 13:07: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: juergen.reuter at desy dot de
X-Bugzilla-Status: WAITING
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: vehre at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65548-4-bBmYZi51zQ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65548-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65548-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: 2015-04/txt/msg02007.txt.bz2
Content-length: 299

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #23 from Jürgen Reuter <juergen.reuter at desy dot de> ---
The other failure occurs for
allocate (foo (this%n), source=this%bar)
where n is integer, foo has type 
character(32), dimension(:), allocatable 
and bar as well.
>From gcc-bugs-return-484456-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 23 13:11:14 2015
Return-Path: <gcc-bugs-return-484456-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 27548 invoked by alias); 23 Apr 2015 13:11:14 -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 27187 invoked by uid 48); 23 Apr 2015 13:11:10 -0000
From: "prathamesh3492 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug ipa/65858] New: ICE in varpool_node::get_constructor during chromium build on arm-linux-gnueabihf with LTO during LINK chrome
Date: Thu, 23 Apr 2015 13:11:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: ipa
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: prathamesh3492 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter attachments.created
Message-ID: <bug-65858-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: 2015-04/txt/msg02008.txt.bz2
Content-length: 1773

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide858

            Bug ID: 65858
           Summary: ICE in varpool_node::get_constructor during chromium
                    build on arm-linux-gnueabihf with LTO during LINK
                    chrome
           Product: gcc
           Version: 6.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: ipa
          Assignee: unassigned at gcc dot gnu.org
          Reporter: prathamesh3492 at gcc dot gnu.org

Created attachment 35390
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id5390&actioníit
disable LTO in Webkit/Source/core/core.gyp and Webkit/Source/web/web.gyp

Hi,
This seems related to PR65776. During building chromium on arm-linux-gnueabihf,
I disabled LTO for lib/libblink_web.so (PR65776),
but got ICE in varpool_node::get_cosntructor() during LINK chrome
Full command line used for linking: http://pastebin.com/fuq4y7QY
[19024/19024] LINK chrome

lto1: internal compiler error: in get_constructor, at varpool.c:331
0xc6abf3 varpool_node::get_constructor()

/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/varpool.c:331
0xc6bb33 varpool_node::assemble_decl()

/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/varpool.c:602
0xc6c675 symbol_table::output_variables()

/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/varpool.c:758
0x5d8953 symbol_table::compile()

/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/cgraphunit.c:2385
0x549e99 lto_main()

/home/prathamesh.kulkarni/gnu-toolchain/src/gcc.git~gcc-chromium/gcc/lto/lto.c:3496

I have attached patch for disabling LTO for Webkit (to prevent ICE in linking
libblink_web.so).

Thank you,
Prathamesh

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #24 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Could you please post complete tests: i.e. triggering only the relevant error?

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #25 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Example 1:
module foo
  type :: t
     integer :: n
     real, dimension(:,:), allocatable :: val
   contains
     procedure :: make => t_make
     generic :: get_int => get_int_array, get_int_element
     procedure :: get_int_array => t_get_int_array
     procedure :: get_int_element => t_get_int_element
  end type t

contains

  subroutine t_make (this)
    class(t), intent(inout) :: this
    real, dimension(:), allocatable :: int
    allocate (int (0:this%n-1), source=this%get_int())
  end subroutine t_make

  pure function t_get_int_array (this) result (array)
    class(t), intent(in) :: this
    real, dimension(this%n) :: array
    array = this%val (0:this%n-1, 4)
  end function t_get_int_array

  pure function t_get_int_element (this, set) result (element)
    class(t), intent(in) :: this
    integer, intent(in) :: set
    real :: element
    element = this%val (set, 4)
  end function t_get_int_element


end module foo
>From gcc-bugs-return-484473-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 23 14:05:28 2015
Return-Path: <gcc-bugs-return-484473-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 68186 invoked by alias); 23 Apr 2015 14:05: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 68123 invoked by uid 48); 23 Apr 2015 14:05:24 -0000
From: "dominiq at lps dot ens.fr" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call
Date: Thu, 23 Apr 2015 14:05: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: dominiq at lps dot ens.fr
X-Bugzilla-Status: NEW
X-Bugzilla-Priority: P4
X-Bugzilla-Assigned-To: vehre at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 5.2
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: bug_status
Message-ID: <bug-65548-4-GOdTiQW2nN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65548-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65548-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: 2015-04/txt/msg02025.txt.bz2
Content-length: 639

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide548

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|WAITING                     |NEW

--- Comment #26 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Compiling the test in comment 25 gives the following ICE

pr65548_2.f90:17:0:

     allocate (int (0:this%n-1), source=this%get_int())
 1
internal compiler error: in gfc_conv_procedure_call, at
fortran/trans-expr.c:5755

even with the patch in comment in comment 13.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #27 from Jürgen Reuter <juergen.reuter at desy dot de> ---
And Example #2 is:

module foo
  type :: t
     integer :: n
     character(32), dimension(:), allocatable :: md5
   contains
     procedure :: init => t_init
  end type t

contains

  subroutine t_init (this)
    class(t), intent(inout) :: this
    character(32), dimension(:), allocatable :: md5
    allocate (md5 (this%n), source=this%md5)
  end subroutine t_init


end module foo

$ gfortran -c bar.f90
bar.f90:14:0:

     allocate (md5 (this%n), source=this%md5)
 1
internal compiler error: Segmentation fault: 11

dreck.f90:14:0: internal compiler error: Abort trap: 6
gfortran: internal compiler error: Abort trap: 6 (program f951)
>From gcc-bugs-return-484484-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Thu Apr 23 15:09:34 2015
Return-Path: <gcc-bugs-return-484484-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 90595 invoked by alias); 23 Apr 2015 15:09:33 -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 90214 invoked by uid 48); 23 Apr 2015 15:09:29 -0000
From: "redi at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug preprocessor/65860] Stringification of User Defined Literals
Date: Thu, 23 Apr 2015 15:09:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: preprocessor
X-Bugzilla-Version: 4.9.2
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: redi at gcc dot gnu.org
X-Bugzilla-Status: NEW
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_status cf_reconfirmed_on cc everconfirmed
Message-ID: <bug-65860-4-d1E2dJuE9r@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65860-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65860-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: 2015-04/txt/msg02036.txt.bz2
Content-length: 474

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide860

Jonathan Wakely <redi at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2015-04-23
                 CC|                            |emsr at gcc dot gnu.org
     Ever confirmed|0                           |1

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[dominiq at lps dot ens.fr]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #28 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> And Example #2 is: ...

Confirmed too, but no ICE under debugger.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
  Attachment #35318|0                           |1
        is obsolete|                            |

--- Comment #29 from vehre at gcc dot gnu.org ---
Created attachment 35419
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=35419&action=edit
Candidate patch for latest regressions.

Juergen, please test.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #30 from Jürgen Reuter <juergen.reuter at desy dot de> ---
I can apply this patch on r222550 of 
https://gcc.gnu.org/svn/gcc/branches/gcc-5-branch/
correct?
>From gcc-bugs-return-484915-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 29 00:28:24 2015
Return-Path: <gcc-bugs-return-484915-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 33282 invoked by alias); 29 Apr 2015 00:28:24 -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 33198 invoked by uid 48); 29 Apr 2015 00:28:19 -0000
From: "prathamesh3492 at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
Date: Wed, 29 Apr 2015 00:28: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: prathamesh3492 at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: prathamesh3492 at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65837-4-gJeRAtbWEN@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65837-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65837-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: 2015-04/txt/msg02467.txt.bz2
Content-length: 2737

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide837

--- Comment #19 from prathamesh3492 at gcc dot gnu.org ---
(In reply to prathamesh3492 from comment #18)
> Created attachment 35420 [details]
> patch to override default options by options in object file
>
> Hi,
>
> The following untested patch gives preference to option value in object file.
> In run_gcc(),
> options from COLLECT_GCC_OPTIONS which are taken from command line are
> stored in decoded_options.
> options from object file are stored in fdecoded_options.
> so override the option in decoded_options if it is present in
> fdecoded_options.
>
> With the patch this works:
> arm-linux-gnueabihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -flto
> only passes -mfpu=neon to lto1
>
> However the patch doesn't work when same option is passed different values
> at compile and link-time:
> arm-linux-gnuebihf-gcc test.c -mfpu=neon -flto -c
> arm-linux-gnueabihf-gcc test.o -mfpu=vfpv3-d16 -flto
>
> In this case, -mfpu=neon is still passed to lto1, since the patch prefers
> option value from object file.
> Without the patch, the option from the command line was given preference.
>
> for both the following cases:
> arm-linux-gnueabihf-gcc test.o -flto
> arm-linux-gnueabihf-gcc test.o -flto -mfpu=vfpv3-d16
>
> COLLECT_GCC_OPTIONS contains "-mfpu=vfpv3-d16", however in the first case it
> isn't explictly passed by user, so passing -mfpu=neon
> would be correct. In the second case, since -mfpu=vfpv3-d16 is passed
> intentionally by user, should it be considered
> as an error - "conflicting options" ?
>
> Unfortunately, it looks like there is no way to distinguish between options
> defined by default and explicitly passed options from COLLECT_GCC_OPTIONS
> and that's the only way command line options are passed to lto-wrapper from
> the driver. One way would be to modify COLLECT_GCC_OPTIONS in the driver to
> indicate which options were explicitly passed from command line.
> For instance, additionally COLLECT_GCC_OPTIONS would contain
> "-mfpu=vfpv3-d16-explicit" to indiciate that -mfpu=vfpv3-d16 was
> passed from command line and not set by default. In lto-wrapper the options
> could be parsed to check if they have "explicit" suffix and thus distinguish
> between explicit and defualt defined options.
> Does that sound reasonable ? I would be grateful for suggestions.

Instead of modifying COLLECT_GCC_OPTIONS, maybe create another environment
variable say COLLECT_GCC_OPTIONS_EXPLICIT and if an option is passed on
command line, put it in COLLECT_GCC_OPTIONS_EXPLICIT, so lto-wrapper
can distinguish between default defined options and options passed on
command line.

Thank you,
Prathamesh
>
> Thank you,
> Prathamesh

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |ASSIGNED

--- Comment #31 from vehre at gcc dot gnu.org ---
That should not matter. I have prepared the patch on trunk (aka 6.0), but it
should also apply on the 5.x-branch (with automatic offsets).

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #32 from Jürgen Reuter <juergen.reuter at desy dot de> ---
With gcc-6.0 trunk I cannot test our complete code because of 
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65894
For gcc 5 trunk I have massive problems in checking out the svn at the moment,
always getting timeouts.
>From gcc-bugs-return-484939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 29 08:09:10 2015
Return-Path: <gcc-bugs-return-484939-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 117379 invoked by alias); 29 Apr 2015 08:09:10 -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 113695 invoked by uid 55); 29 Apr 2015 08:09:06 -0000
From: "rguenther at suse dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug target/65837] [arm-linux-gnueabihf] lto1 target specific builtin not available
Date: Wed, 29 Apr 2015 08:09: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: 6.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: rguenther at suse dot de
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: prathamesh3492 at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65837-4-QncrQAeFjO@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65837-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65837-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: 2015-04/txt/msg02491.txt.bz2
Content-length: 3814

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide837

--- Comment #24 from rguenther at suse dot de <rguenther at suse dot de> ---
On Wed, 29 Apr 2015, ramana at gcc dot gnu.org wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?ide837
>
> --- Comment #23 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
> (In reply to rguenther@suse.de from comment #20)
> > On Tue, 28 Apr 2015, prathamesh3492 at gcc dot gnu.org wrote:
> >
> > > https://gcc.gnu.org/bugzilla/show_bug.cgi?ide837
> > >
> > > --- Comment #17 from prathamesh3492 at gcc dot gnu.org ---
> > > (In reply to clyon from comment #16)
> > > > (In reply to prathamesh3492 from comment #15)
> > > >
> > > > > I am not understanding why vfpv3-d16 appears in collect_gcc_options in
> > > > > run_gcc().
> > > > Isn't this because you configured GCC --with-fpu=vfpv3-d16?
> > >
> > > COLLECT_GCC_OPTIONS is set by gcc.c:set_collect_gcc_options():
> > > /* Build COLLECT_GCC_OPTIONS to have all of the options specified to
> > >      the compiler.  */
> > >   obstack_grow (&collect_obstack, "COLLECT_GCC_OPTIONS=",
> > >                 sizeof ("COLLECT_GCC_OPTIONS=") - 1);
> > >
> > > and at the end of set_collect_gcc_options():
> > > xputenv (XOBFINISH (&collect_obstack, char *));
> > > which makes it environment variable.
> > >
> > > set_collect_gcc_options() is called by do_spec, which is called by
> > > driver::maybe_run_linker(), before executing linker.
> > > So the driver has no knowledge of options passed at compile-time,
> > > it sets the default -mfpu=vfpv3-d16.
> > >
> > > When lto-wrapper executes,
> > > it gets linker command line options from environment variable
> > > COLLECT_GCC_OPTIONS,
> > > which contains -mfpu=vfpv3-d16.
> > > and since that was being appended after compile-time options
> > > (fdecoded_options), -mfpu=vfpv3-d16 overrides -mfpu=neon.
> > >
> > > This also explains why it works in one shot
> > > arm-linux-gnueabihf -flto -mfpu=neon test.c
> > >
> > > COLLECT_GCC_OPTIONS will have "-mfpu=neon" since it's mentioned on command
> > > line, and lto-wrapper has access to this COLLECT_GCC_OPTIONS.
> > >
> > > When compiler and linker are run separately, at link time, the driver has no
> > > knowledege of flags of compile-time run,
> > > and hence sets default flags in COLLECT_GCC_OPTIONS.
> > >
> > > I think correct way to fix would be in run_gcc() to get values from
> > > COLLECT_GCC_OPTIONS in decoded_options as is currently done.
> > > run_gcc() walks through options in object file and saves it in
> > > fdecoded_options. So override the value in
> > > decoded_options for the same option found in fdecoded_options.
> > > Would that be a right approach ?
> >
> > No, link-time options always override compile-time ones.
> >
> > I suspect the fix will be to somehow avoid setting defaults when linking?
>
> Well I'm not sure how easy that's going to be - You will need some amount of
> defaults to get through especially if the user hasn't provided the options in
> the first place :( .

The other option is to special-case only those options that are slipping
in that way (-march, -mtune, -mcpu, -mfpu?) and emit those always first,
hoping that explicit ones will override that.  Of course lto-wrapper
cannot distinguish between implicitely and explicitely such given
arguments at link-time.  Which means the only solution would be to
completely ignore these at link-time.

But I suspect this might break otherwise working cases (due to the fact
that which -march/-mtune/-mcpu/-mfpu options lto-wrapper chooses from
the object files is essentially "random" if they don't agree for all
objects).

It's really unfortunate that these configure-time defaults appear
as regular user command-line arguments :(  I suppose this was done
to make them visible to specs processing.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #33 from vehre at gcc dot gnu.org ---
I can only work on the issue, not do magic.

When you have issues with svn checkout try the gitmirror:
https://gcc.gnu.org/wiki/GitMirror

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #34 from Jürgen Reuter <juergen.reuter at desy dot de> ---
Andre, I checked your patch with r222305 of the gcc 6.0 trunk. Our complete
code (without workarounds for the two remaining cases reported) compiles, and
our complete testsuite works. Thanks for the patch.
>From gcc-bugs-return-484980-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Apr 29 13:22:48 2015
Return-Path: <gcc-bugs-return-484980-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 117586 invoked by alias); 29 Apr 2015 13:22:47 -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 117554 invoked by uid 48); 29 Apr 2015 13:22:42 -0000
From: "david.claessens at tomra dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/65928] std::find_if compilation errors
Date: Wed, 29 Apr 2015 13:22: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: 5.1.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: david.claessens at tomra dot com
X-Bugzilla-Status: RESOLVED
X-Bugzilla-Resolution: INVALID
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-65928-4-gzj9JTXaQD@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65928-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65928-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: 2015-04/txt/msg02532.txt.bz2
Content-length: 236

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide928

--- Comment #6 from david.claessens at tomra dot com ---
Apparently it is not (only) included from string.
Changing to a char array and removing that include doesn't change anything.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

vehre at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |WAITING

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #35 from Jürgen Reuter <juergen.reuter at desy dot de> ---
What are u waiting for?^^ already confirmed in comment #34 that rverything in
our code works with the patch
>From gcc-bugs-return-485487-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 05 09:40:06 2015
Return-Path: <gcc-bugs-return-485487-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 15020 invoked by alias); 5 May 2015 09:40:06 -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 14914 invoked by uid 55); 5 May 2015 09:40:02 -0000
From: "tschwinge at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libgomp/65993] [6 Regression] Numerous libgomp.oacc failures seen in r222712
Date: Tue, 05 May 2015 09:40:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: changed
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libgomp
X-Bugzilla-Version: 6.0
X-Bugzilla-Keywords: openacc
X-Bugzilla-Severity: normal
X-Bugzilla-Who: tschwinge at gcc dot gnu.org
X-Bugzilla-Status: ASSIGNED
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: tschwinge at gcc dot gnu.org
X-Bugzilla-Target-Milestone: 6.0
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-65993-4-1k510RdTjR@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-65993-4@http.gcc.gnu.org/bugzilla/>
References: <bug-65993-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: 2015-05/txt/msg00327.txt.bz2
Content-length: 5306

https://gcc.gnu.org/bugzilla/show_bug.cgi?ide993

--- Comment #4 from Thomas Schwinge <tschwinge at gcc dot gnu.org> ---
Author: tschwinge
Date: Tue May  5 09:39:29 2015
New Revision: 222799

URL: https://gcc.gnu.org/viewcvs?rev"2799&root=gcc&view=rev
Log:
[PR testsuite/65205, libgomp/65993] Fix dg-shouldfail usage in OpenACC libgomp
tests

In dg-output, don't expect "0x" prefix for "%p" format specifier, don't expect
"(nil)" for NULL pointer.

        PR testsuite/65205
        PR libgomp/65993
        libgomp/
        * testsuite/libgomp.oacc-c-c++-common/clauses-2.c: In dg-output,
        don't expect "0x" prefix for "%p" format specifier, don't expect
        "(nil)" for NULL pointer.
        * testsuite/libgomp.oacc-c-c++-common/lib-16.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-17.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-18.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-20.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-21.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-22.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-23.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-25.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-26.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-27.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-28.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-29.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-30.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-34.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-35.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-36.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-39.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-40.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-42.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-43.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-44.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-47.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-48.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-52.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-53.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-54.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-57.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/lib-58.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/data-already-1.c: More
        accurately specify what we're looking for.
        * testsuite/libgomp.oacc-c-c++-common/data-already-2.c: Likewise.
        * testsuite/libgomp.oacc-c-c++-common/data-already-8.c: Likewise.
        * testsuite/libgomp.oacc-fortran/data-already-1.f: Likewise.
        * testsuite/libgomp.oacc-fortran/data-already-2.f: Likewise.
        * testsuite/libgomp.oacc-fortran/data-already-8.f: Likewise.

Modified:
    trunk/libgomp/ChangeLog
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/clauses-2.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-1.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-2.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/data-already-8.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-16.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-17.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-18.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-20.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-21.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-22.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-23.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-25.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-26.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-27.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-28.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-29.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-30.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-34.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-35.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-36.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-39.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-40.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-42.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-43.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-44.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-47.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-48.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-52.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-53.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-54.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-57.c
    trunk/libgomp/testsuite/libgomp.oacc-c-c++-common/lib-58.c
    trunk/libgomp/testsuite/libgomp.oacc-fortran/data-already-1.f
    trunk/libgomp/testsuite/libgomp.oacc-fortran/data-already-2.f
    trunk/libgomp/testsuite/libgomp.oacc-fortran/data-already-8.f

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #36 from vehre at gcc dot gnu.org ---
I am waiting for an official review of the patch, to be allowed to commit to
trunk. So I am not waiting on you. :-)

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[juergen.reuter at desy dot de]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #37 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to vehre from comment #36)
> I am waiting for an official review of the patch, to be allowed to commit to
> trunk. So I am not waiting on you. :-)

I see. Got it. :D
>From gcc-bugs-return-485515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 05 13:04:49 2015
Return-Path: <gcc-bugs-return-485515-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 64091 invoked by alias); 5 May 2015 13:04:49 -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 64030 invoked by uid 48); 5 May 2015 13:04:45 -0000
From: "manu at gcc dot gnu.org" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c/16351] NULL dereference warnings
Date: Tue, 05 May 2015 13:04: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.0.0
X-Bugzilla-Keywords: diagnostic
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: manu at gcc dot gnu.org
X-Bugzilla-Status: NEW
X-Bugzilla-Resolution:
X-Bugzilla-Priority: P2
X-Bugzilla-Assigned-To: law at redhat dot com
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields:
Message-ID: <bug-16351-4-TJHHuyuT5l@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-16351-4@http.gcc.gnu.org/bugzilla/>
References: <bug-16351-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: 2015-05/txt/msg00355.txt.bz2
Content-length: 1067

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=16351

--- Comment #24 from Manuel López-Ibáñez <manu at gcc dot gnu.org> ---
(In reply to Tim Ruehsen from comment #23)

> The requested warning is an absolutely must-have (enabled by default).
> Seeing this bug open since 2004 is... well ... I have no words.

GCC needs lots of more developers. Not "experts" or "hackers", but simply
people with some patience and curiosity and basic knowledge about C/C++ and
compiling and debugging code in GNU/Linux. We need people that can focus on
things like this for a couple of hours every week for months and get it done
from start to finish.

Paid developers are paid to work on other things (targets, optimizations,
extensions) and rarely have the time and focus necessary to get projects like
this finished. Volunteers are few and we already have our hands very full with
our own little projects.

I can give you many examples of old "must-have" bugs that are "easy" to fix,
but simply there is no one with enough time and motivation to get them done.
>From gcc-bugs-return-485516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Tue May 05 13:16:17 2015
Return-Path: <gcc-bugs-return-485516-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 110842 invoked by alias); 5 May 2015 13:16:17 -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 110795 invoked by uid 48); 5 May 2015 13:16:13 -0000
From: "green at moxielogic dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug libstdc++/66018] New: opendir configure test not working when GCC_NO_EXECUTABLES
Date: Tue, 05 May 2015 13:16:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: libstdc++
X-Bugzilla-Version: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: green at moxielogic dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Resolution:
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 target_milestone
Message-ID: <bug-66018-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: 2015-05/txt/msg00356.txt.bz2
Content-length: 676

https://gcc.gnu.org/bugzilla/show_bug.cgi?idf018

            Bug ID: 66018
           Summary: opendir configure test not working when
                    GCC_NO_EXECUTABLES
           Product: gcc
           Version: unknown
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: libstdc++
          Assignee: unassigned at gcc dot gnu.org
          Reporter: green at moxielogic dot com
  Target Milestone: ---

I'm building a moxie-elf toolchain, which defines GCC_NO_EXECUTABLES during
part of the build process.

The new filesystem-ts code forces an opendir configure test that fails when
GCC_NO_EXECUTABLES is defined.

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

--- Comment #38 from vehre at gcc dot gnu.org ---
Author: vehre
Date: Wed May 20 14:56:47 2015
New Revision: 223445

URL: https://gcc.gnu.org/viewcvs?rev=223445&root=gcc&view=rev
Log:
gcc/fortran/ChangeLog:

2015-05-19  Andre Vehreschild  <vehre@gmx.de>

        PR fortran/65548
        * trans-stmt.c (gfc_trans_allocate): Always retrieve the
        descriptor or a reference to a source= expression for
        arrays and non-arrays, respectively.  Use a temporary
        symbol and gfc_trans_assignment for all source=
        assignments to allocated objects besides for class and
        derived types.

gcc/testsuite/ChangeLog:

2015-05-19  Andre Vehreschild  <vehre@gmx.de>

        PR fortran/65548
        * gfortran.dg/allocate_with_source_5.f90: Extend test.


Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-stmt.c
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/allocate_with_source_5.f90

[Bug fortran/65548] [5/6 Regression] gfc_conv_procedure_call

[vehre at gcc dot gnu.org]

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=65548

vehre at gcc dot gnu.org changed:

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

--- Comment #39 from vehre at gcc dot gnu.org ---
No objections so far, seems to be fixed with r223445.