[Bug fortran/60718] New: Test case gfortran.dg/select_type_4.f90 fails on ARM

[Bug fortran/60718] New: Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

            Bug ID: 60718
           Summary: Test case gfortran.dg/select_type_4.f90 fails on ARM
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bernd.edlinger at hotmail dot de

Created attachment 32495
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32495&action=edit
reduced test case

This test case is failing with this configuration at -O2 and above:

../gcc-4.9-20140323/configure --prefix=/home/ed/gnu/arm-linux-gnueabihf
--enable-languages=all,ada,go --with-arch=armv7-a --with-tune=cortex-a9
--with-fpu=vfpv3-d16 --with-float=hard
Thread model: posix
gcc version 4.9.0 20140323 (experimental) (GCC)

The attached reduced test case compiles code like this to initialize
the list header:


  cmp      r2, #0
  streq    ip, [sp]
  ldmeqia  sp, {r0, r1}
  streq    r4, [sp, #4]
  stmeqia  r3, {r0, r1}


this seems to use two words at sp[0..7] as scratchpad,
but the streq r4,[sp,#4] is not seen as a possible alias to
ldmeqia sp, {r0,r1}

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #1 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
I think, instructions 40 and 44 are transposed between 

select_type_4a.f90.209r.asmcons:

(insn 40 38 43 6 (set (mem/f/c:SI (plus:SI (reg/f:SI 102 sfp)
                (const_int -4 [0xfffffffffffffffc])) [3 MEM[(struct
__class_poly_list_Node_type_p *)&node + 4B]+0 S4 A32])
        (reg/f:SI 140)) select_type_4a.f90:36 663 {*arm_movsi_vfp}
     (nil))
(insn 43 40 44 6 (set (reg/f:SI 139)
        (plus:SI (reg/f:SI 102 sfp)
            (const_int -8 [0xfffffffffffffff8]))) select_type_4a.f90:36 5
{*arm_addsi3}
     (nil))
(insn 44 43 45 6 (parallel [
            (set (reg:SI 0 r0)
                (mem/c:SI (reg/f:SI 139) [8 MEM[(struct
__class_poly_list_Node_type &)&node]+0 S4 A64]))
            (set (reg:SI 1 r1)
                (mem/c:SI (plus:SI (reg/f:SI 139)
                        (const_int 4 [0x4])) [8 MEM[(struct
__class_poly_list_Node_type &)&node]+4 S4 A32]))
        ]) select_type_4a.f90:36 420 {*ldm2_ia}
     (nil))

and select_type_4a.f90.212r.sched1:

(insn 44 38 40 6 (parallel [
            (set (reg:SI 0 r0)
                (mem/c:SI (reg/f:SI 139) [8 MEM[(struct
__class_poly_list_Node_type &)&node]+0 S4 A64]))
            (set (reg:SI 1 r1)
                (mem/c:SI (plus:SI (reg/f:SI 139)
                        (const_int 4 [0x4])) [8 MEM[(struct
__class_poly_list_Node_type &)&node]+4 S4 A32]))
        ]) select_type_4a.f90:36 420 {*ldm2_ia}
     (nil))
(insn 40 44 45 6 (set (mem/f/c:SI (plus:SI (reg/f:SI 102 sfp)
                (const_int -4 [0xfffffffffffffffc])) [3 MEM[(struct
__class_poly_list_Node_type_p *)&node + 4B]+0 S4 A32])
        (reg/f:SI 140)) select_type_4a.f90:36 663 {*arm_movsi_vfp}
     (nil))


but they use an alias to the same memory.

interesting, one names the memory MEM[...&node]+4
and the other names it MEM[...&node+4B]+0.

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #2 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Hmm...
adding the option -fno-strict-aliasing generates correct code at -O2 and -O3.

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #3 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
hmm....,

the memref from insn 40 is from alias set 3:       "[3 MEM[(struct"
and the memref from insn 44 is from alias set 8:   "[8 MEM[(struct"

and thus mems_in_disjoint_alias_sets_p tells us they can't possibly
be an alias....


what does that mean?

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #4 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
in this example, we have

__class_poly_list_Node_type_p is alias_set 3
which is used for the list_type::head, next fields

and

__class_poly_list_Node_type is alias set 8
which is used for the parameter new_node of append_node

but the invocation at MAIN__ supplies a __class_poly_list_Node_type_p node.

I am not sure, but I think these should be either the
same type or at least have the same alias set.

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #5 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
both types are essentially identical,
64 bits large, consist of two pointers, data, and vptr.
data points to the target structure, and vptr is the class type.

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #6 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
hmm,

gfc_build_class_symbol creates different types,
if a class has the allocatable, target or pointer attribute.

  get_unique_hashed_string (tname, ts->u.derived);
  if ((*as) && attr->allocatable)
    sprintf (name, "__class_%s_%d_%da", tname, rank, (*as)->corank);
  else if ((*as) && attr->pointer)
    sprintf (name, "__class_%s_%d_%dp", tname, rank, (*as)->corank);
  else if ((*as))
    sprintf (name, "__class_%s_%d_%d", tname, rank, (*as)->corank);
  else if (attr->pointer)
    sprintf (name, "__class_%s_p", tname);
  else if (attr->allocatable)
    sprintf (name, "__class_%s_a", tname);
  else
    sprintf (name, "__class_%s", tname);


But the class(xxx), pointer is passed to class(xxx), target when
used as a procedure parameter. this makes one type alias another.

maybe the test case is wrong, passing one flavor of object to
another?

  subroutine append_node (list, new_node)                                       

    !-- Append a node to a list.                               
    !-- Caller is responsible for allocating the node.         

    !---------- interface.                                     

    type(list_type), intent(inout) :: list                     
-   class(node_type), target :: new_node          
+   class(node_type), pointer, intent(in) :: new_node          

    !---------- executable code.

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[burnus at gcc dot gnu.org]

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

--- Comment #8 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Bernd Edlinger from comment #6)
> maybe the test case is wrong, passing one flavor of object to
> another?
> -   class(node_type), target :: new_node          
> +   class(node_type), pointer, intent(in) :: new_node          

The code as is currently is perfectly valid.

gfortran generates for fixed-size arrays, those for nonallocatable/nonpointer
tyoes and for allocatable (both with TYPE_QUAL_RESTRICT for the address) and
pointer arrays different types - see gfc_build_array_type and for fixed-size
arrays gfc_get_nodesc_array_type.

And for polymorphic types, it wraps it in another struct type, one with the
pointer to the virtual table and one containing the array.

I think one solution would be to create a temporary variable of the target type
(here: nonallocatable) - and assign to that temporary variable.

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #9 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
yes, thanks. When the test case is valid, then probably the IL is invalid.

append_node (struct list_type & restrict list, struct
__class_poly_list_Node_type & new_node)
{
  if (list->head._data == 0B)
    {
      list->head = VIEW_CONVERT_EXPR<struct
__class_poly_list_Node_type_p>(*new_node);
    }
  L.4:;
  if (list->tail._data != 0B)
    {
      list->tail._data->next = VIEW_CONVERT_EXPR<struct
__class_poly_list_Node_type_p>(*new_node);
    }
  L.5:;
  list->tail = VIEW_CONVERT_EXPR<struct
__class_poly_list_Node_type_p>(*new_node);
  return;
}

MAIN__ ()
{
  static struct list_type list = {.head={._data=0B,
._vptr=&__vtab_poly_list_Node_type}, .tail={._data=0B,
._vptr=&__vtab_poly_list_Node_type}};
  struct __class_poly_list_Node_type_p node;

  node._data = (struct node_type *) __builtin_malloc (8);
  if (node._data == 0B)
    {
      _gfortran_os_error (&"Reservierung würde Speichergrenze
überschreiten"[1]{lb: 1 sz: 1});
    }
  (struct __vtype_poly_list_Node_type *) node._vptr =
&__vtab_poly_list_Node_type;
  (void) __builtin_memcpy ((void *) node._data, (void *) node._vptr->_def_init,
(character(kind=4)) node._vptr->_size);
  append_node (&list, &node);
  destroy_list (&list);
}

maybe we need a type-cast in the call statement?

  append_node (&list, VIEW_CONVERT_EXPR<struct __class_poly_list_Node_type
*>(&node));
>From gcc-bugs-return-448336-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Fri Apr 04 21:37:55 2014
Return-Path: <gcc-bugs-return-448336-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 19635 invoked by alias); 4 Apr 2014 21:37:55 -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 19605 invoked by uid 48); 4 Apr 2014 21:37:52 -0000
From: "javiercruz_94 at hotmail dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/39730] incomplete type error can be misleading
Date: Fri, 04 Apr 2014 21:37: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.5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: enhancement
X-Bugzilla-Who: javiercruz_94 at hotmail dot com
X-Bugzilla-Status: UNCONFIRMED
X-Bugzilla-Priority: P3
X-Bugzilla-Assigned-To: unassigned at gcc dot gnu.org
X-Bugzilla-Target-Milestone: ---
X-Bugzilla-Flags:
X-Bugzilla-Changed-Fields: cc
Message-ID: <bug-39730-4-Jvu0vNgIQZ@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-39730-4@http.gcc.gnu.org/bugzilla/>
References: <bug-39730-4@http.gcc.gnu.org/bugzilla/>
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: 7bit
X-Bugzilla-URL: http://gcc.gnu.org/bugzilla/
Auto-Submitted: auto-generated
MIME-Version: 1.0
X-SW-Source: 2014-04/txt/msg00356.txt.bz2
Content-length: 507

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

Javier Cruz <javiercruz_94 at hotmail dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |javiercruz_94 at hotmail dot com

--- Comment #2 from Javier Cruz <javiercruz_94 at hotmail dot com> ---
Yo have to add the library fstream at the beginning.
Example:
#include <fstream>


That will fix the problem =)

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #10 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 32554
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32554&action=edit
possible fix

