[Bug fortran/59198] New: ICE on cyclically dependent polymorphic types

[Bug fortran/59198] New: ICE on cyclically dependent polymorphic types

[juergen.reuter at desy dot de]

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

            Bug ID: 59198
           Summary: ICE on cyclically dependent polymorphic types
           Product: gcc
           Version: 4.9.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: fortran
          Assignee: unassigned at gcc dot gnu.org
          Reporter: juergen.reuter at desy dot de

Created attachment 31254
  --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=31254&action=edit
Code triggering the ICE

Triggers ICE with gfortran 4.9.0 v204344. It compiles with gfortran 4.6.3 (but
in our setup produces seg faults in the final code), ICE is present in 4.6.4,
4.7.3, 4.8.1.
This is the code O(60) lines, also attached:
module decays
  abstract interface
     function obs_unary_int ()
     end function obs_unary_int
  end interface

  type, abstract :: any_config_t
   contains
     procedure (any_config_final), deferred :: final
  end type any_config_t

  type :: decay_term_t
     type(unstable_t), dimension(:), pointer :: unstable_product => null ()
  end type decay_term_t

  type, abstract :: decay_gen_t
     type(decay_term_t), dimension(:), allocatable :: term
     procedure(obs_unary_int),   nopass, pointer :: obs1_int  => null ()     
  end type decay_gen_t

  type, extends (decay_gen_t) :: decay_root_t
   contains
     procedure :: final => decay_root_final
  end type decay_root_t

  type, abstract :: rng_t
  end type rng_t

  type, extends (decay_gen_t) :: decay_t
     class(rng_t), allocatable :: rng
   contains
     procedure :: final => decay_final
  end type decay_t

  type, extends (any_config_t) :: unstable_config_t
   contains
     procedure :: final => unstable_config_final
  end type unstable_config_t

  type :: unstable_t
     type(unstable_config_t), pointer :: config => null ()
     type(decay_t), dimension(:), allocatable :: decay
  end type unstable_t

  interface
     subroutine any_config_final (object)
       import
       class(any_config_t), intent(inout) :: object
     end subroutine any_config_final
  end interface

contains
  subroutine decay_root_final (object)
    class(decay_root_t), intent(inout) :: object
  end subroutine decay_root_final    

  recursive subroutine decay_final (object)
    class(decay_t), intent(inout) :: object
  end subroutine decay_final

  recursive subroutine unstable_config_final (object)
    class(unstable_config_t), intent(inout) :: object
  end subroutine unstable_config_final

end module decays

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[janus at gcc dot gnu.org]

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

janus at gcc dot gnu.org changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|UNCONFIRMED                 |NEW
   Last reconfirmed|                            |2013-11-20
                 CC|                            |janus at gcc dot gnu.org
            Summary|ICE on cyclically dependent |[4.7/4.8/4.9 Regression]
                   |polymorphic types           |ICE on cyclically dependent
                   |                            |polymorphic types
     Ever confirmed|0                           |1

--- Comment #1 from janus at gcc dot gnu.org ---
I tried to reduce this as far as I could, with the following result:


module decays

  implicit none

  type :: decay_term_t
     type(unstable_t), pointer :: unstable_product
  end type

  type :: decay_gen_t
     type(decay_term_t), allocatable :: term
     procedure(), nopass, pointer :: obs1_int
  end type

  type :: rng_t
  end type

  type, extends (decay_gen_t) :: decay_t
     class(rng_t), allocatable :: rng
  end type

  type :: unstable_t
     type(decay_t) :: decay
  end type

  class(decay_t), pointer :: object

end


The ICE I get with trunk is:

c0.f90:18:0: internal compiler error: in tree_low_cst, at tree.h:3667
      class(rng_t), allocatable :: rng
 ^
0xb0735b tree_low_cst
    /home/jweil/gcc49/trunk/gcc/tree.h:3667
0xb0735b output_constructor_array_range
    /home/jweil/gcc49/trunk/gcc/varasm.c:4836
0xb0735b output_constructor
    /home/jweil/gcc49/trunk/gcc/varasm.c:5210
0xb066fa assemble_variable(tree_node*, int, int, int)
    /home/jweil/gcc49/trunk/gcc/varasm.c:2125
0xb081f5 varpool_assemble_decl(varpool_node*)
    /home/jweil/gcc49/trunk/gcc/varpool.c:454
