[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 --- Comment #6 from anlauf at gcc dot gnu.org --- The commit in comment#4 unfortunately contained debugging stuff that should never have been pushed. Thus reverted and created the new commit in comment#5. Sorry for that.
[Bug fortran/93340] [8/9/10/11 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93340 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from anlauf at gcc dot gnu.org --- Should be fixed on master.
[Bug libgomp/98699] Reset OMP_NESTED to true if OMP_MAX_ACTIVE_LEVELS is > 1.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98699 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |libgomp Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Keywords||openmp CC||jakub at gcc dot gnu.org Last reconfirmed||2021-01-15 --- Comment #1 from anlauf at gcc dot gnu.org --- Isn't this a general OpenMP issue rather than Fortran? It would help to provide a C testcase too to resolve this. I've moved this to libgomp.
[Bug fortran/98661] Valgrind errors during error recovery of invalid derived type declarations
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #7 from anlauf at gcc dot gnu.org --- Closing.
[Bug other/86656] [meta-bug] Issues found with -fsanitize=address
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86656 Bug 86656 depends on bug 98661, which changed state. Bug 98661 Summary: Valgrind errors during error recovery of invalid derived type declarations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/89891] [meta-bug] Accessing memory in rejected statements or expressions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89891 Bug 89891 depends on bug 98661, which changed state. Bug 98661 Summary: Valgrind errors during error recovery of invalid derived type declarations https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98661 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/88124] Wrong results with procedure in seperate file
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88124 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||anlauf at gcc dot gnu.org --- Comment #11 from anlauf at gcc dot gnu.org --- I tried the appended code with main and sub split into 2 .F files, and with the flags given in the mail to the ML, but can NOT reproduce the issue with the following compiler versions: (Debian 6.3.0-18+deb9u1) 6.3.0 20170516 (SUSE Linux) 7.5.0 (SUSE Linux) 10.2.1 7.2.0 8.4.1 9.3.1 10.2.1 11 (HEAD) So can we assume that this has been fixed (accidentally) in the meantime?
[Bug fortran/91782] Accepts invalid array constructor with character parameter
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91782 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 --- I am now getting the following results for the testcase in comment#0: gfortran 8.4.1, 9.3.1: aaa aaa aaa 97 97 97 1 1 1 10.2.1 as of 20210116: pr91782-z1.f90:7:20: 7 | print *, ichar(([(x(1:i), i=1,3)])) |1 Error: Argument of ICHAR at (1) must be of length one pr91782-z1.f90:7:20: 7 | print *, ichar(([(x(1:i), i=1,3)])) |1 Error: Argument of ICHAR at (1) must be of length one 11 trunk: pr91782-z1.f90:4:23: 4 | print *, ['abc'(1:1), 'abc'(1:2), 'abc'(1:3)] | 1 Error: Different CHARACTER lengths (1/2) in array constructor at (1) pr91782-z1.f90:7:20: 7 | print *, ichar(([(x(1:i), i=1,3)])) |1 Error: Argument of ICHAR at (1) must be of length one pr91782-z1.f90:7:20: 7 | print *, ichar(([(x(1:i), i=1,3)])) |1 Error: Argument of ICHAR at (1) must be of length one I think the new error for line 4 is a consequence of the patch applied for pr93340. What is left is apparently the following issue: program p integer :: i character(3), parameter :: x = 'abc' print *, [x(1:1), x(1:2), x(1:3)] print *, [(x(1:i), i=1,3)] ! this one gives no warning end which prints: aaa aaa but it is rejected with -std=f2018: pr91782-z1.f90:4:19: 4 | print *, [x(1:1), x(1:2), x(1:3)] | 1 Error: The CHARACTER elements of the array constructor at (1) must have the same length (2/1) pr91782-z1.f90:4:27: 4 | print *, [x(1:1), x(1:2), x(1:3)] | 1 Error: The CHARACTER elements of the array constructor at (1) must have the same length (3/1)
[Bug fortran/91640] [9 Regression] ICE: gimplification failed (contiguous expr)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91640 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Backported to 9-branch (needed only adjustment of commit message from SVN to git) and regtested on x86_64-pc-linux-gnu. Closing.
[Bug fortran/85547] Run-time error: character array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85547
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #6 from anlauf at gcc dot gnu.org ---
The trim() and string concatenation are not even needed to see the string
length getting lost.
Example:
program p
implicit none
character(10) :: path = 'xyz/'
print *, len ( [ character(16) :: path ] ) ! ok
call print_string ( [ character(16) :: path ] ) ! typespec lost
contains
subroutine print_string (s)
character(*), intent(in) :: s(:)
print *, len(s), len(s)==16
end subroutine
end program
prints:
16
10 F
Inspection of the tree-dump shows that the temporary creation for the
subroutine call looks like we initially have the proper string length
after the array constructor
atmp.6.dtype = {.elem_len=16, .rank=1, .type=6};
atmp.6.dim[0].stride = 1;
atmp.6.dim[0].lbound = 0;
atmp.6.dim[0].ubound = 0;
atmp.6.span = 16;
which gets copied to the temporary
atmp.9.dtype = {.elem_len=10, .rank=1, .type=6};
atmp.9.dim[0].stride = 1;
atmp.9.dim[0].lbound = 0;
atmp.9.dim[0].ubound = 0;
atmp.9.span = 10;
I wonder where we get this from.
Besides, we actually create two temporaries in succession instead of just
one...
[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #49687|0 |1 is obsolete|| --- Comment #12 from anlauf at gcc dot gnu.org --- Created attachment 50025 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=50025&action=edit Revised patch, addressing the issue in unix.c Hi Thomas, I've regtested the attached patch. It removes the first (problematic) part of raw_read, and fixes the second part. It seems to regtest fine, BUT: I had one (random?) failure with append_1.f90 which I am unable to reproduce. Looking at the strace output, it appears that there is one additional read(2) with the patch that returns 0. This is reproducible. I have not yet found out why this happens, but then I am probably to blind-sighted. But it fixes the testcase.
[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129 --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #12) > I had one (random?) failure with append_1.f90 which I am unable to reproduce. Likely origin: parallel make -j4 check-fortran and % grep -il open.*[\"\']foo[\'\"] gcc/testsuite/gfortran.dg/ -r gcc/testsuite/gfortran.dg/append_1.f90 gcc/testsuite/gfortran.dg/direct_io_2.f90 gcc/testsuite/gfortran.dg/io_constraints_7.f03 gcc/testsuite/gfortran.dg/large_unit_2.f90 gcc/testsuite/gfortran.dg/open_access_1.f90 gcc/testsuite/gfortran.dg/open_access_append_1.f90 gcc/testsuite/gfortran.dg/open_status_1.f90 gcc/testsuite/gfortran.dg/pr20163-2.f The additional read seen in the strace output comes from the first read attempt on the file which is shorter (169 bytes) that the buffer (8k), so there is another read attempt (returning 0) because of end of file. So that is a feature of the present fix.
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470
--- Comment #7 from anlauf at gcc dot gnu.org ---
Untested patch:
diff --git a/gcc/fortran/trans.c b/gcc/fortran/trans.c
index a2376917635..7699e98f6ea 100644
--- a/gcc/fortran/trans.c
+++ b/gcc/fortran/trans.c
@@ -689,9 +689,14 @@ gfc_call_malloc (stmtblock_t * block, tree type, tree
size)
/* Call malloc. */
gfc_start_block (&block2);
- size = fold_convert (size_type_node, size);
- size = fold_build2_loc (input_location, MAX_EXPR, size_type_node, size,
- build_int_cst (size_type_node, 1));
+ if (size)
+{
+ size = fold_convert (size_type_node, size);
+ size = fold_build2_loc (input_location, MAX_EXPR, size_type_node, size,
+ build_int_cst (size_type_node, 1));
+}
+ else
+size = build_int_cst (size_type_node, 1);
malloc_tree = builtin_decl_explicit (BUILT_IN_MALLOC);
gfc_add_modify (&block2, res,
Not sure if this is correct, but it makes gfc_call_malloc match the comment
preceeding that function.
I'll leave the interpretation to the experts.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to Bill Long from comment #10) > Still fails with 10.2.0. Can you say which release version will include the > fix? According to https://gcc.gnu.org/, gcc 10.2 was released in July 2020. Extrapolating previous schedules, I'd expect 10.3 one year after 9.3, which was released in March 2020. You could check the 10-branch that the fix works for you.
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Keywords||ice-on-invalid-code --- Comment #13 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-January/055628.html
[Bug fortran/70070] ICE on initializing character data beyond min/max bound
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED --- Comment #15 from anlauf at gcc dot gnu.org --- Fixed for gcc-11. Closing. Thanks for the report!
[Bug fortran/33056] [Meta-bug] Data - statement related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=33056 Bug 33056 depends on bug 70070, which changed state. Bug 70070 Summary: ICE on initializing character data beyond min/max bound https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70070 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/70913] ICE in gfc_encode_character, at fortran/target-memory.c:227
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=70913 anlauf at gcc dot gnu.org changed: What|Removed |Added CC|anlauf at gmx dot de | --- Comment #8 from anlauf at gcc dot gnu.org --- Splitting declaration and initialization of b, we get the expected error: program p implicit none character :: a= 'a' character :: b(1) data b(1) / 'b' / equivalence (a, b(1)) end pr70913-c8.f90:6:17: 6 | equivalence (a, b(1)) | 1 Error: Overlapping unequal initializers in EQUIVALENCE at (1) Running under gdb, we seem to enter expr_to_char with exprs for b which look rather different (rank, character length). The real issue is likely elsewhere.
[Bug fortran/87568] Gfortran compile fails with bogus error message.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87568 --- Comment #2 from anlauf at gcc dot gnu.org --- I cannot reproduce the error with r11-6901, but I still see it on 10-branch.
[Bug fortran/91862] [9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2394
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91862 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #5 from anlauf at gcc dot gnu.org --- With r11-6917, I do not get any failures for the testcases in this PR. Actually, z1.f90 works with 7.5.0, 8.4.1, 9.3.1, 10.2.1, and master. z2.f90 works with 9.3.1, 10.2.1, and master. It fails for 8.4.1 and 7.5.0: no ICE, but wrong output. Does anybody know when this was fixed? Close the PR, add a testcase?
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org CC||anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #8 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2021-January/055647.html
[Bug fortran/86470] [8/9/10/11 Regression] [OOP] ICE with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86470 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #13 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/95682] [9/10/11 Regression] Default assignment fails with allocatable array of deferred-length strings
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95682 --- Comment #2 from anlauf at gcc dot gnu.org --- Adding some printout after initializing the t1%x(:), do i = 1, size(t1%x) print *, len_trim (t1%x(i)), t1%x(i) end do I get for gcc-8: 5 three 5 three 5 three and for 9,10,11: 3 one 3 two 5 three That's not a typical regression, but rather wrong code replaced by other wrong code.
[Bug fortran/99111] [10/11 Regression] ICE in gfc_conv_expr_descriptor, at fortran/trans-array.c:7336
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99111
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Priority|P3 |P4
Status|UNCONFIRMED |NEW
Last reconfirmed||2021-02-15
--- Comment #1 from anlauf at gcc dot gnu.org ---
We properly reject this with -std=...
The following checks in io.c might need improvement:
/* If rank is nonzero and type is not character, we allow it under
GFC_STD_LEGACY.
It may be assigned an Hollerith constant. */
if (e->ts.type != BT_CHARACTER)
{
if (!gfc_notify_std (GFC_STD_LEGACY, "Non-character in FORMAT tag "
"at %L", &e->where))
return false;
Since we have e->ts.type == BT_DERIVED in the present case, this could be
straightforward.
[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-02-18 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Priority|P3 |P4 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed using valgrind. Simply reversing the conditions seems to resolve the issue: diff --git a/gcc/fortran/symbol.c b/gcc/fortran/symbol.c index 3b988d1be22..e982374d9d1 100644 --- a/gcc/fortran/symbol.c +++ b/gcc/fortran/symbol.c @@ -1772,8 +1772,8 @@ gfc_add_flavor (symbol_attribute *attr, sym_flavor f, const char *name, /* Copying a procedure dummy argument for a module procedure in a submodule results in the flavor being copied and would result in an error without this. */ - if (gfc_new_block && gfc_new_block->abr_modproc_decl - && attr->flavor == f && f == FL_PROCEDURE) + if (attr->flavor == f && f == FL_PROCEDURE + && gfc_new_block && gfc_new_block->abr_modproc_decl) return true; if (attr->flavor != FL_UNKNOWN)
[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147 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 #2 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-February/055729.html
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to work||8.4.1
Priority|P3 |P4
Summary|Segfault when passing |[9/10/11 Regression]
|allocatable scalar into |Segfault when passing
|intent(out) dummy argument |allocatable scalar into
||intent(out) dummy argument
Ever confirmed|0 |1
Target Milestone|--- |9.4
Keywords||wrong-code
Status|UNCONFIRMED |NEW
Known to fail||10.2.1, 11.0, 9.3.1
Last reconfirmed||2021-02-19
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
The tree dump shows that since at least 9.3.1 we clobber the pointer:
integer(kind=4) * i;
...
i = (integer(kind=4) *) __builtin_malloc (4);
...
i = {CLOBBER};
set_i (i);
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
--- Comment #2 from anlauf at gcc dot gnu.org ---
Note/workaround: the {CLOBBER} disappears if the argument to set_i is declared
INOUT instead of OUT.
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
--- Comment #3 from anlauf at gcc dot gnu.org ---
A conservative solution simply disables the clobber:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 103cb31c664..ce7bfaa89e8 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -6082,6 +6084,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
/* FIXME - PR 87395 and PR 41453 */
&& e->symtree->n.sym->attr.save == SAVE_NONE
&& !e->symtree->n.sym->attr.associate_var
+ && !e->symtree->n.sym->attr.allocatable
&& e->ts.type != BT_CHARACTER && e->ts.type !=
BT_DERIVED
&& e->ts.type != BT_CLASS && !sym->attr.elemental;
This should result only in a missed optimization.
Is there a way to get sth. like:
*i = {CLOBBER};
so that we do not clobber the pointer but the pointer to?
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||tkoenig at gcc dot gnu.org
--- Comment #4 from anlauf at gcc dot gnu.org ---
The following code in trans-expr.c was added by Thomas, so adding him in CC:
else if (add_clobber && expr->ref == NULL)
{
tree clobber;
tree var;
/* FIXME: This fails if var is passed by reference, see PR
41453. */
var = expr->symtree->n.sym->backend_decl;
clobber = build_clobber (TREE_TYPE (var));
gfc_add_modify (&se->pre, var, clobber);
}
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-February/055741.html
[Bug fortran/99147] Sanitizer detects heap-use-after-free in gfc_add_flavor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99147 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11. Closing. Thanks for the report!
[Bug fortran/99204] ICE in fold_read_from_constant_string, at fold-const.c:15441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99204 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|WAITING |NEW CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > WORKSFORME: > > % gfc pr99204.f90 The issue really depends on optimization. Confirmed for all tested -O greater than -O0: -Og, -O, -Os, -O2, -O3. It disappears when declaring i volatile, as in integer, volatile :: i = -12345678
[Bug fortran/99206] [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Status|UNCONFIRMED |NEW Known to work||10.2.1 Known to fail||11.0 Ever confirmed|0 |1 Last reconfirmed||2021-02-22 Target Milestone|--- |11.0 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. gcc-10 emits an appropriate error message for z1 and accepts z2.
[Bug fortran/99206] [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 --- Comment #2 from anlauf at gcc dot gnu.org --- As a sidenote: print *, len (reshape (['a'], [0])) end This prints 0 for gcc-11, and the correct value 1 for 10.2.1. Do we screw up things during simplification?
[Bug fortran/99206] [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 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 --- Potential fix that sets the string length (not regtested): diff --git a/gcc/fortran/simplify.c b/gcc/fortran/simplify.c index 35f267db588..388aca7c38c 100644 --- a/gcc/fortran/simplify.c +++ b/gcc/fortran/simplify.c @@ -6887,6 +6887,8 @@ gfc_simplify_reshape (gfc_expr *source, gfc_expr *shape_exp, &source->where); if (source->ts.type == BT_DERIVED) result->ts.u.derived = source->ts.u.derived; + if (source->ts.type == BT_CHARACTER && result->ts.u.cl == NULL) +result->ts = source->ts; result->rank = rank; result->shape = gfc_get_shape (rank); for (i = 0; i < rank; i++)
[Bug fortran/99206] [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 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 #4 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-February/055745.html
[Bug fortran/99206] [11 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:1980
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99206 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 on mainline. Thanks for the report!
[Bug fortran/99169] [9/10/11 Regression] Segfault when passing allocatable scalar into intent(out) dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99169 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and on 10- and 9-branches. Thanks for the report!
[Bug fortran/99218] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 CC||anlauf at gcc dot gnu.org Last reconfirmed||2021-02-23 Status|UNCONFIRMED |NEW Known to fail||10.2.1, 11.0, 9.3.1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed for matmul(transpose(A),v), where v is of rank 1. No issue for: matmul(A,v) or matmul(transpose(A),B), where B is of rank 2.
[Bug fortran/99218] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 --- Comment #2 from anlauf at gcc dot gnu.org --- Reduced testcase: program play implicit none integer, parameter :: NCON = 1 integer, parameter :: NSTATE = 3 real,parameter :: ZERO = 0.0 real :: G(nCon,nState) = ZERO real :: lambda(nCon) = ZERO real :: fTmp(nState) = ZERO fTmp = matmul (transpose (G), lambda) end program
[Bug fortran/99218] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Known to fail||8.4.1
--- Comment #3 from anlauf at gcc dot gnu.org ---
Playing with the reduced testcase:
fTmp = matmul (transpose (G), lambda(::2))
is clean while
fTmp = matmul (transpose (G), lambda(::1))
is not.
It seems we run into a highly optimized code for rank-2 times rank-2.
The following patch fixes the testcase:
diff --git a/libgfortran/m4/matmul_internal.m4
b/libgfortran/m4/matmul_internal.m4
index 13fd7696238..0e96207a0fc 100644
--- a/libgfortran/m4/matmul_internal.m4
+++ b/libgfortran/m4/matmul_internal.m4
@@ -192,7 +192,8 @@ sinclude(`matmul_asm_'rtype_code`.m4')dnl
}
}
- if (rxstride == 1 && axstride == 1 && bxstride == 1)
+ if (rxstride == 1 && axstride == 1 && bxstride == 1
+ && GFC_DESCRIPTOR_RANK (b) != 1)
{
/* This block of code implements a tuned matmul, derived from
Superscalar GEMM-based level 3 BLAS, Beta version 0.1
[Bug libfortran/99218] [8/9/19/11 Regression] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|matmul on temporary array |[8/9/19/11 Regression] |accesses invalid memory |matmul on temporary array |(segfault) |accesses invalid memory ||(segfault) Priority|P3 |P4 Keywords||wrong-code Component|fortran |libfortran
[Bug libfortran/99218] [8/9/19/11 Regression] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 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 #4 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-February/055751.html
[Bug libfortran/99218] [8/9/10/11 Regression] matmul on temporary array accesses invalid memory (segfault)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99218 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|[8/9/19/11 Regression] |[8/9/10/11 Regression] |matmul on temporary array |matmul on temporary array |accesses invalid memory |accesses invalid memory |(segfault) |(segfault) Target Milestone|--- |8.5
[Bug fortran/99257] ICE in build_field, at fortran/trans-common.c:303
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99257 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-02-25 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. The module file m.mod looks funny. It looks especially wrong for z2.f90
[Bug fortran/93340] [8 Regression] ICE in check_constant_initializer, at fortran/trans-decl.c:5450
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93340 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|8.5 |9.4 Summary|[8/9/10/11 Regression] ICE |[8 Regression] ICE in |in |check_constant_initializer, |check_constant_initializer, |at |at |fortran/trans-decl.c:5450 |fortran/trans-decl.c:5450 | --- Comment #11 from anlauf at gcc dot gnu.org --- Backported to 10- and 9-branches without changes. Since it does not apply cleanly to 8-branch, it may not be worth the effort to adjust the fix and risk new regressions in the final 8-release. Therefore closing. Thanks for the report!
[Bug fortran/100273] [9/10/11/12 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Last reconfirmed||2021-04-26 Status|UNCONFIRMED |NEW --- Comment #2 from anlauf at gcc dot gnu.org --- Looks very related to the len_trim issue in pr84868. Possibly a duplicate.
[Bug fortran/100273] [9/10/11/12 Regression] ICE in gfc_create_module_variable, at fortran/trans-decl.c:5352
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100273 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |9.4 Priority|P3 |P4
[Bug fortran/100274] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100274 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |9.4 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-26 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Obvious fix for NULL pointer dereference: diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c index 213f32b0a67..450ee7e3ae7 100644 --- a/gcc/fortran/trans-expr.c +++ b/gcc/fortran/trans-expr.c @@ -6128,6 +6128,7 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym, bool add_clobber; add_clobber = fsym && fsym->attr.intent == INTENT_OUT && !fsym->attr.allocatable && !fsym->attr.pointer + && e->symtree && !e->symtree->n.sym->attr.dimension && !e->symtree->n.sym->attr.pointer && !e->symtree->n.sym->attr.allocatable
[Bug fortran/100274] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100274
--- Comment #2 from anlauf at gcc dot gnu.org ---
The patch in comment#1 would turn the ICE into an accepts-invalid, since
we would only get a warning instead of an error. This happens because
the character length check in gfc_compare_actual_formal returns too early
after emitting the warning.
The simplest fix would be to continue doing the checking:
diff --git a/gcc/fortran/interface.c b/gcc/fortran/interface.c
index 60736123550..9e3e8aa9da9 100644
--- a/gcc/fortran/interface.c
+++ b/gcc/fortran/interface.c
@@ -3255,10 +3255,13 @@ gfc_compare_actual_formal (gfc_actual_arglist **ap,
gfc_formal_arglist *formal,
&& f->sym->attr.flavor != FL_PROCEDURE)
{
if (a->expr->ts.type == BT_CHARACTER && !f->sym->as && where)
- gfc_warning (0, "Character length of actual argument shorter "
-"than of dummy argument %qs (%lu/%lu) at %L",
-f->sym->name, actual_size, formal_size,
-&a->expr->where);
+ {
+ gfc_warning (0, "Character length of actual argument shorter "
+ "than of dummy argument %qs (%lu/%lu) at %L",
+ f->sym->name, actual_size, formal_size,
+ &a->expr->where);
+ goto skip_size_check;
+ }
else if (where)
{
/* Emit a warning for -std=legacy and an error otherwise. */
This regtests cleanly and allows to emit the same error message as for
matching character length.
[Bug fortran/100274] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100274 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-April/056000.html
[Bug fortran/100218] Allow target of the pointer resulting from the evaluation of function-reference in a variable definition context
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100218 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #4 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11-branch. Closing.
[Bug fortran/100154] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100154 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #14 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on all affected branches (9/10/11). Closing. Thanks for the report!
[Bug fortran/97571] long parsing phase for simple array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||compile-time-hog --- Comment #12 from anlauf at gcc dot gnu.org --- You are throwing an elemental function on a array constructor. Rewriting the constant expression as tacos2 = (/ (acos (i / 10.0), i=64000,99250) /) makes the simplifications much more efficient.
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 --- Comment #13 from anlauf at gcc dot gnu.org --- (In reply to José Rui Faustino de Sousa from comment #12) > I do not have the "edit" or "take" links and if I click "Not yet assigned to > anyone" it tries to send an email to "unassig...@gcc.gnu.org"... Did you log in with your @gcc.gnu.org account?
[Bug fortran/100283] [11/12 Regression] Call to MIN0 with integer(8) arguments raises an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100283 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||11.1.0, 12.0 Status|UNCONFIRMED |NEW Keywords||ice-on-invalid-code Last reconfirmed||2021-04-28 CC||anlauf at gcc dot gnu.org Summary|Call to MIN0 with |[11/12 Regression] Call to |integer(8) arguments raises |MIN0 with integer(8) |an ICE |arguments raises an ICE Ever confirmed|0 |1 Priority|P3 |P4 Version|11.0|11.1.1 Known to work||10.3.1 Target Milestone|--- |11.2 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. gcc-10 gives: % gfc-10 -c pr100283.f90 -std=f2018 pr100283.f90:3:11: 3 | i = min0(j,k) | 1 Error: GNU Extension: Different type kinds at (1)
[Bug fortran/100283] [11/12 Regression] Call to MIN0 with integer(8) arguments raises an ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100283 --- Comment #2 from anlauf at gcc dot gnu.org --- The testcase is accepted with -fdefault-integer-8.
[Bug fortran/100275] ICE in gfc_build_null_descriptor, at fortran/trans-array.c:417
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100275 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2021-04-29
[Bug fortran/100183] Segmentation fault at runtime when passing an internal procedure as argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100183 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 Last reconfirmed||2021-04-29 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to Iain Sandoe from comment #4) > gcc304 is the Apple M1 machine. The GCC support there is highly > experimental and not in master -- please note that there are known issues > with the implementation. > > see : https://github.com/iains/gcc-darwin-arm64/issues So rather a target than a fortran issue?
[Bug fortran/86206] ICE in gfc_resolve_forall, at fortran/resolve.c:9989
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86206 --- Comment #6 from anlauf at gcc dot gnu.org --- I agree that there is a strange bookkeeping issue. Swapping the order of the two functions in comment#0 makes the ICE go away. Printing forall_save, nvar, total_var in gfc_resolve_forall may give a clue what makes the difference.
[Bug fortran/100274] [9/10/11/12 Regression] ICE in gfc_conv_procedure_call, at fortran/trans-expr.c:6131
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100274 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and backported to 11-, 10- and 9-branches. Closing. Thanks for the report!
[Bug fortran/92621] Problems with memory handling with allocatable intent(out) arrays with bind(c)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92621 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED --- Comment #15 from anlauf at gcc dot gnu.org --- It also helps if you change the status to ASSIGNED... ;-)
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #6 from anlauf at gcc dot gnu.org --- There seems to be something fishy with default initialization of function results of derived types. Looking at the attached code, I guessed the following potential reproducer: program p implicit none type multi real, allocatable :: mp(:) end type type fm type(multi) :: mfm end type type(fm), allocatable :: a(:,:) integer :: n = 1 allocate (a(n,n)) a = mm (a, a) a = mm (a, a) ! crashes here with -fsanitize=address contains function mm (ma, mb) type(fm) :: ma(:,:), mb(:,:) type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: mm integer :: i, j do i = 1, size(ma,dim=1) do j = 1, size(mb,dim=2) print *, i, j, allocated (mm(i,j)% mfm% mp) end do end do end function mm end program p Compiling and running the program prints: 1 1 F 1 1 T The second output line should really be identical to the first one, which is confirmed by other compilers. Under Linux, setting MALLOC_PERTURB_=1 I get: 1 1 T 1 1 T Adding -fsanitize=address to the command line, I get a traceback pointing to the line commented above: 1 1 T 1 1 T Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x14c71f85649f in ??? #1 0x14c720845c36 in _ZN11__sanitizer30atomic_compare_exchange_strongINS_14atomic_uint8_tEEEbPVT_PNS2_4TypeES5_NS_12memory_orderE at ../../../../gcc-trunk/libsanitizer/sanitizer_common/sanitizer_atomic_clang.h:80 #2 0x14c720845c36 in _ZN6__asan9Allocator38AtomicallySetQuarantineFlagIfAllocatedEPNS_9AsanChunkEPvPN11__sanitizer18BufferedStackTraceE at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:621 #3 0x14c720845c36 in _ZN6__asan9Allocator10DeallocateEPvmmPN11__sanitizer18BufferedStackTraceENS_9AllocTypeE at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:697 #4 0x14c720845c36 in _ZN6__asan9asan_freeEPvPN11__sanitizer18BufferedStackTraceENS_9AllocTypeE at ../../../../gcc-trunk/libsanitizer/asan/asan_allocator.cpp:971 #5 0x14c7208cac07 in __interceptor_free at ../../../../gcc-trunk/libsanitizer/asan/asan_malloc_linux.cpp:128 #6 0x401f10 in p at /home/anlauf/Downloads/pr100440-red.f90:13 #7 0x402180 in main at /home/anlauf/Downloads/pr100440-red.f90:13
[Bug fortran/100478] Type Pointer Segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100478 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Last reconfirmed||2021-05-07 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Maybe we need a temporary for the second pointer assignment.
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2021-05-08 Ever confirmed|0 |1 Keywords||wrong-code --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to Steve Kargl from comment #7) > There is no default initialization in the code below. default > initialization is > > type foo > integer :: i = 1 ! <-- Default initialization > end tyep foo The F2018 standard says: 7.5.4.6 Default initialization for components [...] Allocatable components are always initialized to unallocated. Anyway, the following extension shows that default initialization does not work: program p implicit none type fm real, allocatable :: mp(:) integer :: dummy = 42 end type type(fm), allocatable :: a(:,:) integer :: n = 1 allocate (a(n,n)) a = mm (a, a) a = mm (a, a) ! crashes here with -fsanitize=address contains function mm (ma, mb) type(fm) :: ma(:,:), mb(:,:) type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: mm integer :: i, j ! type(fm), dimension(size(ma,dim=1),size(mb,dim=2)) :: z ! mm = z ! Explicit initialization of function result do i = 1, size(ma,dim=1) do j = 1, size(mb,dim=2) print *, i, j, allocated (mm(i,j)% mp), mm(i,j)% dummy end do end do end function mm end program p Which gives: 1 1 F 0 1 1 T 0 and with MALLOC_PERTURB_=2 : 1 1 T -33686019 1 1 T -33686019 Uncommenting the indicated lines in function mm procduces: 1 1 F 42 1 1 F 42 and crashes with MALLOC_PERTURB_=2 Not good.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Target Milestone|--- |10.4 Known to work||9.3.1 Known to fail||10.3.1, 11.1.1 --- Comment #4 from anlauf at gcc dot gnu.org --- Patch to silence the warning (which was introduced with r10-4521): diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index cc9d85543ca..12e3ca0d811 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -738,6 +738,7 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) /* Keep variables larger than max-stack-var-size off stack. */ if (!(sym->ns->proc_name && sym->ns->proc_name->attr.recursive) && !sym->attr.automatic + && sym->attr.save != SAVE_EXPLICIT && INTEGER_CST_P (DECL_SIZE_UNIT (decl)) && !gfc_can_put_var_on_stack (DECL_SIZE_UNIT (decl)) /* Put variable length auto array pointers always into stack. */ Regtests ok.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 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 #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056017.html
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #11 from anlauf at gcc dot gnu.org --- For a possibly related case see PR98454.
[Bug fortran/100440] allocated() gives True for unallocated variable
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100440 --- Comment #12 from anlauf at gcc dot gnu.org --- A small variation of the testcase in comment#9 suggests that there are actually two underlying issues: lack of initialization and a missing temporary. program p implicit none type fm real, allocatable :: mp(:) integer :: dummy = 42 end type type(fm), allocatable :: a(:), b(:) integer :: n = 1 allocate (a(n)) print *, "main:", n, allocated (a(n)% mp), a(n)% dummy b = mm (a) a = mm (b) a = mm (a) a = mm (a) ! crashes here with -fsanitize=address contains function mm (ma) type(fm), intent(in) :: ma(:) type(fm) :: mm(size(ma)) integer :: i ! type(fm) :: z(size(ma)) ! mm = z ! Explicit initialization of function result do i = 1, size(ma) print *, "in mm:", i, allocated (mm(i)% mp), mm(i)% dummy end do end function mm end program p This gives: main: 1 F 42 in mm: 1 F 0 in mm: 1 F 42 in mm: 1 F 0 in mm: 1 T 0 while with -fsanitize=address,undefined : main: 1 F 42 in mm: 1 F -1094795586 in mm: 1 F 42 in mm: 1 T -1094795586 in mm: 1 T -1094795586 Program received signal SIGSEGV: Segmentation fault - invalid memory reference. Backtrace for this error: #0 0x14987da6f49f in ??? [...] #6 0x409669 in p at /home/anlauf/gcc-bugs/pr100440-red3.f90:14 #7 0x4097d9 in main at /home/anlauf/gcc-bugs/pr100440-red3.f90:14
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Keywords||wrong-code
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
(In reply to Martin Liška from comment #1)
> Started with r11-6928-g4225af228b5d52e8.
The partial revert:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index cce18d094a6..91efb67ac87 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5826,7 +5826,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
&derived_array);
}
else if (UNLIMITED_POLY (fsym) && e->ts.type != BT_CLASS
- && gfc_expr_attr (e).flavor != FL_PROCEDURE)
+//&& gfc_expr_attr (e).flavor != FL_PROCEDURE)
+ )
{
/* The intrinsic type needs to be converted to a temporary
CLASS object for the unlimited polymorphic formal. */
fixes this issue but breaks testcase proc_ptr_52.f90.
Further reduced testcase for this PR:
program p
implicit none
integer :: result
result = 1
! result = test ((result)) ! works
result = test (int (result)) ! fails
write(*,*) result
contains
integer function test(x)
class(*), intent(in) :: x
select type (x)
type is (integer)
test = x
class default
test = -1
end select
end function test
end program
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551
--- Comment #3 from anlauf at gcc dot gnu.org ---
Below fixes this PR and does not break the other testcase:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index cce18d094a6..ebc9ea42beb 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5826,7 +5826,8 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
&derived_array);
}
else if (UNLIMITED_POLY (fsym) && e->ts.type != BT_CLASS
- && gfc_expr_attr (e).flavor != FL_PROCEDURE)
+ && (gfc_expr_attr (e).flavor != FL_PROCEDURE
+ || gfc_expr_attr (e).proc == PROC_INTRINSIC))
{
/* The intrinsic type needs to be converted to a temporary
CLASS object for the unlimited polymorphic formal. */
I would hope that Paul can explain why this works, or if this is the right
thing.
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551
--- Comment #4 from anlauf at gcc dot gnu.org ---
Playing with the testcase show that the patch in comment#3 is incomplete.
Next try:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index cce18d094a6..3de53009970 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -5826,7 +5826,9 @@ gfc_conv_procedure_call (gfc_se * se, gfc_symbol * sym,
&derived_array);
}
else if (UNLIMITED_POLY (fsym) && e->ts.type != BT_CLASS
- && gfc_expr_attr (e).flavor != FL_PROCEDURE)
+ && e->ts.type != BT_PROCEDURE
+ && (gfc_expr_attr (e).flavor != FL_PROCEDURE
+ || (gfc_expr_attr (e).proc != PROC_UNKNOWN)))
{
/* The intrinsic type needs to be converted to a temporary
CLASS object for the unlimited polymorphic formal. */
This makes the following case work again:
program p
implicit none
integer :: result
result = 1
result = test ((result)) ! works
if (result /= 1) stop 1
result = test (int (result)) ! issue 1
write(*,*) result
result = test (f (result)) ! issue 2
write(*,*) result
contains
integer function test(x)
class(*), intent(in) :: x
select type (x)
type is (integer)
test = x
class default
test = -1
end select
end function test
integer function f(x)
integer, intent(in) :: x
f = 2*x
end function f
end program
[Bug fortran/100602] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-05-14 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. The error message is bogus.
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #8 from anlauf at gcc dot gnu.org --- (In reply to Vladimir Fuka from comment #7) > This sounds like good progress and I thank you for the patch. However, > shouldn't implicitly SAVE'd variables, as e.g. the program local variable in > the original report, be included as well? You are right. However, note that implicit SAVE for the main was added by Tobias only in r12-805, so I might have to think about a follow-up to this one.
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-05-18 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/100602] [11/12 Regression] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 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 --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056049.html
[Bug fortran/98411] [10/11] Pointless: Array larger than ‘-fmax-stack-var-size=’, moved from stack to static storage for main program variables
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98411 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #8) Looking some more into this: I couldn't find a consistent concept of setting variables to implicit-save as e.g. described in F2018 section 8.5.16 clause 4. A hackish approach to fix the remaining part of this PR could look like diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c index 406b4aeb1d4..a2498a04fb9 100644 --- a/gcc/fortran/trans-decl.c +++ b/gcc/fortran/trans-decl.c @@ -737,8 +737,10 @@ gfc_finish_var_decl (tree decl, gfc_symbol * sym) /* Keep variables larger than max-stack-var-size off stack. */ if (!(sym->ns->proc_name && sym->ns->proc_name->attr.recursive) + && !(sym->ns->proc_name && sym->ns->proc_name->attr.is_main_program) && !sym->attr.automatic && sym->attr.save != SAVE_EXPLICIT + && sym->attr.save != SAVE_IMPLICIT && INTEGER_CST_P (DECL_SIZE_UNIT (decl)) && !gfc_can_put_var_on_stack (DECL_SIZE_UNIT (decl)) /* Put variable length auto array pointers always into stack. */ However, the first part of this patch would only address variables in the main program, and the second part needs proper setting of SAVE_IMPLICIT, which is not yet done. As a sidenote: the above would regtest ok and fix comment#0.
[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 --- Comment #27 from anlauf at gcc dot gnu.org --- The code seems to compile with today's trunk, but still fails with 11-branch. Could one of Paul's recent commits have fixed this? If so, a backport might be nice.
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 --- Comment #2 from anlauf at gcc dot gnu.org --- Using a temporary may help: subroutine s(x) character(:), allocatable, optional :: x(:) character(:), allocatable :: y(:) if ( present(x) ) then if ( allocated(x) ) then y = 'a' // x // 'e' x = y end if end if end This does not ICE.
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551 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 #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056071.html
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to work||7.5.0 Ever confirmed|0 |1 Keywords||link-failure, wrong-code Last reconfirmed||2021-05-23 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Interesting bug. With optimization enabled (e.g. -O) I find a linking failure with 8.5.0 and newer, except when I add -ftlo. With -fwhole-program -O -flto the program seems to work up to 11.1, but fails with 12.0 (hangs). With -fwhole-program -O0 it also hangs with 12.0, but not with 11.1. So there are possibly two issues, a 12-regression and an 8+-regression.
[Bug fortran/100724] -fwhole-program breaks module use
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100724 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.3.1, 11.1.0, 12.0, ||8.5.0, 9.3.1 Known to work||9.2.0 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Dave Love from comment #2) > The manual says not to use -flto with -fwhole-program. Is that misleading? I guess the manual entry has a reason, but I do not know why the optimimzations implied by these options should not be combined. > I checked self-built gfortran 10.2.0 again, and it definitely works for me > without -flto on Debian 10, but it fails with Red Hat devtoolset's 10.2.1 on > RHEL7. Odd... I checked against gfortran 9.2.0, which works fine, whereas the current development version 9.3.1 fails too. The change likely happened in a newer developer version and was backported to the release branches.
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-valid-code |ice-on-invalid-code CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Possibly related: PR100283. Note that this is more likely an ice-on-invalid, as the specific intrinsics min0/max accept only default integers as argument. (F2018 table 16.3). 127_8 is not of default integer kind. Accepting non-default integers is an extension.
[Bug fortran/92065] [9/10/11/12 Regression] internal compiler error: in expand_expr_real_1
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92065 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||pault at gcc dot gnu.org --- Comment #30 from anlauf at gcc dot gnu.org --- Adding Paul.
[Bug fortran/100551] [11/12 Regression] Passing return value of intrinsic to class(*) dummy argument can cause segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100551 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12 and on 11-branch. Closing. Thanks for the report!
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 --- Comment #3 from anlauf at gcc dot gnu.org --- The following patch seems to fix the issue: diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c index 6d38ea78273..7eeef554c0f 100644 --- a/gcc/fortran/trans-array.c +++ b/gcc/fortran/trans-array.c @@ -4718,8 +4718,9 @@ done: /* For optional arguments, only check bounds if the argument is present. */ - if (expr->symtree->n.sym->attr.optional - || expr->symtree->n.sym->attr.not_always_present) + if ((expr->symtree->n.sym->attr.optional + || expr->symtree->n.sym->attr.not_always_present) + && expr->symtree->n.sym->attr.dummy) tmp = build3_v (COND_EXPR, gfc_conv_expr_present (expr->symtree->n.sym), tmp, build_empty_stmt (input_location)); If I understand the code correctly, the issue arises since we try to generate runtime checks for a compiler generated temporary that is not a dummy, thus hitting the assert in gfc_conv_expr_present.
[Bug middle-end/100755] Error with fortran object (v11.1.0)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100755 --- Comment #6 from anlauf at gcc dot gnu.org --- Please replace the wrong specifics by the proper generic: min0 -> min max0 -> max This should work and makes the code standard conforming.
[Bug fortran/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||11.1.0 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Known to work||10.3.0, 12.0 Keywords||wrong-code Summary|Get SIGFPE on simple test |[11 Regression] Get SIGFPE |with -fpe-trap=invalid and |on simple test with |SLP vectorization ON, with |-fpe-trap=invalid and SLP |gfortran 11.1.0 on x86_64 |vectorization ON, with ||gfortran 11.1.0 on x86_64 Last reconfirmed||2021-05-26 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed for 11.1, but mainline (12-trunk) seems fine (again?). Comparing the assembler code for both, there seems to be a lot going on ...
[Bug tree-optimization/100778] [11 Regression] Get SIGFPE on simple test with -fpe-trap=invalid and SLP vectorization ON, with gfortran 11.1.0 on x86_64
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100778 anlauf at gcc dot gnu.org changed: What|Removed |Added Component|fortran |tree-optimization --- Comment #2 from anlauf at gcc dot gnu.org --- Changing component to tree-optimization for inspection by experts.
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 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 CC||anlauf at gcc dot gnu.org --- Comment #4 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056088.html
[Bug fortran/99839] [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 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 #4 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2021-May/056095.html
[Bug fortran/100602] [11/12 Regression] Erroneous "pointer argument is not associated" runtime error.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100602 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|rejects-valid |wrong-code Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #6 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12 and on 11-branch. Closing. Thanks for the report!
[Bug fortran/100656] ICE in gfc_conv_expr_present, at fortran/trans-expr.c:1934
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100656 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11-branch. Since this is not a regression, not backporting further for now, although this would be possible. Thanks for the report!
[Bug fortran/100855] pow run time gfortran vs ifort
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100855 --- Comment #2 from anlauf at gcc dot gnu.org --- If you do not care about correct rounding, you can replace sum = sum + (i ** (0.05 + n)) by sum = sum + exp (log (real(i)) * (0.05 + n)) I think __builtin_powf and powf do care. I do not know if there is a gcc flag that replaces __builtin_powf by the combination of __builtin_expf / __builtin_logf which would also allow for (better) vectorization. (I know of a compiler for hardware which offers this).
[Bug fortran/100860] class(*) type is (character(*)) produces a segmentation fault when run
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100860 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2021-06-01 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Possibly related to pr100551, which was fixed after the 11.1 release. I do not see the issue with the current mainline or 11-branch version. Can you please check?
[Bug fortran/86115] move_alloc for class(*) containing value of type character(len=*) looses data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Keywords||wrong-code Last reconfirmed|2018-06-13 00:00:00 |2021-6-1 --- Comment #2 from anlauf at gcc dot gnu.org --- Adding print *, 'string length: ', len (z) in subroutine p prints string length 0.
[Bug fortran/86115] move_alloc for class(*) containing value of type character(len=*) looses data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=86115 --- Comment #3 from anlauf at gcc dot gnu.org --- Looking at the dump tree, it appears that the _vptr component is properly copied, but the _len component is not. But this one is needed for unlimited polymorphics.
[Bug fortran/100194] [9/10/11/12 Regression] ICE in gfc_trans_create_temp_array, at fortran/trans-array.c:1351
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=100194 --- Comment #4 from anlauf at gcc dot gnu.org --- We are hitting the assert 1351 gcc_assert (ss->dimen > 0); in gfc_trans_create_temp_array which does not handle assumed rank yet. (here ss->dimen = -1).
[Bug fortran/99839] [9/10/11/12 Regression] ICE in inline_matmul_assign, at fortran/frontend-passes.c:4234
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99839 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and committed on 11-, 10- and 9-branch. Closing. Thanks for the report!
