Re: [r12-4457 Regression] FAIL: gfortran.dg/deferred_type_param_6.f90 -Os execution test on Linux/x86_64

[Richard Biener via Fortran]

On Sat, Oct 16, 2021 at 8:24 PM Jan Hubicka via Gcc-patches
 wrote:
>
> Hi,
> >
> > FAIL: gfortran.dg/deferred_type_param_6.f90   -O1  execution test
> > FAIL: gfortran.dg/deferred_type_param_6.f90   -Os  execution test
> Sorry for the breakage.  This time it seems like bug in Fortran FE
> which was previously latent:
>
> __attribute__((fn spec (". . R ")))
> void subfunc (character(kind=1)[1:..__result] * & __result, integer(kind=8) * 
> .__result)
> {
>   # PT = nonlocal
>   character(kind=1)[1:..__result] * & __result_3(D) = __result;
>   # PT = nonlocal null
>   integer(kind=8) * .__result_5(D) = .__result;
>   integer(kind=4) _1;
>
>[local count: 1073741824]:
>   *__result_3(D) = &fifec;
>   # USE = nonlocal escaped { D.4230 } (nonlocal, escaped)
>   _1 = _gfortran_compare_string (5, &fifec, 5, &"FIVEC"[1]{lb: 1 sz: 1});
>   if (_1 != 0)
> goto ; [0.04%]
>   else
> goto ; [99.96%]
>
>[local count: 429496]:
>   # USE = nonlocal escaped null
>   # CLB = nonlocal escaped null
>   _gfortran_stop_numeric (10, 0);
>
>[local count: 1073312329]:
>   *.__result_5(D) = 5;
>   return;
> }
>
> The fnspec ". . R " specifies that .__result is readonly however we
> have:
>   *.__result_5(D) = 5;
>
> I am not sure I understand fortran FE well enough to figure out why
> it is set so.  The function is declared as:
>
>   function subfunc() result(res)
> character(len=:), pointer :: res
> res => fifec
> if (len(res) /= 5) STOP 9
> if (res /= "FIVEC") STOP 10
>   end function subfunc
>
> and we indeed optimize load of the result:
> -  # USE = nonlocal escaped { D.4252 D.4254 } (nonlocal, escaped)
> -  # CLB = nonlocal escaped { D.4254 } (escaped)
> +  # USE = nonlocal escaped
> +  # CLB = { D.4254 }
>subfunc (&pstr.5, &slen.4);
> -  .s2_34 = slen.4;
> -  # PT = nonlocal escaped null { D.4254 } (escaped)
> -  s2_35 = pstr.5;
>pstr.5 ={v} {CLOBBER};
>
> and I think tat is what breaks the testcase (I also verified that
> ignoring the fnspec 'R' fixes it).

The FE code adding the fnspec probably fails to consider the
separately passed length of the string result?

Can you open a bugreport please?

Richard.

> Honza
> >
> > with GCC configured with
> >
> > ../../gcc/configure 
> > --prefix=/local/skpandey/gccwork/toolwork/gcc-bisect-master/master/r12-4457/usr
> >  --enable-clocale=gnu --with-system-zlib --with-demangler-in-ld 
> > --with-fpmath=sse --enable-languages=c,c++,fortran --enable-cet 
> > --without-isl --enable-libmpx x86_64-linux --disable-bootstrap
> >
> > To reproduce:
> >
> > $ cd {build_dir}/gcc && make check 
> > RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
> > --target_board='unix{-m32}'"
> > $ cd {build_dir}/gcc && make check 
> > RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
> > --target_board='unix{-m32\ -march=cascadelake}'"
> > $ cd {build_dir}/gcc && make check 
> > RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
> > --target_board='unix{-m64}'"
> > $ cd {build_dir}/gcc && make check 
> > RUNTESTFLAGS="dg.exp=gfortran.dg/deferred_type_param_6.f90 
> > --target_board='unix{-m64\ -march=cascadelake}'"
> >
> > (Please do not reply to this email, for question about this report, contact 
> > me at skpgkp2 at gmail dot com)