0x6cff87 output_in_order
    /home/jweil/gcc49/trunk/gcc/cgraphunit.c:1955
0x6cff87 compile()
    /home/jweil/gcc49/trunk/gcc/cgraphunit.c:2194
0x6d01f9 finalize_compilation_unit()
    /home/jweil/gcc49/trunk/gcc/cgraphunit.c:2276
0x831204 write_global_declarations()
    /home/jweil/gcc49/trunk/gcc/langhooks.c:323


Similar things happen 4.8 and 4.7. However, I can not reproduce the ICE with
4.6.4:

$ gfortran-4.6 -v
Using built-in specs.
COLLECT_GCC=gfortran-4.6
COLLECT_LTO_WRAPPER=/usr/lib/gcc/x86_64-linux-gnu/4.6/lto-wrapper
Target: x86_64-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.6.4-3ubuntu1' --with-bugurl=file:///usr/share/doc/gcc-4.6/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.6 --enable-shared --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib --without-included-gettext
--enable-threads=posix --with-gxx-include-dir=/usr/include/c++/4.6
--libdir=/usr/lib --enable-nls --with-sysroot=/ --enable-clocale=gnu
--enable-libstdcxx-debug --enable-gnu-unique-object --enable-plugin
--enable-objc-gc --disable-werror --with-arch-32=i686 --with-tune=generic
--enable-checking=release --build=x86_64-linux-gnu --host=x86_64-linux-gnu
--target=x86_64-linux-gnu
Thread model: posix
gcc version 4.6.4 (Ubuntu/Linaro 4.6.4-3ubuntu1)

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[janus at gcc dot gnu.org]

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