Hi,

this is probably what Tobias proposed in Comment#8.

What do you think of this patch?

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #11 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Bernd Edlinger from comment #6)
> hmm,
> 
> gfc_build_class_symbol creates different types,
> if a class has the allocatable, target or pointer attribute.
> 
>   get_unique_hashed_string (tname, ts->u.derived);
>   if ((*as) && attr->allocatable)
>     sprintf (name, "__class_%s_%d_%da", tname, rank, (*as)->corank);
>   else if ((*as) && attr->pointer)
>     sprintf (name, "__class_%s_%d_%dp", tname, rank, (*as)->corank);
>   else if ((*as))
>     sprintf (name, "__class_%s_%d_%d", tname, rank, (*as)->corank);
>   else if (attr->pointer)
>     sprintf (name, "__class_%s_p", tname);
>   else if (attr->allocatable)
>     sprintf (name, "__class_%s_a", tname);
>   else
>     sprintf (name, "__class_%s", tname);
> 
> 

One other thing, should be noted:

the above code causes name clashes, if the class name ends with "_p"
as demonstrated in the following test example:

cat unique_name.f90
! { dg-do run }
!
module test_module

  implicit none

  type, public :: test_p
    private
    class(test_p), pointer :: next => null()
  end type test_p

  type, public :: test