Re: libgfortran.so SONAME and powerpc64le-linux ABI changes

[Joseph Myers]

On Fri, 15 Oct 2021, Bill Schmidt via Gcc wrote:

> Beyond ABI and compiler support, glibc would also need to support IEEE 
> QP for these other targets.  Currently we only have support for 
> powerpc64le.

And that would involve new syntax in glibc Versions files, as discussed in 
, to give the 
binary128 versions of certain functions (functions added after the initial 
_Float128 support was added to glibc but before it gets added for these 
other ABIs) the right symbol version.

-- 
Joseph S. Myers
jos...@codesourcery.com

Re: [PATCH] openmp, fortran: Add support for declare variant in Fortran

[Kwok Cheung Yeung]

On 14/10/2021 1:47 pm, Jakub Jelinek wrote:

What I still miss is tests for the (proc_name : variant_name) syntax
in places where proc_name : is optional, but is supplied and is valid, like
e.g. in interface, or in subroutine/function and where proc_name specifies
the name of the containing interface or subroutine/function.
I see that syntax tested in some places with dg-error on that line and
in spaces where it isn't optional (e.g. at module scope before contains).
But if you want, that can be added incrementally.


Do you mean something like these tests?

Thanks

Kwok
From 38733234024697d2144613c4a992e970f40afad8 Mon Sep 17 00:00:00 2001
From: Kwok Cheung Yeung 
Date: Mon, 18 Oct 2021 13:56:59 -0700
Subject: [PATCH] openmp: Add additional tests for declare variant in Fortran

Add tests to check that explicitly specifying the containing procedure as the
base name for declare variant works.

2021-10-18  Kwok Cheung Yeung  

gcc/testsuite/

* gfortran.dg/gomp/declare-variant-15.f90 (variant2, base2, test2):
Add tests.
* gfortran.dg/gomp/declare-variant-16.f90 (base2, variant2, test2):
Add tests.
---
 .../gfortran.dg/gomp/declare-variant-15.f90| 13 +
 .../gfortran.dg/gomp/declare-variant-16.f90| 14 +-
 2 files changed, 26 insertions(+), 1 deletion(-)

diff --git a/gcc/testsuite/gfortran.dg/gomp/declare-variant-15.f90 
b/gcc/testsuite/gfortran.dg/gomp/declare-variant-15.f90
index b2ad96a8998..4a88e3e46c7 100644
--- a/gcc/testsuite/gfortran.dg/gomp/declare-variant-15.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/declare-variant-15.f90
@@ -14,6 +14,13 @@ contains
   subroutine base ()
   end subroutine
 
+  subroutine variant2 ()
+  end subroutine
+
+  subroutine base2 ()
+!$omp declare variant (base2: variant2) match (construct={parallel})
+  end subroutine
+
   subroutine test1 ()
 !$omp target
   !$omp parallel
@@ -21,4 +28,10 @@ contains
   !$omp end parallel
 !$omp end target
   end subroutine