--- Comment #2 from janus at gcc dot gnu.org ---
(In reply to janus from comment #1)
> However, I can not reproduce the ICE with
> 4.6.4:

Neither with the original test case in comment 0, nor with the reduced version
in comment 1!

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
   Target Milestone|---                         |4.7.4

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[rguenth at gcc dot gnu.org]

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

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

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

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[mikael at gcc dot gnu.org]

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

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

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

--- Comment #4 from Mikael Morin <mikael at gcc dot gnu.org> ---
Just a bit shorter (without unstable_t type):

module decays

  implicit none

  type :: decay_term_t
     type(decay_t), pointer :: unstable_product
  end type

  type :: decay_gen_t
     type(decay_term_t), allocatable :: term
     procedure(), nopass, pointer :: obs1_int
  end type

  type :: rng_t
  end type

  type, extends (decay_gen_t) :: decay_t
     class(rng_t), allocatable :: rng
  end type

  class(decay_t), pointer :: object

end

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[janus at gcc dot gnu.org]

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

--- Comment #5 from janus at gcc dot gnu.org ---
The ICE and backtrace one gets on all variants of the test case has changed
slightly to:


internal compiler error: in tree_to_uhwi, at tree.h:3653
      class(rng_t), allocatable :: rng
 ^
0xb24434 tree_to_uhwi
    /home/jweil/gcc49/trunk/gcc/tree.h:3653
0xb24434 output_constructor_regular_field
    /home/jweil/gcc49/trunk/gcc/varasm.c:4894
0xb24434 output_constructor
    /home/jweil/gcc49/trunk/gcc/varasm.c:5231
0xb237aa assemble_variable(tree_node*, int, int, int)
    /home/jweil/gcc49/trunk/gcc/varasm.c:2139
0xb25285 varpool_assemble_decl(varpool_node*)
    /home/jweil/gcc49/trunk/gcc/varpool.c:455
0x6d0b90 output_in_order
    /home/jweil/gcc49/trunk/gcc/cgraphunit.c:2010
0x6d0b90 compile()
    /home/jweil/gcc49/trunk/gcc/cgraphunit.c:2247
0x6d0e59 finalize_compilation_unit()
    /home/jweil/gcc49/trunk/gcc/cgraphunit.c:2329
0x8396b4 write_global_declarations()
    /home/jweil/gcc49/trunk/gcc/langhooks.c:323



Not sure if this is actually a Frotran problem or rather originates from the
middle-end ...

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

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

--- Comment #6 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to janus from comment #5)

This one is intriguing! If the ICE is avoided by:
Index: gcc/varasm.c
===================================================================
*** gcc/varasm.c    (revision 208017)
--- gcc/varasm.c    (working copy)
*************** output_constructor_regular_field (oc_loc
*** 4930,4938 ****
        /* ??? This ought to only checked if DECL_SIZE_UNIT is NULL,
       but we cannot do this until the deprecated support for
       initializing zero-length array members is removed.  */
!       if (TREE_CODE (TREE_TYPE (local->field)) == ARRAY_TYPE
        && TYPE_DOMAIN (TREE_TYPE (local->field))
        && ! TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (local->field))))
      {
        fieldsize = array_size_for_constructor (local->val);
        /* Given a non-empty initialization, this field had
--- 4930,4939 ----
        /* ??? This ought to only checked if DECL_SIZE_UNIT is NULL,
       but we cannot do this until the deprecated support for
       initializing zero-length array members is removed.  */
!       if ((TREE_CODE (TREE_TYPE (local->field)) == ARRAY_TYPE
        && TYPE_DOMAIN (TREE_TYPE (local->field))
        && ! TYPE_MAX_VALUE (TYPE_DOMAIN (TREE_TYPE (local->field))))
+       || DECL_SIZE_UNIT (local->field) == NULL_TREE)
      {
        fieldsize = array_size_for_constructor (local->val);
        /* Given a non-empty initialization, this field had


The examples compile.  However,
module decays

  implicit none

  type :: decay_term_t
     type(decay_t), pointer :: unstable_product
  end type

  type :: decay_gen_t
     type(decay_term_t), allocatable :: term
     procedure(sin), nopass, pointer :: obs1_int
  end type

  type :: rng_t
  end type

  type, extends (decay_gen_t) :: decay_t
     class(rng_t), allocatable :: rng
  end type

  class(decay_t), pointer :: object

end

  use decays
  type(decay_t), pointer :: template
  allocate (template)
  allocate (template%rng)
  template%obs1_int => sin
  allocate (object, mold = template)
  object%obs1_int => sin
  print *, object%obs1_int (3.14159/2.)
end

runs and gives the correct result.  If 'mold' is changed to 'source', the
programme segfaults, with:

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

Backtrace for this error:
#0  0x41372D in _gfortrani_backtrace at backtrace.c:258
#1  0x402DB0 in _gfortrani_backtrace_handler at compile_options.c:129
#2  0x378B2359AF
#3  0x402658 in __decays_MOD___copy_decays_Decay_t
#4  0x402CAD in MAIN__ at pr59198.f90:0
Segmentation fault (core dumped)

Making the component, 'rng' a pointer restores the expected outcome by
eliminating the call to _def_init_decays_Decay_t. The difference in the code
that this copy procedure produces is:
        if (src->rng._data != 0B)
          {
            dst->rng._data = (struct rng_t *) __builtin_malloc ((unsigned long)
src->rng._vptr->_size);
            src->rng._vptr->_copy (src->rng._data, dst->rng._data);
          }
        else
          {
            dst->rng._data = 0B;
          }

This is as far as I have gone in diagnosing the problem. By the way, though,
even without the patch to varasm.c, changing rng to a pointer fixes the
problem.

I have just noticed that my fix to varasm.c should have gone pear-shaped
because there are no arrays, anywhere to be seen. Stranger and stranger.

Paul

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[burnus at gcc dot gnu.org]

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

--- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
(In reply to Paul Thomas from comment #6)
>         if (src->rng._data != 0B)
>           {
>             dst->rng._data = (struct rng_t *) __builtin_malloc ((unsigned
> long) src->rng._vptr->_size);
>             src->rng._vptr->_copy (src->rng._data, dst->rng._data);
>           }

Could this be caused by a NULL pointer? Namely,

Malloc returns: "If size is 0, either a null pointer or a unique  pointer  that
 can  be successfully passed to free() shall be returned."

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[paul.richard.thomas at gmail dot com]

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

--- Comment #8 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Hi Tobias,

I tried giving rng_t a component to avoid that - it didn't work :-(

Cheers

Paul

On 22 February 2014 16:35, burnus at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
>
> --- Comment #7 from Tobias Burnus <burnus at gcc dot gnu.org> ---
> (In reply to Paul Thomas from comment #6)
>>         if (src->rng._data != 0B)
>>           {
>>             dst->rng._data = (struct rng_t *) __builtin_malloc ((unsigned
>> long) src->rng._vptr->_size);
>>             src->rng._vptr->_copy (src->rng._data, dst->rng._data);
>>           }
>
> Could this be caused by a NULL pointer? Namely,
>
> Malloc returns: "If size is 0, either a null pointer or a unique  pointer  that
>  can  be successfully passed to free() shall be returned."
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[paul.richard.thomas at gmail dot com]

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

--- Comment #10 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
A further small remark, when the explicit interface for obs1_int is
turned to a subroutine, everything works perfectly.  I am homing in on
this as being the source of the trouble; I suspect that the function
pointer is not receiving the DEC_SIZE information.  I will look
tonight.

On 23 February 2014 21:49, pault at gcc dot gnu.org
<gcc-bugzilla@gcc.gnu.org> wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
>
> --- Comment #9 from Paul Thomas <pault at gcc dot gnu.org> ---
> Hi Tobias,
>
> I need to walk away from this one for 24 hours.
>
> I have established this chain:
> (i) We start building decay_t;
> (ii) During which we have to build decay_gen_t (from trans-types.c:2456);
> (iii) Followed by decay_term_t;
> (iv) Which has a decay_t as its only component;
> (v) Since this is in the process of being built, what is retruned is the
> backend_decl without any of the fields.  Thus the size cannot be determined;
> (vi) For reasons that I cannot see, since this component is a pointer,
> indeterminate size this propagates back to the size of the decay_gen_t
> component in decay_t; and
> (vii) This I suppose but have not confirmed, clobbers the initialisation of the
> vtable.
>
> This latter is surmise, on the basis that changing the 'term' field to a
> pointer still causes the size problem but the ICE goes away. The programme even
> executes!
>
> I cannot see why there is a problem in estimating the size, since the relevant
> components are either allocatable or pointers - thus the size can be
> determined.
>
> Cheers
>
> Paul
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[pault at gcc dot gnu.org]

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

--- Comment #11 from Paul Thomas <pault at gcc dot gnu.org> ---
A correct version of the patch of comment#6 to varasm.c is:
Index: gcc/varasm.c
===================================================================
*** gcc/varasm.c    (revision 208048)
--- gcc/varasm.c    (working copy)
*************** output_constructor_regular_field (oc_loc
*** 4939,4944 ****
--- 4939,4946 ----
           better be last.  */
        gcc_assert (!fieldsize || !DECL_CHAIN (local->field));
      }
+       else if (DECL_SIZE_UNIT (local->field) == NULL_TREE)
+     fieldsize = int_size_in_bytes (TREE_TYPE (local->field));
        else
      fieldsize = tree_to_uhwi (DECL_SIZE_UNIT (local->field));
      }

