public inbox for gcc-bugs@sourceware.org
help / color / mirror / Atom feed
* [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types
@ 2013-11-20 2:30 juergen.reuter at desy dot de
2013-11-20 14:40 ` [Bug fortran/59198] [4.7/4.8/4.9 Regression] " janus at gcc dot gnu.org
` (24 more replies)
0 siblings, 25 replies; 26+ messages in thread
From: juergen.reuter at desy dot de @ 2013-11-20 2:30 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
@ 2013-11-20 14:40 ` janus at gcc dot gnu.org
2013-11-20 15:55 ` janus at gcc dot gnu.org
` (23 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: janus at gcc dot gnu.org @ 2013-11-20 14:40 UTC (permalink / raw)
To: gcc-bugs
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)
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
2013-11-20 14:40 ` [Bug fortran/59198] [4.7/4.8/4.9 Regression] " janus at gcc dot gnu.org
@ 2013-11-20 15:55 ` janus at gcc dot gnu.org
2013-12-19 15:20 ` rguenth at gcc dot gnu.org
` (22 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: janus at gcc dot gnu.org @ 2013-11-20 15:55 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
2013-11-20 14:40 ` [Bug fortran/59198] [4.7/4.8/4.9 Regression] " janus at gcc dot gnu.org
2013-11-20 15:55 ` janus at gcc dot gnu.org
@ 2013-12-19 15:20 ` rguenth at gcc dot gnu.org
2013-12-19 15:33 ` rguenth at gcc dot gnu.org
` (21 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-12-19 15:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (2 preceding siblings ...)
2013-12-19 15:20 ` rguenth at gcc dot gnu.org
@ 2013-12-19 15:33 ` rguenth at gcc dot gnu.org
2014-01-19 21:31 ` mikael at gcc dot gnu.org
` (20 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2013-12-19 15:33 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (3 preceding siblings ...)
2013-12-19 15:33 ` rguenth at gcc dot gnu.org
@ 2014-01-19 21:31 ` mikael at gcc dot gnu.org
2014-02-09 17:50 ` janus at gcc dot gnu.org
` (19 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: mikael at gcc dot gnu.org @ 2014-01-19 21:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (4 preceding siblings ...)
2014-01-19 21:31 ` mikael at gcc dot gnu.org
@ 2014-02-09 17:50 ` janus at gcc dot gnu.org
2014-02-22 13:35 ` pault at gcc dot gnu.org
` (18 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: janus at gcc dot gnu.org @ 2014-02-09 17:50 UTC (permalink / raw)
To: gcc-bugs
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 ...
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (5 preceding siblings ...)
2014-02-09 17:50 ` janus at gcc dot gnu.org
@ 2014-02-22 13:35 ` pault at gcc dot gnu.org
2014-02-22 15:35 ` burnus at gcc dot gnu.org
` (17 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: pault at gcc dot gnu.org @ 2014-02-22 13:35 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (6 preceding siblings ...)
2014-02-22 13:35 ` pault at gcc dot gnu.org
@ 2014-02-22 15:35 ` burnus at gcc dot gnu.org
2014-02-22 16:02 ` paul.richard.thomas at gmail dot com
` (16 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: burnus at gcc dot gnu.org @ 2014-02-22 15:35 UTC (permalink / raw)
To: gcc-bugs
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."
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (7 preceding siblings ...)
2014-02-22 15:35 ` burnus at gcc dot gnu.org
@ 2014-02-22 16:02 ` paul.richard.thomas at gmail dot com
2014-02-24 9:20 ` paul.richard.thomas at gmail dot com
` (15 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: paul.richard.thomas at gmail dot com @ 2014-02-22 16:02 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (8 preceding siblings ...)
2014-02-22 16:02 ` paul.richard.thomas at gmail dot com
@ 2014-02-24 9:20 ` paul.richard.thomas at gmail dot com
2014-02-25 9:31 ` pault at gcc dot gnu.org
` (14 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: paul.richard.thomas at gmail dot com @ 2014-02-24 9:20 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (9 preceding siblings ...)
2014-02-24 9:20 ` paul.richard.thomas at gmail dot com
@ 2014-02-25 9:31 ` pault at gcc dot gnu.org
2014-02-25 13:44 ` paul.richard.thomas at gmail dot com
` (13 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: pault at gcc dot gnu.org @ 2014-02-25 9:31 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (10 preceding siblings ...)
2014-02-25 9:31 ` pault at gcc dot gnu.org
@ 2014-02-25 13:44 ` paul.richard.thomas at gmail dot com
2014-02-25 20:23 ` pault at gcc dot gnu.org
` (12 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: paul.richard.thomas at gmail dot com @ 2014-02-25 13:44 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (11 preceding siblings ...)
2014-02-25 13:44 ` paul.richard.thomas at gmail dot com
@ 2014-02-25 20:23 ` pault at gcc dot gnu.org
2014-06-12 13:46 ` [Bug fortran/59198] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
` (11 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: pault at gcc dot gnu.org @ 2014-02-25 20:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.7/4.8/4.9/4.10 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (12 preceding siblings ...)
2014-02-25 20:23 ` pault at gcc dot gnu.org
@ 2014-06-12 13:46 ` rguenth at gcc dot gnu.org
2014-12-19 13:40 ` [Bug fortran/59198] [4.8/4.9/5 " jakub at gcc dot gnu.org
` (10 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2014-06-12 13:46 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (13 preceding siblings ...)
2014-06-12 13:46 ` [Bug fortran/59198] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
@ 2014-12-19 13:40 ` jakub at gcc dot gnu.org
2014-12-26 15:59 ` paul.richard.thomas at gmail dot com
` (9 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: jakub at gcc dot gnu.org @ 2014-12-19 13:40 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (14 preceding siblings ...)
2014-12-19 13:40 ` [Bug fortran/59198] [4.8/4.9/5 " jakub at gcc dot gnu.org
@ 2014-12-26 15:59 ` paul.richard.thomas at gmail dot com
2014-12-26 16:25 ` dominiq at lps dot ens.fr
` (8 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: paul.richard.thomas at gmail dot com @ 2014-12-26 15:59 UTC (permalink / raw)
To: gcc-bugs
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.
>
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (15 preceding siblings ...)
2014-12-26 15:59 ` paul.richard.thomas at gmail dot com
@ 2014-12-26 16:25 ` dominiq at lps dot ens.fr
2015-02-17 9:39 ` dominiq at lps dot ens.fr
` (7 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dominiq at lps dot ens.fr @ 2014-12-26 16:25 UTC (permalink / raw)
To: gcc-bugs
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!
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (16 preceding siblings ...)
2014-12-26 16:25 ` dominiq at lps dot ens.fr
@ 2015-02-17 9:39 ` dominiq at lps dot ens.fr
2015-03-16 8:45 ` pault at gcc dot gnu.org
` (6 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: dominiq at lps dot ens.fr @ 2015-02-17 9:39 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (17 preceding siblings ...)
2015-02-17 9:39 ` dominiq at lps dot ens.fr
@ 2015-03-16 8:45 ` pault at gcc dot gnu.org
2015-03-16 11:26 ` juergen.reuter at desy dot de
` (5 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: pault at gcc dot gnu.org @ 2015-03-16 8:45 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (18 preceding siblings ...)
2015-03-16 8:45 ` pault at gcc dot gnu.org
@ 2015-03-16 11:26 ` juergen.reuter at desy dot de
2015-03-17 5:20 ` pault at gcc dot gnu.org
` (4 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: juergen.reuter at desy dot de @ 2015-03-16 11:26 UTC (permalink / raw)
To: gcc-bugs
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?
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9/5 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (19 preceding siblings ...)
2015-03-16 11:26 ` juergen.reuter at desy dot de
@ 2015-03-17 5:20 ` pault at gcc dot gnu.org
2015-03-18 20:22 ` [Bug fortran/59198] [4.8/4.9 " anlauf at gmx dot de
` (3 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: pault at gcc dot gnu.org @ 2015-03-17 5:20 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (20 preceding siblings ...)
2015-03-17 5:20 ` pault at gcc dot gnu.org
@ 2015-03-18 20:22 ` anlauf at gmx dot de
2015-03-18 21:19 ` pault at gcc dot gnu.org
` (2 subsequent siblings)
24 siblings, 0 replies; 26+ messages in thread
From: anlauf at gmx dot de @ 2015-03-18 20:22 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (21 preceding siblings ...)
2015-03-18 20:22 ` [Bug fortran/59198] [4.8/4.9 " anlauf at gmx dot de
@ 2015-03-18 21:19 ` pault at gcc dot gnu.org
2015-03-19 22:23 ` pault at gcc dot gnu.org
2015-06-23 8:47 ` [Bug fortran/59198] [4.8 " rguenth at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: pault at gcc dot gnu.org @ 2015-03-18 21:19 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8/4.9 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (22 preceding siblings ...)
2015-03-18 21:19 ` pault at gcc dot gnu.org
@ 2015-03-19 22:23 ` pault at gcc dot gnu.org
2015-06-23 8:47 ` [Bug fortran/59198] [4.8 " rguenth at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: pault at gcc dot gnu.org @ 2015-03-19 22:23 UTC (permalink / raw)
To: gcc-bugs
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
^ permalink raw reply [flat|nested] 26+ messages in thread
* [Bug fortran/59198] [4.8 Regression] ICE on cyclically dependent polymorphic types
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
` (23 preceding siblings ...)
2015-03-19 22:23 ` pault at gcc dot gnu.org
@ 2015-06-23 8:47 ` rguenth at gcc dot gnu.org
24 siblings, 0 replies; 26+ messages in thread
From: rguenth at gcc dot gnu.org @ 2015-06-23 8:47 UTC (permalink / raw)
To: gcc-bugs
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.
^ permalink raw reply [flat|nested] 26+ messages in thread
end of thread, other threads:[~2015-06-23 8:45 UTC | newest]
Thread overview: 26+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-11-20 2:30 [Bug fortran/59198] New: ICE on cyclically dependent polymorphic types juergen.reuter at desy dot de
2013-11-20 14:40 ` [Bug fortran/59198] [4.7/4.8/4.9 Regression] " janus at gcc dot gnu.org
2013-11-20 15:55 ` janus at gcc dot gnu.org
2013-12-19 15:20 ` rguenth at gcc dot gnu.org
2013-12-19 15:33 ` rguenth at gcc dot gnu.org
2014-01-19 21:31 ` mikael at gcc dot gnu.org
2014-02-09 17:50 ` janus at gcc dot gnu.org
2014-02-22 13:35 ` pault at gcc dot gnu.org
2014-02-22 15:35 ` burnus at gcc dot gnu.org
2014-02-22 16:02 ` paul.richard.thomas at gmail dot com
2014-02-24 9:20 ` paul.richard.thomas at gmail dot com
2014-02-25 9:31 ` pault at gcc dot gnu.org
2014-02-25 13:44 ` paul.richard.thomas at gmail dot com
2014-02-25 20:23 ` pault at gcc dot gnu.org
2014-06-12 13:46 ` [Bug fortran/59198] [4.7/4.8/4.9/4.10 " rguenth at gcc dot gnu.org
2014-12-19 13:40 ` [Bug fortran/59198] [4.8/4.9/5 " jakub at gcc dot gnu.org
2014-12-26 15:59 ` paul.richard.thomas at gmail dot com
2014-12-26 16:25 ` dominiq at lps dot ens.fr
2015-02-17 9:39 ` dominiq at lps dot ens.fr
2015-03-16 8:45 ` pault at gcc dot gnu.org
2015-03-16 11:26 ` juergen.reuter at desy dot de
2015-03-17 5:20 ` pault at gcc dot gnu.org
2015-03-18 20:22 ` [Bug fortran/59198] [4.8/4.9 " anlauf at gmx dot de
2015-03-18 21:19 ` pault at gcc dot gnu.org
2015-03-19 22:23 ` pault at gcc dot gnu.org
2015-06-23 8:47 ` [Bug fortran/59198] [4.8 " rguenth at gcc dot gnu.org
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).