Hello,
On 06/12/2021 23:39, Harald Anlauf via Fortran wrote:
diff --git a/gcc/fortran/array.c b/gcc/fortran/array.c
index 5762c8d92d4..5f9ed17f919 100644
--- a/gcc/fortran/array.c
+++ b/gcc/fortran/array.c
@@ -2403,11 +2403,9 @@ gfc_ref_dimen_size (gfc_array_ref *ar, int dimen, mpz_t
*result, m
On 06/12/2021 23:19, Harald Anlauf via Fortran wrote:
Dear all,
we didn't check the type of the upper bound in a case range.
Bummer. Simply add a corresponding check.
Regtested on x86_64-pc-linux-gnu. OK for mainline?
OK, Thanks.
Hi,
Right now, the logic in libgfortran for the detection of REAL(KIND=16) is in
kinds-override.h:
/* What are the C types corresponding to the real(kind=10) and
real(kind=16) types? We currently rely on the following assumptions:
-- if real(kind=10) exists, i.e. if HAVE_GFC_REAL_10 is d
Hello,
On 05/12/2021 22:55, Harald Anlauf via Fortran wrote:
Dear all,
the check of dummy arguments with pointer attribute and INTENT(IN)
was broken in the case the argument was passed to an intrinsic.
We therefore rejected valid code as e.g. given in the PR.
The patch relaxes the excessive ch
Dear all,
frontend-passes.c(do_subscript) does a check on array subscripts
which failed for the testcase in the PR where the array spec was
foul: the upper bound finally resolves to a REAL instead of an
INTEGER. (There is another related testcase by Gerhard).
I haven't figured out yet how to kil
Hi Mikael,
Am 07.12.21 um 21:17 schrieb Mikael Morin:
Hello,
On 05/12/2021 22:55, Harald Anlauf via Fortran wrote:
Dear all,
the check of dummy arguments with pointer attribute and INTENT(IN)
was broken in the case the argument was passed to an intrinsic.
We therefore rejected valid code as e
On 07/12/2021 21:43, Harald Anlauf via Fortran wrote:
I haven't figured out yet how to kill or fix the array decl in
that case.
As long as an error is reported, and the compiler doesn’t crash after
it, I’m not sure there is something more to fix.
Nevertheless it makes sense to catch situat
Dear all,
when simplifying SHAPE(), we rely on spec_dimen_size returning
non-negative dimensions. That actually did not happen in all
cases, as the testcase by Gerhard shows. (The testcase is
rather fallout from the wrong simplification).
The solution is trivial: simply check the dimensions aga
Hi Harald,
when simplifying SHAPE(), we rely on spec_dimen_size returning
non-negative dimensions. That actually did not happen in all
cases, as the testcase by Gerhard shows. (The testcase is
rather fallout from the wrong simplification).
The solution is trivial: simply check the dimensions