Clearly, this is bomb-proof and so regtesting proceeds without problem for gcc
and gfortran.

It now remains to understand how structure fields can be built with type size
information but with the decl comon information missing! ie. it should be
possible to render the above unnecessary.

Cheers

Paul

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[paul.richard.thomas at gmail dot com]

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

--- Comment #12 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
Dear Tobias,

I think that I have see the light!  In a particularly uninteresting
part of our Board Meeting, I took a look at the Doxygen documentation
of the compiler.  I was trying to figure out how it is possible to get
TYPE_SIZE_UNIT and no DECL_SIZE_UNIT.....

Right at the beginning of trans-decl.c (gfc_get_symbol_decl) is:

01193   /* Make sure that the vtab for the declared type is completed.  */
01194   if (sym->ts.type == BT_CLASS)
01195     {
01196       gfc_component *c = CLASS_DATA (sym);
01197       if (!c->ts.u.derived->backend_decl)
01198         {
01199           gfc_find_derived_vtab (c->ts.u.derived);
01200           gfc_get_derived_type (sym->ts.u.derived);
01201         }
01202     }

I think that the derived type should be built first, followed by the
vtable.  With the declared type being in a cyclic type definition, one
is asking for the size information to be unavailable/incorrect when
the vtable is built.  I suspect that the ICE is occurring when the
vtable is initialized.

I suspect that we should have:

01193   /* Make sure that the vtab for the declared type is completed.  */
01194   if (sym->ts.type == BT_CLASS)
01195     {
01196       gfc_component *c = CLASS_DATA (sym);
01197       if (!c->ts.u.derived->backend_decl)
01198         {
01198bis      gfc_symbol *s;
01199           gfc_get_derived_type (sym->ts.u.derived); /* Ensure
backend_decl is complete. */
01200           s = gfc_find_derived_vtab (c->ts.u.derived); /* Maybe
set backend_decl to NULL_TREE?  */
01200bis       gfc_get_symbol_decl (s); /* Build the vtable backend_decl.  */
01201         }
01202     }

