[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70853
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||ice-on-invalid-code
Priority|P3 |P4
Status|NEW |ASSIGNED
CC||anlauf at gcc dot gnu.org
Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot
gnu.org
--- Comment #4 from anlauf at gcc dot gnu.org ---
Tentative patch:
Index: gcc/fortran/trans-expr.c
===
--- gcc/fortran/trans-expr.c(Revision 279398)
+++ gcc/fortran/trans-expr.c(Arbeitskopie)
@@ -9218,6 +9218,13 @@ gfc_trans_pointer_assignment (gfc_expr * expr1, gf
break;
rank_remap = (remap && remap->u.ar.end[0]);
+ if (remap && expr2->expr_type == EXPR_NULL)
+ {
+ gfc_error ("If bounds remapping is specified at %L, "
+"the data target shall not be NULL", &expr1->where);
+ return NULL_TREE;
+ }
+
gfc_init_se (&lse, NULL);
if (remap)
lse.descriptor_only = 1;
[Bug fortran/92976] [8/9/10 Regression][OOP] ICE in trans_associate_var, at fortran/trans-stmt.c:1963
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92976 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-17 Summary|[8/9/10 Regression] ICE in |[8/9/10 Regression][OOP] |trans_associate_var, at |ICE in trans_associate_var, |fortran/trans-stmt.c:1963 |at ||fortran/trans-stmt.c:1963 Ever confirmed|0 |1 Known to fail||10.0, 7.4.1, 8.3.1, 9.2.1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/92977] ICE in gfc_trans_omp_atomic, at fortran/trans-openmp.c:3526
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92977 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||openmp Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-17 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed when compiling with optimization. Actually, you can compile with optimization, but need to disable front-end optimization (-fno-frontend-optimize).
[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70853 --- Comment #5 from anlauf at gcc dot gnu.org --- Patch with slightly more user-friendly error message: https://gcc.gnu.org/ml/fortran/2019-12/msg00159.html
[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70853 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Wed Dec 18 16:34:06 2019 New Revision: 279527 URL: https://gcc.gnu.org/viewcvs?rev=279527&root=gcc&view=rev Log: 2019-12-18 Harald Anlauf PR fortran/70853 * trans-expr.c (gfc_trans_pointer_assignment): Reject bounds remapping if pointer target is NULL(). PR fortran/70853 * gfortran.dg/pr70853.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr70853.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/70853] ICE on pointing to null, in gfc_add_block_to_block, at fortran/trans.c:1599
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70853 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed. Thanks for the report! As Tobias Burnus noticed, this fixes a related ICE with NULLIFY.
[Bug fortran/92785] expressions passed as real arguments to a dummy polymorphic argument fail with indexing error
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92785 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||wrong-code Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-18 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Known to fail||10.0, 7.4.1, 8.3.1, 9.2.1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. I think there are related PRs where the passed array descriptor is not set correctly.
[Bug fortran/87908] [PDT] ICE in check_interface0, at fortran/interface.c:1841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87908 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed|2018-11-06 00:00:00 |2019-12-18 CC||anlauf at gcc dot gnu.org Summary|ICE in check_interface0, at |[PDT] ICE in |fortran/interface.c:1841|check_interface0, at ||fortran/interface.c:1841 Known to fail||10.0 --- Comment #3 from anlauf at gcc dot gnu.org --- I think this is an ICE-on-valid. Moving subroutine s after g makes the ICE go away. One of several resolution issues?
[Bug fortran/92996] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92996
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-18
CC||anlauf at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from anlauf at gcc dot gnu.org ---
Funny. Setting a breakpoint in match.c, after
3086 /* Use the machinery for an initialization expression to reduce
the
3087 stop-code to a constant. */
3088 gfc_init_expr_flag = true;
3089 gfc_reduce_init_expr (e);
3090 gfc_init_expr_flag = false;
I get for case 0 (a(:) is variable):
(gdb) p e->expr_type
$5 = EXPR_VARIABLE
(gdb) p e->rank
$6 = 1
whereas for case 1 (a(:) is parameter):
(gdb) p e->expr_type
$7 = EXPR_ARRAY
(gdb) p e->rank
$8 = 0
How can that happen?
This is the reason it later misses the part:
3107 if (e->rank != 0)
3108{
3109 gfc_error ("STOP code at %L must be scalar", &e->where);
3110 goto cleanup;
3111}
[Bug fortran/92996] ICE in gfc_conv_array_constructor_expr, at fortran/trans-expr.c:7590
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92996 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4
[Bug fortran/92990] INVALID code with NULLIFY – partially misleading error message "If bounds remapping is specified at (1), the pointer target shall not be NULL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92990
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
Status|UNCONFIRMED |NEW
Last reconfirmed||2019-12-19
Ever confirmed|0 |1
--- Comment #1 from anlauf at gcc dot gnu.org ---
How about a simple approach to catch this early?
Beware: this is untested.
Index: gcc/fortran/match.c
===
--- gcc/fortran/match.c (Revision 279592)
+++ gcc/fortran/match.c (Arbeitskopie)
@@ -4589,6 +4589,19 @@ gfc_match_nullify (void)
goto cleanup;
}
+ /* Check for valid array pointer object. Bounds remapping is not
+allowed with NULLIFY. */
+ if (p->ref)
+ {
+ gfc_ref* remap;
+ for (remap = p->ref; remap; remap = remap->next)
+ if (!remap->next && remap->type == REF_ARRAY
+ && remap->u.ar.type != AR_FULL)
+ break;
+ if (remap)
+ goto syntax;
+ }
+
/* build ' => NULL() '. */
e = gfc_get_null_expr (&gfc_current_locus);
[Bug fortran/92990] INVALID code with NULLIFY – partially misleading error message "If bounds remapping is specified at (1), the pointer target shall not be NULL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92990 --- Comment #2 from anlauf at gcc dot gnu.org --- Patch cleaned up and with adjusted error message at https://gcc.gnu.org/ml/fortran/2019-12/msg00182.html
[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91661 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|NEW |WAITING Known to work||10.0 Known to fail||7.4.1, 8.3.1, 9.2.1 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #4) > Given the clumsiness to circumvent the issue with type-bound procedures, > I feel that the simplifications involved should be done at an earlier stage. > Anybody knows where that might be? My feeling was right: it appears that Tobias' fix for PR92996 (r279638) collaterally fixed this one, too! Add a testcase and close?
[Bug fortran/92990] INVALID code with NULLIFY – partially misleading error message "If bounds remapping is specified at (1), the pointer target shall not be NULL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92990 --- Comment #3 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Dec 21 20:25:43 2019 New Revision: 279698 URL: https://gcc.gnu.org/viewcvs?rev=279698&root=gcc&view=rev Log: 2019-12-21 Harald Anlauf PR fortran/92990 * match.c (gfc_match_nullify): Check for valid pointer object. Reject bounds remapping. PR fortran/92990 * gfortran.dg/pr92990.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr92990.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/match.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/92990] INVALID code with NULLIFY – partially misleading error message "If bounds remapping is specified at (1), the pointer target shall not be NULL"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92990 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91661 --- Comment #7 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Dec 21 20:42:14 2019 New Revision: 279699 URL: https://gcc.gnu.org/viewcvs?rev=279699&root=gcc&view=rev Log: 2019-12-21 Harald Anlauf PR fortran/91661 * gfortran.dg/pr91661.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr91661.f90 Modified: trunk/gcc/testsuite/ChangeLog
[Bug fortran/91661] ICE in gfc_conv_intrinsic_dot_product, at fortran/trans-intrinsic.c:4804
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91661 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed in GCC 10. Thanks for the report!
[Bug fortran/72715] [OpenACC] ICE in gfc_trans_omp_do, at fortran/trans-openmp.c:3164
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=72715 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid CC||anlauf at gcc dot gnu.org Summary|ICE in gfc_trans_omp_do, at |[OpenACC] ICE in |fortran/trans-openmp.c:3164 |gfc_trans_omp_do, at ||fortran/trans-openmp.c:3164 --- Comment #6 from anlauf at gcc dot gnu.org --- Code is still rejected with current 10-trunk: x.f90:4:23: 4 | do concurrent (i=1:3) | 1 Error: !$ACC LOOP cannot be a DO CONCURRENT loop at (1)
[Bug fortran/92873] ICE in unmodified_parm_or_parm_agg_item, at ipa-fnsummary.c:1166
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92873 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Adding a declaration of sub as elemental seems to avoid the ICE: elemental subroutine sub (x) character(*), intent(in) :: x end subroutine sub whereas a non-elemental version does not help: subroutine sub (x) character(*), intent(in) :: x(:) end subroutine sub
[Bug fortran/91960] ICE: backend decl for module variable 'j' already exists
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91960 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2019-12-22 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. We fail to detect that j is used in an initialization expression. As a consequence, we end up with junk later on. E.g.: module m implicit none integer :: i, j integer, parameter :: a(3) = [1, 2, 3] integer, parameter :: c= a(j) integer:: d= c end produces: pr91960b.f90:6:30: 6 | integer:: d= c | 1 Error: non-constant initialization expression at (1)
[Bug fortran/93091] [OOP] Apparent bugs in "sizeof" and "transfer" intrinsic functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93091
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Component|libfortran |fortran
Summary|Apparent bugs in "sizeof" |[OOP] Apparent bugs in
|and "transfer" intrinsic|"sizeof" and "transfer"
|functions |intrinsic functions
--- Comment #1 from anlauf at gcc dot gnu.org ---
If I add the following to poly/poly1, I get correct results:
select type (obj)
type is (character(*))
print "('Sizeof: ',i0)", sizeof(obj)
print "('Transfer: ',i0)",
size(transfer(obj,[0_c_int8_t]),kind=c_size_t)
type is (integer)
print "('Sizeof: ',i0)", sizeof(obj)
print "('Transfer: ',i0)",
size(transfer(obj,[0_c_int8_t]),kind=c_size_t)
end select
This will print:
Character
DIRECT-C
sizeof: 80
transfer: 80
POLY
sizeof: 1
transfer: 1
Sizeof: 80
Transfer: 80
etc.
Apparently OOP-related. Not sure if the bug is in the source code or
in the compiler handling polymorphism.
[Bug fortran/57553] [F08] Valid use of STORAGE_SIZE rejected, bad error message for invalid use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553 --- Comment #8 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Jan 26 20:45:55 2019 New Revision: 268303 URL: https://gcc.gnu.org/viewcvs?rev=268303&root=gcc&view=rev Log: 2019-01-26 Harald Anlauf PR fortran/57553 * expr.c (check_inquiry): Add list of inquiry functions allowed in constant expressions for F2008+. 2019-01-26 Harald Anlauf PR fortran/57553 * gfortran.dg/pr57553.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr57553.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 --- Comment #9 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Mon Feb 4 20:44:22 2019 New Revision: 268525 URL: https://gcc.gnu.org/viewcvs?rev=268525&root=gcc&view=rev Log: 2019-02-04 Harald Anlauf PR fortran/89077 * gfortran.dg/pr89077.f90: New test. 2019-02-04 Harald Anlauf PR fortran/89077 * gfortran.dg/pr89077.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr89077.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903 --- Comment #2 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Tue Jul 16 19:58:15 2019 New Revision: 273535 URL: https://gcc.gnu.org/viewcvs?rev=273535&root=gcc&view=rev Log: 2019-07-16 Harald Anlauf PR fortran/90903 * libgfortran.h: Add mask for -fcheck=bits option. * options.c (gfc_handle_runtime_check_option): Add option "bits" to run-time checks selectable via -fcheck. * trans-intrinsic.c (gfc_conv_intrinsic_btest) (gfc_conv_intrinsic_singlebitop, gfc_conv_intrinsic_ibits) (gfc_conv_intrinsic_shift, gfc_conv_intrinsic_ishft) (gfc_conv_intrinsic_ishftc): Implement run-time checks for the POS, LEN, SHIFT, and SIZE arguments. * gfortran.texi: Document run-time checks for bit manipulation intrinsics. * invoke.texi: Document new -fcheck=bits option. PR fortran/90903 * gfortran.dg/check_bits_1.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/check_bits_1.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/invoke.texi trunk/gcc/fortran/libgfortran.h trunk/gcc/fortran/options.c trunk/gcc/fortran/trans-intrinsic.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/90903] Implement runtime checks for bit manipulation intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=90903 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Checks for the functions part committed. Will now look into what can be done about the MVBITS subroutine.
[Bug fortran/91485] New: [10 Regression] Erroneous conflict between variable x and operator(.x.)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91485 Bug ID: 91485 Summary: [10 Regression] Erroneous conflict between variable x and operator(.x.) Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- Created attachment 46725 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=46725&action=edit Minimal reproducer The attached valid code suddenly fails with current 10-trunk: gfcbug155.f90:23:26: 23 | subroutine print_prod (x, y) | 1 24 | use foo, only: cartesian, operator(.x.) | 2 Error: Symbol 'x' at (1) conflicts with the symbol at (2) gfcbug155.f90:26:19: 26 | type(cartesian), intent(in) :: x, y | 1 Error: Derived type 'cartesian' at (1) is being used before it is defined gfcbug155.f90:23:26: 23 | subroutine print_prod (x, y) | 1 Error: Symbol 'x' at (1) has no IMPLICIT type gfcbug155.f90:23:29: 23 | subroutine print_prod (x, y) | 1 Error: Symbol 'y' at (1) has no IMPLICIT type The regression is most likely introduced in the last 2 days. Note that it is important that the USE statement is placed in the contained subroutine, not at module level.
[Bug fortran/91496] !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Status|UNCONFIRMED |ASSIGNED Last reconfirmed||2019-08-26 CC||anlauf at gcc dot gnu.org Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Ever confirmed|0 |1 Severity|normal |enhancement --- Comment #2 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/ml/fortran/2019-08/msg00120.html
[Bug fortran/91496] !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 --- Comment #3 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Tue Aug 27 19:16:33 2019 New Revision: 274966 URL: https://gcc.gnu.org/viewcvs?rev=274966&root=gcc&view=rev Log: 2019-08-27 Harald Anlauf PR fortran/91496 * gfortran.h: Extend struct gfc_iterator for loop annotations. * array.c (gfc_copy_iterator): Copy loop annotations by IVDEP, VECTOR, and NOVECTOR pragmas. * decl.c (gfc_match_gcc_ivdep, gfc_match_gcc_vector) (gfc_match_gcc_novector): New matcher functions handling IVDEP, VECTOR, and NOVECTOR pragmas. * match.h: Declare prototypes of matcher functions handling IVDEP, VECTOR, and NOVECTOR pragmas. * parse.c (decode_gcc_attribute, parse_do_block) (parse_executable): Decode IVDEP, VECTOR, and NOVECTOR pragmas; emit warning for unrecognized pragmas instead of error. * trans-stmt.c (gfc_trans_simple_do, gfc_trans_do): Add code to emit annotations for IVDEP, VECTOR, and NOVECTOR pragmas. * gfortran.texi: Document IVDEP, VECTOR, and NOVECTOR pragmas. PR fortran/91496 * gfortran.dg/pr91496.f90: New testcase. Added: trunk/gcc/testsuite/gfortran.dg/pr91496.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/array.c trunk/gcc/fortran/decl.c trunk/gcc/fortran/gfortran.h trunk/gcc/fortran/gfortran.texi trunk/gcc/fortran/match.h trunk/gcc/fortran/parse.c trunk/gcc/fortran/trans-stmt.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #14 from anlauf at gcc dot gnu.org --- The current solution is a bit annoying for implicitly-derived interfaces. Consider a code like: module foo implicit none type t1 integer :: i = 1 end type t1 type t2 integer :: j = 2 end type t2 contains subroutine s1 (x) type(t1) :: x call my_mpi_bcast_wrapper (x, storage_size (x)/8) end subroutine s1 subroutine s2 (y) type(t2) :: y call my_mpi_bcast_wrapper (y, storage_size (y)/8) end subroutine s2 end module foo That's perfectly legal, but gets rejected unless -fallow-argument-mismatch is specified. But then I still get a warning (or many if this appears in a large module). I know that there is a (quite clumsy) solution to the above by providing many dummy interfaces, just to defeat the checking. I would like to see an error only for explicit interfaces. But e.g. for packages like MPI, where the mpi_* routines can handle different argument types, and where by default one doesn't need (or want) an explicit interface, I'd hope that that the checks could be downgraded.
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 --- Comment #16 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #15) > On Thu, Aug 29, 2019 at 06:49:15PM +0000, anlauf at gcc dot gnu.org wrote: > > module foo > > implicit none > > type t1 > > integer :: i = 1 > > end type t1 > > type t2 > > integer :: j = 2 > > end type t2 > > contains > > subroutine s1 (x) > > type(t1) :: x > > call my_mpi_bcast_wrapper (x, storage_size (x)/8) > > end subroutine s1 > > subroutine s2 (y) > > type(t2) :: y > > call my_mpi_bcast_wrapper (y, storage_size (y)/8) > > end subroutine s2 > > end module foo > > > > That's perfectly legal, but gets rejected unless -fallow-argument-mismatch > > is specified. But then I still get a warning (or many if this appears in > > a large module). > > You can get rid of the warning with -w. That would get rid of all warnings.
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 --- Comment #19 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #18) > (In reply to anlauf from comment #14) > > The current solution is a bit annoying for implicitly-derived interfaces. > > > > Consider a code like: > > > > module foo > > implicit none > > type t1 > > integer :: i = 1 > > end type t1 > > type t2 > > integer :: j = 2 > > end type t2 > > contains > > subroutine s1 (x) > > type(t1) :: x > > call my_mpi_bcast_wrapper (x, storage_size (x)/8) > > end subroutine s1 > > subroutine s2 (y) > > type(t2) :: y > > call my_mpi_bcast_wrapper (y, storage_size (y)/8) > > end subroutine s2 > > end module foo > > > > That's perfectly legal, > > This is illegal, as far as I know. The type names are different, > which makes them different types. Of course the types are different - that's the point! The above is an attempt to extract a self-contained example demonstrating what does happen in real-world codes using MPI. You can convert it to the real thing yourself (see e.g. man mpi_bcast). What I wanted to say: in many codes using MPI, the 'buffer' argument of MPI_* can be of any type or kind, provided the other arguments are appropriately set. There is no explicit interface - the library routines may not even be written in Fortran - and there cannot be any reasonable inference from an implicit interface. Using this to generate an error *by default* is not a good idea. The same problem shows up for me in parts of the code using direct calls to BLAS (again, no explicit interfaces), or to NetCDF. I guess this is similar to the issues people reported for the SPEC codes. The recommendation to use -fallow-argument-mismatch to downgrade this to a warning (not silence it!) does not really solve the issue: the signal-to-noise ratio of gfortran warnings has become close to useless. (Just ask colleagues whether they pay attention to warnings.) And do you really want users to add -w to the list of options? If you think about it, you might conclude that this will do gfortran a poor service. I'll stop ranting now.
[Bug fortran/91556] Problems with better interface checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91556 --- Comment #23 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #22) > A problem with such code is that type violations like that are likely to > cause > actual wrong code issues because much of the aliasing analysis is type > based... > > What I could do is to > > a) restrict the number of warnings for each routine to one (put a flag >Into the gsym) > > b) try to figure something out to make this harmless to the middle end... > like >passing a void* instead of a reference. I do see that there was a motivation for the change. However, I think that the resolution happens at the wrong time and comes to wrong conclusions. The example in comment#14 compiles if I add e.g. interface subroutine my_mpi_bcast_wrapper (buffer, len) type(*), dimension(..) :: buffer integer, intent(in):: len end subroutine my_mpi_bcast_wrapper end interface which I think is the appropriate explicit interface *if* it needs to be explicitly given. Then the code compiles without any warnings. > If we just continue to ignore this error, is is going to bite people sooner > or > later. And wehn somevody finds that a complex MPI code no longer works, I > want > to have that warning in the build log. A warning by default would be fine with me, especially when it can be turned off. I am not happy to make this an error. (I may have a different opinion for a varying number of arguments to a procedure.) > Also, this sort of code is a major obstacle for LTO, If we do not fix this, > then > I might as well give up on making gfortran LTO clean. Is the current treatment only necessary for LTO? How does LTO handle TYPE(*) etc.? It has to be able to deal with it! Otherwise, can procedures without explicit interfaces be marked that they are not eligible to this kind of optimization?
[Bug fortran/91641] [9/10 Regression] ICE in gfc_conv_is_contiguous_expr, at fortran/trans-intrinsic.c:2857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91641 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Last reconfirmed||2019-9-2 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Not really a regression as IS_CONTIGUOUS was added in 9.0
[Bug fortran/91641] [9/10 Regression] ICE in gfc_conv_is_contiguous_expr, at fortran/trans-intrinsic.c:2857
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91641 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1
[Bug fortran/91496] !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 --- Comment #5 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Thu Sep 5 20:13:00 2019 New Revision: 275442 URL: https://gcc.gnu.org/viewcvs?rev=275442&root=gcc&view=rev Log: 2019-09-05 Harald Anlauf PR fortran/91496 * parse.c (parse_executable): Improve error messages for improperly placed pragmas not preceeding a loop. PR fortran/91496 * gfortran.dg/directive_unroll_5.f90: Adjust error message. Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/parse.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/directive_unroll_5.f90
[Bug fortran/91496] !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Thu Sep 5 21:02:44 2019 New Revision: 275445 URL: https://gcc.gnu.org/viewcvs?rev=275445&root=gcc&view=rev Log: 2019-09-05 Harald Anlauf Backport from mainline PR fortran/91496 * gfortran.h: Extend struct gfc_iterator for loop annotations. * array.c (gfc_copy_iterator): Copy loop annotations by IVDEP, VECTOR, and NOVECTOR pragmas. * decl.c (gfc_match_gcc_ivdep, gfc_match_gcc_vector) (gfc_match_gcc_novector): New matcher functions handling IVDEP, VECTOR, and NOVECTOR pragmas. * match.h: Declare prototypes of matcher functions handling IVDEP, VECTOR, and NOVECTOR pragmas. * parse.c (decode_gcc_attribute, parse_do_block) (parse_executable): Decode IVDEP, VECTOR, and NOVECTOR pragmas; emit warning for unrecognized pragmas instead of error. * trans-stmt.c (gfc_trans_simple_do, gfc_trans_do): Add code to emit annotations for IVDEP, VECTOR, and NOVECTOR pragmas. * gfortran.texi: Document IVDEP, VECTOR, and NOVECTOR pragmas. PR fortran/91496 * parse.c (parse_executable): Improve error messages for improperly placed pragmas not preceeding a loop. PR fortran/91496 * gfortran.dg/pr91496.f90: New testcase. PR fortran/91496 * gfortran.dg/directive_unroll_5.f90: Adjust error message. Added: branches/gcc-9-branch/gcc/testsuite/gfortran.dg/pr91496.f90 Modified: branches/gcc-9-branch/gcc/fortran/ChangeLog branches/gcc-9-branch/gcc/fortran/array.c branches/gcc-9-branch/gcc/fortran/decl.c branches/gcc-9-branch/gcc/fortran/gfortran.h branches/gcc-9-branch/gcc/fortran/gfortran.texi branches/gcc-9-branch/gcc/fortran/match.h branches/gcc-9-branch/gcc/fortran/parse.c branches/gcc-9-branch/gcc/fortran/trans-stmt.c branches/gcc-9-branch/gcc/testsuite/ChangeLog branches/gcc-9-branch/gcc/testsuite/gfortran.dg/directive_unroll_5.f90
[Bug fortran/91496] !GCC$ directives error if mistyped or unknown
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91496 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |9.3 --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on trunk and 9-branch. The diagnostic message emitted if a pragma does not precede a loop has been adjusted as discussed on the gfortran mailing list. Thanks for the report!
[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91668 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Last reconfirmed||2019-09-06 CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. All tested versions since at least 4.3 show the leak.
[Bug fortran/91668] Failure to deallocate ALLOCATABLE component of a type in a POINTER array of types on deallocation of POINTER array
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91668 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #2) > Is this actually required? My feeling would be that is is not, but I may > well be mistaken. > > Does somebody have chapter & verse on this? And what do other compilers do? NAG, Intel & Cray do not leak according to valgrind. NAG also gives a nice runtime memory trace with -mtrace. I think the following applies: F2018 DIS: 9.7.3.2 Deallocation of allocatable variables 8 When a variable of derived type is deallocated, any allocated allocatable subobject is deallocated. [...] I do not see any mentioning to whether "variable" is ALLOCATABLE or POINTER here.
[Bug fortran/92072] New: [10 Regression] ICE on include from other directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92072 Bug ID: 92072 Summary: [10 Regression] ICE on include from other directory Product: gcc Version: unknown Status: UNCONFIRMED Severity: normal Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- The following ICE appears to be a recent regression: % cat bug.f90 module bug implicit none public include 'inc1.f90' end module bug % cat otherdir/inc1.f90 character*1 c gcc-10 svn rev. 276902. % gfc-10 -c bug.f90 -I otherdir 0x17941f5 linemap_position_for_loc_and_offset(line_maps*, unsigned int, unsigned int) ../../trunk/libcpp/line-map.c:930 0x653ce2 gfc_format_decoder ../../trunk/gcc/fortran/error.c:981 0x176cb00 pp_format(pretty_printer*, text_info*) ../../trunk/gcc/pretty-print.c:1391 0x1756d05 diagnostic_report_diagnostic(diagnostic_context*, diagnostic_info*) ../../trunk/gcc/diagnostic.c:1057 0x653e59 gfc_report_diagnostic ../../trunk/gcc/fortran/error.c:782 0x653f65 gfc_error_opt ../../trunk/gcc/fortran/error.c:1351 0x655450 gfc_error(char const*, ...) ../../trunk/gcc/fortran/error.c:1380 0x6b72f8 gfc_match_rvalue(gfc_expr**) ../../trunk/gcc/fortran/primary.c:3586 0x68d32e match_primary ../../trunk/gcc/fortran/matchexp.c:157 0x68d32e match_level_1 ../../trunk/gcc/fortran/matchexp.c:211 0x68d32e match_mult_operand ../../trunk/gcc/fortran/matchexp.c:267 0x68d578 match_add_operand ../../trunk/gcc/fortran/matchexp.c:356 0x68d7cc match_level_2 ../../trunk/gcc/fortran/matchexp.c:480 0x68d922 match_level_3 ../../trunk/gcc/fortran/matchexp.c:551 0x68da14 match_level_4 ../../trunk/gcc/fortran/matchexp.c:599 0x68da14 match_and_operand ../../trunk/gcc/fortran/matchexp.c:693 0x68dc02 match_or_operand ../../trunk/gcc/fortran/matchexp.c:722 0x68dcd2 match_equiv_operand ../../trunk/gcc/fortran/matchexp.c:765 0x68dda4 match_level_5 ../../trunk/gcc/fortran/matchexp.c:811 0x68d181 gfc_match_expr(gfc_expr**) ../../trunk/gcc/fortran/matchexp.c:870 Works with gcc-9 and earlier.
[Bug fortran/92072] [10 Regression] ICE on include from other directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92072 --- Comment #1 from anlauf at gcc dot gnu.org --- The ICE disappears if the include line and the PUBLIC declaration are interchanged.
[Bug fortran/92072] [10 Regression] ICE on include from other directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92072 --- Comment #2 from anlauf at gcc dot gnu.org --- The ICE also disappears if an empty line is added between the PUBLIC statement and the INCLUDE.
[Bug fortran/92072] [10 Regression] ICE on include from other directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92072 --- Comment #3 from anlauf at gcc dot gnu.org --- The ICE also disappears if the include file starts with an empty line.
[Bug fortran/92072] [10 Regression] ICE on include from other directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92072 --- Comment #4 from anlauf at gcc dot gnu.org --- Also adding a blank or a comment after the public makes the ICE go away.
[Bug fortran/92072] [10 Regression] ICE on include from other directory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92072 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||burnus at gcc dot gnu.org --- Comment #5 from anlauf at gcc dot gnu.org --- Bisection points to the possible 'culprit': r276567 | burnus | 2019-10-04 11:29:31 +0200 (Fr, 04. Okt 2019) | 9 Zeilen [Fortran] Fix column of %C diagnostic location gcc/fortran/ * error (error_print, gfc_format_decoder): Fix off-by one issue with %C. Adding Tobias to CC.
[Bug fortran/92091] New: Inconsistent diagnostics for INCLUDE vs. #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92091 Bug ID: 92091 Summary: Inconsistent diagnostics for INCLUDE vs. #include Product: gcc Version: 10.0 Status: UNCONFIRMED Severity: enhancement Priority: P3 Component: fortran Assignee: unassigned at gcc dot gnu.org Reporter: anlauf at gcc dot gnu.org Target Milestone: --- For files included via INCLUDE, the diagnostics printed may be incomplete when the included file resides in a different directory. There is no problem when using #include. Reproducer: % cat bug.f90 module bug implicit none public include 'inc1.f90' include 'inc2.f90' end module bug # cat bug.F90 module bug implicit none public #include "inc1.f90" #include "inc2.f90" end module bug % cat otherdir/inc1.f90 character*1 c % cat inc2.f90 character*2 d Using e.g. svn rev.276967, I get: % gfc-10 -c bug.f90 -Iotherdir -std=f2008 inc1.f90:1:14: Warning: Obsolescent feature: Old-style character length at (1) inc2.f90:1:14: 1 | character*2 d | 1 Warning: Obsolescent feature: Old-style character length at (1) % gfc-10 -c bug.F90 -Iotherdir -std=f2008 otherdir/inc1.f90:1:14: 1 | character*1 c | 1 Warning: Obsolescent feature: Old-style character length at (1) inc2.f90:1:14: 1 | character*2 d | 1 Warning: Obsolescent feature: Old-style character length at (1) Note that the diagnostics for inc1.f90 is incomplete for INCLUDE. Also, the filename does not show the full path in that case. Not sure if this is relevant to the issue. This affects all gcc versions down to at least 7.x, so no regression.
[Bug fortran/92091] Inconsistent diagnostics for INCLUDE vs. #include
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92091 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P5 Known to fail||10.0, 7.4.1, 8.3.1, 9.2.1
[Bug fortran/87752] ICE in omp_add_variable, at gimplify.c:6776
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87752 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Compiles for me with 10-trunk rev.277008. Fixed?
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 --- Comment #13 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Feb 9 17:25:23 2019 New Revision: 268726 URL: https://gcc.gnu.org/viewcvs?rev=268726&root=gcc&view=rev Log: 2019-02-09 Harald Anlauf PR fortran/89077 * resolve.c (gfc_resolve_substring_charlen): Check substring length for constantness prior to general calculation of length. PR fortran/89077 * gfortran.dg/substr_simplify.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/substr_simplify.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 --- Comment #14 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Feb 10 20:01:15 2019 New Revision: 268752 URL: https://gcc.gnu.org/viewcvs?rev=268752&root=gcc&view=rev Log: 2019-02-10 Harald Anlauf Backport from trunk PR fortran/89077 * decl.c (add_init_expr_to_sym): Copy length of string initializer to declared symbol. PR fortran/89077 * gfortran.dg/pr89077.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89077.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/decl.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 --- Comment #15 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Feb 10 20:05:34 2019 New Revision: 268753 URL: https://gcc.gnu.org/viewcvs?rev=268753&root=gcc&view=rev Log: 2019-02-10 Harald Anlauf Backport from trunk PR fortran/89077 * decl.c (add_init_expr_to_sym): Copy length of string initializer to declared symbol. PR fortran/89077 * gfortran.dg/pr89077.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr89077.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/decl.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/88248] [F18] Bogus warning about obsolescent feature: Labeled DO statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88248 --- Comment #8 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Thu Feb 14 20:24:54 2019 New Revision: 268895 URL: https://gcc.gnu.org/viewcvs?rev=268895&root=gcc&view=rev Log: 2019-02-14 Harald Anlauf PR fortran/88248 * symbol.c: Move check for labeled DO statement from gfc_define_st_label to gfc_reference_st_label. PR fortran/88248 * gfortran.dg/pr88248.f90: New test. * gfortran.dg/f2018_obs.f90: Updated test. Added: trunk/gcc/testsuite/gfortran.dg/pr88248.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/f2018_obs.f90
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 --- Comment #18 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Feb 17 21:14:14 2019 New Revision: 268973 URL: https://gcc.gnu.org/viewcvs?rev=268973&root=gcc&view=rev Log: 2019-02-17 Harald Anlauf PR fortran/89077 * decl.c (gfc_set_constant_character_len): Clear original string representation after padding has been performed to target length. PR fortran/89077 * gfortran.dg/transfer_simplify_12.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_simplify_12.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/decl.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88299] [F18] COMMON in a legacy module produces bogus warnings in dependent code
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88299 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Feb 17 21:19:20 2019 New Revision: 268974 URL: https://gcc.gnu.org/viewcvs?rev=268974&root=gcc&view=rev Log: 2019-02-17 Harald Anlauf PR fortran/88299 * resolve.c (resolve_common_blocks,resolve_common_vars): Move check for obsolent COMMON feature in F2018 to better place. PR fortran/88299 * gfortran.dg/pr88299.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88299.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/resolve.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/83057] OPEN without a filename and without STATUS='SCRATCH' could produce a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83057 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Fri Feb 22 20:35:38 2019 New Revision: 269134 URL: https://gcc.gnu.org/viewcvs?rev=269134&root=gcc&view=rev Log: 2019-02-22 Harald Anlauf PR fortran/83057 * io.c (gfc_match_open): Fix logic in checks of OPEN statement when NEWUNIT= is specified. PR fortran/83057 * gfortran.dg/newunit_6.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/newunit_6.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/io.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/88326] [7/8/9 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Feb 24 20:03:28 2019 New Revision: 269177 URL: https://gcc.gnu.org/viewcvs?rev=269177&root=gcc&view=rev Log: 2019-02-24 Harald Anlauf PR fortran/89266 PR fortran/88326 * target-memory.c (gfc_element_size): Return false if element size cannot be determined; element size is returned separately. (gfc_target_expr_size): Return false if expression size cannot be determined; expression size is returned separately. * target-memory.h: Adjust prototypes. * check.c (gfc_calculate_transfer_sizes): Adjust references to gfc_target_expr_size, gfc_element_size. * arith.c (hollerith2representation): Likewise. * class.c (find_intrinsic_vtab): Likewise. * simplify.c (gfc_simplify_sizeof): Likewise. PR fortran/89266 PR fortran/88326 * gfortran.dg/pr89266.f90: New test. * gfortran.dg/pr88326.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88326.f90 trunk/gcc/testsuite/gfortran.dg/pr89266.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/check.c trunk/gcc/fortran/class.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/89266] ICE with TRANSFER of len=0 character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266 --- Comment #11 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Feb 24 20:03:28 2019 New Revision: 269177 URL: https://gcc.gnu.org/viewcvs?rev=269177&root=gcc&view=rev Log: 2019-02-24 Harald Anlauf PR fortran/89266 PR fortran/88326 * target-memory.c (gfc_element_size): Return false if element size cannot be determined; element size is returned separately. (gfc_target_expr_size): Return false if expression size cannot be determined; expression size is returned separately. * target-memory.h: Adjust prototypes. * check.c (gfc_calculate_transfer_sizes): Adjust references to gfc_target_expr_size, gfc_element_size. * arith.c (hollerith2representation): Likewise. * class.c (find_intrinsic_vtab): Likewise. * simplify.c (gfc_simplify_sizeof): Likewise. PR fortran/89266 PR fortran/88326 * gfortran.dg/pr89266.f90: New test. * gfortran.dg/pr88326.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr88326.f90 trunk/gcc/testsuite/gfortran.dg/pr89266.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/arith.c trunk/gcc/fortran/check.c trunk/gcc/fortran/class.c trunk/gcc/fortran/simplify.c trunk/gcc/fortran/target-memory.c trunk/gcc/fortran/target-memory.h trunk/gcc/testsuite/ChangeLog
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 --- Comment #5 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Tue Feb 26 20:03:08 2019 New Revision: 269227 URL: https://gcc.gnu.org/viewcvs?rev=269227&root=gcc&view=rev Log: 2019-02-26 Harald Anlauf PR fortran/89492 * check.c (gfc_calculate_transfer_sizes): Handle cases where storage size of elements of MOLD is 0. PR fortran/89492 * gfortran.dg/pr89492.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr89492.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/57553] [F08] Valid use of STORAGE_SIZE rejected, bad error message for invalid use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=57553 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/83057] OPEN without a filename and without STATUS='SCRATCH' could produce a warning
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83057 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- The case with NEWUNIT= has been fixed. I do not see a need to give a warning for open(20) except for e.g. -pedantic, but if you feel differently, please reopen.
[Bug fortran/89516] ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89516
--- Comment #2 from anlauf at gcc dot gnu.org ---
The ICE is triggered by a code path that is executed only when -Wsurprising
is used together with TRANSFER.
I'm currently testing the following patch:
Index: gcc/fortran/check.c
===
--- gcc/fortran/check.c (revision 269227)
+++ gcc/fortran/check.c (working copy)
@@ -5503,7 +5503,8 @@
if (result_elt_size == 0 && *source_size == 0 && !size)
{
*result_size = 0;
- *result_length_p = 0;
+ if (result_length_p)
+ *result_length_p = 0;
return true;
}
Will commit as obvious if it finishes successfully.
[Bug fortran/89516] ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89516 --- Comment #3 from anlauf at gcc dot gnu.org --- The patch turned out to require a small adjustment for scalar MOLD of size 0, so I posted it for review: https://gcc.gnu.org/ml/fortran/2019-02/msg00237.html
[Bug fortran/87751] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:10255
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87751 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING Known to fail||7.3.1, 8.2.1 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to G. Steinmetz from comment #2) > Changed in gcc-9 between 2018 (ICE) and 20181118 (ok=error), > presumably due to pr70260. > > > $ gfortran-9-20181125 -c z1.f90 > z1.f90:8:3: > > 8 |g = 1 > | 1 > Error: Illegal assignment to external procedure at (1) So resolved on trunk?
[Bug fortran/60576] [7/8/9 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 --- Comment #28 from anlauf at gcc dot gnu.org --- Is this still an issue? On x86_64-pc-linux-gnu and with current trunk, I do only get a memory leak with -fsanitize=address (both -m32 and -m64), which disappears if I deallocate the arrays at the end.
[Bug fortran/84868] [7/8/9 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Works also if len_trim is replaced by len. I wonder if this is related to PR86249.
[Bug fortran/84868] [7/8/9 Regression] ICE in gfc_conv_descriptor_offset, at fortran/trans-array.c:208
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84868 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #3) > Works also if len_trim is replaced by len. > > I wonder if this is related to PR86249. Sorry, off-by-one, that should have been PR86248. Also the date given in comment #0 points to rev. 243478 or nearby.
[Bug fortran/67894] bounds of assumed-rank dummy argument not equal to actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67894 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- For an analysis of how the code shall behave, see PR89365, especially Reinhold's quote of F2018 (PR89365 comment #3). IMHO this PR is invalid.
[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to kargl from comment #4)
> (In reply to Manuel López-Ibáñez from comment #2)
> > check_conflict is sometimes called with name = NULL and that is passed to
> > %qs causing a crash.
>
> Index: symbol.c
> ===
> --- symbol.c (revision 240140)
> +++ symbol.c (working copy)
> @@ -473,8 +473,8 @@ check_conflict (symbol_attribute *attr,
> }
> }
>
> - if (attr->dummy && ((attr->function || attr->subroutine) &&
> - gfc_current_state () == COMP_CONTAINS))
> + if (name && attr->dummy && ((attr->function || attr->subroutine)
> + && gfc_current_state () == COMP_CONTAINS))
> gfc_error_now ("internal procedure %qs at %L conflicts with "
> "DUMMY argument", name, where);
The additional check on 'name' basically applies on current trunk and
fixes the ICE.
Are you still pursuing this?
[Bug fortran/89516] ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89516 --- Comment #5 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Mar 2 15:29:27 2019 New Revision: 269341 URL: https://gcc.gnu.org/viewcvs?rev=269341&root=gcc&view=rev Log: 2019-03-02 Harald Anlauf PR fortran/89516 * check.c (gfc_calculate_transfer_sizes): Correct checks for cases where storage size of elements of MOLD is 0. PR fortran/89516 * gfortran.dg/pr89492.f90: Adjust testcase. * gfortran.dg/transfer_check_5.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/transfer_check_5.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/check.c trunk/gcc/testsuite/ChangeLog trunk/gcc/testsuite/gfortran.dg/pr89492.f90
[Bug fortran/88326] [7/8/9 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326 --- Comment #7 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Mar 2 16:08:03 2019 New Revision: 269342 URL: https://gcc.gnu.org/viewcvs?rev=269342&root=gcc&view=rev Log: 2019-03-02 Harald Anlauf Backport from trunk PR fortran/89516 * check.c (gfc_calculate_transfer_sizes): Correct checks for cases where storage size of elements of MOLD is 0. PR fortran/89492 * check.c (gfc_calculate_transfer_sizes): Handle cases where storage size of elements of MOLD is 0. PR fortran/89266 PR fortran/88326 * target-memory.c (gfc_element_size): Return false if element size cannot be determined; element size is returned separately. (gfc_target_expr_size): Return false if expression size cannot be determined; expression size is returned separately. * target-memory.h: Adjust prototypes. * check.c (gfc_calculate_transfer_sizes): Adjust references to gfc_target_expr_size, gfc_element_size. * arith.c (hollerith2representation): Likewise. * class.c (find_intrinsic_vtab): Likewise. * simplify.c (gfc_simplify_sizeof): Likewise. Backport from trunk PR fortran/89516 * gfortran.dg/pr89492.f90: Adjust testcase. * gfortran.dg/transfer_check_5.f90: New test. PR fortran/89492 * gfortran.dg/pr89492.f90: New test. PR fortran/89266 PR fortran/88326 * gfortran.dg/pr89266.f90: New test. * gfortran.dg/pr88326.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88326.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89266.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89492.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/transfer_check_5.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/arith.c branches/gcc-8-branch/gcc/fortran/check.c branches/gcc-8-branch/gcc/fortran/class.c branches/gcc-8-branch/gcc/fortran/simplify.c branches/gcc-8-branch/gcc/fortran/target-memory.c branches/gcc-8-branch/gcc/fortran/target-memory.h branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/89516] ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89516 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Mar 2 16:08:03 2019 New Revision: 269342 URL: https://gcc.gnu.org/viewcvs?rev=269342&root=gcc&view=rev Log: 2019-03-02 Harald Anlauf Backport from trunk PR fortran/89516 * check.c (gfc_calculate_transfer_sizes): Correct checks for cases where storage size of elements of MOLD is 0. PR fortran/89492 * check.c (gfc_calculate_transfer_sizes): Handle cases where storage size of elements of MOLD is 0. PR fortran/89266 PR fortran/88326 * target-memory.c (gfc_element_size): Return false if element size cannot be determined; element size is returned separately. (gfc_target_expr_size): Return false if expression size cannot be determined; expression size is returned separately. * target-memory.h: Adjust prototypes. * check.c (gfc_calculate_transfer_sizes): Adjust references to gfc_target_expr_size, gfc_element_size. * arith.c (hollerith2representation): Likewise. * class.c (find_intrinsic_vtab): Likewise. * simplify.c (gfc_simplify_sizeof): Likewise. Backport from trunk PR fortran/89516 * gfortran.dg/pr89492.f90: Adjust testcase. * gfortran.dg/transfer_check_5.f90: New test. PR fortran/89492 * gfortran.dg/pr89492.f90: New test. PR fortran/89266 PR fortran/88326 * gfortran.dg/pr89266.f90: New test. * gfortran.dg/pr88326.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88326.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89266.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89492.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/transfer_check_5.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/arith.c branches/gcc-8-branch/gcc/fortran/check.c branches/gcc-8-branch/gcc/fortran/class.c branches/gcc-8-branch/gcc/fortran/simplify.c branches/gcc-8-branch/gcc/fortran/target-memory.c branches/gcc-8-branch/gcc/fortran/target-memory.h branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 --- Comment #6 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Mar 2 16:08:03 2019 New Revision: 269342 URL: https://gcc.gnu.org/viewcvs?rev=269342&root=gcc&view=rev Log: 2019-03-02 Harald Anlauf Backport from trunk PR fortran/89516 * check.c (gfc_calculate_transfer_sizes): Correct checks for cases where storage size of elements of MOLD is 0. PR fortran/89492 * check.c (gfc_calculate_transfer_sizes): Handle cases where storage size of elements of MOLD is 0. PR fortran/89266 PR fortran/88326 * target-memory.c (gfc_element_size): Return false if element size cannot be determined; element size is returned separately. (gfc_target_expr_size): Return false if expression size cannot be determined; expression size is returned separately. * target-memory.h: Adjust prototypes. * check.c (gfc_calculate_transfer_sizes): Adjust references to gfc_target_expr_size, gfc_element_size. * arith.c (hollerith2representation): Likewise. * class.c (find_intrinsic_vtab): Likewise. * simplify.c (gfc_simplify_sizeof): Likewise. Backport from trunk PR fortran/89516 * gfortran.dg/pr89492.f90: Adjust testcase. * gfortran.dg/transfer_check_5.f90: New test. PR fortran/89492 * gfortran.dg/pr89492.f90: New test. PR fortran/89266 PR fortran/88326 * gfortran.dg/pr89266.f90: New test. * gfortran.dg/pr88326.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88326.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89266.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89492.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/transfer_check_5.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/arith.c branches/gcc-8-branch/gcc/fortran/check.c branches/gcc-8-branch/gcc/fortran/class.c branches/gcc-8-branch/gcc/fortran/simplify.c branches/gcc-8-branch/gcc/fortran/target-memory.c branches/gcc-8-branch/gcc/fortran/target-memory.h branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/89266] ICE with TRANSFER of len=0 character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266 --- Comment #14 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sat Mar 2 16:08:03 2019 New Revision: 269342 URL: https://gcc.gnu.org/viewcvs?rev=269342&root=gcc&view=rev Log: 2019-03-02 Harald Anlauf Backport from trunk PR fortran/89516 * check.c (gfc_calculate_transfer_sizes): Correct checks for cases where storage size of elements of MOLD is 0. PR fortran/89492 * check.c (gfc_calculate_transfer_sizes): Handle cases where storage size of elements of MOLD is 0. PR fortran/89266 PR fortran/88326 * target-memory.c (gfc_element_size): Return false if element size cannot be determined; element size is returned separately. (gfc_target_expr_size): Return false if expression size cannot be determined; expression size is returned separately. * target-memory.h: Adjust prototypes. * check.c (gfc_calculate_transfer_sizes): Adjust references to gfc_target_expr_size, gfc_element_size. * arith.c (hollerith2representation): Likewise. * class.c (find_intrinsic_vtab): Likewise. * simplify.c (gfc_simplify_sizeof): Likewise. Backport from trunk PR fortran/89516 * gfortran.dg/pr89492.f90: Adjust testcase. * gfortran.dg/transfer_check_5.f90: New test. PR fortran/89492 * gfortran.dg/pr89492.f90: New test. PR fortran/89266 PR fortran/88326 * gfortran.dg/pr89266.f90: New test. * gfortran.dg/pr88326.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr88326.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89266.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr89492.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/transfer_check_5.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/arith.c branches/gcc-8-branch/gcc/fortran/check.c branches/gcc-8-branch/gcc/fortran/class.c branches/gcc-8-branch/gcc/fortran/simplify.c branches/gcc-8-branch/gcc/fortran/target-memory.c branches/gcc-8-branch/gcc/fortran/target-memory.h branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583 --- Comment #8 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 3 20:24:53 2019 New Revision: 269353 URL: https://gcc.gnu.org/viewcvs?rev=269353&root=gcc&view=rev Log: 2019-03-03 Harald Anlauf Steven G. Kargl PR fortran/77583 * symbol.c (check_conflict): Check for valid procedure name passed to error reporting routine. PR fortran/77583 * gfortran.dg/pr77583.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr77583.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/symbol.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583 --- Comment #9 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 3 20:30:44 2019 New Revision: 269354 URL: https://gcc.gnu.org/viewcvs?rev=269354&root=gcc&view=rev Log: 2019-03-03 Harald Anlauf Steven G. Kargl Backport from trunk PR fortran/77583 * symbol.c (check_conflict): Check for valid procedure name passed to error reporting routine. PR fortran/77583 * gfortran.dg/pr77583.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/pr77583.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/symbol.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583 --- Comment #10 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 3 20:36:12 2019 New Revision: 269355 URL: https://gcc.gnu.org/viewcvs?rev=269355&root=gcc&view=rev Log: 2019-03-03 Harald Anlauf Steven G. Kargl Backport from trunk PR fortran/77583 * symbol.c (check_conflict): Check for valid procedure name passed to error reporting routine. PR fortran/77583 * gfortran.dg/pr77583.f90: New test. Added: branches/gcc-7-branch/gcc/testsuite/gfortran.dg/pr77583.f90 Modified: branches/gcc-7-branch/gcc/fortran/ChangeLog branches/gcc-7-branch/gcc/fortran/symbol.c branches/gcc-7-branch/gcc/testsuite/ChangeLog
[Bug fortran/77583] ICE in pp_quoted_string, at pretty-print.c:966
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77583 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-invalid-code Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |7.5 --- Comment #11 from anlauf at gcc dot gnu.org --- Fixed on trunk, 8- and 7-branches. Closing.
[Bug fortran/88326] [7 Regression] ICE in gfc_conv_array_initializer, at fortran/trans-array.c:6085
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88326 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on 9-trunk and 8-branch. My backporting attempt of the fix from PR89266 to 7-branch does fix this PR, but still ICEs on the testcase for PR89266. This may be related to the changes for handling of string length, or something else. Given that 7.5 will be the final 7-release, I find it too risky to introduce potential new regressions. If nobody objects, we might close this PR. (Target milestone 8.4?)
[Bug fortran/89492] [9 Regression] Endless compilation of an invalid TRANSFER after r269177
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on 9-trunk and 8-branch.
[Bug fortran/31237] [meta-bug] TRANSFER intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237 Bug 31237 depends on bug 89492, which changed state. Bug 89492 Summary: [9 Regression] Endless compilation of an invalid TRANSFER after r269177 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89492 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/31237] [meta-bug] TRANSFER intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237 Bug 31237 depends on bug 89516, which changed state. Bug 89516 Summary: ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89516 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/89516] ICE in gfc_calculate_transfer_sizes at gcc/fortran/check.c:5506
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89516 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on 9-trunk and 8-branch.
[Bug fortran/89266] ICE with TRANSFER of len=0 character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed on 9-trunk and 8-branch. My backporting attempt of the fix from PR89266 to 7-branch unfortunately does not fix this PR. This may be related to the changes for handling of string length, or something else. (It appears to fix PR88326, though, which was a regression). Given that 7.5 will be the final 7-release, I find it too risky to introduce potential new regressions. If nobody objects, we might close this PR. (Target milestone 8.4?)
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 --- Comment #21 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Sun Mar 3 22:24:00 2019 New Revision: 269357 URL: https://gcc.gnu.org/viewcvs?rev=269357&root=gcc&view=rev Log: 2019-03-03 Harald Anlauf Backport from trunk PR fortran/89077 * decl.c (gfc_set_constant_character_len): Clear original string representation after padding has been performed to target length. * resolve.c (gfc_resolve_substring_charlen): Check substring length for constantness prior to general calculation of length. Backport from trunk PR fortran/89077 * gfortran.dg/transfer_simplify_12.f90: New test. * gfortran.dg/substr_simplify.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/substr_simplify.f90 branches/gcc-8-branch/gcc/testsuite/gfortran.dg/transfer_simplify_12.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/decl.c branches/gcc-8-branch/gcc/fortran/resolve.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/89077] ICE using * as len specifier for character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Target Milestone|--- |8.4 --- Comment #22 from anlauf at gcc dot gnu.org --- Fixed on 9-trunk and 8-branch. Backporting patches parts 2 and 3 to 7-branch may be too risky. So closing.
[Bug fortran/31237] [meta-bug] TRANSFER intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237 Bug 31237 depends on bug 89077, which changed state. Bug 89077 Summary: ICE using * as len specifier for character parameter https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89077 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/31237] [meta-bug] TRANSFER intrinsic
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31237 Bug 31237 depends on bug 89266, which changed state. Bug 89266 Summary: ICE with TRANSFER of len=0 character array constructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/19276] [meta-bug] CHARACTER related bugs in gfortran
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=19276 Bug 19276 depends on bug 89266, which changed state. Bug 89266 Summary: ICE with TRANSFER of len=0 character array constructor https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266 What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED
[Bug fortran/89266] ICE with TRANSFER of len=0 character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89266 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |RESOLVED Resolution|--- |FIXED Target Milestone|--- |8.4 --- Comment #17 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #16) > > Given that 7.5 will be the final 7-release, I find it too risky to > > introduce potential new regressions. If nobody objects, we might > > close this PR. (Target milestone 8.4?) > > Makes sense for me. If someone really needs it in 7.5, (s)he can try the > back port in her/his working tree. OK, so closing.
[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203 --- Comment #10 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Wed Mar 6 21:06:35 2019 New Revision: 269444 URL: https://gcc.gnu.org/viewcvs?rev=269444&root=gcc&view=rev Log: 2019-03-06 Harald Anlauf PR fortran/71203 * expr.c (simplify_const_ref): Avoid null pointer dereference. PR fortran/71203 * gfortran.dg/substr_8.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/substr_8.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203 --- Comment #11 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Wed Mar 6 21:16:00 2019 New Revision: 269445 URL: https://gcc.gnu.org/viewcvs?rev=269445&root=gcc&view=rev Log: 2019-03-06 Harald Anlauf Backport from trunk PR fortran/71203 * expr.c (simplify_const_ref): Avoid null pointer dereference. PR fortran/71203 * gfortran.dg/substr_8.f90: New test. Added: branches/gcc-8-branch/gcc/testsuite/gfortran.dg/substr_8.f90 Modified: branches/gcc-8-branch/gcc/fortran/ChangeLog branches/gcc-8-branch/gcc/fortran/expr.c branches/gcc-8-branch/gcc/testsuite/ChangeLog
[Bug fortran/71203] ICE in add_init_expr_to_sym, at fortran/decl.c:1512 and :1564
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=71203 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #14 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #13) > With the following patch [...] > I get errors such as > > % gfc pr71203_3.f90 > pr71203_3.f90:4:29: > > 4 |integer, parameter :: y(*) = [(x(i:i), i=1,2)] > | 1 > Error: Can't initialize array with unknown shape at (1) Well, the issue is with the implied do loop in the constructor in conjunction with the array section not generating the proper shape. (The "unrolled" loop does it right.) There are several issues with (nested) array constructors, such as [[ integer :: ]] not getting it right. I'd rather leave the ICE here, as it might encourage debugging... ;-)
[Bug fortran/87045] pointer to array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Patch that moves the check submitted: https://gcc.gnu.org/ml/fortran/2019-03/msg00050.html
[Bug fortran/89462] [7/8/9 Regression] gfortran loops in code generation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89462 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Commenting the line ! CALL ttest3(aTP) it does no longer loop indefinitely, but produce a bogus error: pr89462.f90:2:0: 2 | CHARACTER*1 test2,TR,aTP | Error: size of variable 'tr' is too large The dump tree of this variant looks strange. Maybe the character length is not handled properly.
[Bug fortran/67123] ICE with source allocation
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67123 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #3 from anlauf at gcc dot gnu.org --- Cannot reproduce the ICE with current 9-trunk or 8-branch. As this is supposedly a duplicate, can it be set to fixed?
[Bug fortran/61261] [OOP] Segfault on source-allocating polymorphic variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=61261 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||anlauf at gcc dot gnu.org --- Comment #9 from anlauf at gcc dot gnu.org --- AFAICT all related PRs are fixed. Close this one, too?
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- The dump-tree looks funny: it appears that in the last test print *, "Associated contents?", associated(p1%string, p2%string) the association is already evaluated at compile time to .false.
[Bug fortran/87045] pointer to array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045 --- Comment #4 from anlauf at gcc dot gnu.org --- Author: anlauf Date: Wed Mar 13 21:33:27 2019 New Revision: 269664 URL: https://gcc.gnu.org/viewcvs?rev=269664&root=gcc&view=rev Log: 2019-03-13 Harald Anlauf PR fortran/87045 * trans-expr.c (gfc_trans_pointer_assignment): Move check for same string length so that we do not get false errors for deferred length. PR fortran/87045 * gfortran.dg/pr87045.f90: New test. Added: trunk/gcc/testsuite/gfortran.dg/pr87045.f90 Modified: trunk/gcc/fortran/ChangeLog trunk/gcc/fortran/trans-expr.c trunk/gcc/testsuite/ChangeLog
[Bug fortran/87045] pointer to array of character
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87045 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on trunk.
[Bug fortran/67740] Wrong association status of allocatable character pointer in derived types
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67740 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #2) > The dump-tree looks funny: it appears that in the last test > > print *, "Associated contents?", associated(p1%string, p2%string) > > the association is already evaluated at compile time to .false. I do not understand the following code in trans-intrinsic.c, which may be part of the underlying cause: 8426 nonzero_charlen = NULL_TREE; 8427 if (arg1->expr->ts.type == BT_CHARACTER) 8428nonzero_charlen = fold_build2_loc (input_location, NE_EXPR, 8429 logical_type_node, 8430 arg1->expr->ts.u.cl->backend_decl, 8431 build_zero_cst 8432 (TREE_TYPE (arg1->expr->ts.u.cl->backend_decl))); and 8500 /* If target is present zero character length pointers cannot 8501 be associated. */ 8502 if (nonzero_charlen != NULL_TREE) 8503se->expr = fold_build2_loc (input_location, TRUTH_AND_EXPR, 8504logical_type_node, 8505se->expr, nonzero_charlen);
