[Bug fortran/104311] [9/10/11/12 Regression] ICE out of memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104311 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2022-01-31 Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- We could limit the size of the resulting array constructor, using e.g. flag_max_array_constructor.
[Bug fortran/104309] Elemental character function should not return array of character variables of different lengths.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104309 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Priority|P3 |P4 Last reconfirmed||2022-01-31 Version|fortran-dev |12.0 --- Comment #1 from anlauf at gcc dot gnu.org --- I don't think the wording of g95 is explaining what is wrong. Browsing F2018 I saw: C15103 In the specification-expr that specifies a type parameter value of the result of an elemental function, an object designator with a dummy argument of the function as the base object shall appear only as the subject of a specification inquiry (10.1.11), ... And 10.1.11 has: A specification inquiry is a reference to (1) an intrinsic inquiry function other than PRESENT, (2) a type parameter inquiry (9.4.5), (3) ... TRIM and LEN_TRIM are not intrinsic inquiry functions.
[Bug fortran/104382] Finalization of parent components not compliant with standard
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104382 --- Comment #2 from anlauf at gcc dot gnu.org --- crayftn 11 & 12 output: destructor4(complicated) 2*2. destructor5 (simple2) 5 destructor5 (simple2) 6 destructor2(simple) 2*1 destructor4(complicated) 4., 5. destructor5 (simple2) -1 destructor5 (simple2) -2 destructor2(simple) 3, 4 final_count after assignment = 8 destructor4(complicated) 4., 5. destructor5 (simple2) -1 destructor5 (simple2) -2 destructor2(simple) 3, 4 final_count after deallocation = 12
[Bug fortran/93482] ICE in gfc_resolve_character_array_constructor, at fortran/array.c:2096
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93482 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |WAITING --- Comment #3 from anlauf at gcc dot gnu.org --- Seems to have been fixed on mainline, and backported to 11- and 10-branch. Likely a duplicate.
[Bug fortran/77693] ICE in rtl_for_decl_init, at dwarf2out.c:17378
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77693 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 #7 from anlauf at gcc dot gnu.org --- Patch at: https://gcc.gnu.org/pipermail/fortran/2022-February/057529.html
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211 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 --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057535.html
[Bug fortran/66193] ICE for initialisation of some non-zero-sized arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=66193 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 #19 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-February/057520.html
[Bug fortran/101135] Load of null pointer when passing absent assumed-shape array argument for an optional dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101135 --- Comment #4 from anlauf at gcc dot gnu.org --- Created attachment 52311 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52311=edit Patch that regtests ok. The patch suggested by the reporter is rather close to this one. We need to special-case optional arguments of procedures with bind(c) attribute. I haven't understood the details yet, but excluding those prevents regressions in the c-binding testsuite, e.g. bind-c-contiguous-4.*. We need to fix the pattern for testcase gfortran.dg/missing_optional_dummy_6a.f90 which would have failed with -fsanitize=undefined without this patch.
[Bug fortran/77667] ICE in expand_call, at calls.c:2588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77667 --- Comment #5 from anlauf at gcc dot gnu.org --- Seems fixed on mainline for gcc-12. Most likely fix: r12-6557 for pr67804.
[Bug fortran/99256] ICE in variable_check, at fortran/check.c:1012
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=99256 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED Target Milestone|--- |12.0 --- Comment #7 from anlauf at gcc dot gnu.org --- Committed as obvious, see also https://gcc.gnu.org/pipermail/fortran/2022-January/057398.html Closing. Thanks for the report!
[Bug fortran/85150] internal compiler error for module with illegal non-constant pointer initialization designator
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85150 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 --- This seems to have been recently fixed on mainline for gcc-12. Likely fix: r12-6387 for pr101762.
[Bug fortran/79685] [9/10/11/12 Regression] ICE on valid code in gfc_match_structur_constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=79685 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 --- The following tentative change fixes testcase z1 in comment#5: diff --git a/gcc/fortran/primary.c b/gcc/fortran/primary.c index 3f01f67cd49..d3729b20446 100644 --- a/gcc/fortran/primary.c +++ b/gcc/fortran/primary.c @@ -3373,8 +3373,8 @@ gfc_match_structure_constructor (gfc_symbol *sym, gfc_expr **result) e->expr_type = EXPR_FUNCTION; e->where = gfc_current_locus; - gcc_assert (gfc_fl_struct (sym->attr.flavor) - && symtree->n.sym->attr.flavor == FL_PROCEDURE); + gcc_assert (gfc_fl_struct (sym->attr.flavor)); +// && symtree->n.sym->attr.flavor == FL_PROCEDURE); e->value.function.esym = sym; e->symtree->n.sym->attr.generic = 1; However, it does not fix the example in comment#0. Playing a little, it seems that commenting the "implicit none" in module foo then lets the code compile. Alternative reproducer: module m implicit none private public :: t type t integer :: i end type end module m2 use m, t2 => t implicit none ! <--- Error: Symbol 't' at (1) has no IMPLICIT type private type(t2), public, protected :: x(2) data x(1) /t2(3)/ end program p use m2 implicit none print *, x(1)%i end program p So there is more to it...
[Bug fortran/103475] ICE in gfc_expr_attr, at fortran/primary.c:2782
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103475 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING --- Comment #2 from anlauf at gcc dot gnu.org --- While the patch in comment#1 looks correct, I don't see the ICE for r12-6697. Running under gdb shows why: we seem to no longer get here.
[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|WAITING --- Comment #4 from anlauf at gcc dot gnu.org --- Seems to work at r12-6697, r11-9477 and r10-10403. gcc-9 still fails. Does a bisection make sense to find what fixed it? Otherwise we could close it and set the target milestone to 10.4.
[Bug fortran/103692] [11/12 Regression] ICE in add_init_expr_to_sym, at fortran/decl.c:2062
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103692 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 mainline for gcc-12, and on 11- and 10-branches. Closing. Thanks for the report!
[Bug fortran/104127] [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127 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 --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-January/057428.html
[Bug fortran/104128] ICE in gfc_widechar_to_char, at fortran/scanner.c:199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #3) > with TRANSFER between different integer kinds. E.g. oops, that should read: character kinds
[Bug fortran/104128] ICE in gfc_widechar_to_char, at fortran/scanner.c:199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128 anlauf at gcc dot gnu.org changed: What|Removed |Added Priority|P3 |P4 Keywords||wrong-code --- Comment #3 from anlauf at gcc dot gnu.org --- The patch in comment#2 fixes the ICE in comment#0, but uncovers a few issues with TRANSFER between different integer kinds. E.g. program p implicit none character(kind=4,len=2), parameter :: z= 4_"FG" character(kind=1,len=*), parameter :: x= transfer (z, 'abcdefgh') character(kind=4,len=*), parameter :: v= transfer (x, z) print *, z print *, v if (v /= z) stop 3 end shows that we do not get a clean round-trip.
[Bug fortran/104128] ICE in gfc_widechar_to_char, at fortran/scanner.c:199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128 --- Comment #5 from anlauf at gcc dot gnu.org --- The issue in comment#3 is likely unrelated to TRANSFER: program p implicit none ! integer, parameter :: k = 1 integer, parameter :: k = 4 character(kind=k,len=2), parameter :: z = k_"FG" character(kind=1,len=*), parameter :: x = transfer (z, 'abcdefgh') character(kind=k,len=2):: u = transfer (x, z) ! always OK character(kind=k,len=2), parameter :: v = transfer (x, z) ! OK (kind=1) logical, parameter :: l = (z == v) print *, "z == v:", l print *, z print *, u if (u /= z) stop 4 print *, v if (v /= z) stop 3 ! stops here for kind=4 end This works for k=1 (z==v), but fails for k=4 (z/=v, but should be same). (NAG confirms my expectations.)
[Bug fortran/103931] Type name "c_ptr" is ambiguous when iso_c_binding is imported both directly and indirectly
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103931 --- Comment #2 from anlauf at gcc dot gnu.org --- Created attachment 52138 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=52138=edit Somewhat reduced reproducer The issue can be reproduced with a few less modules
[Bug fortran/83079] ICE in gfc_widechar_to_char, at fortran/scanner.c:198
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83079 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 --- The testcase in comment#0 is fixed by: diff --git a/gcc/fortran/target-memory.c b/gcc/fortran/target-memory.c index af1c21047f6..9b5af8d1482 100644 --- a/gcc/fortran/target-memory.c +++ b/gcc/fortran/target-memory.c @@ -485,7 +485,7 @@ gfc_interpret_character (unsigned char *buffer, size_t buffer_size, result->value.character.string[result->value.character.length] = '\0'; - return result->value.character.length; + return size_character (result->value.character.length, result->ts.kind); }
[Bug fortran/104128] ICE in gfc_widechar_to_char, at fortran/scanner.c:199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128 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||2022-01-19 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[Bug fortran/104127] [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127
--- Comment #2 from anlauf at gcc dot gnu.org ---
We die here:
(gdb) l 7244
7239case EXPR_ARRAY:
7240
7241 /* This is somewhat brutal. The expression for the first
7242 element of the array is evaluated and assigned to a
7243 new string length for the original expression. */
7244 e = gfc_constructor_first (expr->value.constructor)->expr;
7245
7246 gfc_init_se (, NULL);
7247
7248 /* Avoid evaluating trailing array references since all we need
is
(gdb) p expr->value.constructor
$45 = (gfc_constructor_base) 0x0
(gdb) p expr->ts.u.cl->length
$46 = (gfc_expr *) 0x0
(gdb) p *expr->shape[0]
$47 = {_mp_alloc = 1, _mp_size = 0, _mp_d = 0x2f0c840}
The shape is correct, but the character length is lost.
We could handle a zero-sized array but need the right spec.
[Bug fortran/104127] [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Last reconfirmed||2022-01-19
Status|UNCONFIRMED |NEW
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
Happens even for default character, e.g.
call sub (transfer('a', 'y', size=0))
Likely an issue with the result being an array of size 0.
[Bug fortran/104127] [9/10/11/12 Regression] ICE in get_array_charlen, at fortran/trans-array.c:7244
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104127
--- Comment #3 from anlauf at gcc dot gnu.org ---
Tentative patch:
diff --git a/gcc/fortran/simplify.cc b/gcc/fortran/simplify.cc
index 3881370d947..366b00c28dd 100644
--- a/gcc/fortran/simplify.cc
+++ b/gcc/fortran/simplify.cc
@@ -8162,7 +8162,15 @@ gfc_simplify_transfer (gfc_expr *source, gfc_expr *mold,
gfc_expr *size)
set even for array expressions, in order to pass this information into
gfc_target_interpret_expr. */
if (result->ts.type == BT_CHARACTER && gfc_is_constant_expr (mold_element))
-result->value.character.length = mold_element->value.character.length;
+{
+ result->value.character.length = mold_element->value.character.length;
+
+ /* A zero-sized result array needs to inherit the string length. */
+ if (result_length == 0)
+ result->ts.u.cl->length =
+ gfc_get_int_expr (gfc_charlen_int_kind, NULL,
+ mold_element->value.character.length);
+}
/* Set the number of elements in the result, and determine its size. */
This fixes the ICE as well as now produces a correct result e.g. for
print *, len (transfer('ab', 'xyz', size=0))
However, looking at the tree dump of comment#0 I see very similar multiple
temporaries being generated as for other empty array constructors being passed
to procedures (pr86277).
[Bug fortran/104128] ICE in gfc_widechar_to_char, at fortran/scanner.c:199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128
--- Comment #2 from anlauf at gcc dot gnu.org ---
Tentative, semi-obvious patch:
diff --git a/gcc/fortran/target-memory.cc b/gcc/fortran/target-memory.cc
index 361907b0e51..7ce7d736629 100644
--- a/gcc/fortran/target-memory.cc
+++ b/gcc/fortran/target-memory.cc
@@ -365,7 +365,8 @@ gfc_target_encode_expr (gfc_expr *source, unsigned char
*buffer,
static size_t
-interpret_array (unsigned char *buffer, size_t buffer_size, gfc_expr *result)
+interpret_array (unsigned char *buffer, size_t buffer_size, gfc_expr *result,
+bool convert_widechar)
{
gfc_constructor_base base = NULL;
size_t array_size = 1;
@@ -390,7 +391,7 @@ interpret_array (unsigned char *buffer, size_t buffer_size,
gfc_expr *result)
gfc_constructor_append_expr (, e, >where);
ptr += gfc_target_interpret_expr ([ptr], buffer_size - ptr, e,
- true);
+ convert_widechar);
}
result->value.constructor = base;
@@ -580,7 +581,7 @@ gfc_target_interpret_expr (unsigned char *buffer, size_t
buffer_size,
gfc_expr *result, bool convert_widechar)
{
if (result->expr_type == EXPR_ARRAY)
-return interpret_array (buffer, buffer_size, result);
+return interpret_array (buffer, buffer_size, result, convert_widechar);
switch (result->ts.type)
{
[Bug fortran/104128] ICE in gfc_widechar_to_char, at fortran/scanner.c:199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128 --- Comment #6 from anlauf at gcc dot gnu.org --- The remaining issues in this PR seem to be related to inconsistencies between expr->representation.string and expr->value.character.string that occur for non-default character kind that are created in gfc_copy_expr. Hackish fix to avoid converting the (bytewise) representation.string for non-default character kind: diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc index 279d9b30991..ed82a94022f 100644 --- a/gcc/fortran/expr.cc +++ b/gcc/fortran/expr.cc @@ -312,7 +312,8 @@ gfc_copy_expr (gfc_expr *p) break; case BT_CHARACTER: - if (p->representation.string) + if (p->representation.string + && p->ts.kind == gfc_default_character_kind) q->value.character.string = gfc_char_to_widechar (q->representation.string); else Needs regtesting.
[Bug fortran/104128] ICE in gfc_widechar_to_char, at fortran/scanner.c:199
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104128 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 #7 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-January/057437.html
[Bug fortran/103782] [9/10/11/12 Regression] internal error occurs when overloading intrinsic since r9-1566-g87c789f1c0b2df41
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=103782 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on all open branches. Closing. Thanks for the report!
[Bug fortran/104212] ICE in transformational_result, at fortran/simplify.cc:466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104212 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Ever confirmed|0 |1 Last reconfirmed||2022-01-24 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. We simply need a check on argument DIM: diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc index 5fe8d452413..431a803c4c6 100644 --- a/gcc/fortran/check.cc +++ b/gcc/fortran/check.cc @@ -4476,6 +4476,9 @@ gfc_check_parity (gfc_expr *mask, gfc_expr *dim) if (!array_check (mask, 0)) return false; + if (!dim_check (dim, 1, false)) +return false; + if (!dim_rank_check (dim, mask, false)) return false;
[Bug fortran/104212] ICE in transformational_result, at fortran/simplify.cc:466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104212 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 #2 from anlauf at gcc dot gnu.org --- Posted: https://gcc.gnu.org/pipermail/fortran/2022-January/057446.html
[Bug fortran/104211] ICE in find_array_section, at fortran/expr.cc:1720
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104211
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-24
Priority|P3 |P4
CC||anlauf at gcc dot gnu.org
Ever confirmed|0 |1
--- Comment #1 from anlauf at gcc dot gnu.org ---
Confirmed.
We hit an assert which can be replaced by an error message, such as:
diff --git a/gcc/fortran/expr.cc b/gcc/fortran/expr.cc
index ed82a94022f..78f21c24f43 100644
--- a/gcc/fortran/expr.cc
+++ b/gcc/fortran/expr.cc
@@ -1718,7 +1718,12 @@ find_array_section (gfc_expr *expr, gfc_ref *ref)
}
cons = gfc_constructor_lookup (base, limit);
- gcc_assert (cons);
+ if (cons == NULL)
+ {
+ gfc_error ("Bad array constructor at %L", >u.ar.where);
+ t = false;
+ goto cleanup;
+ }
gfc_constructor_append_expr (>value.constructor,
gfc_copy_expr (cons->expr), NULL);
}
[Bug fortran/59104] Wrong result with SIZE specification expression
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=59104 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Last reconfirmed|2015-08-18 00:00:00 |2022-1-24 --- Comment #3 from anlauf at gcc dot gnu.org --- Interestingly, when using the RESULT clause in the function declaration, the evaluation of SIZE appears to work for: program bug implicit none real :: u(3) u = f(3) u = g(3) contains !- function f(n) integer, intent(in) :: n real:: f(n) integer :: y(size(f)) f = 1 print *, 'f: size(y) =',size(y) end function f !- function g(n) result (f) integer, intent(in) :: n real:: f(n) integer :: y(size(f)) f = 2 print *, 'g: size(y) =',size(y) end function g end This prints: f: size(y) = 0 g: size(y) = 3 (Expecting size=3 in both cases).
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||gs...@t-online.de --- Comment #8 from anlauf at gcc dot gnu.org --- *** Bug 100275 has been marked as a duplicate of this bug. ***
[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 CC||anlauf at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from anlauf at gcc dot gnu.org --- Looks very much like a duplicate of pr67804. *** This bug has been marked as a duplicate of bug 67804 ***
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |10.4 --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Trying to back further shows an unexpected failure during regtesting. Not worth investigating, thus 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 67804, which changed state. Bug 67804 Summary: ICE on data initialization of type(character) with wrong data https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/101762] ICE with "Every subscript of the target specification must be a constant expression"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=101762 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |10.4 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-12, and on 11- and 10-branch. Backporting further is probably not necessary. Closing. Thanks for the report!
[Bug fortran/104227] [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Status|UNCONFIRMED |NEW
Last reconfirmed||2022-01-25
--- Comment #1 from anlauf at gcc dot gnu.org ---
Obvious fix:
diff --git a/gcc/fortran/check.cc b/gcc/fortran/check.cc
index 4fa05ee7e9b..d6c6767ae9e 100644
--- a/gcc/fortran/check.cc
+++ b/gcc/fortran/check.cc
@@ -6151,7 +6151,7 @@ gfc_calculate_transfer_sizes (gfc_expr *source, gfc_expr
*mold, gfc_expr *size,
* If SIZE is present, the result is an array of rank one and size SIZE.
*/
if (result_elt_size == 0 && *source_size > 0 && !size
- && mold->expr_type == EXPR_ARRAY)
+ && (mold->expr_type == EXPR_ARRAY || mold->rank))
{
gfc_error ("% argument of % intrinsic at %L is an "
"array and shall not have storage size 0 when % "
[Bug fortran/104227] [9/10/11/12 Regression] ICE virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Target Milestone|--- |9.5 Priority|P3 |P4 Status|NEW |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Taking.
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 --- Comment #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2022-January/057478.html This fixes gfortran.dg/team_change_1.f90 gfortran.dg/team_number_1.f90 gfortran.dg/popcnt_poppar_2.F90 (-m64, not supported with -m32) I was unable to reproduce gfortran.dg/coarray/sync_3.f90 (with -fcheck=all) gfortran.dg/goacc/nested-function-1.f90 Could somebody else have a look at these and give details? Especially which function or code triggers the error?
[Bug fortran/84787] ICEs: in decompose, at wide-int.h:933 with -default-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|NEW |RESOLVED Resolution|--- |DUPLICATE --- Comment #1 from anlauf at gcc dot gnu.org --- Likely fixed by the patch for pr84784 which also addresses this intrinsic. *** This bug has been marked as a duplicate of bug 84784 ***
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 --- Comment #6 from anlauf at gcc dot gnu.org --- *** Bug 84787 has been marked as a duplicate of this bug. ***
[Bug fortran/32770] [Meta-bug] -fdefault-integer-8 issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=32770 Bug 32770 depends on bug 84787, which changed state. Bug 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/83700] [Meta-bug] Fortran Coarray issues
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=83700 Bug 83700 depends on bug 84787, which changed state. Bug 84787 Summary: ICEs: in decompose, at wide-int.h:933 with -default-integer-8 https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84787 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |DUPLICATE
[Bug fortran/104212] ICE in transformational_result, at fortran/simplify.cc:466
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104212 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |11.3 --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed.
[Bug fortran/104227] [9/10/11 Regression] ICE virtual memory exhausted: Cannot allocate memory
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104227 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 all open branches. Closing. Thanks for the report!
[Bug fortran/67804] ICE on data initialization of type(character) with wrong data
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=67804 --- Comment #7 from anlauf at gcc dot gnu.org --- *** Bug 77667 has been marked as a duplicate of this bug. ***
[Bug fortran/77667] ICE in expand_call, at calls.c:2588
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=77667 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #6 from anlauf at gcc dot gnu.org --- Indeed fixed on mainline by r12-6557. *** This bug has been marked as a duplicate of bug 67804 ***
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784
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 ---
Another reduced testcase:
! { dg-do run }
! { dg-options "-fdefault-integer-8" }
! { dg-require-effective-target fortran_integer_16 }
if (runtime_popcnt(0_16) /= 0) STOP 2
contains
integer function runtime_popcnt (i)
integer(kind=16), intent(in) :: i
runtime_popcnt = popcnt(i)
end function
end
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> Another reduced testcase:
>
> ! { dg-do run }
> ! { dg-options "-fdefault-integer-8" }
> ! { dg-require-effective-target fortran_integer_16 }
>
> if (runtime_popcnt(0_16) /= 0) STOP 2
> contains
> integer function runtime_popcnt (i)
> integer(kind=16), intent(in) :: i
> runtime_popcnt = popcnt(i)
> end function
> end
Interestingly, this works for me with 11- and 10-branches, but fails with
12-mainline...
[Bug fortran/84784] ICEs: verify_gimple failed with -fdefault-integer-8
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=84784 --- Comment #4 from anlauf at gcc dot gnu.org --- OK, the following fixes the ICE: diff --git a/gcc/fortran/trans-intrinsic.cc b/gcc/fortran/trans-intrinsic.cc index fccf0a9b229..d5564f659f8 100644 --- a/gcc/fortran/trans-intrinsic.cc +++ b/gcc/fortran/trans-intrinsic.cc @@ -7254,13 +7254,15 @@ gfc_conv_intrinsic_popcnt_poppar (gfc_se * se, gfc_expr *expr, int parity) arg2)); /* Combine the results. */ + tree builtin_type = integer_type_node; if (parity) - se->expr = fold_build2_loc (input_location, BIT_XOR_EXPR, result_type, + se->expr = fold_build2_loc (input_location, BIT_XOR_EXPR, builtin_type, call1, call2); else - se->expr = fold_build2_loc (input_location, PLUS_EXPR, result_type, + se->expr = fold_build2_loc (input_location, PLUS_EXPR, builtin_type, call1, call2); + se->expr = convert (result_type, se->expr); return; }
[Bug fortran/105168] [9/10/11/12 Regression] ICE in gfc_maybe_dereference_var, at fortran/trans-expr.cc:2870
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105168 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Priority|P3 |P4 Status|UNCONFIRMED |NEW See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=100155 Last reconfirmed||2022-04-05 --- Comment #1 from anlauf at gcc dot gnu.org --- Likely related to pr100155 or a duplicate.
[Bug fortran/104210] [11 Regression] ICE in gfc_zero_size_array, at fortran/arith.cc:1685 since r11-1814-gcc9a9229285a26ac
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104210 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.
[Bug fortran/105182] [11/12 Regression] compiling NJOY21 causes a ICE segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105182 --- Comment #12 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #11) > Remove myself from CC list. I do not have 11.x source tree. Minimum > example that should have been supplied by someone else. What options are needed to make it fail? I can't reproduce a failure for this example on x86_64-pc-linux-gnu with current HEAD of 11-branch.
[Bug fortran/105182] [11/12 Regression] compiling NJOY21 causes a ICE segmentation fault: 11
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105182 --- Comment #14 from anlauf at gcc dot gnu.org --- I found a machine with 11.2 where I get the ICE. Likely a duplicate of pr103609 which has been fixed. If you agree, you may close this one as a duplicate.
[Bug fortran/105184] ICE in gfc_array_init_size, at fortran/trans-array.cc:5841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105184
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 ---
Testing the following patch:
diff --git a/gcc/fortran/resolve.cc b/gcc/fortran/resolve.cc
index 21c8797c938..45a04dab703 100644
--- a/gcc/fortran/resolve.cc
+++ b/gcc/fortran/resolve.cc
@@ -8108,12 +8108,12 @@ resolve_allocate_expr (gfc_expr *e, gfc_code *code,
bool *array_alloc_wo_spec)
goto failure;
case DIMEN_RANGE:
- if (ar->start[i] == 0 || ar->end[i] == 0)
+ // F2018:R937:
+ // allocate-coshape-spec is [ lower-bound-expr : ] upper-bound-expr
+ if (ar->start[i] == 0 || ar->end[i] == 0 || ar->stride[i] != NULL)
{
- /* If ar->stride[i] is NULL, we issued a previous error. */
- if (ar->stride[i] == NULL)
- gfc_error ("Bad array specification in ALLOCATE statement "
-"at %L", >where);
+ gfc_error ("Bad array specification in ALLOCATE statement "
+ "at %L", >where);
goto failure;
}
else if (gfc_dep_compare_expr (ar->start[i], ar->end[i]) == 1)
[Bug fortran/105184] ICE in gfc_array_init_size, at fortran/trans-array.cc:5841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105184 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2022-04-06 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. The checking for bad array shape specifications needs improvement.
[Bug fortran/105184] ICE in gfc_array_init_size, at fortran/trans-array.cc:5841
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=105184 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 --- Submitted: https://gcc.gnu.org/pipermail/fortran/2022-April/057743.html
[Bug fortran/111341] Elemental operator on zero-sized array seg-faults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111341 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |WAITING Last reconfirmed||2023-09-11 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Brad Richardson from comment #2) > You'll need to use fpm. I.e. Please provide a self-contained testcase. Ideally a minimal reproducer.
[Bug fortran/37802] Improve wording for matmul bound checking
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=37802 Bug 37802 depends on bug 30802, which changed state. Bug 30802 Summary: out of bounds error array I/O not picked up with -fbounds-check https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anthony.debeus at gmail dot com --- Comment #13 from anlauf at gcc dot gnu.org --- *** Bug 97039 has been marked as a duplicate of this bug. ***
[Bug fortran/97039] -fbounds-check misses violation with slice of array but not an element
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97039 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|NEW |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- Should be fixed by r14-4039-g1cbf18978aa384 for pr30802. Thus marking as duplicate. *** This bug has been marked as a duplicate of bug 30802 ***
[Bug fortran/27766] [meta-bug] -fbounds-check related bugs
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=27766 Bug 27766 depends on bug 30802, which changed state. Bug 30802 Summary: out of bounds error array I/O not picked up with -fbounds-check https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #14 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14.
[Bug fortran/93485] ICE in gfc_trans_array_ctor_element, at fortran/trans-array.c:1682
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93485 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Known to work||11.3.0, 12.1.0, 13.1.0, ||14.0 Status|WAITING |RESOLVED Known to fail||10.5.0 --- Comment #4 from anlauf at gcc dot gnu.org --- Apparently fixed since gcc-11. Closing.
[Bug fortran/31059] bounds-check does not detect nonconforming assignment arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059 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 #11 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-August/059722.html
[Bug fortran/102417] Wrong error message about character length with -std=f2018
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102417 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Keywords|diagnostic |rejects-valid, wrong-code CC||anlauf at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=107721 Ever confirmed|0 |1 Last reconfirmed||2023-08-28 --- Comment #2 from anlauf at gcc dot gnu.org --- It appears that we lose the typespec for nested ctors, so I guess this PR is related to pr107721. Slight variation of testcase: program p character:: x = 'a' character(4) :: y(2) y = [ character(4) :: x, 'b' ] y = [[character(4) :: x, 'b']] print *, y print *, len ([ character(4) :: x, 'b' ]) print *, len ([[character(4) :: x, 'b']]) end Compiling with -fdump-fortran-original, I see: code: ASSIGN p:y(FULL) (/ p:x , 'b ' /) ASSIGN p:y(FULL) (/ p:x , 'b' /) WRITE UNIT=6 FMT=-1 TRANSFER p:y(FULL) DT_END WRITE UNIT=6 FMT=-1 TRANSFER 4 DT_END WRITE UNIT=6 FMT=-1 TRANSFER 1 DT_END Clearly, the code for the lines with nested ctors is wrong.
[Bug fortran/31059] bounds-check does not detect nonconforming assignment arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059 anlauf at gcc dot gnu.org changed: What|Removed |Added Attachment #55821|0 |1 is obsolete|| --- Comment #10 from anlauf at gcc dot gnu.org --- Created attachment 55828 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55828=edit Improved patch This one also handles arbitrary order of array section and constructor.
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||alexandre.poux at coria dot fr --- Comment #22 from anlauf at gcc dot gnu.org --- *** Bug 111321 has been marked as a duplicate of this bug. ***
[Bug fortran/111321] Segmentation fault with associate construct
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111321 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED Resolution|--- |DUPLICATE --- Comment #3 from anlauf at gcc dot gnu.org --- Duplicate. Fixed in 13.3. *** This bug has been marked as a duplicate of bug 109948 ***
[Bug fortran/109948] [13/14 Regression] ICE(segfault) in gfc_expression_rank() from gfc_op_rank_conformable()
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=109948 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|13.2|13.3 --- Comment #23 from anlauf at gcc dot gnu.org --- The fix was applied to 13-branch after the 13.2 release. Updating target milestone appropriately.
[Bug fortran/108957] Fortran FE memleak with interfaces
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108957 --- Comment #4 from anlauf at gcc dot gnu.org --- Mikael, are you still onto it?
[Bug fortran/97122] Spurious FINAL ... must be in the specification part of a MODULE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97122 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||rejects-valid Status|NEW |WAITING --- Comment #12 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14. Shall we close it? Or does it deserve backporting?
[Bug fortran/111339] bounds-check does not detect nonconforming functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111339 anlauf at gcc dot gnu.org changed: What|Removed |Added Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-09-08 --- Comment #1 from anlauf at gcc dot gnu.org --- The use of the intrinsic TRANSFER produces the equivalent of a function but with non-constant size, derived from pr34740, also not detected: program p real, allocatable :: ivec(:) real :: jvec(3) = [1,2,3] ivec= [1.,2.] ivec(:) = transfer (jvec, [1.]) end Detected by NAG, but not by Intel.
[Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code Status|UNCONFIRMED |NEW Last reconfirmed||2023-08-29 Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- I get an ICE for all gcc >= 11 here, and I think the code is actually valid. (Other compilers, like NAG, Intel, NVidia accept it). Might be a regression, as my installs of 7 <= gcc <= 10 all pass.
[Bug fortran/111218] Conflict in BIND(C) INTERFACEs in two Modules leads to ICE.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111218 --- Comment #3 from anlauf at gcc dot gnu.org --- A workaround is to add a 'private' statement to any of the first two modules.
[Bug fortran/31059] bounds-check does not detect nonconforming assignment arrays
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=31059 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 --- Created attachment 55821 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=55821=edit Partial patch (proof of concept) The attached patch adds bounds-checking for the case that the r.h.s. has only an array constructor. Note the the original testcase is bogus, as it does not prevent (re)allocation on assignment, which became default in F2003. Adjusted testcase: program p integer :: jvec(3) = [1,2,3] integer, allocatable :: ivec(:) allocate (ivec(2)) ivec(:) = [4,5,6] ! shall be detected ivec(:) = jvec! already detected end
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 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 #10 from anlauf at gcc dot gnu.org --- I am working on a patch.
[Bug fortran/30802] out of bounds error array I/O not picked up with -fbounds-check
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=30802 --- Comment #11 from anlauf at gcc dot gnu.org --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-September/059756.html
[Bug libfortran/111022] ES0.0E0 format gave ES0.dE0 output with d too high.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111022 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #19 from anlauf at gcc dot gnu.org --- (In reply to Jerry DeLisle from comment #18) > With Johns test case from Comment #15 and the patch in Comment #17 I get the > following: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0 ) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. > With (A,1X,EN0.0E0) 666. Intel prints With (A,1X,EN0.0E0) 666.+0 which I think is slightly more in accordance with F2018 Table 13.2, which requires printing the exponent for the ...E0 version with the minimum number of digits, which is 1 for a zero exponent. See the "footnote (1)" there. Can you please check? Or am I missing something? > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0 ) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > With (A,1X,ES0.0E0) 7.E+2 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > Notice that the width of exponents is also minimized and where the exponent > is zero it is not shown at all. If I do specify an exponent width it shown. > For example with exponent width of 4 and changing the value to 66600 I get: > > $ ./a.out > real kinds 4 8 10 16 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0 ) 67.E+3 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,EN0.0E4) 67.E+0003 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0 ) 7.E+4 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > With (A,1X,ES0.0E4) 7.E+0004 > ERROR STOP Scale factor out of range in format specifier 'E' or 'D' > > This seems reasonable to me. Other opinions?
[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||mailling-lists-bd at posteo dot de --- Comment #7 from anlauf at gcc dot gnu.org --- *** Bug 111304 has been marked as a duplicate of this bug. ***
[Bug fortran/111304] Problem when passing implicit arrays of characters to functions
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111304 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #2 from anlauf at gcc dot gnu.org --- Looks like a duplicate of pr85547. *** This bug has been marked as a duplicate of bug 85547 ***
[Bug fortran/104351] ICE in gfc_generate_initializer, at fortran/expr.cc:5140
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104351 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 --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-October/059812.html
[Bug fortran/111837] [8/9/10/11/12/13/14 Regression] Out of bounds access with optimization inside io-implied-do-control
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111837 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Priority|P3 |P4 Keywords||wrong-code Summary|[8,9,10,11,12,13|[8/9/10/11/12/13/14 |Regression] Out of bounds |Regression] Out of bounds |access with optimization|access with optimization |inside |inside |io-implied-do-control |io-implied-do-control Known to fail||8.5.0 Known to work||7.5.0 Target Milestone|--- |11.5 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2023-10-16 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. This is a frontend-optimization bug. Workaround: compile with -fno-frontend-optimize .
[Bug fortran/111837] [8/9/10/11/12/13/14 Regression] Out of bounds access with optimization inside io-implied-do-control
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111837
--- Comment #2 from anlauf at gcc dot gnu.org ---
Lightly tested, probably obvious patch:
diff --git a/gcc/fortran/frontend-passes.cc b/gcc/fortran/frontend-passes.cc
index 136a292807d..536884b13f0 100644
--- a/gcc/fortran/frontend-passes.cc
+++ b/gcc/fortran/frontend-passes.cc
@@ -1326,7 +1326,7 @@ traverse_io_block (gfc_code *code, bool *has_reached,
gfc_code *prev)
if (iters[i])
{
gfc_expr *var = iters[i]->var;
- for (int j = i - 1; j < i; j++)
+ for (int j = 0; j < i; j++)
{
if (iters[j]
&& (var_in_expr (var, iters[j]->start)
[Bug fortran/111837] [8/9/10/11/12/13/14 Regression] Out of bounds access with optimization inside io-implied-do-control
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111837 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 --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-October/059832.html
[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104625 --- Comment #6 from anlauf at gcc dot gnu.org --- Steve Lionel of Intel confirmed that the code is valid, and that if X is polymorphic, so is (X): community.intel.com/t5/Intel-Fortran-Compiler/SELECT-TYPE-statement-and-parenthesized-selector/m-p/1537256#M168843
[Bug fortran/104649] ICE in gfc_match_formal_arglist, at fortran/decl.cc:6733 since r6-1958-g4668d6f9c00d4767
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104649 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED Target Milestone|--- |14.0 --- Comment #8 from anlauf at gcc dot gnu.org --- Fixed in gcc-14. Closing. Thanks for the report!
[Bug fortran/104555] ICE in gfc_compare_derived_types, at fortran/interface.cc:628 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104555 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 --- In this case the associate-name is essential in the SELECT TYPE, as well as the surrounding SELECT RANK, and a CHARACTER component in the derived type. Replacing character(:), allocatable :: a by character(10) :: a changes the ICE to a bogus error message with a corrupted variable name. valgrind gives invalid reads...
[Bug fortran/111291] ASAN error: heap-use-after-free gcc/fortran/parse.cc:359 in decode_statement
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111291 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||error-recovery Last reconfirmed||2023-10-30 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- I see the same when running f951 under valgrind. Thus confirmed.
[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887 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 --- Cleaned up patch submitted: https://gcc.gnu.org/pipermail/fortran/2023-November/059883.html
[Bug fortran/92887] [F2008] Passing nullified/disassociated pointer or unalloc allocatable to OPTIONAL + VALUE dummy fails
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92887 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED Target Milestone|--- |14.0 --- Comment #10 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14.
[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|ASSOCIATE intrinsic does|ASSOCIATED intrinsic does |not recognize a ponter |not recognize a pointer |variable the second time it |variable the second time it |is used |is used Keywords||rejects-valid CC||anlauf at gcc dot gnu.org --- Comment #2 from anlauf at gcc dot gnu.org --- Interesting bug. The code is accepted if the declaration PROCEDURE(proc_void), POINTER:: pADJSensib is moved into the subroutine. In the original form, -fdump-fortran-original shows the following: code: IF _gfortran_associated[[((formulaciones:padjsensib) ((arg not-present)))]] CALL padjsensib () ENDIF IF associated[((calculo:padjsensib))] CALL padjsensib () ENDIF This is weird.
[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245
--- Comment #3 from anlauf at gcc dot gnu.org ---
Potential fix:
diff --git a/gcc/fortran/match.cc b/gcc/fortran/match.cc
index f848e52be4c..9e3571d3dbe 100644
--- a/gcc/fortran/match.cc
+++ b/gcc/fortran/match.cc
@@ -5064,6 +5064,7 @@ gfc_match_call (void)
right association is made. They are thrown out in resolution.)
... */
if (!sym->attr.generic
+ && !sym->attr.proc_pointer
&& !sym->attr.subroutine
&& !sym->attr.function)
{
Regtests OK.
[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245 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 --- Submitted: https://gcc.gnu.org/pipermail/fortran/2023-November/059892.html
[Bug fortran/97245] ASSOCIATED intrinsic does not recognize a pointer variable the second time it is used
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97245 anlauf at gcc dot gnu.org changed: What|Removed |Added Target Milestone|--- |13.3 Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #7 from anlauf at gcc dot gnu.org --- Fixed on mainline for gcc-14, and backported to 13-branch. Closing. Thanks for the report!
[Bug fortran/97045] A wrong column is selected when addressing individual elements of unlimited polymorphic dummy argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97045 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||10.5.0 Known to work||11.3.0 Status|ASSIGNED|WAITING --- Comment #4 from anlauf at gcc dot gnu.org --- This PR seems to have been fixed 3 years ago. @Paul: can we close it?
[Bug fortran/104131] ICE in gfc_conv_array_ref, at fortran/trans-array.c:3810
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104131
--- Comment #5 from anlauf at gcc dot gnu.org ---
The coarray cases in comment#2 will be rejected with:
diff --git a/gcc/fortran/openmp.cc b/gcc/fortran/openmp.cc
index 1cc65d7fa49..08081dacde4 100644
--- a/gcc/fortran/openmp.cc
+++ b/gcc/fortran/openmp.cc
@@ -8967,6 +8967,9 @@ resolve_omp_clauses (gfc_code *code, gfc_omp_clauses
*omp_clauses,
else if (omp_clauses->detach->symtree->n.sym->attr.dimension > 0)
gfc_error ("The event handle at %L must not be an array element",
_clauses->detach->where);
+ else if (omp_clauses->detach->symtree->n.sym->attr.codimension)
+ gfc_error ("The event handle at %L must not be a coarray",
+ _clauses->detach->where);
else if (omp_clauses->detach->symtree->n.sym->ts.type == BT_DERIVED
|| omp_clauses->detach->symtree->n.sym->ts.type == BT_CLASS)
gfc_error ("The event handle at %L must not be part of "
I assume that these are not allowed.
[Bug fortran/104625] ICE in fixup_array_ref, at fortran/resolve.cc:9275 since r10-2912-g70570ec192745095
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=104625 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords|ice-on-invalid-code |ice-on-valid-code CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Intel rejects the code with: pr104625.f90(10): error #8247: Selector in SELECT TYPE statements must be polymorphic value. select type (z => (y)) ^ However, NAG thinks the code is actually valid. And from reading the standard, I do not immediately see that the parentheses should be a problem: F2023 has: C1162 (R1155) If selector is not a named variable, associate-name => shall appear. C1164 (R1155) The selector in a select-type-stmt shall be polymorphic. F2018 has the same wording (slight shift in actual number of constraint). For this reason changing to ice-on-valid.