It'll probably be wrong but I can only get to it tonight.

What are you up to?

Cheers

Paul

PS Must update Doxygen documentation on wiki and the bug statistics




---------- Forwarded message ----------
From: pault at gcc dot gnu.org <gcc-bugzilla@gcc.gnu.org>
Date: 25 February 2014 10:31
Subject: [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on
cyclically dependent polymorphic types
To: pault@gcc.gnu.org


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

--- Comment #11 from Paul Thomas <pault at gcc dot gnu.org> ---
A correct version of the patch of comment#6 to varasm.c is:
Index: gcc/varasm.c
===================================================================
*** gcc/varasm.c    (revision 208048)
--- gcc/varasm.c    (working copy)
*************** output_constructor_regular_field (oc_loc
*** 4939,4944 ****
--- 4939,4946 ----
           better be last.  */
        gcc_assert (!fieldsize || !DECL_CHAIN (local->field));
      }
+       else if (DECL_SIZE_UNIT (local->field) == NULL_TREE)
+     fieldsize = int_size_in_bytes (TREE_TYPE (local->field));
        else
      fieldsize = tree_to_uhwi (DECL_SIZE_UNIT (local->field));
      }

Clearly, this is bomb-proof and so regtesting proceeds without problem for gcc
and gfortran.

It now remains to understand how structure fields can be built with type size
information but with the decl comon information missing! ie. it should be
possible to render the above unnecessary.

Cheers

Paul

--
You are receiving this mail because:
You are on the CC list for the bug.

[Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[pault at gcc dot gnu.org]

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

--- Comment #13 from Paul Thomas <pault at gcc dot gnu.org> ---
(In reply to paul.richard.thomas@gmail.com from comment #12)
Wrong! That doesn't do it at all.

Paul

[Bug fortran/59198] [4.7/4.8/4.9/4.10 Regression] ICE on cyclically dependent polymorphic types

[rguenth at gcc dot gnu.org]

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

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

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

--- Comment #14 from Richard Biener <rguenth at gcc dot gnu.org> ---
The 4.7 branch is being closed, moving target milestone to 4.8.4.

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[jakub at gcc dot gnu.org]

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

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

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

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

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[paul.richard.thomas at gmail dot com]

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

--- Comment #17 from paul.richard.thomas at gmail dot com <paul.richard.thomas at gmail dot com> ---
However, it is a patch that doesn't do the job.

Cheers

Paul
On Dec 26, 2014 2:35 PM, "dominiq at lps dot ens.fr" <
gcc-bugzilla@gcc.gnu.org> wrote:

> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59198
>
> --- Comment #16 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> For the record a patch has been submitted at
> https://gcc.gnu.org/ml/fortran/2014-03/msg00165.html.
>
> --
> You are receiving this mail because:
> You are on the CC list for the bug.
>

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[dominiq at lps dot ens.fr]

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

--- Comment #18 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
> However, it is a patch that doesn't do the job.
>
> Cheers
>
> Paul

Almost!

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[dominiq at lps dot ens.fr]

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

--- Comment #19 from Dominique d'Humieres <dominiq at lps dot ens.fr> ---
The test in comment 0 compiles with revision r172608 (2011-04-17), but r173450
(2011-05-05) gives the ICE.

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[pault at gcc dot gnu.org]

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

Paul Thomas <pault at gcc dot gnu.org> changed:

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

--- Comment #20 from Paul Thomas <pault at gcc dot gnu.org> ---
Patch posted last night: https://gcc.gnu.org/ml/fortran/2015-03/msg00069.html

A somewhat better version might emerge tonight now that I understand better
what was happening.

Thanks for your patience on this one Juergen! As you were aware, I kept coming
back to it but did not have much joy until yesterday because I was sniffing
around the wrong symptoms.

Cheers

Paul

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[juergen.reuter at desy dot de]

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

--- Comment #21 from Jürgen Reuter <juergen.reuter at desy dot de> ---
(In reply to Paul Thomas from comment #20)
> Patch posted last night: https://gcc.gnu.org/ml/fortran/2015-03/msg00069.html
> 
> A somewhat better version might emerge tonight now that I understand better
> what was happening.
> 
> Thanks for your patience on this one Juergen! As you were aware, I kept
> coming back to it but did not have much joy until yesterday because I was
> sniffing around the wrong symptoms.
> 
> Cheers
> 
> Paul

Paul, no worries, we were able to find a workaround in our code, so the issue
was not too pressing. But thanks for looking into it!
>From gcc-bugs-return-480430-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Mon Mar 16 11:27:13 2015
Return-Path: <gcc-bugs-return-480430-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 3758 invoked by alias); 16 Mar 2015 11:27:13 -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 3699 invoked by uid 48); 16 Mar 2015 11:27:09 -0000
From: "bernd.edlinger at hotmail dot de" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug sanitizer/65435] New: UBsan runtime error reports in OpenSSL aes_core.c
Date: Mon, 16 Mar 2015 11:27:00 -0000
X-Bugzilla-Reason: CC
X-Bugzilla-Type: new
X-Bugzilla-Watch-Reason: None
X-Bugzilla-Product: gcc
X-Bugzilla-Component: sanitizer
X-Bugzilla-Version: 5.0
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: bernd.edlinger at hotmail 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: bug_id short_desc product version bug_status bug_severity priority component assigned_to reporter cc
Message-ID: <bug-65435-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/msg01574.txt.bz2
Content-length: 1658

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

            Bug ID: 65435
           Summary: UBsan runtime error reports in OpenSSL aes_core.c
           Product: gcc
           Version: 5.0
            Status: UNCONFIRMED
          Severity: normal
          Priority: P3
         Component: sanitizer
          Assignee: unassigned at gcc dot gnu.org
          Reporter: bernd.edlinger at hotmail dot de
                CC: dodji at gcc dot gnu.org, dvyukov at gcc dot gnu.org,
                    jakub at gcc dot gnu.org, kcc at gcc dot gnu.org

