[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95979 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Known to work||7.4.1, 8.4.1, 9.3.1 Status|NEW |ASSIGNED Known to fail||10.2.1, 11.0 --- Comment #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-October/055162.html
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and on 10- and 9-branch. Not applied to 8-branch, which did not support the back argument, so not considered worth it. Thanks for the report!
[Bug fortran/92422] [9 Regression] Warning with character and optimisation flags
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92422 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING Known to work||9.3.1 --- Comment #3 from anlauf at gcc dot gnu.org --- Thomas (see comment#1) may still want to commit a testcase to 9-branch before closing as fixed.
[Bug fortran/97408] Handle ac-do-variable KIND argument to intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97408 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|NEW Assignee|anlauf at gcc dot gnu.org |unassigned at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Tobias, can you help explain which parts of the following program are legal then? program p implicit none integer :: i print *, [ integer :: (int (1 , kind=i), i=4,4) ] print *, [(int (1 , kind=i), i=4,4) ] print *, (int (1 , kind=i), i=4,4) end Lines 4 and 5 have array constructors, line 6 is just an ac-implied-do. So by what was quoted lines 4 and 5 are legal, but line 6 is maybe not. That would be very odd and not much fun to check.
[Bug fortran/97408] New: Diagnose non-constant KIND argument to intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97408
Bug ID: 97408
Summary: Diagnose non-constant KIND argument to intrinsics
Product: gcc
Version: unknown
Status: UNCONFIRMED
Severity: normal
Priority: P3
Component: fortran
Assignee: unassigned at gcc dot gnu.org
Reporter: anlauf at gcc dot gnu.org
Target Milestone: ---
While looking at PR91963, I found that non-constant KIND arguments are not
properly diagnosed.
The test:
! { dg-do compile }
!
program p
implicit none
integer :: i
integer, parameter :: lk(1) = [ 4 ]
print *, (int (1 , lk(i)), i=1,1) ! { dg-error "must be a constant" }
print *, (real(1 , lk(i)), i=1,1) ! { dg-error "must be a constant" }
print *, (cmplx (1, kind=lk(i)), i=1,1) ! { dg-error "must be a constant" }
print *, (logical (.true., lk(i)), i=1,1) ! { dg-error "must be a constant" }
end
produces:
kind_2.f90:7:29:
7 | print *, (int (1 , lk(i)), i=1,1) ! { dg-error "must be a
constant" }
| 1
Error: Invalid kind for INTEGER at (1)
kind_2.f90:8:29:
8 | print *, (real(1 , lk(i)), i=1,1) ! { dg-error "must be a
constant" }
| 1
Error: Invalid kind for REAL at (1)
kind_2.f90:9:29:
9 | print *, (cmplx (1, kind=lk(i)), i=1,1) ! { dg-error "must be a
constant" }
| 1
Error: Invalid kind for COMPLEX at (1)
kind_2.f90:10:29:
10 | print *, (logical (.true., lk(i)), i=1,1) ! { dg-error "must be a
constant" }
| 1
Error: Invalid kind for LOGICAL at (1)
but should diagnose:
kind_2.f90:7:29:
7 | print *, (int (1 , lk(i)), i=1,1) ! { dg-error "must be a
constant" }
| 1
Error: 'kind' argument of 'int' intrinsic at (1) must be a constant
kind_2.f90:8:29:
8 | print *, (real(1 , lk(i)), i=1,1) ! { dg-error "must be a
constant" }
| 1
Error: 'kind' argument of 'real' intrinsic at (1) must be a constant
kind_2.f90:9:29:
9 | print *, (cmplx (1, kind=lk(i)), i=1,1) ! { dg-error "must be a
constant" }
| 1
Error: 'kind' argument of 'cmplx' intrinsic at (1) must be a constant
kind_2.f90:10:29:
10 | print *, (logical (.true., lk(i)), i=1,1) ! { dg-error "must be a
constant" }
| 1
Error: 'kind' argument of 'logical' intrinsic at (1) must be a constant
Obvious patch:
diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 1e64fab3401..f2b502af3ca 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -646,7 +646,7 @@ kind_check (gfc_expr *k, int n, bt type)
if (!scalar_check (k, n))
return false;
- if (!gfc_check_init_expr (k))
+ if (!gfc_check_init_expr (k) || k->expr_type == EXPR_VARIABLE)
{
gfc_error ("%qs argument of %qs intrinsic at %L must be a constant",
gfc_current_intrinsic_arg[n]->name, gfc_current_intrinsic,
[Bug fortran/97408] Diagnose non-constant KIND argument to intrinsics
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97408 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-10-13 Status|UNCONFIRMED |ASSIGNED Ever confirmed|0 |1 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-October/055180.html
[Bug fortran/95644] [F2018] IEEE_FMA is missing from the IEEE_ARITHMETIC module
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95644 anlauf at gcc dot gnu.org changed: What|Removed |Added Summary|IEEE_FMA is missing from|[F2018] IEEE_FMA is missing |the IEEE_ARITHMETIC module |from the IEEE_ARITHMETIC ||module --- Comment #3 from anlauf at gcc dot gnu.org --- > Any update on a fix for this? (The original customer is asking.) I assume the customer or Cray didn't set a bounty on this? Adding F2018 to summary.
[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95979 --- Comment #4 from anlauf at gcc dot gnu.org --- (In reply to anlauf from comment #3) > Maybe the issue is related to PR87711, where the optional KIND argument > causes havoc with the elementalness of an intrinsic. (There it is LEN_TRIM). Replying to myself: it seems to be that simplification fails when one of the arguments to INDEX is array-valued. Might be a general issue.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 --- Comment #6 from anlauf at gcc dot gnu.org --- (In reply to Bill Long from comment #5) > The original intent of adding the KIND argument was because some > implementations used a 32-bit integer for the result, and it is possible for > the answer to be larger than 2**31-1. Just checking to be sure that the > underlying library code returns a 64-bit integer that can later be converted > based on the KIND value. Did you try? It's not exactly fast, but program test implicit none integer(8) :: k, l = 10 + 2_8**32 character, allocatable :: a(:) allocate (a(l)) print *, l a(:) = 'a' l = l - 1 a(l) = 'b' print *, l print *, size (a, kind=8) k = maxloc (a, dim=1, kind=8, back=.true.) print *, 'k = ', k, 'a(k) = ', a(k) end works for me on master now on a 64-bit platform: 4294967306 4294967305 4294967306 k =4294967305 a(k) = b
[Bug fortran/82721] [8/9/10/11 Regression] Error message with corrupted text, sometimes ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82721 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #12 from anlauf at gcc dot gnu.org --- On Linux it seems to help setting MALLOC_PERTURB_ to a non-zero value to get a consistent ICE.
[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 Keywords||diagnostic Last reconfirmed||2020-10-16 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- Reduced testcase: program test implicit none integer, parameter :: m=2, n=3 real, allocatable :: r(:,:) allocate (r(m,n)) write(*,*) r(m+1,:) write(*,*) r(m+1,1) end Looking at the tree dump, there are array bounds checks generated for both dimensions in the latter write, but there are suspiciously looking checks for dimension 2 for the first case (r(m+1,:)).
[Bug libfortran/97063] [ MATMUL intrinsic] The value of result is wrong when vector (step size is negative) * matrix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97063 --- Comment #6 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-October/055169.html
[Bug libfortran/97063] [ MATMUL intrinsic] The value of result is wrong when vector (step size is negative) * matrix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97063 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 Component|fortran |libfortran --- Comment #5 from anlauf at gcc dot gnu.org --- I have a patch.
[Bug fortran/96711] Internal Compiler Error on NINT() Function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=96711 --- Comment #21 from anlauf at gcc dot gnu.org --- Please see PR96983 for the fallout. Note that my bandaid fix was rejected in favor of a "real solution" for powerpc*. See the other PR and the Fortran ML for background.
[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Last reconfirmed||2020-10-19 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. I've looked at gfc_impure_variable, but do not understand it.
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272
--- Comment #2 from anlauf at gcc dot gnu.org ---
Untested fix:
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index 3b3bd8629cd..9e9898c2bbf 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -5211,7 +5211,9 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * se, gfc_expr *
expr, enum tree_code op)
while (a->next)
{
b = a->next;
- if (b->expr == NULL || strcmp (b->name, "dim") == 0)
+ if (b->expr == NULL
+ || strcmp (b->name, "dim") == 0
+ || strcmp (b->name, "kind") == 0)
{
a->next = b->next;
b->next = NULL;
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW Last reconfirmed||2020-10-02 Keywords||wrong-code CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed for the case where the kind argument is present: i = maxloc (a, dim=1, kind=8) or i = maxloc (a, dim=1, kind=4) The issue does not occur when the kind argument is not present: i = maxloc (a, dim=1)
[Bug fortran/97272] Wrong answer from MAXLOC with character arg
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97272 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/2020-October/055143.html
[Bug fortran/95979] [10/11 Regression] ICE in get_kind, at fortran/simplify.c:129
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95979 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 master for gcc-11, and on 10-branch. Closing. Thanks for the report!
[Bug libfortran/97581] libgfortran/intrinsics/random.c:754: bad array size ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Status|WAITING |ASSIGNED --- Comment #3 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2020-October/055242.html
[Bug fortran/97592] Incorrectly set pointer remapping with array pointer argument to CONTIGUOUS dummy
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97592 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org --- Comment #1 from anlauf at gcc dot gnu.org --- gfortran seems to see the CONTIGUOUS attribute in the declaration of the dummy argument C_2D of SetPointer, but no corresponding attribute to B_2D. Workaround: add CONTIGUOUS to the declaration of B_2D.
[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491 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 --- Fixed on master so far. If there is no fallout, and if after some waiting time the patch still seems to be safe, I'll consider to backport to 10-branch, as Paul mentioned on the ML.
[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491 --- Comment #2 from anlauf at gcc dot gnu.org --- The patch diff --git a/gcc/fortran/resolve.c b/gcc/fortran/resolve.c index a210f9aad43..096108f4317 100644 --- a/gcc/fortran/resolve.c +++ b/gcc/fortran/resolve.c @@ -16476,6 +16507,7 @@ gfc_impure_variable (gfc_symbol *sym) proc = sym->ns->proc_name; if (sym->attr.dummy + && !sym->attr.value && ((proc->attr.subroutine && sym->attr.intent == INTENT_IN) || proc->attr.function)) return 1; regtests fine. Not sure if this is the best solution, since older Fortran standards seemed to require INTENT(IN) for dummy x, while F2018 forbids INTENT(INOUT) and INTENT(OUT), as well as ALLOCATABLE, POINTER and VOLATILE here.
[Bug libfortran/97581] libgfortran/intrinsics/random.c:754: bad array size ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
(In reply to David Binderman from comment #0)
> gcc has a new warning, so a problem is found in fortran library.
>
> libgfortran/intrinsics/random.c:754:37: warning: expression does not compute
> the number of elements in this array; element type is ‘uint64_t’ {aka ‘long
> unsigned int’}, not ‘GFC_INTEGER_4’ {aka ‘int’} [-Wsizeof-array-div]
>
> Source code is
>
> #define SZ (sizeof (master_state.s) / sizeof (GFC_INTEGER_4))
>
> Maybe better code
>
> #define SZ (sizeof (master_state.s) / sizeof (master_state.s[0]))
No, this would be definitely wrong.
The purpose of RANDOM_SEED is to set/get the internal state of the PRNG in
an array of integers, with the size depending on the kind of the argument.
The function random_seed_i4 uses GFC_INTEGER_4 for that purpose.
If the original code does not make you happy, do you think sth. along
#define SZ (SZU64 * (sizeof (uint64_t) / sizeof (GFC_INTEGER_4)))
would be better?
[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491 --- Comment #3 from anlauf at gcc dot gnu.org --- Submitted here: https://gcc.gnu.org/pipermail/fortran/2020-October/055235.html
[Bug libfortran/97581] libgfortran/intrinsics/random.c:754: bad array size ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |WAITING Last reconfirmed||2020-10-26 Ever confirmed|0 |1
[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||anlauf at gcc dot gnu.org See Also||https://gcc.gnu.org/bugzill ||a/show_bug.cgi?id=97039 --- Comment #9 from anlauf at gcc dot gnu.org --- (In reply to markeggleston from comment #8) > Changing to allocated arrays and bounds checking does not work at compile > time but does at runtime: > > program test > real, allocatable :: x(:) > allocate(x(10)) > x = 0.0 > print *, x(0) > deallocate(x) > end program test > > $ gfortran -fbounds-check pr30802.f90 > $ ./a.out > > At line 5 of file pr30802.f90 > Fortran runtime error: Index '0' of dimension 1 of array 'x' below lower > bound of 1 > > Error termination. Backtrace: > #0 0x400ea1 in ??? > #1 0x400f6d in ??? > #2 0x4380b2 in ??? > #3 0x438471 in ??? > #4 0x400c69 in ??? I think the point is that bounds-checking does not work for sections of rank-2 arrays. See also PR97039. This is not I/O specific, but what Thomas said in comment#3.
[Bug libfortran/97063] [ MATMUL intrinsic] The value of result is wrong when vector (step size is negative) * matrix
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97063 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #11 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11, and on all open branches (10/9/8). Closing. Thanks for the report!
[Bug fortran/97547] How to fix problem causing warning?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97547 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |MOVED CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- Comment#0 is about a specific installation. Please report to the Cygwin people.
[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
CC||anlauf at gcc dot gnu.org
--- Comment #1 from anlauf at gcc dot gnu.org ---
Looking at the dump-tree of a reduced case reveals that simplification
of the line with the ACOS of the array constructor causes the difference:
subroutine bpr_init
implicit none
integer :: i
real :: tacos2(2)
tacos2 = acos( (/ (i, i=1,size(tacos2)) /) / 2.0)
end subroutine bpr_init
11-master:
bpr_init ()
{
integer(kind=4) i;
real(kind=4) tacos2[2];
{
static real(kind=4) A.0[2] = {1.0471975803375244140625e+0, 0.0};
(void) __builtin_memcpy ((void *) , (void *) , 8);
}
}
older versions:
bpr_init ()
{
integer(kind=4) i;
real(kind=4) tacos2[2];
{
static real(kind=4) A.0[2] = {5.0e-1, 1.0e+0};
{
integer(kind=8) S.1;
S.1 = 0;
while (1)
{
if (S.1 > 1) goto L.1;
tacos2[S.1] = __builtin_acosf (A.0[S.1]);
S.1 = S.1 + 1;
}
L.1:;
}
}
}
So the new compiler does compile-time simplification already at -O0, while
older versions maybe not.
[Bug fortran/98445] Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-12-26 Status|UNCONFIRMED |WAITING Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Can you explain when did this become valid? And which compiler accepts this? Intel v21 also rejects it with a similar error: pr98445.f90(31): error #6478: A type-name must not be used as a variable. [T] call s(t) ---^ plus some more.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 anlauf at gcc dot gnu.org changed: What|Removed |Added Last reconfirmed||2020-12-27 CC||anlauf at gcc dot gnu.org Status|UNCONFIRMED |NEW Ever confirmed|0 |1 --- Comment #2 from anlauf at gcc dot gnu.org --- I think there already exists at least one PR with issues with initializers. A reduced testcase shows that default initialization works for intent(out), whereas you get random junk for function results. module m_test implicit none type t integer :: unit = -1 end type t interface test module procedure test_fun end interface contains function test_fun() result(res) type(t) :: res !res = t() ! <-- workaround end function test_fun subroutine test_sub (res) type(t), intent(out) :: res end subroutine test_sub end module m_test program p use m_test implicit none type(t) :: x write(6,*) 'Before constructor' write(6,*) ' unit = ', x%unit x = test() write(6,*) 'After constructor (test_fun)' write(6,*) ' unit = ', x%unit call test_sub (x) write(6,*) 'After test_sub' write(6,*) ' unit = ', x%unit end program p If you need a workaround, uncomment the indicated line.
[Bug fortran/85877] [8/9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877 --- Comment #6 from anlauf at gcc dot gnu.org --- Digging some more, it appears that the logic in resolve.c is incomplete. There is some inconsistency between what is dealt with in resolve_symbol and in resolve_fl_procedure. resolve_symbol: 15637 if (sym->attr.is_bind_c && sym->attr.use_assoc == 0 15638 && sym->attr.dummy == 0 && sym->attr.flavor != FL_PROCEDURE 15639 && sym->attr.flavor != FL_DERIVED) Commenting out the second half of line 15638 (sym->attr.flavor != FL_PROCEDURE) fixed the issue, but hell breaks loose in regtesting...
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #3 from anlauf at gcc dot gnu.org --- According to the tree-dump, adding a print *, res% unit to the function body invokes the implicit initializer, while the line res = t() actually invokes the initializer effectively twice!
[Bug fortran/98445] Bogus error: derived type used as an actual argument
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98445 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|WAITING |RESOLVED --- Comment #4 from anlauf at gcc dot gnu.org --- OK, closing as invalid as suggested by the original submitter.
[Bug fortran/98454] Apparent wrong initialization in function result
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98454 --- Comment #5 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #4) > Should be closed as invalid as the original code contains a number > of issues caused by invalid code. Steve, stop it! My reduced testcase shows that there is a real bug.
[Bug fortran/92736] [9 Regression] Error when using a variable from a module in a submodule and its parent module.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=92736 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED CC||anlauf at gcc dot gnu.org --- Comment #10 from anlauf at gcc dot gnu.org --- Backported to 9-branch with commit r9-9155. Applied cleanly and regtested fine. Closing. Thanks for the report!
[Bug fortran/88356] [9/10/11 Regression] ICE with -Werror in reduce_binary_ac, at fortran/arith.c:1318 (and others)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=88356 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |WAITING CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- Can't reproduce any of the issues in comment#0 and comment#1 with current HEAD on x86_64-pc-linux-gnu. Has this been "accidentally" solved?
[Bug fortran/98577] Wrong "count_rate" values with int32 and real32 if the "count" argument is int64.
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98577 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |INVALID Status|UNCONFIRMED |RESOLVED --- Comment #1 from anlauf at gcc dot gnu.org --- This is standard conforming and documented. See https://gcc.gnu.org/onlinedocs/gfortran/SYSTEM_005fCLOCK.html COUNT_RATE is system dependent and can vary depending on the kind of the arguments. For kind=4 arguments (and smaller integer kinds), COUNT represents milliseconds, while for kind=8 arguments (and larger integer kinds), COUNT typically represents micro- or nanoseconds depending on resolution of the underlying platform clock. COUNT_MAX usually equals HUGE(COUNT_MAX). Note that the millisecond resolution of the kind=4 version implies that the COUNT will wrap around in roughly 25 days. In order to avoid issues with the wrap around and for more precise timing, please use the kind=8 version.
[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 78746, which changed state. Bug 78746 Summary: charlen_03, charlen_10 ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/78746] charlen_03, charlen_10 ICE
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|ASSIGNED|RESOLVED --- Comment #26 from anlauf at gcc dot gnu.org --- Should be fixed on master for gcc-11, and on 10- and 9-branch. Validated with valgrind that class_61.f90 no longer shows the issue. 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 78746, which changed state. Bug 78746 Summary: charlen_03, charlen_10 ICE https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78746 What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED
[Bug fortran/89661] FAIL: gfortran.dg/class_61.f90 -O (internal compiler error)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |FIXED Status|NEW |RESOLVED --- Comment #9 from anlauf at gcc dot gnu.org --- The issue found with valgrind should be fixed, see PR78746. Closing. Thanks for the report!
[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 89661, which changed state. Bug 89661 Summary: FAIL: gfortran.dg/class_61.f90 -O (internal compiler error) https://gcc.gnu.org/bugzilla/show_bug.cgi?id=89661 What|Removed |Added Status|NEW |RESOLVED Resolution|--- |FIXED
[Bug fortran/60576] [8/9/10/11 Regression] FAIL: gfortran.dg/assumed_rank_7.f90
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=60576 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|REOPENED|WAITING CC||anlauf at gcc dot gnu.org --- Comment #32 from anlauf at gcc dot gnu.org --- I cannot reproduce the issue with 8-branch and newer on x86_64-pc-linux-gnu, also valgrind seems to be happy enough. If the issue still persists, could someone please identify the currently failing versions?
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 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 --- It's much more interesting than a mere regression. Reduced and modified testcase: program p implicit none integer :: i character(*), parameter :: exprs(1) = ['abc()'] print *, (pack(exprs,exprs(:)(:1)=='a'),i=1,1) print *, (pack(exprs,exprs(:)(:1)=='a') ) end 7.4.1 gives: abc() a 8.4.1 and later give: a a Expected output: abc() abc()
[Bug fortran/85796] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796 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 master for gcc-11, and backported to 10-branch. Closing. Thanks for the report!
[Bug fortran/97977] Fortran deferred length strings incompatible with OMP
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97977 anlauf at gcc dot gnu.org changed: What|Removed |Added Known to fail||11.0 Status|UNCONFIRMED |NEW Last reconfirmed||2020-11-25 Ever confirmed|0 |1 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. The issue occurs when assigning to at least one of string1/string2 twice. When lifting the thread limit, I've also seen SIGSEGV.
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Last reconfirmed|2020-01-29 00:00:00 |2020-12-6 Priority|P3 |P4 --- Comment #2 from anlauf at gcc dot gnu.org --- Reduced even further. program p print *, +[ real :: +(1) ] print *, +[ real :: +[1] ] end
[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 CC||anlauf at gcc dot gnu.org --- Comment #7 from anlauf at gcc dot gnu.org --- Intel and PGI/Nvidia work w/o problems on my Linux system. We might try to solve it in a similar way.
[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 Status|WAITING |NEW --- Comment #9 from anlauf at gcc dot gnu.org --- The patch seems to regtest ok, but certainly needs some wider testing. NIST? Other I/O test suites? May also need some cosmetic cleanup to match GNU coding style.
[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129 --- Comment #8 from anlauf at gcc dot gnu.org --- Created attachment 49687 --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=49687=edit Untested patch (proof of concept) Here's a possible patch that retries after short reads. Not regtested.
[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #8 from anlauf at gcc dot gnu.org --- For on mainline for gcc-11, and on 10- and 9-branch. Closing. Thanks for the report!
[Bug libfortran/98129] Failure on reading big chunk of /dev/urandom
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98129 --- Comment #11 from anlauf at gcc dot gnu.org --- (In reply to Thomas Koenig from comment #10) > Seems like that, if nbyte <= MAX_CHUNK, we do not take account of the > possibility of a short read. Yes, that seems to be the better/right place.
[Bug fortran/93483] ICE in gfc_constructor_copy, at fortran/constructor.c:103
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93483
--- Comment #3 from anlauf at gcc dot gnu.org ---
The case
program p
print *, +[ real :: +(1) ]
end
is solved by e.g.
diff --git a/gcc/fortran/arith.c b/gcc/fortran/arith.c
index c4c1041afdf..b2fbeddeb49 100644
--- a/gcc/fortran/arith.c
+++ b/gcc/fortran/arith.c
@@ -1268,6 +1268,11 @@ reduce_unary (arith (*eval) (gfc_expr *, gfc_expr **),
gfc_expr *op,
head = gfc_constructor_copy (op->value.constructor);
for (c = gfc_constructor_first (head); c; c = gfc_constructor_next (c))
{
+ if (c->expr->expr_type == EXPR_FUNCTION
+ && c->expr->value.function.isym
+ && c->expr->value.function.isym->elemental)
+ gfc_simplify_expr (c->expr, 1);
+
rc = reduce_unary (eval, c->expr, );
if (rc != ARITH_OK)
Another case of missed simplification?
[Bug fortran/85796] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796 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 --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2020-November/055325.html Thus taking.
[Bug fortran/95342] [9/10/11 Regression] ICE in gfc_match_subroutine, at fortran/decl.c:7913
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95342 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |ASSIGNED CC||anlauf at gcc dot gnu.org Known to fail||10.2.1, 11.0, 9.3.1 Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Known to work||7.4.1, 8.4.1 --- Comment #4 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-November/055356.html
[Bug fortran/91300] Wrong runtime error message with allocate and errmsg=
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=91300 --- Comment #6 from anlauf at gcc dot gnu.org --- Currently the only generated STAT code is 5014 for LIBERROR_ALLOCATION. This is ambiguous. Shall we add another enum value to libgfortran_error_codes, such as LIBERROR_VIRTUAL_MEMORY, LIBERROR_MEMORY, or LIBERROR_ALLOCATED?
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 --- Comment #3 from anlauf at gcc dot gnu.org --- Further reduced variant: program p implicit none character(*), parameter :: exprs(1) = ['abc()'] print *, len (pack ( exprs , exprs(:)(:1) =='a')) print *, len (pack (['abc()'],['abc()' (:1)]=='a')) end gcc-7 prints: 5 5 while 8 and newer print: 1 5 My debugging attempts so far suggest that this part of expr.c corrupts the string length: 227 if (e->expr_type == EXPR_VARIABLE && e->rank > 0 228 && e->symtree->n.sym->attr.flavor == FL_PARAMETER) 229 gfc_simplify_expr (e, 1); After gfc_simplify_expr (e, 1), (gdb) p *e->ts.u.cl->length->value.integer._mp_d $34 = 1 for the first variant, while we don't simplify for the second and keep (gdb) p *e->ts.u.cl->length->value.integer._mp_d $37 = 5
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 anlauf at gcc dot gnu.org changed: What|Removed |Added Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Host|ubuntu 20.04| Keywords||wrong-code Priority|P3 |P4 Target Milestone|--- |8.5 Status|NEW |ASSIGNED --- Comment #4 from anlauf at gcc dot gnu.org --- I have a patch.
[Bug fortran/98017] [8/9/10/11 Regression] Suspected regression (relative to 7.5) using PACK in iolist since r8-4151-g6c6bde30706c29ff
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98017 --- Comment #5 from anlauf at gcc dot gnu.org --- Patch: https://gcc.gnu.org/pipermail/fortran/2020-November/055367.html
[Bug fortran/98023] ICE: free_expr0(): Bad expr type
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98023 --- Comment #3 from anlauf at gcc dot gnu.org --- The patch in comment#1 does not work for me on x86_64-pc-linux-gnu. In decl.c: 6242cleanup: 6243 if (saved_kind_expr) 6244gfc_free_expr (saved_kind_expr); 6245 if (type_param_spec_list) 6246gfc_free_actual_arglist (type_param_spec_list); (gdb) p type_param_spec_list->expr->expr_type $177 = 42350080 So type_param_spec_list really gets screwed up.
[Bug fortran/97571] long parsing phase for simple array constructor
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97571 --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to Dominique d'Humieres from comment #2) > > So the new compiler does compile-time simplification already at -O0, > > while older versions maybe not. > > Is this expected? Depends. I'd expect constant expressions like this to be simplified. There could be (artificial) limits when to give up. The tree dump does not really give me the impression nor enough information to know that this happens with previous version of the compiler at this stage.
[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 Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-21 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed.
[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 Priority|P3 |P4 CC||anlauf at gcc dot gnu.org
[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98307 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 master for gcc-11, and backported to all open branches. Closing. Thanks for the report!
[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
CC||anlauf at gcc dot gnu.org
--- Comment #5 from anlauf at gcc dot gnu.org ---
There is also a related missed simplification of substrings.
The dump-tree of
subroutine p
call foo ('abcd'(1:1))
end
is:
void p ()
{
foo (&"abcd"[1]{lb: 1 sz: 1}, 1);
}
I'd expect:
void p ()
{
foo (&"a"[1]{lb: 1 sz: 1}, 1);
}
which we get for
call foo ('a'(1:1))
or
call foo ('a')
[Bug fortran/98433] double free detected in tcache 2, after merge of structures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98433 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|UNCONFIRMED |NEW CC||anlauf at gcc dot gnu.org Last reconfirmed||2020-12-24 Ever confirmed|0 |1 --- Comment #5 from anlauf at gcc dot gnu.org --- The user code is alright, it is the implementation of the intrinsic MERGE which prevents doing the right thing when assigning to the l.h.s. Extending the subroutine of the test program to module bug_merge_m implicit none contains subroutine bug_merge type t real, allocatable :: v(:) end type t type(t) :: x1, x2, x3, x4, x5 logical :: f = .false. allocate(x1%v(1)) x1%v = 1. allocate(x2%v(1)) x2%v = 2. x3 = merge(x1, x2, .false.) print *, "x3%v = ", x3%v x4 = merge(x1, x2, f) print *, "x4%v = ", x4%v if (f) then; x5 = x1; else; x5 = x2; endif print *, "x5%v = ", x5%v end subroutine bug_merge end module bug_merge_m and looking a the generated dump-tree, one sees that the assignments to x3 and x4 are generating wrong code, only the assignment to x5 is fine. @Steve: that's pretty basic F2003 stuff, almost TR15581...
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685 anlauf at gcc dot gnu.org changed: What|Removed |Added Keywords||ice-on-valid-code CC||anlauf at gcc dot gnu.org --- Comment #3 from anlauf at gcc dot gnu.org --- (In reply to markeggleston from comment #1) > I think the issues of error messages and -std can be postponed until the > next release. The current status is that program p type u integer, pointer :: i end type u type(u) :: y integer , target :: i = 10 data y%i /i/ print *, y%i end works with current master, while the (valid) code program p type t character, pointer :: a end type t type(t) :: x character, target :: c = 'c' data x%a /c/ print *, x%a end still ICEs the same as the (invalid) testcase in comment#0.
[Bug fortran/95372] ICE in find_array_section, at fortran/expr.c:1687
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=95372 --- Comment #3 from anlauf at gcc dot gnu.org --- Playing around with the above patches, I found that the following now gets rejected instead of an ICE: program p type t integer :: a = 1 end type t type(t), parameter :: z(3) = t() type(t):: v(1) = z(2:2) ! Rejected ! type(t):: v(1) = [z(2:2)] ! Rejected print *, v% a end pr95372-1.f90:6:3: 6 | type(t):: v(1) = z(2:2) ! Rejected | 1 Error: Unclassifiable statement at (1) pr95372-1.f90:8:14: 8 | print *, v% a | 1 Error: Symbol 'v' at (1) has no IMPLICIT type This is a consequence of find_array_section returning false instead of true. However, removing the t=false from the patch the original testcase will ICE in a different place. Staring some more at the code in find_array_section, it appears that there is a stale cons = gfc_constructor_first (base); followed later by the critical cons = gfc_constructor_lookup (base, limit); Strange. And "git blame" so far did not really help me much.
[Bug fortran/98284] ICE in get_array_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98284 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|NEW |RESOLVED Assignee|unassigned at gcc dot gnu.org |anlauf at gcc dot gnu.org Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Fixed on master for gcc-11. Thanks for the reduced testcase and for draft patch!
[Bug fortran/98284] ICE in get_array_index
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98284 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 --- Steve, https://gcc.gnu.org/pipermail/fortran/2020-December/055427.html is mostly your patch, but with adjusted locus. Try data & ...
[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98307 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/2020-December/055430.html
[Bug fortran/98307] Dependency check fails when using "allocatable" instead of "pointer" (forall_3.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98307 --- Comment #2 from anlauf at gcc dot gnu.org --- I'm regtesting the following patch candidate: diff --git a/gcc/fortran/trans-stmt.c b/gcc/fortran/trans-stmt.c index adc6b8fefb5..e35b2f9ed34 100644 --- a/gcc/fortran/trans-stmt.c +++ b/gcc/fortran/trans-stmt.c @@ -3951,7 +3951,8 @@ check_forall_dependencies (gfc_code *c, stmtblock_t *pre, stmtblock_t *post) pointer components. We therefore leave these to their own devices. */ if (lsym->ts.type == BT_DERIVED - && lsym->ts.u.derived->attr.pointer_comp) + && (lsym->ts.u.derived->attr.pointer_comp + || lsym->ts.u.derived->attr.alloc_comp)) return need_temp; new_symtree = NULL;
[Bug fortran/98307] use "allocatable" instead of "pointer" (forall_3.f90)
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98307 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Known to fail||10.2.1, 11.0, 8.4.1, 9.3.1 Status|UNCONFIRMED |NEW Keywords||wrong-code Ever confirmed|0 |1 Last reconfirmed||2020-12-16 --- Comment #1 from anlauf at gcc dot gnu.org --- Confirmed. Enforcing the creation of a temporary in the forall fixes the issue. Something is missing in the logic of check_forall_dependencies(). Reduced testcase: program evil_forall implicit none type t logical :: valid = .true. integer :: s = 0 !integer, dimension(:), pointer :: p integer, dimension(:), allocatable :: p end type type(t) :: v(2) integer :: i allocate (v(1)%p(8)) allocate (v(2)%p(8)) v(1)%s= 8 v(2)%s= 6 v(1)%p(:) = (/1, 2, 3, 4, 5, 6, 7, 8/) v(2)%p(:) = (/13, 14, 15, 16, 17, 18, 19, 20/) !forall (i=1:2, v(i)%valid) forall (i=1:2) v(i)%p(1:v(i)%s) = v(3-i)%p(1:v(i)%s) end forall if (any(v(2)%p(:) .ne. (/1, 2, 3, 4, 5, 6, 19, 20/))) stop 1 end program
[Bug fortran/85877] [8/9/10/11 Regression] ICE in fold_convert_loc, at fold-const.c:2449
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85877 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Keywords|ice-on-valid-code |ice-on-invalid-code --- Comment #5 from anlauf at gcc dot gnu.org --- I doubt that the testcase in comment#0 is actually valid. In fact, it is empirically rejected by most compilers. E.g. Intel v21: pr85877.f90(2): error #8067: If any bind-entity in a bind-stmt is an entity-name, the bind-stmt shall appear in the specification part of a module. [F] bind(c) f --^ pr85877.f90(3): error #6410: This name has not been declared as an array or a function. [F] x = f() --^ The F2018 standard has a few things here, e.g. on the BIND statement ! 8.6.4 BIND statement ! ... ! The BIND statement specifies the BIND attribute for a list of variables ! and common blocks. ! 18.3.6 Interoperability of procedures and procedure interfaces ! A Fortran procedure is interoperable if and only if it has the BIND ! attribute, that is, if its interface is specified with a ! proc-language-binding-spec. Since there is no explicit interface, c.f. ! 15.4.2.2 Explicit interface ! Within the scope of a procedure identifier, the procedure shall have an ! explicit interface if it is not a statement function and ! ... ! (6) the procedure has the BIND attribute. While I'm not sure that Intel has all the wording right, the reason is almost right. ;-) Thus changing to ice-on-invalid.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278
anlauf at gcc dot gnu.org changed:
What|Removed |Added
CC||anlauf at gcc dot gnu.org
Keywords||ice-on-valid-code,
||wrong-code
--- Comment #21 from anlauf at gcc dot gnu.org ---
There's also valid code that ICEs, and invalid code that is silently accepted.
Invalid code:
program p
implicit none
integer, parameter :: b = 1
data b / 2 /
print *, b
end
Instead of being rejected, this prints:
1
One could catch this one in gfc_assign_data_value, but I haven't found out
yet how to get this right with derived type components, so there's possibly
a better place.
And after fixing an obvious NULL pointer dereference,
diff --git a/gcc/fortran/trans-decl.c b/gcc/fortran/trans-decl.c
index 37a0c85fa30..783a0bbddcc 100644
--- a/gcc/fortran/trans-decl.c
+++ b/gcc/fortran/trans-decl.c
@@ -5520,7 +5520,7 @@ check_constant_initializer (gfc_expr *expr, gfc_typespec
*ts, bool array,
return false;
cm = expr->ts.u.derived->components;
for (c = gfc_constructor_first (expr->value.constructor);
- c; c = gfc_constructor_next (c), cm = cm->next)
+ c && cm; c = gfc_constructor_next (c), cm = cm->next)
{
if (!c->expr || cm->attr.allocatable)
continue;
we arrive at wrong code on valid input:
program p
implicit none
type t
real :: a
end type t
type(t) :: z = t(4.0)
data z%a /3.0/
print *, z%a
end
This now prints
4.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #22 from anlauf at gcc dot gnu.org --- The -fdump-fortran-original of the last example in comment#21 contains symtree: 'z' || symbol: 'z' type spec : (DERIVED t) attributes: (VARIABLE IMPLICIT-SAVE DATA) value: t(4. , 3.) so perhaps we should properly overwrite or merge with the default initializer instead of appending?
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #25 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #24) > (In reply to anlauf from comment #21) > Looks like the patch from comment #2 that I posted 9 years ago. LoL. > Bug must not hit real code too often as no one has fixed it. Well, there are multiple places with almost identical un-code.
[Bug fortran/49278] ICE (segfault) when combining DATA with default initialization
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=49278 --- Comment #26 from anlauf at gcc dot gnu.org --- (In reply to kargl from comment #23) > (In reply to anlauf from comment #21) > > There's also valid code that ICEs, and invalid code that is silently > > accepted. > > > > Invalid code: > > > > program p > > implicit none > > integer, parameter :: b = 1 > > data b / 2 / > > print *, b > > end > > > > Instead of being rejected, this prints: > >1 > > You need know about gfortran's extensions. > > % gfcx -Wall -o z -std=f95 a.f90 > a.f90:4:12: > > 4 | data b / 2 / > |1 > Error: GNU Extension: re-initialization of 'b' at (1) I hope you noticed the PARAMETER, which should have been caught by -fno-writable-parameters ... ;-)
[Bug fortran/93337] [9/10/11 Regression] ICE in gfc_dt_upper_string, at fortran/module.c:441
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93337
--- Comment #12 from anlauf at gcc dot gnu.org ---
The valgrind invalid read is possibly an issue with error recovery when
handling
the assignment.
Modifying the testcase:
program p
type t
character(:), allocatable :: a
end type t
class(t), allocatable :: y
class(t) :: x ! { dg-error "must be dummy, allocatable or pointer" }
y = x
end
one still gets the invalid read; swapping x and y in the assignment it
disappears.
Could you open a new PR to simplify tracking?
[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 CC||anlauf at gcc dot gnu.org 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/2020-December/055420.html
[Bug fortran/98263] valgrind error in gfc_find_derived_vtab
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=98263 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||anlauf at gcc dot gnu.org Ever confirmed|0 |1 Status|UNCONFIRMED |NEW Last reconfirmed||2020-12-13 --- Comment #2 from anlauf at gcc dot gnu.org --- Confirmed. A slightly modified version of pr93337.f90 suggests that the invalid read happens when dealing with the assignment: program p type t character(:), allocatable :: a end type t class(t), allocatable :: y class(t) :: x y = x end Swapping x and y in the assignment makes the invalid read disappear. Either the parsing or resolution of the assignment causes the issue, or there is corruption during error recovery. Apparently the fix for PR93337 uncovered this (latent) issue.
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685
--- Comment #4 from anlauf at gcc dot gnu.org ---
A first attempt to fix the character / non-character issue seem to require
a replacement of the following hunk from
commit eb401400f59e4d1f28bbdc788c3234e0968081d7
Author: Andre Vehreschild
Date: Wed Dec 14 12:52:09 2016 +0100
re PR fortran/78672 (Gfortran test suite failures with a sanitized
compiler)
diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c
index 139ce880534..ea19732ccc3 100644
--- a/gcc/fortran/data.c
+++ b/gcc/fortran/data.c
@@ -483,7 +483,10 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr *rvalue,
mpz_t index,
if (ref || last_ts->type == BT_CHARACTER)
{
- if (lvalue->ts.u.cl->length == NULL && !(ref && ref->u.ss.length !=
NULL))
+ /* An initializer has to be constant. */
+ if (rvalue->expr_type != EXPR_CONSTANT
+ || (lvalue->ts.u.cl->length == NULL
+ && !(ref && ref->u.ss.length != NULL)))
return false;
expr = create_character_initializer (init, last_ts, ref, rvalue);
}
by
diff --git a/gcc/fortran/data.c b/gcc/fortran/data.c
index 3e52a5717b5..76ddd9dab7f 100644
--- a/gcc/fortran/data.c
+++ b/gcc/fortran/data.c
@@ -546,12 +546,11 @@ gfc_assign_data_value (gfc_expr *lvalue, gfc_expr
*rvalue, mpz_t index,
return false;
}
- if (ref || last_ts->type == BT_CHARACTER)
+ if (ref || (last_ts->type == BT_CHARACTER
+ && rvalue->expr_type == EXPR_CONSTANT))
{
/* An initializer has to be constant. */
- if (rvalue->expr_type != EXPR_CONSTANT
- || (lvalue->ts.u.cl->length == NULL
- && !(ref && ref->u.ss.length != NULL)))
+ if (lvalue->ts.u.cl->length == NULL && !(ref && ref->u.ss.length !=
NULL))
return false;
expr = create_character_initializer (init, last_ts, ref, rvalue);
}
which fixes the ICE to the second testcase in comment#3.
However, it changes the traceback for comment#0 to:
pr93685.f90:1:9:
1 | program p
| 1
internal compiler error: in gfc_conv_string_init, at fortran/trans-const.c:148
0x79a56a gfc_conv_string_init(tree_node*, gfc_expr*)
../../gcc-trunk/gcc/fortran/trans-const.c:148
0x7c735f gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-trunk/gcc/fortran/trans-expr.c:7883
0x7c79e6 gfc_conv_structure(gfc_se*, gfc_expr*, int)
../../gcc-trunk/gcc/fortran/trans-expr.c:8754
0x7c7391 gfc_conv_initializer(gfc_expr*, gfc_typespec*, tree_node*, bool, bool,
bool)
../../gcc-trunk/gcc/fortran/trans-expr.c:7876
0x7a7f2a gfc_get_symbol_decl(gfc_symbol*)
../../gcc-trunk/gcc/fortran/trans-decl.c:1917
0x7aba8f generate_local_decl
../../gcc-trunk/gcc/fortran/trans-decl.c:5950
0x75bf12 do_traverse_symtree
../../gcc-trunk/gcc/fortran/symbol.c:4171
0x7acfcc generate_local_vars
../../gcc-trunk/gcc/fortran/trans-decl.c:6156
0x7acfcc gfc_generate_function_code(gfc_namespace*)
../../gcc-trunk/gcc/fortran/trans-decl.c:6815
0x724cc7 translate_all_program_units
../../gcc-trunk/gcc/fortran/parse.c:6351
0x724cc7 gfc_parse_file()
../../gcc-trunk/gcc/fortran/parse.c:6620
0x77187f gfc_be_parse_file
../../gcc-trunk/gcc/fortran/f95-lang.c:212
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685
--- Comment #5 from anlauf at gcc dot gnu.org ---
The following seems to do the latter job:
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index bfe08be2a94..f66afab85d1 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -7877,12 +7877,14 @@ gfc_conv_initializer (gfc_expr * expr, gfc_typespec *
ts, tree type,
return se.expr;
case BT_CHARACTER:
- {
- tree ctor = gfc_conv_string_init (ts->u.cl->backend_decl,expr);
- TREE_STATIC (ctor) = 1;
- return ctor;
- }
+ if (expr->expr_type == EXPR_CONSTANT)
+ {
+ tree ctor = gfc_conv_string_init (ts->u.cl->backend_decl, expr);
+ TREE_STATIC (ctor) = 1;
+ return ctor;
+ }
+ /* Fallthrough. */
default:
gfc_init_se (, NULL);
gfc_conv_constant (, expr);
[Bug fortran/93685] [9/10/11 Regression] ICE in gfc_constructor_append_expr, at fortran/constructor.c:135
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93685 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 #6 from anlauf at gcc dot gnu.org --- Patch submitted: https://gcc.gnu.org/pipermail/fortran/2020-December/055452.html
[Bug fortran/97768] [10/11 Regression] 32-bit f951 ICE on code from OpenMolcas
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97768
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|UNCONFIRMED |NEW
Last reconfirmed||2020-11-09
Ever confirmed|0 |1
CC||anlauf at gcc dot gnu.org
Priority|P3 |P4
--- Comment #5 from anlauf at gcc dot gnu.org ---
So sth. technically similar to
diff --git a/gcc/fortran/misc.c b/gcc/fortran/misc.c
index 65bcfa6162f..1338f7e3114 100644
--- a/gcc/fortran/misc.c
+++ b/gcc/fortran/misc.c
@@ -224,6 +224,14 @@ gfc_typename (gfc_expr *ex)
if (ex->ts.type == BT_CHARACTER)
{
+ if (ex->expr_type != EXPR_CONSTANT)
+ {
+ if (ex->ts.kind == gfc_default_character_kind)
+ sprintf (buffer, "CHARACTER");
+ else
+ sprintf (buffer, "CHARACTER(KIND=%d)", ex->ts.kind);
+ return buffer;
+ }
if (ex->ts.u.cl && ex->ts.u.cl->length)
length = gfc_mpz_get_hwi (ex->ts.u.cl->length->value.integer);
else
(or a cleaned up version of that function) would solve this?
[Bug fortran/82314] internal compiler error: in gfc_conv_expr_descriptor, at fortran/trans-array.c:6972
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=82314 --- Comment #7 from anlauf at gcc dot gnu.org --- The ICE in comment#0 vanishes when one replaces integer,parameter::iarray(merge(2,3,.true.)) = 1 with integer,parameter::iarray(merge(2,3,.true.)) = [ 1, 1 ]
[Bug fortran/85796] ICE: Floating point exception
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=85796 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 --- Jerry, are you still following this one?
[Bug fortran/97799] Passing CHARACTER*(*) var(*) through ENTRY causes segfaults
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97799 --- Comment #6 from anlauf at gcc dot gnu.org --- I couldn't find any current 11-master, 10-, 9- and 8-branch version that fails on x86_64-pc-linux-gnu, under valgrind, and with -m32 and -m64. So it looks very likely that Dominique is right that this has been fixed everywhere. Otherwise please provide more details on your environment.
[Bug libfortran/48958] Add runtime diagnostics for SIZE intrinsic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48958 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 --- Incomplete patch: https://gcc.gnu.org/pipermail/fortran/2020-November/055300.html
[Bug fortran/48958] Add runtime diagnostics for SIZE intrinsic function
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=48958
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Priority|P3 |P5
Status|SUSPENDED |NEW
CC|anlauf at gmx dot de |
Component|libfortran |fortran
--- Comment #7 from anlauf at gcc dot gnu.org ---
The question on what to do with runtime checks and possibly undefined pointers,
which has been repeated by Thomas on the ML, could be solved by initializing
the data component when -fcheck=pointer is specified.
A somewhat hackish solution which regtests cleanly:
diff --git a/gcc/fortran/trans-array.c b/gcc/fortran/trans-array.c
index b2c39aa32de..6e1f27ead45 100644
--- a/gcc/fortran/trans-array.c
+++ b/gcc/fortran/trans-array.c
@@ -10668,7 +10668,9 @@ gfc_trans_deferred_array (gfc_symbol * sym,
gfc_wrapped_block * block)
}
/* NULLIFY the data pointer, for non-saved allocatables. */
- if (GFC_DESCRIPTOR_TYPE_P (type) && !sym->attr.save &&
sym->attr.allocatable)
+ if (GFC_DESCRIPTOR_TYPE_P (type) && !sym->attr.save
+ && (sym->attr.allocatable
+ || (sym->attr.pointer && (gfc_option.rtcheck &
GFC_RTCHECK_POINTER
{
gfc_conv_descriptor_data_set (, descriptor, null_pointer_node);
if (flag_coarray == GFC_FCOARRAY_LIB && sym->attr.codimension)
Still need to learn weather this is the right solution, but it does the job.
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #3 from anlauf at gcc dot gnu.org ---
(In reply to anlauf from comment #2)
> Reverting the following snippet from my fix attempt for pr91651:
That snippet is necessary for the scalarizer during simplification.
The original ICE is coming from the assert in trans-expr.c:
11155 else
11156 {
11157 gcc_assert (lse.ss == gfc_ss_terminator
11158 && rse.ss == gfc_ss_terminator);
Printing lse.ss and rse.ss for
b = index ('xyxyz','yx', back=a)
b = index ('xyxyz','yx', back=a, kind=4)
one sees that the first case without kind is fine, while the second case has
(gdb) p *rse.ss
$30 = {info = 0x288c1c0, dimen = 0, dim = {0 }, loop_chain =
0x2814270,
next = 0x268eb80 , parent = 0x0, nested_ss = 0x0,
loop = 0x7fffcd90, is_alloc_lhs = 0, no_bounds_check = 0}
so something is screwing up the scalarization.
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
--- Comment #5 from anlauf at gcc dot gnu.org ---
(In reply to Mikael Morin from comment #4)
> Elemental actual arguments are some of those arrays involved.
> Obviously one should not remove some of them in the middle of code
> generation.
> It should be done beforehand if at all.
The problem is only the KIND argument, which must be a scalar constant that
determines the function call and subsequent conversions.
The patch below solves the issue in comment#0, as well as most of
program p
implicit none
logical:: a(2)
integer:: b(2)
integer(8) :: d(2)
b = index ('xyxyz','yx', back=a)
b = index ('xyxyz','yx', back=a, kind=4) ! works now
d = index ('xyxyz','yx', back=a, kind=8) ! works now
! b = index ('xyxyz','yx', back=a, kind=8) ! ICE remains
! d = index ('xyxyz','yx', back=a, kind=4) ! ICE remains
print *, b, d
end
diff --git a/gcc/fortran/trans-expr.c b/gcc/fortran/trans-expr.c
index 2167de455b8..dc3624f2204 100644
--- a/gcc/fortran/trans-expr.c
+++ b/gcc/fortran/trans-expr.c
@@ -10858,6 +10860,8 @@ gfc_trans_assignment_1 (gfc_expr * expr1, gfc_expr *
expr2, bool init_flag,
gfc_init_loopinfo ();
/* Walk the rhs. */
+ if (expr2->value.function.isym)
+ gfc_strip_kind_from_actual (expr2->value.function.actual);
rss = gfc_walk_expr (expr2);
if (rss == gfc_ss_terminator)
/* The rhs is scalar. Add a ss for the expression. */
diff --git a/gcc/fortran/trans-intrinsic.c b/gcc/fortran/trans-intrinsic.c
index d17b623924c..b5ca67198c2 100644
--- a/gcc/fortran/trans-intrinsic.c
+++ b/gcc/fortran/trans-intrinsic.c
@@ -5149,8 +5149,8 @@ gfc_conv_intrinsic_dot_product (gfc_se * se, gfc_expr *
expr)
/* Remove unneeded kind= argument from actual argument list when the
result conversion is dealt with in a different place. */
-static void
-strip_kind_from_actual (gfc_actual_arglist * actual)
+void
+gfc_strip_kind_from_actual (gfc_actual_arglist * actual)
{
for (gfc_actual_arglist *a = actual; a; a = a->next)
{
@@ -5297,7 +5297,7 @@ gfc_conv_intrinsic_minmaxloc (gfc_se * se, gfc_expr *
expr, enum tree_code op)
{
gfc_actual_arglist *a;
a = actual;
- strip_kind_from_actual (a);
+ gfc_strip_kind_from_actual (a);
while (a)
{
if (a->name && strcmp (a->name, "dim") == 0)
diff --git a/gcc/fortran/trans.h b/gcc/fortran/trans.h
index 16b4215605e..617916fa579 100644
--- a/gcc/fortran/trans.h
+++ b/gcc/fortran/trans.h
@@ -821,6 +821,7 @@ void gfc_omp_firstprivatize_type_sizes (struct
gimplify_omp_ctx *, tree);
/* In trans-intrinsic.c. */
void gfc_conv_intrinsic_mvbits (gfc_se *, gfc_actual_arglist *,
gfc_loopinfo *);
+void gfc_strip_kind_from_actual (gfc_actual_arglist *);
/* Runtime library function decls. */
extern GTY(()) tree gfor_fndecl_pause_numeric;
[Bug fortran/97896] [11 Regression] ICE in gfc_trans_assignment_1, at fortran/trans-expr.c:11156
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97896
anlauf at gcc dot gnu.org changed:
What|Removed |Added
Status|WAITING |NEW
CC||anlauf at gcc dot gnu.org
--- Comment #2 from anlauf at gcc dot gnu.org ---
Reverting the following snippet from my fix attempt for pr91651:
diff --git a/gcc/fortran/iresolve.c b/gcc/fortran/iresolve.c
index c2a4865f28f..994a9af4eb8 100644
--- a/gcc/fortran/iresolve.c
+++ b/gcc/fortran/iresolve.c
@@ -1296,11 +1296,7 @@ gfc_resolve_index_func (gfc_expr *f, gfc_actual_arglist
*a)
f->ts.type = BT_INTEGER;
if (kind)
-{
- f->ts.kind = mpz_get_si ((kind)->value.integer);
- a_back->next = NULL;
- gfc_free_actual_arglist (a_kind);
-}
+f->ts.kind = mpz_get_si ((kind)->value.integer);
else
f->ts.kind = gfc_default_integer_kind;
fixes the current PR, but breaks testcase index_4.f90
[Bug fortran/97320] False positive "Array reference out of bounds in loop" in a protecting if block
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97320 anlauf at gcc dot gnu.org changed: What|Removed |Added Resolution|--- |DUPLICATE Status|WAITING |RESOLVED --- Comment #5 from anlauf at gcc dot gnu.org --- See PR 94978. *** This bug has been marked as a duplicate of bug 94978 ***
[Bug fortran/94978] [8/9/10/11 Regression] Bogus warning "Array reference at (1) out of bounds in loop beginning at (2)"
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=94978 anlauf at gcc dot gnu.org changed: What|Removed |Added CC||trnka at scm dot com --- Comment #4 from anlauf at gcc dot gnu.org --- *** Bug 97320 has been marked as a duplicate of this bug. ***
[Bug fortran/97491] Wrong restriction for VALUE arguments of pure procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97491 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 master for gcc-11 and on 10-branch. Closing. Thanks for the report!
[Bug fortran/93678] [8/9/10/11 Regression] ICE with TRANSFER and typebound procedures
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=93678 --- Comment #9 from anlauf at gcc dot gnu.org --- Another data point: comparing the -fdump-fortran-original of res = b_unpackbytes (me) ! ok vs. res = me% unpackbytes () ! ICE I see: ASSIGN b_unpackint:res(FULL) b_unpackbytes[[((b_unpackint:me))]] vs. ASSIGN b_unpackint:res(FULL) b_unpackbytes % _vptr % unpackbytes[[((b_unpackint:me))]] This hasn't changed since gcc-7. Maybe Paul(?) has some idea?
[Bug libfortran/97581] libgfortran/intrinsics/random.c:754: bad array size ?
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=97581 anlauf at gcc dot gnu.org changed: What|Removed |Added Status|ASSIGNED|RESOLVED Resolution|--- |FIXED --- Comment #5 from anlauf at gcc dot gnu.org --- Should be fixed on master.
