[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- (In reply to anlauf from comment #3) > so something is screwing up the scalarization. Indeed. gfc_walk_expr registers all the arrays involved as an early step of scalarizing a statement. The failing assert checks that all the arrays have been used/consumed, meaning that the array registration and the actual code generation are kept synchronized. Elemental actual arguments are some of those arrays involved. Obviously one should not remove some of them in the middle of code generation. It should be done beforehand if at all.
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #6 from Mikael Morin --- Created attachment 49609 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49609&action=edit rough patch OK, I understand better the problem. It’s not a bug that the kind argument is not used to produce code. It is known to be a constant, and that constant can be used directly at compile time. So it is the walking functions that should be fixed. I attach a rough patch doing that, it should sit on top of a full revert of pr91651.
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #7 from Mikael Morin --- (In reply to Mikael Morin from comment #6) > rough patch > Well, it doesn’t fix comment #5. :-(
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 --- Comment #8 from Mikael Morin --- (In reply to Mikael Morin from comment #7) > Well, it doesn’t fix comment #5. :-( Pilot error, it does fix it.
[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|NEW |ASSIGNED CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- Taking, patch submitted: https://gcc.gnu.org/pipermail/gcc-patches/2023-January/610834.html
[Bug fortran/108450] [12/13 Regression] ICE in sort_actual, at fortran/intrinsic.cc:4380 since r12-5793-g689407ef916503b2
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108450 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from Mikael Morin --- Fixed for gcc-13.1 and gcc-12.3. Closing.
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Last reconfirmed||2023-02-24 CC||mikael at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED --- Comment #1 from Mikael Morin --- I'm the culprit I guess. Should be easy to fix anyway. Taking.
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 --- Comment #2 from Mikael Morin --- (In reply to Mikael Morin from comment #1) > Should be easy to fix anyway. Not that easy after all. The following (obvious) fix regresses heavily. diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc index c295721b9d6..73ee50e385c 100644 --- a/gcc/fortran/expr.cc +++ b/gcc/fortran/expr.cc @@ -545,6 +545,7 @@ gfc_free_actual_arglist (gfc_actual_arglist *a1) a2 = a1->next; if (a1->expr) gfc_free_expr (a1->expr); + free (a1->associated_dummy); free (a1); a1 = a2; }
[Bug fortran/108923] memory leak of get_intrinsic_dummy_arg result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108923 --- Comment #3 from Mikael Morin --- Here is a small reproducer by the way: program p implicit none call s(0) contains subroutine s(i) integer :: i end subroutine s end program p
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- This seems to do the trick for this testcase: diff --git a/gcc/fortran/parse.cc b/gcc/fortran/parse.cc index f1e55316e5b..f7670591fad 100644 --- a/gcc/fortran/parse.cc +++ b/gcc/fortran/parse.cc @@ -3864,9 +3864,6 @@ loop: accept_statement (st); prog_unit = gfc_new_block; prog_unit->formal_ns = gfc_current_ns; - if (prog_unit == prog_unit->formal_ns->proc_name - && prog_unit->ns != prog_unit->formal_ns) -prog_unit->refs++; decl: /* Read data declaration statements. */ I can't fully test it right now.
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 --- Comment #2 from Mikael Morin --- Interestingly, the three lines removed in the previous comment come from a fix for PR41093, whose title is "memory leaks with gfc_namespace".
[Bug fortran/108925] memory leak of gfc_get_namespace result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Can't reproduce with simple examples, testcase? I have used the following case, it does show some leaks, but none with load_needed in the backtrace. module m integer i end module m module n use m contains subroutine s(a) integer a i = a end subroutine end module n program p use n call s(0) print *, i end program
[Bug fortran/108925] memory leak of gfc_get_namespace result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925 --- Comment #3 from Mikael Morin --- (In reply to anlauf from comment #2) > The attachment in pr68800 may serve as a starting point: > > https://gcc.gnu.org/bugzilla/attachment.cgi?id=36964 Thanks, reduced: MODULE m TYPE :: a END TYPE END MODULE USE m END
[Bug fortran/108925] memory leak of gfc_get_namespace result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925 --- Comment #5 from Mikael Morin --- This does NOT improve things: diff --git a/gcc/fortran/module.cc b/gcc/fortran/module.cc index 601497e0998..2d6c7b8ef73 100644 --- a/gcc/fortran/module.cc +++ b/gcc/fortran/module.cc @@ -5258,7 +5258,10 @@ read_cleanup (pointer_info *p) vtypes - their name is fine for a symtree and reduces the namespace pollution. */ st = gfc_find_symtree (ns->sym_root, p->u.rsym.sym->name); - if (!st) + if (st) + /* The symtree is reassigned below. */ + st->n.sym->refs--; + else st = gfc_new_symtree (&ns->sym_root, p->u.rsym.sym->name); }
[Bug fortran/108925] memory leak of gfc_get_namespace result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108925 --- Comment #6 from Mikael Morin --- Created attachment 54598 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54598&action=edit Tentative patch Indeed the namespaces created during module loading are not stored anywhere, so they are leaked basically. As they are the pieces holding symbols, which themselves hold other things, etc, all these are leaked as well. The attached patch stores in the current namespace a tree of module namespaces, and use those namespaces when loading a symbol from a module. For a symbol that is present in a module, this means that its sym->ns will be the module namespace, even if its sym->ns was not the module namespace at the time it was written. This makes a difference for symbols that are present in more than one namespace, but I'm not sure how important that difference is. This seems to work on the reduced testcases, can't fully test right now.
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- Created attachment 54641 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54641&action=edit Draft patch I couldn't track the exact path of the memory error reported by valgrind, but the attached patch "fixes" (well, it makes it latent I guess) the problem by removing from the use statement list the statements that are rejected.
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 --- Comment #4 from Mikael Morin --- Created attachment 54642 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54642&action=edit Dra (In reply to Mikael Morin from comment #3) > Created attachment 54641 [details] > Draft patch > > I couldn't track the exact path of the memory error reported by valgrind, > but the attached patch "fixes" (well, it makes it latent I guess) the > problem by removing from the use statement list the statements that are > rejected. There is a bug in it: new use statements are at the end of the linked list, not at the beginning.
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added Attachment #54641|0 |1 is obsolete|| Attachment #54642|0 |1 is obsolete|| --- Comment #5 from Mikael Morin --- Created attachment 54643 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54643&action=edit Corrected draft patch (In reply to Mikael Morin from comment #4) > Created attachment 54642 [details] > Dra > I was meaning: Draft patch, corrected.
[Bug fortran/107426] [12/13 Regression] ICE in gfc_compare_derived_types, at fortran/interface.cc:636
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107426 Mikael Morin changed: What|Removed |Added Attachment #54643|0 |1 is obsolete|| --- Comment #6 from Mikael Morin --- Created attachment 54644 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=54644&action=edit Corrected patch The previous patch was broken in multiple ways. This one works.
[Bug fortran/104570] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681 since r12-7217-g57da34939703a6e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from Mikael Morin --- Created attachment 52521 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52521&action=edit Draft patch, regtests cleanly My bug, I guess. Here is a (very ad hoc) fix. I have yet to see how much of it is really necessary, and whether I want this rather than reverting the regressing revision.
[Bug fortran/104570] [12 Regression] ICE in gfc_conv_scalarized_array_ref, at fortran/trans-array.cc:3681 since r12-7217-g57da34939703a6e6
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104570 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #5 from Mikael Morin --- Fixed.
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #35 from Mikael Morin --- A little status update. I have pushed the latest patch attached to this PR a little further, but not far enough to reduce the number of testsuite regressions to 0. I plan to submit it for gcc-13, but it won’t make it for gcc-12. (In reply to Richard Biener from comment #33) > With > a single dimension there's not much value in using ARRAY_REF over > pointer arithmetic and dereference. I have tried to fix this PR using pointer arithmetic too. But there are so many places in the frontend where we expect to have an array type when dereferencing a descriptor pointer, that it’s not as simple as it seems and I finally convinced myself that the patch attached to this PR was the best way to go. For gcc-12, is there a way to add a middle-end workaround using annotations on descriptor types (a lang flag or something) ?
[Bug fortran/102043] [9/10/11/12 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #43 from Mikael Morin --- I’m working on it.
[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #12 from Mikael Morin --- Created attachment 52828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52828&action=edit Fix attempt I think the attached patch avoids the multiple declarations for __class_STAR_p, but the testsuite FAIL remains, so I must be missing important. Is there a -fdump-tree-types or something so that the problem can be seen in dumps (both for eyeballing and for matching with the testsuite)?
[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662 --- Comment #13 from Mikael Morin --- (In reply to Mikael Morin from comment #12) > ... so I must be missing important. I must be missing *something* important.
[Bug fortran/103662] [12 Regression] TBAA problem in Fortran FE triggering in gfortran.dg/unlimited_polymorphic_3.f03
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103662 --- Comment #17 from Mikael Morin --- (In reply to Jakub Jelinek from comment #15) > Now, the question is what is the Fortran unlimited polymorphic semantics, if > one can store through one type and read through a different type which just > has the same layout, or if it also has to use the same name etc., or if it > is even acceptable to store through say a type with a pair of integers and > read through a type with double precision etc. I think the pointer assignments in foo are invalid: 10.2.2.3 Data pointer assignment … If the pointer object is of a type with the BIND attribute or the SEQUENCE attribute, the dynamic type of the pointer target shall be that type. => the dynamic type of tgt shall be respectively s and t 7.3.2.3 CLASS type specifier … The dynamic type of an associated polymorphic pointer is the dynamic type of its target. => the dynamic type of tgt is that of z => the dynamic type of z is that of y => the dynamic type of y is that of x, which is sq 7.5.2.4 Determination of derived types … Data entities also have the same type if they are declared with reference to different derived-type definitions that specify the same type name, all have the SEQUENCE attribute or all have the BIND attribute, have no components with PRIVATE accessibility, and have components that agree in order, name, and attributes. Otherwise, they are of different derived types. => sq and s are different types (different component name) => sq and t are different types (different component name, bind(c), sequence) => s and t are different types (bind(c), sequence) So ptr1 and ptr2 should either have type sq, or s and t should be changed to be "compatible" with sq. And "compatible" is defined in the 7.5.2.4 excerpt above.
[Bug fortran/99308] [OOP] passing array of object as class(TYPE) to procedure leads to incorrect length of array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99308 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- Possible duplicate of PR57590, which has lengthy explanations.
[Bug fortran/59881] Memory corruption with allocatable arrays in polymorphic types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59881 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #6 from Mikael Morin --- (In reply to Jürgen Reuter from comment #5) > I checked again, and I don't see any issues any more. There might still be > some memory leaks, I haven't checked. Would it make sense to close this one > and open a new report in case there is a definite reproducer? Yes, assuming fixed. Closing.
[Bug fortran/93256] Assumed-shape unlimited polymorphic variable passes values incorrectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93256 Mikael Morin changed: What|Removed |Added Status|NEW |WAITING CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Can’t reproduce, it prints 10, 20, 30 in order.
[Bug fortran/99307] FAIL: gfortran.dg/class_assign_4.f90 execution test
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99307 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #13 from Mikael Morin --- Fixed?
[Bug fortran/104845] Wrong array size for component of CLASS array element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104845 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- (In reply to Tobias Burnus from comment #0) > > allocate (t :: var%ct2%d(3,2), var%ct2a(5,4,2)%d(3,2)) > allocate (t :: cvar%ct2%d(3,2), cvar%ct2a(5,4,2)%d(3,2)) > > Thus, the expected array size is 3*2 = 6. However, the result is > 6 0 6 0 > for > print *, size(var%ct2%d), size(var%ct2a(5,3,2)%d), & >size(cvar%ct2%d), size(cvar%ct2a(5,3,2)%d) > > where 'ct2' is scalar > and 'ct2a(5,3,2)' is an array element (also scalar) ct2a(5,3,2)%d isn’t allocated, should it be ct2a(5,4,2)%d ?
[Bug fortran/100813] Function of array of pointers to abstract class returning an array since r6-202-gf3b0bb7a560be0f0
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100813 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #2 from Mikael Morin --- It seems to work with a recent master (12.0.1 20220410).
[Bug fortran/105379] [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379 Mikael Morin changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |ASSIGNED CC||mikael at gcc dot gnu.org Last reconfirmed||2022-04-25 --- Comment #1 from Mikael Morin --- Caused by r12-8235-gfa5cd7102da676dcb1757b1288421f5f3439ae0e, I guess. So I am the culprit.
[Bug fortran/105379] [12 Regression] ICE in gfc_compare_array_spec(): Array spec clobbered since r12-8235-gfa5cd7102da676dc
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105379 --- Comment #3 from Mikael Morin --- Created attachment 52876 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52876&action=edit Draft patch This shows no testsuite regression. But there is something that I want to check before submitting it tomorrow.
[Bug fortran/105381] [12 Regression] Memory-hog since r12-8230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381 --- Comment #1 from Mikael Morin --- Draft patch. diff --git a/gcc/fortran/trans-array.cc b/gcc/fortran/trans-array.cc index e4b6270ccf8..e0070aa080d 100644 --- a/gcc/fortran/trans-array.cc +++ b/gcc/fortran/trans-array.cc @@ -3698,7 +3698,8 @@ non_negative_strides_array_p (tree expr) if (DECL_P (expr) && DECL_LANG_SPECIFIC (expr)) if (tree orig_decl = GFC_DECL_SAVED_DESCRIPTOR (expr)) - return non_negative_strides_array_p (orig_decl); + if (orig_decl != expr) + return non_negative_strides_array_p (orig_decl); return true; }
[Bug fortran/105381] [12 Regression] Memory-hog since r12-8230
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105381 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
--- Comment #21 from Mikael Morin ---
(In reply to anlauf from comment #18)
> Tentative patch, regtests cleanly but otherwise untested:
>
> diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
> index 850007fd2e1..0a1520e95ba 100644
> --- a/gcc/fortran/trans-expr.cc
> +++ b/gcc/fortran/trans-expr.cc
> @@ -6503,8 +6503,19 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol *
> sym,
> else
> {
> bool add_clobber;
> - add_clobber = fsym && fsym->attr.intent == INTENT_OUT
> - && !fsym->attr.allocatable && !fsym->attr.pointer
> + gfc_symbol *dsym = fsym;
> + gfc_dummy_arg *dummy;
> +
> + /* Use associated dummy as fallback for formal
> +argument if there is no explicit interface. */
> (...)
Note that if there is no explicit interface, I expect associated_dummy to be
NULL, and as a result dsym and fsym to always actually be the same thing.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
--- Comment #24 from Mikael Morin ---
(In reply to anlauf from comment #22)
>
> The remaining problem from PR41453#c8 is the following code in trans-expr.cc:
>
> (gdb) l 9539,9548
> 9539 else if (add_clobber && expr->ref == NULL)
> 9540{
> 9541 tree clobber;
> 9542 tree var;
> 9543 /* FIXME: This fails if var is passed by reference, see PR
> 9544 41453. */
> 9545 var = expr->symtree->n.sym->backend_decl;
> 9546 clobber = build_clobber (TREE_TYPE (var));
> 9547 gfc_add_modify (&se->pre, var, clobber);
> 9548}
>
> One needs to understand how to fix up 'var' here for the case at hand.
>
I guess the obvious one (se->expr) doesn’t work?
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
--- Comment #26 from Mikael Morin ---
(In reply to anlauf from comment #25)
> (In reply to Mikael Morin from comment #24)
> > (In reply to anlauf from comment #22)
> > >
> > > The remaining problem from PR41453#c8 is the following code in
> > > trans-expr.cc:
> > >
> > > (gdb) l 9539,9548
> > > 9539 else if (add_clobber && expr->ref == NULL)
> > > 9540{
> > > 9541 tree clobber;
> > > 9542 tree var;
> > > 9543 /* FIXME: This fails if var is passed by reference, see
> > > PR
> > > 9544 41453. */
> > > 9545 var = expr->symtree->n.sym->backend_decl;
> > > 9546 clobber = build_clobber (TREE_TYPE (var));
> > > 9547 gfc_add_modify (&se->pre, var, clobber);
> > > 9548}
> > >
> > > One needs to understand how to fix up 'var' here for the case at hand.
> > >
> > I guess the obvious one (se->expr) doesn’t work?
>
> Could you explain how to use it? (I don't have the necessary vision.)
Upon return from gfc_conv_expr, se->expr holds the value of the expression.
So basically var = se->expr;
As we manage to pass __result_derfc as argument, then I expect se->expr to have
value __result_derfc at that point.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012
--- Comment #28 from Mikael Morin ---
(In reply to anlauf from comment #23)
>
> No, they're not, when the procedures are in the same file.
> At least that's what gdb tells me...
gdb tells me the same. :-)
It is a side effect of calling gfc_check_externals it seems.
(In reply to anlauf from comment #27)
> (In reply to Mikael Morin from comment #26)
> >
> > Upon return from gfc_conv_expr, se->expr holds the value of the expression.
> > So basically var = se->expr;
> > As we manage to pass __result_derfc as argument, then I expect se->expr to
> > have value __result_derfc at that point.
>
> I tried that - just rechecked - and get an ICE: gimplification failed.
> So there's some magic missing I don't see...
With se->expr, what is generated is:
&__result_derfc = {CLOBBER};
Not too bad, but not exactly there yet.
With the following, I get the expected result.
Indeed, with se->want_pointer set, gfc_conv_expr generates an address
expression, so it has to be dereferenced to get back the variable.
diff --git a/gcc/fortran/trans-expr.cc b/gcc/fortran/trans-expr.cc
index 6c8fa16e723..367ecc2eb65 100644
--- a/gcc/fortran/trans-expr.cc
+++ b/gcc/fortran/trans-expr.cc
@@ -9602,7 +9602,7 @@ gfc_conv_expr_reference (gfc_se * se, gfc_expr * expr,
bool add_clobber)
tree var;
/* FIXME: This fails if var is passed by reference, see PR
41453. */
- var = expr->symtree->n.sym->backend_decl;
+ var = build_fold_indirect_ref_loc (input_location, se->expr);
clobber = build_clobber (TREE_TYPE (var));
gfc_add_modify (&se->pre, var, clobber);
}
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 Mikael Morin changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #30 from Mikael Morin --- (In reply to anlauf from comment #29) > > but if your patch regtests fine then you should proceed. Ok, let’s see how good it is. Assigning.
[Bug fortran/102043] [10/11 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Assignee|mikael at gcc dot gnu.org |unassigned at gcc dot gnu.org Status|ASSIGNED|NEW --- Comment #52 from Mikael Morin --- I posted a mostly-finished patch at [1] to restore array indexing of descriptor arrays. I got an answer suggesting to do the array descriptor reform (aka PR37577) by the way, if the ABI had to be broken anyway. This made me realize that the patch was going in the opposite direction as the long term one the fortran front-end is supposed to take, that is move to an array descriptor that would always require pointer arithmetics. So, I’m not working on introducing more array indexing any more. Unassigning.
[Bug fortran/102043] [10/11 Regression] Wrong array types used for negative stride accesses, gfortran.dg/vector_subscript_1.f90 FAILs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #53 from Mikael Morin --- (In reply to Mikael Morin from comment #52) > I posted a mostly-finished patch at [1] to restore array indexing of > descriptor arrays. I forgot to add a link for [1]: https://gcc.gnu.org/pipermail/fortran/2022-July/057980.html
[Bug fortran/106817] New: clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817 Bug ID: 106817 Summary: clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- module m implicit none contains subroutine copy(in, out) integer, intent(in) :: in integer, intent(out) :: out out = in end subroutine copy end module m program p use m implicit none integer :: a a = 3 call copy(a+1, a) if (a /= 4) stop 1 end program p The in value (a+1) depends on the value of a, but a is clobbered at the beginning of the call to copy, so we should make sure that we have evaluated a+1 before generating the clobber.
[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817 --- Comment #1 from Mikael Morin --- PR92178 is vaguely related. The tests are very similar, but that other PR is about allocatables whereas this one isn’t, so I think they are different.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 --- Comment #31 from Mikael Morin --- (In reply to Mikael Morin from comment #30) > (In reply to anlauf from comment #29) > > > > but if your patch regtests fine then you should proceed. > > Ok, let’s see how good it is. > Assigning. It seems to work, but trying to extend clobbering further, I uncovered a bug latent on master: PR106817. Maybe not that good an idea to extend clobbering further. :-(
[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817 --- Comment #3 from Mikael Morin --- (In reply to anlauf from comment #2) > > What am I missing? The right testcase. Try this one. module m implicit none contains subroutine copy(out, in) integer, intent(in) :: in integer, intent(out) :: out out = in end subroutine copy end module m program p use m implicit none integer :: a a = 3 call copy(a, a+1) if (a /= 4) stop 1 end program p
[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817
--- Comment #4 from Mikael Morin ---
(In reply to anlauf from comment #2)
> I see:
>
> D.4225 = a + 1;
> a = {CLOBBER};
> copy (&D.4225, &a);
>
> so I do not see any failure.
With the testcase from comment #3, it becomes:
a = {CLOBBER};
D.4223 = a + 1;
copy (&a, &D.4223);
[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817 Mikael Morin changed: What|Removed |Added Last reconfirmed||2022-09-03 Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org Status|UNCONFIRMED |ASSIGNED --- Comment #6 from Mikael Morin --- I’m on it.
[Bug fortran/106750] Memory leak calling array slice of derived type containing `allocatable` entries
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106750 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- Regarding the other "leak" from the original test: (In reply to federico from comment #0) > > program test (...) >type(t), allocatable :: ts(:) (...) >! [leak #2] happens if ts is not deallocated. Shouldn't a program work > like a >! subroutine, and deallocate everything that's going out of scope? >deallocate(ts) > > end program test > Not automatically deallocating is the correct behavior here, I think: > A variable, (...) declared in the scoping unit of a main program, module, or > submodule implicitly has the SAVE attribute => TS has the save attribute. > The SAVE attribute specifies that a local variable of a program unit or > subprogram retains its association status, allocation status, definition > status, and value after execution of a RETURN or END statement (...). => TS is not deallocated at the end of the program > When the execution of a procedure is terminated by execution of a RETURN or > END statement, an unsaved allocatable local variable of the procedure retains > its allocation and definition status if it is a function result or a > subobject thereof; otherwise, if it is allocated it will be deallocated. => this doesn’t apply as TS has the save attribute.
[Bug fortran/41453] use INTENT(out) for optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=41453 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #15 from Mikael Morin --- Status update: (In reply to Thomas Koenig from comment #5) > Still missing: To clobber > > - variables passed by reference to the caller > - saved variables > - associated variables (there are passed as pointers to > the associate blocsk) These have been done now. Still missing: pointer or allocatable dummy. Seems doable, probably a low hanging fruit. > - intent(out) variables on entry to the procedure. This remains to do. (In reply to Thomas Koenig from comment #7) > Also still to do: Do some more precise clobbering for > the case of PR88364, i.e. for > > call foo(a&x) > > clobber a%x, which is currently not done. This is impossible for now on the caller side because of lack of middle-end support: only full variable declarations can be clobbered, or pointer targets. There was a patch to handle the case above, but it was dropped for that reason. See: https://gcc.gnu.org/pipermail/fortran/2022-September/058181.html Maybe part of that patch can be resurrected, but restricted to the case of allocatable or pointer components. Another case that could be handled is the case of arrays: when the full array is passed as argument, and it is contiguous, and maybe some other condition, we can clobber its decl. The hard part is the "maybe some other condition". Not sure it's worth keeping this PR open. Surely the initial test works as expected, and has been working for a long time.
[Bug fortran/107075] ICE in get, at cgraph.h:461
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107075 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- (In reply to anlauf from comment #1) > > Uncommenting the 'save' also avoids the ICE, as does adding -fno-automatic . ... as does adding an initializer to A. That's something I noticed just a few days ago: variables from main program without initializer don't get (implicitly) the SAVE attribute. (In reply to Richard Biener from comment #2) > > But maybe 'z' shouldn't be of static storage duration ... No, I think it shouldn't. A should be static, and Z should not.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #13 from Mikael Morin --- Here is my understanding of the problem. There is a check on operand types in eval_intrinsic guarding numerical evaluation: 1573case INTRINSIC_PLUS: 1574case INTRINSIC_MINUS: 1575case INTRINSIC_TIMES: 1576case INTRINSIC_DIVIDE: 1577case INTRINSIC_POWER: 1578 if (!gfc_numeric_ts (&op1->ts) || !gfc_numeric_ts (&op2->ts)) 1579goto runtime; If we pass this check, we proceed to reduce_binary, where if one (or both) of the operands is an array, we do numerical evaluation for every element of the array. With the guarding check above, it is safe, with the assumption that elements of an array have the same type as the array itself. If that condition is not true, well, it doesn't work obviously. I don't see right now where an additional check would fit well, but the fix doesn't belong to walk_array_constructor in any case from my point of view.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #18 from Mikael Morin --- (In reply to anlauf from comment #14) > > We could walk through the elements of each array passed to reduce_binary > and check the types of the elements there, or do this check in a somewhat > more clever way than in the patch attached to comment#3. > > This patch tried to perform checks in reduce_binary_ac, but I was not happy > with that particular implementation. > > When looping over the elements, we currently have > > gfc_simplify_expr (c->expr, 0); > > if (c->expr->expr_type == EXPR_CONSTANT) > rc = eval (c->expr, op2, &r); > else > rc = reduce_binary_ac (eval, c->expr, op2, &r); > > and do not handle the case that c->expr->ts.type == BT_UNKNOWN. > Should we return sth. like rc = ARITH_INCOMMENSURATE, except that it is > not array .op. array? Well, a new return code seems better (ARITH_INVALID_TYPE ?). I think it's better to move the check to the various gfc_arith_times, gfc_arith_plus, gfc_arith_concat etc, because only those functions know what type is appropriate and what is not. Admittedly BT_UNKNOWN is probably never appropriate, and the check could be done in reduce_binary_ac, but then it should be in reduce_binary_ca, reduce_binary_aa and reduce_unary as well. Then what's missing is a goto runtime in eval_intrinsic if evaluation returns ARITH_INVALID_TYPE. That's the first solution.
[Bug fortran/107000] ICE in gfc_real2complex, at fortran/arith.cc:2243
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107000 --- Comment #19 from Mikael Morin --- (In reply to anlauf from comment #17) > (In reply to anlauf from comment #16) > > Created attachment 53651 [details] > > Revised patch > > Unfortunately this regresses on gfortran.dg/pr91552.f90, e.g. > > print *, 2 * [real :: 1, [2], 3] Yes, verify_types misses a call to itself for every element that is an array. I think we should not reject all mismatching types, because there is a call to gfc_type_convert_binary further down that is able to handle conversions on numeric types. Basically all numeric types, even if mismatching, should work. That's the second solution.
[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #7 from Mikael Morin --- (In reply to anlauf from comment #6) > (In reply to Steve Kargl from comment #5) > > > Perhaps, someone, who cares about this bug, can point at the language in > > the Fortran standard. > > I looked again at F2018 and couldn't find anything. > I think it's in 15.4.3.4.5 Restrictions on generic declarations. But it's too late for me to decipher what's written there.
[Bug fortran/66409] Reporting ambiguous interface when overloading assignment with polymorphic array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66409 --- Comment #9 from Mikael Morin --- (In reply to Jeff Hammond from comment #2) > > My MCVE: > > module f > implicit none > > interface test > module procedure test_f08 > module procedure test_f08ts > end interface test > > contains > > subroutine test_f08(buf) > integer :: buf > end subroutine test_f08 > > subroutine test_f08ts(buffer) > type(*), dimension(..), intent(inout) :: buffer > end subroutine test_f08ts > > end module f The following variant is not pretty, and I don't know if it does the job. But at least it is accepted by the compiler. module f implicit none interface test module procedure test_f08ts end interface test contains subroutine test_f08(buf) integer :: buf end subroutine test_f08 subroutine test_f08ts(buffer) class(*), dimension(..), intent(inout) :: buffer select rank(a => buffer) rank(0) select type(b => a) type is(integer) call test_f08(b) end select end select end subroutine test_f08ts end module f
[Bug fortran/87659] Memory corruption in array component of intent(in) unlimited polymorphic with optimization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87659 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- Seems to work now...
[Bug fortran/102275] Assumed rank, unlimited polymorphic pointer gives incorrect behaviour
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102275 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Seems to work now...
[Bug fortran/106817] clobber ordering problem when an actual intent(in) argument depends on the value of an intent(out) argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=106817 Mikael Morin changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #11 from Mikael Morin --- Fixed for 13.1, 12.3, 11.4 and 10.5. Closing.
[Bug fortran/105012] [12/13 Regression] wrf from SPECCPU2017 ICEs during LTO linking since r12-7692-g8db155ddf8cec9
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105012 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #37 from Mikael Morin --- (In reply to Richard Biener from comment #14) > I installed a workaround for the ICE, the fortran issue remains Fortran issue now fixed as well, and backported for 12.3, 11.4, and 10.5 releases. Closing.
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #11 from Mikael Morin --- (In reply to Steve Kargl from comment #8) > If regtesting complete ok, and Mikael doesn't find any additional > problems. Please commit. Unfortunately, I think there is one problem. Generally speaking, I don't like doing too much at parsing stage, and especially simplifying. It's too early in my opinion. Here is an example, where the array simplifies using the host-associated parameter value instead of calling the contained function with the same name hiding it. It is admittedly somewhat artificial. module m implicit none integer, parameter :: a(*) = [ 7, 11 ] contains subroutine bug real :: b(1) b = [ real :: (a(1)) ] print *, b if (any(b /= [ 14. ])) stop 1 contains function a(c) integer :: a, c a = c + 13 end function a end subroutine bug end module m program p use m call bug end program p
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483 --- Comment #17 from Mikael Morin --- There is the possibility to bail out at the very point where things are about to go wrong, and hope that at resolution time simplification will happen. Like this for the first part of the test from the patch: diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc index 9e079e42995..5e96bb9658e 100644 --- a/gcc/fortran/arith.cc +++ b/gcc/fortran/arith.cc @@ -1267,6 +1267,9 @@ reduce_unary (arith (*eval) (gfc_expr *, gfc_expr **), gfc_expr *op, if (op->expr_type == EXPR_CONSTANT) return eval (op, result); + if (op->expr_type != EXPR_ARRAY) +return ARITH_INVALID_TYPE; + rc = ARITH_OK; head = gfc_constructor_copy (op->value.constructor); for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c)) And something similar for the rest of the test (the binary operators).
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #18 from Mikael Morin ---
(In reply to Mikael Morin from comment #17)
> And something similar for the rest of the test (the binary operators).
Like this:
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 5e96bb9658e..3fdda045227 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1318,7 +1318,7 @@ reduce_binary_ac (arith (*eval) (gfc_expr *, gfc_expr *,
gfc_expr **),
if (c->expr->expr_type == EXPR_CONSTANT)
rc = eval (c->expr, op2, &r);
- else if (c->expr->expr_type == EXPR_OP && c->expr->ts.type ==
BT_UNKNOWN)
+ else if (c->expr->expr_type != EXPR_ARRAY)
rc = ARITH_INVALID_TYPE;
else
rc = reduce_binary_ac (eval, c->expr, op2, &r);
@@ -1372,7 +1372,7 @@ reduce_binary_ca (arith (*eval) (gfc_expr *, gfc_expr *,
gfc_expr **),
if (c->expr->expr_type == EXPR_CONSTANT)
rc = eval (op1, c->expr, &r);
- else if (c->expr->expr_type == EXPR_OP && c->expr->ts.type ==
BT_UNKNOWN)
+ else if (c->expr->expr_type != EXPR_ARRAY)
rc = ARITH_INVALID_TYPE;
else
rc = reduce_binary_ca (eval, op1, c->expr, &r);
@@ -1433,8 +1433,8 @@ reduce_binary_aa (arith (*eval) (gfc_expr *, gfc_expr *,
gfc_expr **),
c && d;
c = gfc_constructor_next (c), d = gfc_constructor_next (d))
{
- if ((c->expr->expr_type == EXPR_OP && c->expr->ts.type == BT_UNKNOWN)
- || (d->expr->expr_type == EXPR_OP && d->expr->ts.type == BT_UNKNOWN))
+ if ((c->expr->expr_type != EXPR_ARRAY)
+ || (d->expr->expr_type != EXPR_ARRAY))
rc = ARITH_INVALID_TYPE;
else
rc = reduce_binary (eval, c->expr, d->expr, &r);
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483 --- Comment #19 from Mikael Morin --- (In reply to Mikael Morin from comment #18) > (In reply to Mikael Morin from comment #17) > > And something similar for the rest of the test (the binary operators). > > Like this: > It doesn't work unfortunately: array_constructor_56.f90:18:28: 18 | real, parameter :: r7(*) = [real :: 1, 2] * [real :: 1, (2)] |1 Error: Bad shape of initializer at (1)
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #20 from Mikael Morin ---
(In reply to Mikael Morin from comment #19)
> (In reply to Mikael Morin from comment #18)
> > (In reply to Mikael Morin from comment #17)
> > > And something similar for the rest of the test (the binary operators).
> >
> > Like this:
> >
> It doesn't work unfortunately:
>
This one works:
diff --git a/gcc/fortran/arith.cc b/gcc/fortran/arith.cc
index 5e96bb9658e..c51ae105387 100644
--- a/gcc/fortran/arith.cc
+++ b/gcc/fortran/arith.cc
@@ -1318,7 +1318,7 @@ reduce_binary_ac (arith (*eval) (gfc_expr *, gfc_expr *,
gfc_expr **),
if (c->expr->expr_type == EXPR_CONSTANT)
rc = eval (c->expr, op2, &r);
- else if (c->expr->expr_type == EXPR_OP && c->expr->ts.type ==
BT_UNKNOWN)
+ else if (c->expr->expr_type != EXPR_ARRAY)
rc = ARITH_INVALID_TYPE;
else
rc = reduce_binary_ac (eval, c->expr, op2, &r);
@@ -1372,7 +1372,7 @@ reduce_binary_ca (arith (*eval) (gfc_expr *, gfc_expr *,
gfc_expr **),
if (c->expr->expr_type == EXPR_CONSTANT)
rc = eval (op1, c->expr, &r);
- else if (c->expr->expr_type == EXPR_OP && c->expr->ts.type ==
BT_UNKNOWN)
+ else if (c->expr->expr_type != EXPR_ARRAY)
rc = ARITH_INVALID_TYPE;
else
rc = reduce_binary_ca (eval, op1, c->expr, &r);
@@ -1433,8 +1433,8 @@ reduce_binary_aa (arith (*eval) (gfc_expr *, gfc_expr *,
gfc_expr **),
c && d;
c = gfc_constructor_next (c), d = gfc_constructor_next (d))
{
- if ((c->expr->expr_type == EXPR_OP && c->expr->ts.type == BT_UNKNOWN)
- || (d->expr->expr_type == EXPR_OP && d->expr->ts.type == BT_UNKNOWN))
+ if ((!(c->expr->expr_type == EXPR_CONSTANT || c->expr->expr_type ==
EXPR_ARRAY))
+ || (!(d->expr->expr_type == EXPR_CONSTANT || d->expr->expr_type ==
EXPR_ARRAY)))
rc = ARITH_INVALID_TYPE;
else
rc = reduce_binary (eval, c->expr, d->expr, &r);
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483 --- Comment #24 from Mikael Morin --- (In reply to anlauf from comment #21) > > Yeah, I was getting just rather close to this one... > Sorry, I didn't want to take it out of your hands. It seemed that no real solution was emerging. (In reply to anlauf from comment #23) > Here's a patch that incorporates comment#17 and comment#20 and adds a > testcase > for comment #11. Regtests fine. > > @Mikael: is it what you suggested? Yes. It gives a general direction, but there are a couple of things that I'm not satisfied with. First, the ARITH_INVALID_TYPE should be renamed as it has now a broader usage (ARITH_OP_NOT_LITERAL_VALUE is a bit long, ARITH_OP_NOT_CONSTANT is a bit misleading, ARITH_OP_NOT_SIMPLIFIED not great either, any other idea?). Second, I'm wondering whether the check in reduce_binary_aa shouldn't be moved to reduce binary where it would be more clear. But then it would be less consistent with reduce_binary_ac and reduce_binary_ca.
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483 --- Comment #27 from Mikael Morin --- (In reply to anlauf from comment #25) > (In reply to Mikael Morin from comment #24) > > First, the ARITH_INVALID_TYPE should be renamed as it has now a broader > > usage (ARITH_OP_NOT_LITERAL_VALUE is a bit long, ARITH_OP_NOT_CONSTANT is a > > bit misleading, ARITH_OP_NOT_SIMPLIFIED not great either, any other idea?). > > I think we should keep the enum ARITH_INVALID_TYPE for those cases where it > is appropriate, Are there such cases remaining? It seems that that value can't be returned any more. > I was contemplating either ARITH_NOT_REDUCED or > ARITH_CANNOT_REDUCE, > and opted for the latter. > I have a slight preference for the former but let's go with the latter if you prefer. But please add a comment describing it in the definition. Most enum values have an obvious meaning there, this one less so. > > Second, I'm wondering whether the check in reduce_binary_aa shouldn't be > > moved to reduce binary where it would be more clear. > > I agree that it is preferable to have checks already in reduce_binary, see > updated patch. After this one could remove the check from reduce_binary_aa, > as it would be redundant. > And there is a redundant check in reduce_unary as well.
[Bug fortran/103789] ICE when providing kind argument to mask{l,r}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #9 from Mikael Morin --- Finally fixed for upcoming 12.1 and 11.3 versions.
[Bug fortran/104228] [9/10/11/12 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228
Mikael Morin changed:
What|Removed |Added
CC||mikael at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot
gnu.org
Status|NEW |ASSIGNED
--- Comment #6 from Mikael Morin ---
The full typespec is copied from the associate target (x) to the associate
symbol (y) at parse.cc:4925. This includes the character length object, which
starting from there is shared between x and y. None of the various conditions
are met in resolve_assoc_var to overwrite the character length object. So when
we create the length decl (.y) for y and store it in its character length
object, it also appears in that of x at the same time. And from there it is
added to both functions along a path that I have lost.
Draft patch:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 835a4783718..266e41e25b1 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -9227,7 +9227,6 @@ resolve_assoc_var (gfc_symbol* sym, bool resolve_target)
sym->ts.u.cl = target->ts.u.cl;
if (sym->ts.deferred && target->expr_type == EXPR_VARIABLE
- && target->symtree->n.sym->attr.dummy
&& sym->ts.u.cl == target->ts.u.cl)
{
sym->ts.u.cl = gfc_new_charlen (sym->ns, NULL);
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #8 from Mikael Morin --- It comes from gfc_conv_expr_descriptor: /* Point the data pointer at the 1st element in the section. */ gfc_get_dataptr_offset (&loop.pre, parm, desc, base, subref_array_target, expr); where base has been calculated as the index of the first element. I’ve tried doing a mere "if (forward) start else end" in the calculation of base, but then I needed to add an offset (i.e. array index offset) to vector subscript accesses, and then a delta was missing (i.e. loop index offset) as the descriptor is one-based, but I don’t know how to fix the latter without impacting all the vector subscript handling which seems to rely on quite a few assumptions (no delta, no offset, zero-based loop?, forward loop?).
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #12 from Mikael Morin --- (In reply to Thomas Koenig from comment #11) > (In reply to Richard Biener from comment #10) > > > Is there any case where the frontend would make 'data' point into the > > middle of the array and iteration over the array would end up accessing > > elements on "both sides"? Can somebody write a short testcase where that > > would happen? > > I've tried, but I have been unable to find such a test case, and > I do not think this can (or should) happen. I would say it can happen as things stand, when one dimension is accessed going backward and another going forward. program main implicit none integer, dimension :: a(4, 4) a = 0 call s(a(4:1:-1,:)) if (any(a /= 10)) stop 1 contains subroutine s(b) implicit none integer, dimension(:,:) :: b b = 10 end subroutine s end program main
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #14 from Mikael Morin --- Created attachment 51787 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51787&action=edit draft patch This "fixes" the problem of negative index access, and adjusts vector subscript handling, so that correct code is produced for comment #1. It seems to break comment #13 even more, for reasons that I don’t see (yet).
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Attachment #51787|0 |1 is obsolete|| --- Comment #18 from Mikael Morin --- Created attachment 51791 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51791&action=edit new draft patch This fixes comment #13 as well, but it breaks printing of the dummy array from the contained subroutine s. :-(
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #19 from Mikael Morin --- (In reply to Thomas Koenig from comment #15) > One possibility would be to extend the patch Sandra posted at > https://gcc.gnu.org/pipermail/fortran/2021-January/055563.html > to scalarization. Probably nice to have, but it relies on casts which I see as fragile, and I don’t trust the middle end to not mishandle corner cases here and there. (In reply to Bernhard Reutner-Fischer from comment #17) > Do we want to address arrays always at position 0 (maybe to help graphite ?) > or would it be sufficient to just not dereference the array "before" the > first position > I’m not sure I understand the difference.
[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Mikael Morin --- Fixed for 11.3 and 12.1. Closing.
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Attachment #51791|0 |1 is obsolete|| --- Comment #22 from Mikael Morin --- Created attachment 51839 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51839&action=edit third try Yet another patch. It works with comment #1 and comment #13. However, with the testsuite it is a disaster.
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #23 from Mikael Morin --- (In reply to Richard Biener from comment #21) > (In reply to Bernhard Reutner-Fischer from comment #17) > > Do we want to address arrays always at position 0 (maybe to help graphite ?) > > Helping graphite (and other loop optimizers) would be to not lower > multi-dimensional accesses to a single dimension (I think that's what > Sandras patches try to do). Or maybe graphite can be taught to handle flattened array access? Anyway, does the middle-end support out-of-order array access? Namely for an array arr(4, 5, 6), arr(:, 1, :) is an array of size (4, 6). Does the middle-end type system support this? In any case, it’s not for gcc 12. > The lower bound doesn't really matter here and > is well-handled by all code. Well, unless the lower bound is negative. ;-)
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Attachment #51839|0 |1 is obsolete|| --- Comment #26 from Mikael Morin --- Created attachment 51891 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51891&action=edit latest patch Here is the patch I have arrived to so far. I have managed to reduce the number of regressions to 24. The ones that remain are more and more difficult to analyze and fix, with some iterating code for internal io that seems mishandled, and a few bind(c) stuff. There are also middle-end regressions (loop versioning) that I haven’t looked at.
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added Attachment #51891|0 |1 is obsolete|| --- Comment #27 from Mikael Morin --- Created attachment 51974 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51974&action=edit latest patch This is an almost complete fix. Almost because one regression remains on ISO_Fortran_binding_1.f90 Indeed this patch doesn’t handle c-fortran interface (aka CFI) descriptors. Those don’t have any offset field, so it should be fixed differently for them. In fact, I think the patch, as it is, is not worth it. It complicates bounds calculations, and I doubt the benefit out-weights the added complexity. I’m going to see how to just remove the lower bound information from the descriptor.
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #28 from Mikael Morin --- I’m reading the previous comments again: (In reply to Richard Biener from comment #10) > So to clarify the ARRAY_REF constraints - there is currently no way to > construct a valid ARRAY_REF where an index does an access to memory before > the supplied > base object. TREE_OPERAND (array_ref, 0) needs to always be the array, > it's address needs to be the address of the _first_ element. For negative > strides gfortran seems to construct the array object in a way so its > address points to the _last_ element of the array. That's not supported. > does that means that clearing the lower bound information from the type as I suggested in my last comment would not work?
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 Mikael Morin changed: What|Removed |Added See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=80645 --- Comment #29 from Mikael Morin --- PR #80645 is possibly related to this.
[Bug fortran/103472] ICE in gfc_conv_ss_startstride, at fortran/trans-array.c:4527
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103472 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #1 from Mikael Morin --- Created attachment 51982 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=51982&action=edit draft patch We could workaround it by replacing warnings with errors. Are there cases where we do want warnings, not errors?
[Bug fortran/103671] New: arrays with negative strides are wrongly passed as argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103671 Bug ID: 103671 Summary: arrays with negative strides are wrongly passed as argument. Product: gcc Version: 12.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- This has been identified in PR102043 comment #13. Testcase from there: program main implicit none integer, dimension :: a(4, 4) a = 0 call s(a(4:1:-1,:)) if (any(a /= 10)) stop 1 contains subroutine s(b) implicit none integer, dimension(:,:) :: b b = 10 end subroutine s end program main
[Bug fortran/103671] arrays with negative strides are wrongly passed as argument.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103671 Mikael Morin changed: What|Removed |Added Resolution|--- |DUPLICATE Status|UNCONFIRMED |RESOLVED --- Comment #1 from Mikael Morin --- Well, I thought there was an independent problem, but on closer look, it seems to be the same as the original. *** This bug has been marked as a duplicate of bug 102043 ***
[Bug fortran/102043] Wrong array types used for negative stride accesses
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102043 --- Comment #30 from Mikael Morin --- *** Bug 103671 has been marked as a duplicate of this bug. ***
[Bug fortran/103789] New: ICE when providing kind argument to mask{l,r}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789
Bug ID: 103789
Summary: ICE when providing kind argument to mask{l,r}
Product: gcc
Version: 12.0
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: mikael at gcc dot gnu.org
Target Milestone: ---
program p
integer :: z(2), y(2)
y = [1, 13]
z = maskl(y, kind=4) + 1
end
test.f90:4:27:
4 |z = maskl(y, kind=4) + 1
| 1
internal compiler error: in gfc_conv_constant, at fortran/trans-const.c:415
0x682a2a gfc_conv_constant(gfc_se*, gfc_expr*)
../../src/gcc/fortran/trans-const.c:415
0x9b83b7 gfc_conv_expr_op
../../src/gcc/fortran/trans-expr.c:3894
0x9b83b7 gfc_conv_expr(gfc_se*, gfc_expr*)
../../src/gcc/fortran/trans-expr.c:9390
0x9c52ac gfc_trans_assignment_1
../../src/gcc/fortran/trans-expr.c:11687
0x975837 trans_code
../../src/gcc/fortran/trans.c:1916
0x9a7b4f gfc_generate_function_code(gfc_namespace*)
../../src/gcc/fortran/trans-decl.c:7644
0x92223e translate_all_program_units
../../src/gcc/fortran/parse.c:6638
0x92223e gfc_parse_file()
../../src/gcc/fortran/parse.c:6925
0x9726ff gfc_be_parse_file
../../src/gcc/fortran/f95-lang.c:216
[Bug fortran/103789] ICE when providing kind argument to mask{l,r}
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103789 --- Comment #1 from Mikael Morin --- maskr is the same. Fix probably similar to PR87851.
[Bug fortran/107680] ICE in arith_power, at fortran/arith.cc:989 and :1006
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107680 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #3 from Mikael Morin --- I thought the call to gfc_type_convert_binary in eval_intrinsic was taking care of mismatching types, doesn't it?
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- (In reply to anlauf from comment #3) > But then no temporary is generated for a(n), which means we miss a > corresponding check elsewhere. > But is it required to generate a temporary? As I understand it, the code is invalid, and (correctly) diagnosed, so there is nothing else to do. It's invalid because of 15.5.2.13 Restrictions on entities associated with dummy arguments: (4) If the value of the entity or any subobject of it is affected through the dummy argument, then at any time during the invocation and execution of the procedure, either before or after the definition, it shall be referenced only through that dummy argument unless (...)
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 --- Comment #6 from Mikael Morin --- (In reply to anlauf from comment #5) > (In reply to Mikael Morin from comment #4) > > But is it required to generate a temporary? > > As I understand it, the code is invalid, and (correctly) diagnosed, so there > > is nothing else to do. > > It's invalid because of 15.5.2.13 Restrictions on entities associated with > > dummy arguments: > > (4) If the value of the entity or any subobject of it is affected through > > the dummy argument, then at any time during the invocation and execution of > > the procedure, either before or after the definition, it shall be referenced > > only through that dummy argument unless (...) > > Right. > > I was confused by two observations. First, NAG & Cray seem to generate > temporaries, while Intel and NVidia don't and would agree with gfortran > after the patch. > > Second, I stumbled over: > > ! 15.5.2.3 Argument association > ! (4) A present dummy argument with the VALUE attribute becomes argument > ! associated with a definable anonymous data object whose initial value is > ! the value of the actual argument. > Ouch! You're right, this makes the part I quoted above irrelevant. And it explicitly asks for a temporary. > So it boils down to what ELEMENTAL actually means in that context. F2018: > > 15.8.3 Elemental subroutine actual arguments > > ! In a reference to an elemental subroutine, if the actual arguments > ! corresponding to INTENT(OUT) and INTENT(INOUT) dummy arguments are > ! arrays, the values of the elements, if any, of the results are the same > ! as would be obtained if the subroutine had been applied separately, in > ! array element order, to corresponding elements of each array actual > ! argument. > > So I read this that > >call s (a(n), a) > > is to be interpreted as > > do i = 1, size (a) > call s (a(n(i)), a(i)) > end do > > and this would actually be well-defined behavior... ;-) With your quote from 15.5.2.3 above, it would be more like: do i = 1, size(a) tmp(i) = a(n(i)) end do do i = 1, size(a) call s(tmp(i), a(i)) end do
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 --- Comment #8 from Mikael Morin --- (In reply to anlauf from comment #3) > Could need help by some expert on this... I guess I qualify as expert. Reading the code again after years, it is not exactly crystal clear... Here is a dump of what I could gather about the gfc_check_fncall_dependency and friends functions. The different gfc_dep_check cases are the following: ELEM_DONT_CHECK_VARIABLE: This is the simple case of direct subroutine call. As per the 15.5.2.13 I quoted above, this is invalid: call elem_sub(a(2:n), a(1:n-1)) while this isn't call elem_sub(a, a) so we can always generate: do i = ... call elem_sub(a(...), a(...)) end do without caring for temporaries ELEM_CHECK_VARIABLE: This is the case of multiple elemental procedures. For example: call elem_sub(a, elem_func(a)) The semantics is like: tmp = elem_func(a) call elem_sub(a, tmp) Here, elem_sub can write to a without modifying tmp, and we have to preserve that. We generate code like this: do i = ... call elem_sub(tmp(i), elem_func(a(i))) end do a = tmp and try to avoid the temporary tmp if possible. we explore the second argument to elem_sub and look for the same variable as the expression from the first one, and we generate a temporary if we find it. But there is no need if they are strictly the same variable reference. NOT_ELEMENTAL: This is the case of the presence of transpose in the expression For example, for elem_sub(var, elem_func(transpose(var))), the semantics is: tmp1 = transpose(var) tmp2 = elem_func(tmp1) call elem_sub(var, tmp2) which we try to preserve, but with less temporaries. We try to generate do i = ..., j = ... call elem_sub(tmp(i,j), elem_func(var(j,i))) end do var = tmp and try to avoid the temporary tmp if possible (it's not with this example). We have to make sure that if the same variable appears in a subexpression of the argument, a temporary is generated. Contrary to the previous case, we have to generate the temporary even if the variable references are strictly the same.
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 --- Comment #9 from Mikael Morin --- (In reply to anlauf from comment #7) > > In the meantime, do you have an idea where to force the generation of a > temporary? I've been scrolling through gfc_conv_procedure_call to see > if that might be the right place, but that's not a small function... It seems the semantics when an argument has the value attribute is the same as the case ELEM_CHECK_VARIABLE in my previous comment. So forcing the value of the elemental argument to ELEM_CHECK_VARIABLE at some appropriate place could possibly work.
[Bug fortran/107819] ICE in gfc_check_argument_var_dependency, at fortran/dependency.cc:978
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=107819 --- Comment #12 from Mikael Morin --- (In reply to anlauf from comment #11) > Update: Steve Lionel thinks that no temporary is necessary, and testcase > z1.f90 > is non-conforming: > > https://community.intel.com/t5/Intel-Fortran-Compiler/ELEMENTAL-subroutine- > and-dummy-with-VALUE-attribute/m-p/1432932 > > In this case the patch of comment#2 would be sufficient. I was about to suggest to push the check_variable value change down into gfc_check_fncall_dependency, to be more aggressive wrt temporary elimination. But if the test is not conforming, let's throw all that away.
[Bug fortran/104228] [9/10/11 Regression] ICE in df_install_ref, at df-scan.cc:2294 since r8-3589-g707905d0773e5a8e
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104228 Mikael Morin changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from Mikael Morin --- Fixed for releases 9.5, 10.4, 11.3 and 12.1. Closing. Thanks for the report.
[Bug fortran/105547] New: No further "Unclassifiable statement" after the first one if multiple syntax errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547 Bug ID: 105547 Summary: No further "Unclassifiable statement" after the first one if multiple syntax errors. Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: mikael at gcc dot gnu.org Target Milestone: --- Testcase as reported by Harald here: https://gcc.gnu.org/pipermail/fortran/2022-May/057841.html subroutine a errorstop end subroutine b errorstop end This gives only one error as output instead of two: xxx.f90:2:3: 2 | errorstop | 1 Error: Unclassifiable statement at (1)
[Bug fortran/105547] No further "Unclassifiable statement" after the first one if multiple syntax errors.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105547
--- Comment #1 from Mikael Morin ---
In parse.cc, we avoid emitting an error if an other has been emitted.
But it uses the total error count, not the number of errors since we started
matching the current statement.
597 if (!gfc_error_check ())
598{
599 int ecnt;
600 gfc_get_errors (NULL, &ecnt);
601 if (ecnt <= 0)
602gfc_error_now ("Unclassifiable statement at %C");
603}
[Bug fortran/97896] [11/12 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896 Mikael Morin changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |mikael at gcc dot gnu.org --- Comment #11 from Mikael Morin --- Patches posted: v1: https://gcc.gnu.org/pipermail/fortran/2021-August/056303.html v2: https://gcc.gnu.org/pipermail/fortran/2021-August/056317.html 11 backport: https://gcc.gnu.org/pipermail/fortran/2021-August/056329.html
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 Mikael Morin changed: What|Removed |Added CC||mikael at gcc dot gnu.org --- Comment #4 from Mikael Morin --- (In reply to Jerry DeLisle from comment #2) > It looks like the 'selector' in this case is an expr. > Agreed. > The expr must be a pointer object or a 'designator' > Really? Can't find the constraint saying that. The only associate constraint mentioning 'designator' I can see is this: C1105 (R1105) expr shall not be a designator of a procedure pointer or a function reference that returns a procedure pointer. ... but it relates more to procedure pointers (and it is a 'shall NOT be' constraint). (In reply to kargl from comment #3) > Yep, agreed. I went back an re-read the section about ASSOCIATE. > Not sure how I convinced myself that a constant expression, which > reduces to a constant is okay. > Not sure how you convinced yourself it isn't. ;-)
[Bug fortran/114141] ASSOCIATE and complex part ref when associate target is a function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=114141 --- Comment #6 from Mikael Morin --- (In reply to kargl from comment #5) > (In reply to Mikael Morin from comment #4) > > > (In reply to kargl from comment #3) > > > Yep, agreed. I went back an re-read the section about ASSOCIATE. > > > Not sure how I convinced myself that a constant expression, which > > > reduces to a constant is okay. > > > > > Not sure how you convinced yourself it isn't. ;-) > > x => log(cmplx(-1,0)) > > R1104 association is associate-name => selector > > R1105 selector is expr >or variable > > R902 variable is designator >or function-reference > > R901 designatoris object-name >or array-element >or array-section >or coindexed-named-object >or complex-part-designator >or structure-component >or substring > > log(cmplx(-1,0)) is certainly not a designator. > > log(cmplx(-1,0)) is a function-reference. But this then > leads to > > C902 (R902) function-reference shall have a data pointer result. > > > log(cmplx(-1,0)) violates C902, so this then means that it > must be an expr. Agreed. > One now needs > > > R915 complex-part-designator is designator % RE > or designator % IM > > C922 (R915) The designator shall be of complex type. > > which shows that expr%im is invalid; even though log(cmplx(-1,0)) > reduces to a constant (i.e., it's not a named constant. This > is likely the error [pun intended] in my ways.). > This is about x%im, which is a different expression from log(cmplx(-1, 0)). x is an associate-name, and thus (I think) an object-name, and a valid designator, even if it's associated selector isn't.
