[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele changed: What|Removed |Added Status|REOPENED|RESOLVED Resolution|--- |FIXED --- Comment #103 from Joost VandeVondele --- (In reply to rguent...@suse.de from comment #102) > On February 8, 2014 1:47:14 PM GMT+01:00, "pault at gcc dot gnu.org" > >> Fixed on trunk. > I don't intend to backport this. Thus fixed for 4.9 & won't fix for earlier branches. Thanks!
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #102 from rguenther at suse dot de --- On February 8, 2014 1:47:14 PM GMT+01:00, "pault at gcc dot gnu.org" wrote: >http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > >Paul Thomas changed: > > What|Removed |Added > > CC||pault at gcc dot gnu.org > >--- Comment #101 from Paul Thomas --- >(In reply to Richard Biener from comment #100) >> Fixed on trunk. > >Hi Richard, > >Do you intend to backport this to 4.8 or, come to that, is it even >backportable? If 'no' to either, I'll close it out (I am engaged in >regression >bashing this afternoon). I don't intend to backport this. Richard. >Cheers > >Paul > >PS Thanks to everybody for their intestinal fortitude and persistence >in fixing >this PR!
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Paul Thomas changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #101 from Paul Thomas --- (In reply to Richard Biener from comment #100) > Fixed on trunk. Hi Richard, Do you intend to backport this to 4.8 or, come to that, is it even backportable? If 'no' to either, I'll close it out (I am engaged in regression bashing this afternoon). Cheers Paul PS Thanks to everybody for their intestinal fortitude and persistence in fixing this PR!
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Richard Biener changed: What|Removed |Added Summary|[4.8/4.9 Regression] ICE|[4.8 Regression] ICE |non-trivial conversion at |non-trivial conversion at |assignment |assignment --- Comment #100 from Richard Biener --- Fixed on trunk.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 rsand...@gcc.gnu.org changed: What|Removed |Added CC||rsandifo at gcc dot gnu.org --- Comment #91 from rsandifo at gcc dot gnu.org 2013-01-15 19:54:00 UTC --- FWIW, fails for -mabi=32 on mips*-linux-gnu too (but not -mabi=n32 or -mabi=64).
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #90 from Joost VandeVondele 2012-12-13 15:13:26 UTC --- (In reply to comment #89) > Just to repeat, the ICEs are with checking enabled only (but possibly cover up > for wong-code). I'm indeed worried that the release branches will as a result silently miscompile Fortran code in LTO mode, but I appreciate that the problem is hard to fix correctly. I wonder if an intermediate solution would be dropping the 'restrict qualifier' (in default of a better term) from allocatable components of derived types. This is a very small set of variables (as this was not allowed in Fortran90, IIRC) and should have small impact on the performance of typical programs. In exchange one would be able to use LTO without the risk of miscompilation, and presumably with significant benefit.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #89 from Richard Biener 2012-12-13 12:06:57 UTC --- Just to repeat, the ICEs are with checking enabled only (but possibly cover up for wong-code). I believe the correct solution will involve implementing the proposal for introducing explicit restrict tags and using that in the fortran frontend (removing the restrict qualification work). See http://gcc.gnu.org/ml/gcc-patches/2011-10/msg01011.html.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele changed: What|Removed |Added Last reconfirmed|2011-07-09 09:36:18 |2012-12-13 9:36:18 CC||Joost.VandeVondele at mat ||dot ethz.ch --- Comment #88 from Joost VandeVondele 2012-12-13 08:41:19 UTC --- reconfirmed with current trunk.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Peter Bergner changed: What|Removed |Added CC||bergner at gcc dot gnu.org --- Comment #87 from Peter Bergner 2012-11-15 22:46:23 UTC --- I noticed this same error on the pr45586*.f90 test cases, but the reduced test case in Comment #86 ICEs for me too on powerpc64-linux.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #86 from Joost VandeVondele 2012-09-30 12:30:43 UTC --- (In reply to comment #84) LTO might work for many codes, as using allocatables in derived types was not standard Fortran90 (IIRC) and appears needed to trigger the bug. Anyway, since most people will use released versions of gcc, this checking error will be hidden behind --enable-checking=release. Only very few people will be able to locate and in particular reduce wrong code generation that only happens with LTO, so I wouldn't expect bug reports for actual wrong code generation very quickly. Meanwhile a shorter testcase for 4.8, using gfortran -flto -O0. TYPE t REAL, DIMENSION(:), ALLOCATABLE :: r END TYPE t TYPE t_p TYPE(t), POINTER :: d_t END TYPE t_p REAL, DIMENSION(:), POINTER:: d TYPE(t_p) :: x d=>x%d_t%r END
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #85 from Mikael Morin 2012-09-26 16:06:59 UTC --- (In reply to comment #84) > (In reply to comment #83) > > any progress on this one? > > Well, the patch at http://gcc.gnu.org/ml/fortran/2012-08/msg00150.html solves > several issues, but it still has issues, cf. > http://gcc.gnu.org/ml/fortran/2012-08/msg00176.html And some of the remaining issues are not present on trunk, so the patch is not a complete improvement. I'm not actively working on this (nor anything else actually) any more.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Tobias Burnus changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #84 from Tobias Burnus 2012-09-26 09:37:57 UTC --- (In reply to comment #83) > any progress on this one? Well, the patch at http://gcc.gnu.org/ml/fortran/2012-08/msg00150.html solves several issues, but it still has issues, cf. http://gcc.gnu.org/ml/fortran/2012-08/msg00176.html > It would be great to have LTO work with Fortran in 4.8 Well, it does for many codes; also the issue is merely* a tree-checking issues thus it should work* when GCC is compiled with release checking. (* As the tree-checking failure is related to the "restrict" qualifier / pointer/target attribute, the issue of this PR might lead to wrong code. But seemingly, the issue doesn't surface in most codes.)
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #83 from Joost VandeVondele 2012-09-26 06:42:59 UTC --- Mikael, any progress on this one (BTW, the PR is not yet assigned)? It would be great to have LTO work with Fortran in 4.8 (especially with all the inlining improvements). However, I would guess that this is stage 1 material, and I'm assuming stage 1 is nearing its end.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Joost VandeVondele changed: What|Removed |Added URL||http://gcc.gnu.org/ml/fortr ||an/2012-08/msg00150.html --- Comment #82 from Joost VandeVondele 2012-09-04 12:22:12 UTC --- URL for the current version of the patch added.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #81 from Mikael Morin 2012-08-01 18:37:55 UTC --- (In reply to comment #79) > If that's valid then you can make the middle-end happy by wrapping > the RHS inside a VIEW_CONVERT_EXPR with the LHS type. OK. will try. I don't know yet though how to limit that to the very cases where it is necessary. (In reply to comment #80) > I have not closely looked at the dump, however, > this%y = this%find_y() > means that one assigns component-wise the values from the RHS to the LHS; if > there are pointer components, the pointer address is assigned; if there are > allocatable components, those are - if needed - first (re)allocated and then > (element-wise) assigned. > > Thus, one only assigns the values and no pointers - and, hence, the RHS can be > a nontarget while the LHS can be a target. > Actually, there is a wrong-code bug about exactly this line (see bugs #47455 and #47586). But I think that even if there wasn't, the middle-end wouldn't be happy about it. The values are assigned component-wise, and that's the only way the middle-end would accept it.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #80 from Tobias Burnus 2012-08-01
16:22:52 UTC ---
(In reply to comment #79)
> > this%y = this%find_y() ! FAILS
> >
> > the lhs is a target, and the rhs is NOT a target, so that the middle-end
> > types
> > are different. :-(
>
> But how can this be a valid fortran program? You assign something
> that is not aliased to something that suddenly makes it aliased?
> If that's valid then you can make the middle-end happy by wrapping
> the RHS inside a VIEW_CONVERT_EXPR with the LHS type.
I have not closely looked at the dump, however,
this%y = this%find_y()
means that one assigns component-wise the values from the RHS to the LHS; if
there are pointer components, the pointer address is assigned; if there are
allocatable components, those are - if needed - first (re)allocated and then
(element-wise) assigned.
Thus, one only assigns the values and no pointers - and, hence, the RHS can be
a nontarget while the LHS can be a target.
In this example, "this%y" is a derived type with an allocatable-array
component. I think the current algorithm is something like:
*dst = *src;
if (src->data)
{
(re)allocate dst->data
memcpy (dst->data, src->data);
}
Thus, one first transfers the pointer address [besides the array bounds], but
if "data" is not NULL, the data is copied. Thus, it should be safe - but an
ARRAY_RANGE_REF could be nicer than a memcpy, and the VIEW_CONVERT_EXPR could
be inserted.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #79 from rguenther at suse dot de 2012-08-01 15:05:22 UTC --- On Wed, 1 Aug 2012, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #78 from Mikael Morin 2012-08-01 > 15:01:59 UTC --- > (In reply to comment #76) > > You mean > > > > [...] > > > > ? Yes, that also should be build_distinct_type_copy. > > > Even without that, the patch regtests cleanly (including the pr45586 tests), > apart for typebound_proc_20.f90. That one fail in the following line from the > `calc' subroutine: > > this%y = this%find_y() ! FAILS > > the lhs is a target, and the rhs is NOT a target, so that the middle-end types > are different. :-( But how can this be a valid fortran program? You assign something that is not aliased to something that suddenly makes it aliased? If that's valid then you can make the middle-end happy by wrapping the RHS inside a VIEW_CONVERT_EXPR with the LHS type.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #78 from Mikael Morin 2012-08-01 15:01:59 UTC --- (In reply to comment #76) > You mean > > [...] > > ? Yes, that also should be build_distinct_type_copy. > Even without that, the patch regtests cleanly (including the pr45586 tests), apart for typebound_proc_20.f90. That one fail in the following line from the `calc' subroutine: this%y = this%find_y() ! FAILS the lhs is a target, and the rhs is NOT a target, so that the middle-end types are different. :-(
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #77 from Mikael Morin 2012-08-01 12:37:45 UTC --- (In reply to comment #75) > Created attachment 27919 [details] > rough patch > About the patch: The failures are mostly(all?) due to structure constructors. Structure constructors use components' backend_decl which are of restricted types. however, if the lhs is a target, one should use the non-restricted components. I tried fixing the constructor using gfc_convert (see the patch). However, it doesn't work with scalarization, as the constructor is evaluated outside the loop into a variable (which gets the restricted type). So, this patch adds a flag restricted to gfc_conv_structure. the flag propagates to gfc_conv_expr, and gfc_conv_initializer, gfc_conv_initializer, etc. To know whether we need to call gfc_conv_expr with the restricted flag set or not in the scalarizer, a new flag field is added to the scalarizer's gfc_ss_info structures to tell whether we want a non-restricted expression. For it to be set appropriately, a flag is propagated to the gfc_walk_* functions.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
--- Comment #76 from rguenther at suse dot de
2012-08-01 12:28:10 UTC ---
On Wed, 1 Aug 2012, mikael at gcc dot gnu.org wrote:
> http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586
>
> --- Comment #75 from Mikael Morin 2012-08-01
> 12:22:03 UTC ---
> Created attachment 27919
> --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27919
> rough patch
>
> (In reply to comment #74)
> > > For variable to be type compatible for assignment, they shall be variants
> > > of
> > > the same type, and thus have the same TYPE_FIELDS.
> > > If they shall have the same TYPE_FIELDS, they shall have the same
> > > components,
> > > the same components have the same types, so that one cannot be restrict
> > > qualified.
> >
> > The types should not be variant types ;) (see my hack patch in
> > this or another bug)
> Ah OK, I thought it was just a hack.
>
> > > > nor does it address the original
> > > > issue of supporting INTENT IN/OUT properly.
> > > Ah? Isn't a restricted type variable (resp. component, etc) merely one
> > > that has
> > > its own alias set? So if it works with restrict, it works with alias sets?
> >
> > No, alias-sets and restrict are different beasts. It's important to
> > have the data member restrict qualified for INTENT IN/OUT.
> Ah.
>
> I have attached a (very rough) patch which is already in the testsuite past
> the
> first failing cases reported by Dominique.
> About your fix:
> (In reply to comment #64)
> > Index: gcc/fortran/trans-types.c
> > ===
> > --- gcc/fortran/trans-types.c (revision 184203)
> > +++ gcc/fortran/trans-types.c (working copy)
> > @@ -2042,7 +2042,8 @@ gfc_nonrestricted_type (tree t)
> > }
> > if (!field)
> > break;
> > - ret = build_variant_type_copy (t);
> > + ret = build_distinct_type_copy (t);
> > + TYPE_CANONICAL (ret) = TYPE_CANONICAL (t);
> > TYPE_FIELDS (ret) = NULL_TREE;
> >
> > /* Here we make sure that as soon as we know we have to copy
> there is another call to build_variant_type_copy before about array types.
> Should the same fix by applied or are variants OK there?
You mean
case ARRAY_TYPE:
{
tree elemtype = gfc_nonrestricted_type (TREE_TYPE (t));
if (elemtype == TREE_TYPE (t))
ret = t;
else
{
ret = build_variant_type_copy (t);
? Yes, that also should be build_distinct_type_copy.
Richard.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #75 from Mikael Morin 2012-08-01 12:22:03 UTC --- Created attachment 27919 --> http://gcc.gnu.org/bugzilla/attachment.cgi?id=27919 rough patch (In reply to comment #74) > > For variable to be type compatible for assignment, they shall be variants of > > the same type, and thus have the same TYPE_FIELDS. > > If they shall have the same TYPE_FIELDS, they shall have the same > > components, > > the same components have the same types, so that one cannot be restrict > > qualified. > > The types should not be variant types ;) (see my hack patch in > this or another bug) Ah OK, I thought it was just a hack. > > > nor does it address the original > > > issue of supporting INTENT IN/OUT properly. > > Ah? Isn't a restricted type variable (resp. component, etc) merely one that > > has > > its own alias set? So if it works with restrict, it works with alias sets? > > No, alias-sets and restrict are different beasts. It's important to > have the data member restrict qualified for INTENT IN/OUT. Ah. I have attached a (very rough) patch which is already in the testsuite past the first failing cases reported by Dominique. About your fix: (In reply to comment #64) > Index: gcc/fortran/trans-types.c > === > --- gcc/fortran/trans-types.c (revision 184203) > +++ gcc/fortran/trans-types.c (working copy) > @@ -2042,7 +2042,8 @@ gfc_nonrestricted_type (tree t) > } > if (!field) > break; > - ret = build_variant_type_copy (t); > + ret = build_distinct_type_copy (t); > + TYPE_CANONICAL (ret) = TYPE_CANONICAL (t); > TYPE_FIELDS (ret) = NULL_TREE; > > /* Here we make sure that as soon as we know we have to copy there is another call to build_variant_type_copy before about array types. Should the same fix by applied or are variants OK there?
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #74 from rguenther at suse dot de 2012-07-30 12:33:01 UTC --- On Mon, 30 Jul 2012, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #73 from Mikael Morin 2012-07-30 > 12:29:33 UTC --- > (In reply to comment #72) > > > (In reply to comment #63) > > > > That's bogus as TYPE_FIELDS > > > > is supposed to be shared amongst variant types. > > > > > > Then we'll have to revert Micha's recursive restrict work. > > > > I don't think so, it merely has to be fixed. > How so? by making it non-recursive? > For variable to be type compatible for assignment, they shall be variants of > the same type, and thus have the same TYPE_FIELDS. > If they shall have the same TYPE_FIELDS, they shall have the same components, > the same components have the same types, so that one cannot be restrict > qualified. The types should not be variant types ;) (see my hack patch in this or another bug) > > > Is it possible for the front-end to specify alias sets by hand (I mean > > > without > > > relying on the middle-end computing them based on types etc)? > > > > Yes. But that does not work with LTO, > You mean calling the front-end's code does not work at LTO time or the alias > sets are not saved/restored for LTO? LTO re-computes alias-sets based on types. > > nor does it address the original > > issue of supporting INTENT IN/OUT properly. > Ah? Isn't a restricted type variable (resp. component, etc) merely one that > has > its own alias set? So if it works with restrict, it works with alias sets? No, alias-sets and restrict are different beasts. It's important to have the data member restrict qualified for INTENT IN/OUT.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #73 from Mikael Morin 2012-07-30 12:29:33 UTC --- (In reply to comment #72) > > (In reply to comment #63) > > > That's bogus as TYPE_FIELDS > > > is supposed to be shared amongst variant types. > > > > Then we'll have to revert Micha's recursive restrict work. > > I don't think so, it merely has to be fixed. How so? by making it non-recursive? For variable to be type compatible for assignment, they shall be variants of the same type, and thus have the same TYPE_FIELDS. If they shall have the same TYPE_FIELDS, they shall have the same components, the same components have the same types, so that one cannot be restrict qualified. > > > Is it possible for the front-end to specify alias sets by hand (I mean > > without > > relying on the middle-end computing them based on types etc)? > > Yes. But that does not work with LTO, You mean calling the front-end's code does not work at LTO time or the alias sets are not saved/restored for LTO? > nor does it address the original > issue of supporting INTENT IN/OUT properly. Ah? Isn't a restricted type variable (resp. component, etc) merely one that has its own alias set? So if it works with restrict, it works with alias sets?
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #72 from rguenther at suse dot de 2012-07-30 11:04:39 UTC --- On Mon, 30 Jul 2012, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #71 from Mikael Morin 2012-07-30 > 10:35:48 UTC --- > (In reply to comment #70) > > On Sat, 28 Jul 2012, mikael at gcc dot gnu.org wrote: > > > So, is this a fortran front-end bug, a middle-end bug, or a lto bug ? > > > (Hint: PR 51765 is a marked as a lto bug ;-) ) > > > > It's a frontend bug. > > great :-(. > > > (In reply to comment #63) > > That's bogus as TYPE_FIELDS > > is supposed to be shared amongst variant types. > > Then we'll have to revert Micha's recursive restrict work. I don't think so, it merely has to be fixed. > Is it possible for the front-end to specify alias sets by hand (I mean without > relying on the middle-end computing them based on types etc)? Yes. But that does not work with LTO, nor does it address the original issue of supporting INTENT IN/OUT properly.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #71 from Mikael Morin 2012-07-30 10:35:48 UTC --- (In reply to comment #70) > On Sat, 28 Jul 2012, mikael at gcc dot gnu.org wrote: > > So, is this a fortran front-end bug, a middle-end bug, or a lto bug ? > > (Hint: PR 51765 is a marked as a lto bug ;-) ) > > It's a frontend bug. great :-(. (In reply to comment #63) > That's bogus as TYPE_FIELDS > is supposed to be shared amongst variant types. Then we'll have to revert Micha's recursive restrict work. Is it possible for the front-end to specify alias sets by hand (I mean without relying on the middle-end computing them based on types etc)?
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #70 from rguenther at suse dot de 2012-07-30 08:43:09 UTC --- On Sat, 28 Jul 2012, mikael at gcc dot gnu.org wrote: > http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 > > --- Comment #69 from Mikael Morin 2012-07-28 > 09:46:00 UTC --- > (In reply to comment #63) > > With a (seemingly) unrelated patch (attached to PR52097) I'm back on ICEing > > for the gfortran.dg/lto/pr45586*.f90 testcases ... > > > > Even before the adjusted type merging we have (at compile-time) > > > [...] > > > > _BUT_(!) its main-variant is > > > [...] > > > > thus has a restrict-qualified data field. That's bogus as TYPE_FIELDS > > is supposed to be shared amongst variant types. > > So, is this a fortran front-end bug, a middle-end bug, or a lto bug ? > (Hint: PR 51765 is a marked as a lto bug ;-) ) It's a frontend bug.
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #69 from Mikael Morin 2012-07-28 09:46:00 UTC --- (In reply to comment #63) > With a (seemingly) unrelated patch (attached to PR52097) I'm back on ICEing > for the gfortran.dg/lto/pr45586*.f90 testcases ... > > Even before the adjusted type merging we have (at compile-time) > [...] > > _BUT_(!) its main-variant is > [...] > > thus has a restrict-qualified data field. That's bogus as TYPE_FIELDS > is supposed to be shared amongst variant types. So, is this a fortran front-end bug, a middle-end bug, or a lto bug ? (Hint: PR 51765 is a marked as a lto bug ;-) )
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Richard Guenther changed: What|Removed |Added CC||kargl at gcc dot gnu.org --- Comment #68 from Richard Guenther 2012-05-11 08:31:57 UTC --- *** Bug 53318 has been marked as a duplicate of this bug. ***
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 --- Comment #67 from Dominique d'Humieres 2012-03-12 10:15:39 UTC --- The patch in comment #64 fixes the failures reported in pr52516 but introduces many regressions: === gfortran Summary for unix/-m64 === # of expected passes41076 # of unexpected failures92 # of expected failures56 # of unresolved testcases12 # of unsupported tests71 === gfortran Summary === # of expected passes81865 # of unexpected failures184 # of expected failures112 # of unresolved testcases24 # of unsupported tests280 The failing tests are FAIL: gfortran.dg/alloc_comp_assign_10.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_basics_2.f90 -O0 (internal compiler error) FAIL: gfortran.dg/alloc_comp_initializer_1.f90 -O0 (internal compiler error) FAIL: gfortran.dg/dependency_25.f90 -O0 (internal compiler error) FAIL: gfortran.dg/dependency_37.f90 -O (internal compiler error) FAIL: gfortran.dg/typebound_proc_20.f90 -O (internal compiler error) FAIL: gfortran.dg/whole_file_31.f90 -O (internal compiler error) FAIL: gfortran.dg/lto/pr45586 f_lto_pr45586_0.o assemble, -O0 -flto -flto-partition=none (internal compiler error) and the internal compiler errors are /opt/gcc/work/gcc/testsuite/gfortran.dg/alloc_comp_assign_10.f90: In function 'tao_program': /opt/gcc/work/gcc/testsuite/gfortran.dg/alloc_comp_assign_10.f90:48:0: internal compiler error: in fold_convert_loc, at fold-const.c:2016 > ... but I suspect it would not fix the Fortran -flto ICEs in > PR51765 (which happen on pristine trunk, much to the same issue I suppose). confirmed AFACT: === gfortran Summary for unix/-m64/-flto === # of expected passes40973 # of unexpected failures186 # of expected failures56 # of unresolved testcases12 # of unsupported tests71 === gfortran Summary === # of expected passes81659 # of unexpected failures372 # of expected failures112 # of unresolved testcases24 # of unsupported tests280
[Bug fortran/45586] [4.8 Regression] ICE non-trivial conversion at assignment
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=45586 Richard Guenther changed: What|Removed |Added Status|RESOLVED|REOPENED Version|4.6.0 |4.8.0 Resolution|FIXED | Target Milestone|4.6.2 |4.8.0 Summary|[4.6/4.7 Regression] ICE|[4.8 Regression] ICE |non-trivial conversion at |non-trivial conversion at |assignment |assignment --- Comment #66 from Richard Guenther 2012-03-07 09:48:12 UTC --- Now exposed again.