Hi,

I am not quite sure if this is a bug in OpenSSL or in UBSan.
This gets reported by ubsan in OpenSSL 1.0.0m 5 Jun 2014:

aes_core.c:1144:30: runtime error: left shift of 136 by 24 places cannot be
represented in type 'int'
aes_core.c:1151:30: runtime error: left shift of 158 by 24 places cannot be
represented in type 'int'
aes_core.c:1137:30: runtime error: left shift of 239 by 24 places cannot be
represented in type 'int'
aes_core.c:1130:30: runtime error: left shift of 139 by 24 places cannot be
represented in type 'int'


when I look at that lines, I see the following (repeated 4 times):

        s0                 (Td4[(t0 >> 24)       ] << 24) ^
                (Td4[(t3 >> 16) & 0xff] << 16) ^
                (Td4[(t2 >>  8) & 0xff] <<  8) ^
                (Td4[(t1      ) & 0xff])       ^
                rk[0];

and
static const u8 Td4[256] = {
    0x52U, 0x09U, 0x6aU, 0xd5U, 0x30U, 0x36U, 0xa5U, 0x38U, ...

I assume u8 means unsigned char.
So are we correct to convert u8 to int before << 24,
or should it be u8 to unsigned int before << 24, what OpenSSL
apparently expects?

[Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types

[pault at gcc dot gnu.org]

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

--- Comment #22 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Tue Mar 17 05:20:08 2015
New Revision: 221474

URL: https://gcc.gnu.org/viewcvs?rev=221474&root=gcc&view=rev
Log:
2014-03-17  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/59198
    * trans-types.c (gfc_get_derived_type): If an abstract derived
    type with procedure pointer components has no other type of
    component, return the backend_decl. Otherwise build the
    components if any of the non-procedure pointer components have
    no backend_decl.

2014-03-17  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/59198
    * gfortran.dg/proc_ptr_comp_44.f90 : New test
    * gfortran.dg/proc_ptr_comp_45.f90 : New test


Added:
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_44.f90
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_45.f90
Modified:
    trunk/gcc/fortran/ChangeLog
    trunk/gcc/fortran/trans-types.c
    trunk/gcc/testsuite/ChangeLog

[Bug fortran/59198] [4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[anlauf at gmx dot de]

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

Harald Anlauf <anlauf at gmx dot de> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |anlauf at gmx dot de

--- Comment #23 from Harald Anlauf <anlauf at gmx dot de> ---
(In reply to Paul Thomas from comment #22)
> 2014-03-17  Paul Thomas  <pault@gcc.gnu.org>
> 
> 	PR fortran/59198
> 	* gfortran.dg/proc_ptr_comp_44.f90 : New test
> 	* gfortran.dg/proc_ptr_comp_45.f90 : New test
> 
> 
> Added:
>     trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_44.f90
>     trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_45.f90

Paul,

I'm seeing failures of the testcase proc_ptr_comp_45.f90 on my
i686-pc-linux-gnu box.  Manually compiling the test with -mfpmath=sse
makes the test pass.

Alternatively, replacing the conditions by:

  if (abs (template%obs1_int (arg) - cos (arg)) > 2.e-15) call abort

and

  if (abs (object%obs1_int (arg) - cos (arg)) > 2.e-15) call abort

works for me.
>From gcc-bugs-return-480736-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org Wed Mar 18 20:31:43 2015
Return-Path: <gcc-bugs-return-480736-listarch-gcc-bugs=gcc.gnu.org@gcc.gnu.org>
Delivered-To: listarch-gcc-bugs@gcc.gnu.org
Received: (qmail 8288 invoked by alias); 18 Mar 2015 20:31: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 8224 invoked by uid 48); 18 Mar 2015 20:31:39 -0000
From: "paolo.carlini at oracle dot com" <gcc-bugzilla@gcc.gnu.org>
To: gcc-bugs@gcc.gnu.org
Subject: [Bug c++/62051] [4.9/5] Undefined reference to vtable with -O2 and -fdevirtualize-speculatively
Date: Wed, 18 Mar 2015 20:31: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: unknown
X-Bugzilla-Keywords:
X-Bugzilla-Severity: normal
X-Bugzilla-Who: paolo.carlini at oracle dot com
X-Bugzilla-Status: UNCONFIRMED
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: cc
Message-ID: <bug-62051-4-Jz9DlZvb6q@http.gcc.gnu.org/bugzilla/>
In-Reply-To: <bug-62051-4@http.gcc.gnu.org/bugzilla/>
References: <bug-62051-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/msg01880.txt.bz2
Content-length: 564

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

Paolo Carlini <paolo.carlini at oracle dot com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |hubicka at gcc dot gnu.org,
                   |                            |jason at gcc dot gnu.org

--- Comment #1 from Paolo Carlini <paolo.carlini at oracle dot com> ---
Honza, can you double check this? Could be a regression. I can reproduce the
error, in any case.

[Bug fortran/59198] [4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[pault at gcc dot gnu.org]

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

--- Comment #24 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Wed Mar 18 21:18:38 2015
New Revision: 221501

URL: https://gcc.gnu.org/viewcvs?rev=221501&root=gcc&view=rev
Log:
2014-03-18  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/59198
    * gfortran.dg/proc_ptr_comp_45.f90 : Make tests fuzzy.


Modified:
    trunk/gcc/testsuite/ChangeLog
    trunk/gcc/testsuite/gfortran.dg/proc_ptr_comp_45.f90

[Bug fortran/59198] [4.8/4.9 Regression] ICE on cyclically dependent polymorphic types

[pault at gcc dot gnu.org]

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

--- Comment #25 from Paul Thomas <pault at gcc dot gnu.org> ---
Author: pault
Date: Thu Mar 19 20:12:29 2015
New Revision: 221523

URL: https://gcc.gnu.org/viewcvs?rev=221523&root=gcc&view=rev
Log:
2014-03-19  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/59198
    * trans-types.c (gfc_get_derived_type): If an abstract derived
    type with procedure pointer components has no other type of
    component, return the backend_decl. Otherwise build the
    components if any of the non-procedure pointer components have
    no backend_decl.

2014-03-19  Paul Thomas  <pault@gcc.gnu.org>

    PR fortran/59198
    * gfortran.dg/proc_ptr_comp_44.f90 : New test
    * gfortran.dg/proc_ptr_comp_45.f90 : New test


Added:
    branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_44.f90
    branches/gcc-4_9-branch/gcc/testsuite/gfortran.dg/proc_ptr_comp_45.f90
Modified:
    branches/gcc-4_9-branch/gcc/fortran/ChangeLog
    branches/gcc-4_9-branch/gcc/fortran/trans-types.c
    branches/gcc-4_9-branch/gcc/testsuite/ChangeLog

[Bug fortran/59198] [4.8 Regression] ICE on cyclically dependent polymorphic types

[rguenth at gcc dot gnu.org]

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
      Known to work|                            |4.9.3
         Resolution|---                         |FIXED
   Target Milestone|4.8.5                       |4.9.3
      Known to fail|                            |4.8.5

--- Comment #26 from Richard Biener <rguenth at gcc dot gnu.org> ---
Fixed for 4.9.3.