+
+  subroutine test2 ()
+!$omp parallel
+   call base2 ()   ! { dg-final { scan-tree-dump-times "variant2 
\\\(\\\);" 1 "gimple" } }
+!$omp end parallel
+  end subroutine
 end module
diff --git a/gcc/testsuite/gfortran.dg/gomp/declare-variant-16.f90 
b/gcc/testsuite/gfortran.dg/gomp/declare-variant-16.f90
index fc97322e667..5e34d474da4 100644
--- a/gcc/testsuite/gfortran.dg/gomp/declare-variant-16.f90
+++ b/gcc/testsuite/gfortran.dg/gomp/declare-variant-16.f90
@@ -10,15 +10,27 @@ module main
 subroutine base ()
   !$omp declare variant (variant) match (construct={parallel})
 end subroutine
+
+subroutine base2 ()
+  !$omp declare variant (base2: variant2) match (construct={target})
+end subroutine
   end interface
-
 contains
   subroutine variant ()
   end subroutine
 
+  subroutine variant2 ()
+  end subroutine
+
   subroutine test ()
 !$omp parallel
   call base ()  ! { dg-final { scan-tree-dump-times "variant \\\(\\\);" 1 
"gimple" } }
 !$omp end parallel
   end subroutine
+
+  subroutine test2 ()
+!$omp target
+  call base2 ()  ! { dg-final { scan-tree-dump-times "variant2 \\\(\\\);" 
1 "gimple" } }
+!$omp end target
+  end subroutine
 end module
-- 
2.30.0.335.ge636282

Re: [PATCH] openmp, fortran: Add support for declare variant in Fortran

[Jakub Jelinek via Fortran]

On Mon, Oct 18, 2021 at 10:05:29PM +0100, Kwok Cheung Yeung wrote:
> On 14/10/2021 1:47 pm, Jakub Jelinek wrote:
> > What I still miss is tests for the (proc_name : variant_name) syntax
> > in places where proc_name : is optional, but is supplied and is valid, like
> > e.g. in interface, or in subroutine/function and where proc_name specifies
> > the name of the containing interface or subroutine/function.
> > I see that syntax tested in some places with dg-error on that line and
> > in spaces where it isn't optional (e.g. at module scope before contains).
> > But if you want, that can be added incrementally.
> 
> Do you mean something like these tests?

Yeah, LGTM, thanks.

Jakub

Re: [PATCH][WIP] Add install-dvi Makefile targets

[Eric Gallager via Fortran]

On Tue, Oct 12, 2021 at 5:09 PM Eric Gallager  wrote:
>
> On Thu, Oct 6, 2016 at 10:41 AM Eric Gallager  wrote:
> >
> > Currently the build machinery handles install-pdf and install-html
> > targets, but no install-dvi target. This patch is a step towards
> > fixing that. Note that I have only tested with
> > --enable-languages=c,c++,lto,objc,obj-c++. Thus, target hooks will
> > probably also have to be added for the languages I skipped.
> > Also, please note that this patch applies on top of:
> > https://gcc.gnu.org/ml/gcc-patches/2016-10/msg00370.html
> >
> > ChangeLog:
> >
> > 2016-10-06  Eric Gallager  
> >
> > * Makefile.def: Handle install-dvi target.
> > * Makefile.tpl: Likewise.
> > * Makefile.in: Regenerate.
> >
> > gcc/ChangeLog:
> >
> > 2016-10-06  Eric Gallager  
> >
> > * Makefile.in: Handle dvidir and install-dvi target.
> > * ./[c|cp|lto|objc|objcp]/Make-lang.in: Add dummy install-dvi
> > target hooks.
> > * configure.ac: Handle install-dvi target.
> > * configure: Regenerate.
> >
> > libiberty/ChangeLog:
> >
> > 2016-10-06  Eric Gallager  
> >
> > * Makefile.in: Handle dvidir and install-dvi target.
> > * functions.texi: Regenerate.
>
> Ping. The prerequisite patch that I linked to previously has gone in now.
> I'm not sure if this specific patch still applies, though.
> Also note that I've opened a bug to track this issue:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102663

Hi, I have updated this patch and tested it with more languages now; I
can now confirm that it works with ada, d, and fortran now. The only
languages that remain untested now are go (since I'm building on
darwin and go doesn't build on darwin anyways, as per bug 46986) and
jit (which I ran into a bug about that I brought up on IRC, and will
probably need to file on bugzilla). OK to install?


patch-install-dvi.diff
Description: Binary data

Re: [PATCH][WIP] Add install-dvi Makefile targets

[Thomas Koenig via Fortran]

Hi Eric,


Hi, I have updated this patch and tested it with more languages now; I
can now confirm that it works with ada, d, and fortran now. The only
languages that remain untested now are go (since I'm building on
darwin and go doesn't build on darwin anyways, as per bug 46986) and
jit (which I ran into a bug about that I brought up on IRC, and will
probably need to file on bugzilla). OK to install?


Fortran parts look good.

Best regards

Thomas