Re: Failing tests after applying patches?

[Richard Biener via Fortran]

On Tue, Aug 24, 2021 at 8:47 AM Arjen Markus via Fortran
 wrote:
>
> Hi Tobias,
>
> thanks for these tips - this should come in handy indeed.
>
> One thing though: when I tried to run my freshly built gfortran compiler on
> one of the test programs, I got the message that it could not find the file
> libgfortran.spec. Is there some environment variable that muist be set?

If you are running gfortran from inside the build directory you'll need quite
some -B arguments, like

 objdir/gcc> ./gfortran -B ..//libgfortran -B
..//libgfortran/.libs -B ..//libquadmath/.libs

where the latter two are when you are also doing linking.   is
x86_64-pc-linux-gnu for me but likely sth with cygwin for you.

Richard.

> Regards,
>
> Arjen
>
> Op ma 23 aug. 2021 om 21:36 schreef Tobias Burnus :
>
> > Hi Arjen,
> >
> > On 23.08.21 20:59, Arjen Markus via Fortran wrote:
> > > as promised, here is an overview of the unexpectedly failing tests. I got
> > > these after applying the patches by Steve Kargl for bug ID 101951 and
> > > 101967. The platform I used to build it is Cygwin on WIndows 10.
> > >
> > > FAIL: gfortran.dg/analyzer/pr96949.f90   -O  (internal compiler error)
> > > FAIL: gfortran.dg/analyzer/pr96949.f90   -O  (test for excess errors)
> >
> > I recommend: https://gcc.gnu.org/pipermail/gcc-testresults/current – it
> > shows what others are getting.
> >
> > In particular, it helps: to ensure to look at the right branch (12.0
> > mainline), to look at  x86-64 Linux (as others tend to have some
> > additional issues) — and to make sure that that build actual does test
> > Fortran.
> >
> > But the simplest test is to undo your patches - recompile GCC and then
> > run (in the build directory):
> >
> > cd gcc; make check-fortran RUNTESTFLAGS="analyzer.exp=pr96949.f90"
> >
> > If the error still occurs, it is probably unrelated to the patch; if it
> > is gone, the patch probably caused it.
> >
> > I also do note that many analyzer commits have been committed today,
> > hence, it is a moving target. (It does work for me – with the current
> > checkout. But this does not tell anything about when you did your tests,
> > given that several commits were done this evening.)
> >
> > Tobias
> >
> >

[PATCH] PR fortran/93834 - [9/10/11/12 Regression] ICE in trans_caf_is_present, at fortran/trans-intrinsic.c:8469

[Harald Anlauf via Fortran]

Dear Fortranners,

here's a pretty obvious one: we didn't properly check the arguments
for intrinsics when these had to be ALLOCATABLE and in the case that
argument was a coarray object.  Simple solution: just reuse a check
that was used for pointer etc.

Regtested on x86_64-pc-linux-gnu.  OK for mainline / backports?

Thanks,
Harald


Fortran - extend allocatable_check to coarrays

gcc/fortran/ChangeLog:

PR fortran/93834
* check.c (allocatable_check): A coindexed array element is not an
allocatable object.

gcc/testsuite/ChangeLog:

PR fortran/93834
* gfortran.dg/coarray_allocated.f90: New test.

diff --git a/gcc/fortran/check.c b/gcc/fortran/check.c
index 851af1b30dc..a293a7b9592 100644
--- a/gcc/fortran/check.c
+++ b/gcc/fortran/check.c
@@ -983,6 +983,14 @@ allocatable_check (gfc_expr *e, int n)
   return false;
 }

+  if (attr.codimension && gfc_is_coindexed (e))
+{
+  gfc_error ("%qs argument of %qs intrinsic at %L shall not be "
+		 "coindexed", gfc_current_intrinsic_arg[n]->name,
+		 gfc_current_intrinsic, &e->where);
+  return false;
+}
+
   return true;
 }

diff --git a/gcc/testsuite/gfortran.dg/coarray_allocated.f90 b/gcc/testsuite/gfortran.dg/coarray_allocated.f90
new file mode 100644
index 000..70e865c94ac
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/coarray_allocated.f90
@@ -0,0 +1,9 @@
+! { dg-do compile }
+! { dg-options "-fcoarray=lib" }
+! PR fortran/93834 - ICE in trans_caf_is_present
+
+program p
+  integer, allocatable :: a[:]
+  print *, allocated (a)
+  print *, allocated (a[1]) ! { dg-error "shall not be coindexed" }
+end