!  call do_it (x)
!  Error: Type mismatch in argument 'x' at (1); passed CLASS(test_p) to
CLASS(test)
    class(test), pointer :: next => null()
  end type test

contains

  subroutine do_it (x)
    class(test_p), target :: x

    x%next => x
    return
  end subroutine do_it

end module test_module

  use test_module
  class(test_p), pointer :: x
  allocate (x)
  call do_it (x)
  deallocate (x)
end

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

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

--- Comment #12 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Created attachment 32563
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=32563&action=edit
possible fix

added one missing "else": the new version of the patch passes
all x86_64 tests now.

ARM boot-strap and testing still running and will take a few days.

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #13 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
Patch posted at
http://gcc.gnu.org/ml/gcc-patches/2014-04/msg00537.html

[Bug fortran/60718] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #14 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
FYI: updated patch was posted at
https://gcc.gnu.org/ml/gcc-patches/2014-04/msg00774.html
but not yet reviewed/approved.

[Bug fortran/60718] [4.8 / 4.9 / 4.10 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[ramana at gcc dot gnu.org]

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

Ramana Radhakrishnan <ramana at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Target|                            |arm-none-linux-gnueabihf
             Status|UNCONFIRMED                 |NEW
      Known to work|                            |4.7.2
           Keywords|                            |wrong-code
   Last reconfirmed|                            |2014-06-19
                 CC|                            |ramana at gcc dot gnu.org
               Host|                            |arm-none-linux-gnueabihf
     Ever confirmed|0                           |1
            Summary|Test case                   |[4.8 / 4.9 / 4.10
                   |gfortran.dg/select_type_4.f |regression] Test case
                   |90 fails on ARM             |gfortran.dg/select_type_4.f
                   |                            |90 fails on ARM
      Known to fail|                            |4.8.0, 4.8.1, 4.8.2, 4.9.0

--- Comment #15 from Ramana Radhakrishnan <ramana at gcc dot gnu.org> ---
This looks very similar to PR57297 and might even be a dup of that. I found
atleast one test result for 4.7.2 which shows it worked there. Therefore
technically a regression.

[Bug fortran/60718] [4.8/4.9/4.10 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.8.4
            Summary|[4.8 / 4.9 / 4.10           |[4.8/4.9/4.10 regression]
                   |regression] Test case       |Test case
                   |gfortran.dg/select_type_4.f |gfortran.dg/select_type_4.f
                   |90 fails on ARM             |90 fails on ARM

[Bug fortran/60718] [4.8/4.9/4.10 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[rguenth at gcc dot gnu.org]

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

Richard Biener <rguenth at gcc dot gnu.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Priority|P3                          |P4

[Bug fortran/60718] [4.8/4.9/5 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[edlinger at gcc dot gnu.org]

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

--- Comment #16 from Bernd Edlinger <edlinger at gcc dot gnu.org> ---
Author: edlinger
Date: Wed Dec 10 15:29:19 2014
New Revision: 218584

URL: https://gcc.gnu.org/viewcvs?rev=218584&root=gcc&view=rev
Log:
2014-12-10  Bernd Edlinger  <bernd.edlinger@hotmail.de>

    PR fortran/60718
    * trans-expr.c (gfc_conv_procedure_call): Fix a strict aliasing
    violation when passing a class object to a formal parameter which has
    different pointer or allocatable attributes.

testsuite:
2014-12-10  Bernd Edlinger  <bernd.edlinger@hotmail.de>

    PR fortran/60718
    * gfortran.dg/class_alias.f90: New.

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

[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[jakub at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|4.8.4                       |4.8.5

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

[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[dominiq at lps dot ens.fr]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bernd.edlinger at hotmail dot de

--- Comment #18 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
Any project to back port r218584 to 4.9/8?

[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #19 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Dominique d'Humieres from comment #18)
> Any project to back port r218584 to 4.9/8?

4.9 should be easy, because I missed the deadline for 4.9.0 just
by a few days.  What I applied was just the original patch for 4.9.

[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[dominiq at lps dot ens.fr]

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

--- Comment #20 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> 4.9 should be easy, because I missed the deadline for 4.9.0 just
> by a few days.  What I applied was just the original patch for 4.9.

Could you please do it? I cannot test on arm-*-*. If it is too difficult for
4.8, the PR can be closed after the commit for 4.9.

[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

--- Comment #21 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
(In reply to Dominique d'Humieres from comment #20)
> > 4.9 should be easy, because I missed the deadline for 4.9.0 just
> > by a few days.  What I applied was just the original patch for 4.9.
> 
> Could you please do it? I cannot test on arm-*-*. If it is too difficult for
> 4.8, the PR can be closed after the commit for 4.9.

OK, will re-do that test for 4.9 next week.

[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[dominiq at lps dot ens.fr]

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

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

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

--- Comment #23 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> I tried to boot-strap a clean gcc 4.9.2 with this patch, but it did
> not make it.  Looks like some one spoiled the armv7l-unknown-linux-gnueabihf
> target. So it is currently pointless to fix this for 4.9.x and as far as
> I remember the situation for 4.8.x was similar.

Do I understand correctly the above that there will be no back port of r218584?
If yes, could you please close the PR?

[Bug fortran/60718] [4.8/4.9 regression] Test case gfortran.dg/select_type_4.f90 fails on ARM

[bernd.edlinger at hotmail dot de]

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

Bernd Edlinger <bernd.edlinger at hotmail dot de> changed:

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

--- Comment #24 from Bernd Edlinger <bernd.edlinger at hotmail dot de> ---
ok, closed.