Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
Thomas, Am 06.11.21 um 19:28 schrieb Thomas Koenig: > > Hi Manfred, > > looks good to me. > > Thanks for the patch! > could you commit it for me? I do not have commit access. Thanks, Manfred > Best regards > > Thomas
[Patch] Fortran: Handle compare in OpenMP atomic
Some Sunday work ...
Implement the 'compare' part in trans-openmp of OpenMP 5.1's atomic changes
plus a couple of bugfixes throughout.
OK?
Tobias
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
Fortran: Handle compare in OpenMP atomic
gcc/fortran/ChangeLog:
PR fortran/103576
* openmp.c (is_scalar_intrinsic_expr): Fix condition.
(resolve_omp_atomic): Fix/update checks, accept compare.
* trans-openmp.c (gfc_trans_omp_atomic): Handle compare.
libgomp/ChangeLog:
* libgomp.texi (OpenMP 5.1): Set Fortran support for atomic to 'Y'.
* testsuite/libgomp.fortran/atomic-19.f90: New test.
gcc/testsuite/ChangeLog:
* gfortran.dg/gomp/atomic-25.f90: Remove sorry, fix + add checks.
* gfortran.dg/gomp/atomic-26.f90: Likewise.
* gfortran.dg/gomp/atomic-21.f90: New test.
gcc/fortran/openmp.c| 81 +++---
gcc/fortran/trans-openmp.c | 211
gcc/testsuite/gfortran.dg/gomp/atomic-21.f90| 93 +++
gcc/testsuite/gfortran.dg/gomp/atomic-25.f90| 18 +-
gcc/testsuite/gfortran.dg/gomp/atomic-26.f90| 26 +-
libgomp/libgomp.texi| 3 +-
libgomp/testsuite/libgomp.fortran/atomic-19.f90 | 313
7 files changed, 650 insertions(+), 95 deletions(-)
diff --git a/gcc/fortran/openmp.c b/gcc/fortran/openmp.c
index 846fd7b5c5a..2036bc1349f 100644
--- a/gcc/fortran/openmp.c
+++ b/gcc/fortran/openmp.c
@@ -7552,10 +7552,10 @@ is_scalar_intrinsic_expr (gfc_expr *expr, bool must_be_var, bool conv_ok)
return false;
return (expr->rank == 0
&& !gfc_is_coindexed (expr)
- && (expr->ts.type != BT_INTEGER
- || expr->ts.type != BT_REAL
- || expr->ts.type != BT_COMPLEX
- || expr->ts.type != BT_LOGICAL));
+ && (expr->ts.type == BT_INTEGER
+ || expr->ts.type == BT_REAL
+ || expr->ts.type == BT_COMPLEX
+ || expr->ts.type == BT_LOGICAL));
}
static void
@@ -7574,12 +7574,9 @@ resolve_omp_atomic (gfc_code *code)
code = code->block->next;
/* resolve_blocks asserts this is initially EXEC_ASSIGN or EXEC_IF
If it changed to EXEC_NOP, assume an error has been emitted already. */
- if (code->op == EXEC_NOP /* FIXME: || (code->next && code->next->op == EXEC_NOP)*/)
+ if (code->op == EXEC_NOP)
return;
- if (code->op == EXEC_IF && code->block->op == EXEC_IF)
-comp_cond = code->block->expr1;
-
if (atomic_code->ext.omp_clauses->compare
&& atomic_code->ext.omp_clauses->capture)
{
@@ -7597,6 +7594,7 @@ resolve_omp_atomic (gfc_code *code)
&& next->block->op == EXEC_IF
&& next->block->next->op == EXEC_ASSIGN)
{
+ comp_cond = next->block->expr1;
stmt = next->block->next;
if (stmt->next)
{
@@ -7604,11 +7602,20 @@ resolve_omp_atomic (gfc_code *code)
goto unexpected;
}
}
+ else if (capture_stmt)
+ {
+ gfc_error ("Expected IF at %L in atomic compare capture",
+ &next->loc);
+ return;
+ }
if (stmt && !capture_stmt && next->block->block)
{
if (next->block->block->expr1)
- gfc_error ("Expected ELSE at %L in atomic compare capture",
- &next->block->block->expr1->where);
+ {
+ gfc_error ("Expected ELSE at %L in atomic compare capture",
+ &next->block->block->expr1->where);
+ return;
+ }
if (!code->block->block->next
|| code->block->block->next->op != EXEC_ASSIGN)
{
@@ -7623,10 +7630,8 @@ resolve_omp_atomic (gfc_code *code)
goto unexpected;
}
}
- if (stmt && !capture_stmt && code->op == EXEC_ASSIGN)
- {
- capture_stmt = code;
- }
+ if (stmt && !capture_stmt && next->next->op == EXEC_ASSIGN)
+ capture_stmt = next->next;
else if (!capture_stmt)
{
loc = &code->loc;
@@ -7641,6 +7646,7 @@ resolve_omp_atomic (gfc_code *code)
&& code->block->op == EXEC_IF
&& code->block->next->op == EXEC_ASSIGN)
{
+ comp_cond = code->block->expr1;
stmt = code->block->next;
if (stmt->next || code->block->block)
{
@@ -7703,8 +7709,7 @@ resolve_omp_atomic (gfc_code *code)
{
/* x = ... */
stmt = code;
- if ((!atomic_code->ext.omp_clauses->compare && stmt->op != EXEC_ASSIGN)
- || (atomic_code->ext.omp_clauses->compare && stmt->op != EXEC_IF))
+ if (!atomic_code->ext.omp_clauses->compare && stmt->op != EXEC_ASSIGN)
goto unexpected;
gcc_assert (!code->next);
}
@@ -7720,7 +7725,7 @@ resolve_omp_atomic (gfc_code *code)
"expression at %L", &comp_cond->where);
return;
}
- if (!is_scalar_intrinsic_expr (comp_cond->value.op.op1, true, false))
+ if (!is_scalar_intrinsic_expr (comp_cond->value.op.op1, true, true))
{
gfc_error ("Expected scalar intrinsic variable at %L in atomic "
"comparison", &comp_co
Re: [Patch] Fortran: Handle compare in OpenMP atomic
On Mon, Dec 13, 2021 at 12:19:50PM +0100, Tobias Burnus wrote: > Some Sunday work ... > Implement the 'compare' part in trans-openmp of OpenMP 5.1's atomic changes > plus a couple of bugfixes throughout. > > OK? > > Tobias > - > Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634 > München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas > Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht > München, HRB 106955 > Fortran: Handle compare in OpenMP atomic > > gcc/fortran/ChangeLog: > > PR fortran/103576 > * openmp.c (is_scalar_intrinsic_expr): Fix condition. > (resolve_omp_atomic): Fix/update checks, accept compare. > * trans-openmp.c (gfc_trans_omp_atomic): Handle compare. > > libgomp/ChangeLog: > > * libgomp.texi (OpenMP 5.1): Set Fortran support for atomic to 'Y'. > * testsuite/libgomp.fortran/atomic-19.f90: New test. > > gcc/testsuite/ChangeLog: > > * gfortran.dg/gomp/atomic-25.f90: Remove sorry, fix + add checks. > * gfortran.dg/gomp/atomic-26.f90: Likewise. > * gfortran.dg/gomp/atomic-21.f90: New test. Ok, thanks. Jakub
Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
On 12/13/21 12:18, Manfred Schwarb via Fortran wrote: could you commit it for me? I do not have commit access. I can definitely do that, but please attach the patches as output of git format-patch so that git am can be directly used. Cheers, Martin
[PATCH, v2] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays
Hi Mikael,
Am 09.12.21 um 21:37 schrieb Mikael Morin:
Hello,
On 09/12/2021 21:05, Harald Anlauf via Fortran wrote:
Dear all,
I had thought that we had fixed this in the past (see PR31001),
but it did fail for me with all gcc versions I have tried (7-12)
for a slightly more elaborate case as in the old testcase.
The loop in pack_internal did try to access the first element of
the array argument to PACK even if one (or more) extents were zero.
This is not good.
Solution: check the extents and return early. (We already do a
related check for the vector argument if present).
If there is a vector argument, aren’t we supposed to copy it to the
result ?
There is something else to pay attention for, the early return should
come at least after the return array bounds have been set. In the
testcase an array with the correct bounds has been allocated beforehand
to hold the return value, but it’s not always the case.
you are absolutely right, I had gotten that wrong.
For what it’s worth, the non-generic variant in pack.m4 (or in
pack_{i,f,c}{1,2,4,8,10,16}.c) has a zero extent check and it clears the
source ptr in that case, which makes it setup the return array and then
jump to the vector copy at the end of the function.
The code is so similar (for good reason) that it makes sense to keep
it synchronous. I added code for 'zero_sized' array with the minor
difference that I made it boolean instead of integer.
I also extended the testcase so that it exercises PACK/pack_internal
a little, for argument 'vector' present as well as not. (There are
existing tests for intrinsic types, but not for the issue at hand).
Regtested again, and checked the testcase (against other compilers
and also with valgrind).
OK now?
Thanks,
Harald
Re: [PATCH, v2] PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays
Works better with patch attached...
Am 13.12.21 um 21:25 schrieb Harald Anlauf via Gcc-patches:
Hi Mikael,
Am 09.12.21 um 21:37 schrieb Mikael Morin:
Hello,
On 09/12/2021 21:05, Harald Anlauf via Fortran wrote:
Dear all,
I had thought that we had fixed this in the past (see PR31001),
but it did fail for me with all gcc versions I have tried (7-12)
for a slightly more elaborate case as in the old testcase.
The loop in pack_internal did try to access the first element of
the array argument to PACK even if one (or more) extents were zero.
This is not good.
Solution: check the extents and return early. (We already do a
related check for the vector argument if present).
If there is a vector argument, aren’t we supposed to copy it to the
result ?
There is something else to pay attention for, the early return should
come at least after the return array bounds have been set. In the
testcase an array with the correct bounds has been allocated beforehand
to hold the return value, but it’s not always the case.
you are absolutely right, I had gotten that wrong.
For what it’s worth, the non-generic variant in pack.m4 (or in
pack_{i,f,c}{1,2,4,8,10,16}.c) has a zero extent check and it clears the
source ptr in that case, which makes it setup the return array and then
jump to the vector copy at the end of the function.
The code is so similar (for good reason) that it makes sense to keep
it synchronous. I added code for 'zero_sized' array with the minor
difference that I made it boolean instead of integer.
I also extended the testcase so that it exercises PACK/pack_internal
a little, for argument 'vector' present as well as not. (There are
existing tests for intrinsic types, but not for the issue at hand).
Regtested again, and checked the testcase (against other compilers
and also with valgrind).
OK now?
Thanks,
Harald
From f6879cdcc1de83c86eb47bfae33d06fd00f51a99 Mon Sep 17 00:00:00 2001
From: Harald Anlauf
Date: Mon, 13 Dec 2021 20:50:19 +0100
Subject: [PATCH] Fortran: PACK intrinsic should not try to read from
zero-sized array
libgfortran/ChangeLog:
PR libfortran/103634
* intrinsics/pack_generic.c (pack_internal): Handle case when the
array argument of PACK has one or more extents of size zero to
avoid invalid reads.
gcc/testsuite/ChangeLog:
PR libfortran/103634
* gfortran.dg/intrinsic_pack_6.f90: New test.
---
.../gfortran.dg/intrinsic_pack_6.f90 | 57 +++
libgfortran/intrinsics/pack_generic.c | 9 +++
2 files changed, 66 insertions(+)
create mode 100644 gcc/testsuite/gfortran.dg/intrinsic_pack_6.f90
diff --git a/gcc/testsuite/gfortran.dg/intrinsic_pack_6.f90 b/gcc/testsuite/gfortran.dg/intrinsic_pack_6.f90
new file mode 100644
index 000..917944d8846
--- /dev/null
+++ b/gcc/testsuite/gfortran.dg/intrinsic_pack_6.f90
@@ -0,0 +1,57 @@
+! { dg-do run }
+! PR libfortran/103634 - Runtime crash with PACK on zero-sized arrays
+! Exercise PACK intrinsic for cases when it calls pack_internal
+
+program p
+ implicit none
+ type t
+ real :: r(24) = -99.
+ end type
+ type(t), allocatable :: new(:), old(:), vec(:)
+ logical, allocatable :: mask(:)
+ integer :: n, m
+! m = 1! works
+ m = 0! failed with SIGSEGV in pack_internal
+ do m = 0, 2
+ print *, m
+ allocate (old(m), mask(m), vec(m))
+ if (m > 0) vec(m)% r(1) = 42
+ mask(:) = .true.
+ n = count (mask)
+ allocate (new(n))
+
+ mask(:) = .false.
+ if (size (pack (old, mask)) /= 0) stop 1
+ mask(:) = .true.
+ if (size (pack (old, mask)) /= m) stop 2
+ new(:) = pack (old, mask) ! this used to segfault for m=0
+
+ mask(:) = .false.
+ if (size (pack (old, mask, vector=vec)) /= m) stop 3
+ new(:) = t()
+ new(:) = pack (old, mask, vector=vec) ! this used to segfault for m=0
+ if (m > 0) then
+if ( new( m )% r(1) /= 42) stop 4
+if (any (new(:m-1)% r(1) /= -99)) stop 5
+ end if
+
+ if (m > 0) mask(m) = .true.
+ if (size (pack (old, mask, vector=vec)) /= m) stop 6
+ new(:) = t()
+ new(:) = pack (old, mask, vector=vec) ! this used to segfault for m=0
+ if (m > 0) then
+if (new(1)% r(1) /= -99) stop 7
+ end if
+ if (m > 1) then
+if (new(m)% r(1) /= 42) stop 8
+ end if
+
+ if (size (pack (old(:0), mask(:0), vector=vec)) /= m) stop 9
+ new(:) = t()
+ new(:) = pack (old(:0), mask(:0), vector=vec) ! did segfault for m=0
+ if (m > 0) then
+if (new(m)% r(1) /= 42) stop 10
+ end if
+ deallocate (old, mask, new, vec)
+ end do
+end
diff --git a/libgfortran/intrinsics/pack_generic.c b/libgfortran/intrinsics/pack_generic.c
index cad2fbbfbcd..15880e74348 100644
--- a/libgfortran/intrinsics/pack_generic.c
+++ b/libgfortran/intrinsics/pack_generic.c
@@ -85,6 +85,7 @@ pack_internal (gfc_array_char *ret, const gfc_array_char *array,
index_type count[GFC_MAX_DIMENSIONS];
index_type extent[GFC_MAX_
[power-ieee128] Which options for libquadmath / native ieee128
Hi, looking at what the REAL(KIND=17) numbers should be compiled for, I see the following options that should be considered: a) xsaddqp and friends are not supported by the CPU; libquadmath should be called for all operations, including simple arithmetic. b) xsaddqp and friends are supported, but glibc is too old and lacks the *ieee128 functions. libquadmath should be called for these functions. c) xsaddqp and friends are supported, and glibc is new enough. Call the *ieee128 functions. What is the best way to check in the library config files that the quad precision instructions are supported (to differentiate between a) on the one hand and b) and c) on the other? And which options to the compiler make sure the libquadmath library is called? Regards Thomas
Re: [power-ieee128] Which options for libquadmath / native ieee128
On Mon, Dec 13, 2021 at 09:29:16PM +0100, Thomas Koenig wrote: > > Hi, > > looking at what the REAL(KIND=17) numbers should be compiled for, I see > the following options that should be considered: > > a) xsaddqp and friends are not supported by the CPU; libquadmath should >be called for all operations, including simple arithmetic. Note, we do not use the emulator in libquadmath. Libgcc has support for doing software emulation of the IEEE 128-bit basic support. > b) xsaddqp and friends are supported, but glibc is too old and lacks the >*ieee128 functions. libquadmath should be called for these >functions. Yes, this would be the place to call libquadmath. Or possibly don't use libquadmath at all and don't allow KIND=17. It is probably better for the users if we use libquadmath instead of disabling it all together. > c) xsaddqp and friends are supported, and glibc is new enough. Call >the *ieee128 functions. The necessary support is in the little endian GLIBC 2.32 or newer. I don't recall if you also need Elf abi V2 (which is default on little endian). You could check via: #if (((__GLIBC__ * 1000) + __GLIBC_MINOR__) >= 2032 && \ (__BYTE_ORDER__ == __ORDER_LITTLE_ENDIAN__) \ (_CALL_ELF == 2)) If you are writing C code for the library, and using _Float128 for the type instead of using long double and using the -mabi=ieeelongdouble switch, you want to define the following macros before math.h or other system include files are included: #define __STDC_WANT_IEC_60559_TYPES_EXT__ 1 #define __STDC_WANT_IEC_60559_FUNCS_EXT__ 1 > What is the best way to check in the library config files that the quad > precision instructions are supported (to differentiate between a) on the > one hand and b) and c) on the other? You can check whether long double is IEEE 128-bit via: #if defined(__LONG_DOUBLE_IEEE128__)/* or */ #if __LONG_DOUBLE_IEEE128__ and similarly to check for IBM 128-bit long double: #if defined(__LONG_DOUBLE_IBM128__) /* or */ #if __LONG_DOUBLE_IBM128__ To check whether IEEE 128-bit instructions are enabled: #if defined(__FLOAT128_HARDWARE__) /* or */ #if __FLOAT128_HARDWARE__ To check whether the _Float128 or __float128 keywords are available (whether or not the hardware supports the instructions): #if defined(__FLOAT128_TYPE__) /* or */ #if __FLOAT128_TYPE__ Note, that C++ does not support the _Float128 type (which is in one of the IEC papers), but it does support the non-standard __float128 keyword. Unfortunately, __float128 _Complex does not work. There is a GLIBC macro that gives the appropriate _Complex type for __float128 use in C++, but I don't remember what it is. Alternatively, it might be simpler to build the library parts using long double and build those modules with the appropriate options. > > And which options to the compiler make sure the libquadmath library > is called? The libqaudmath library should always be linked in if it is built. I had actually meant to turn off building it once all of the 2.32 support went in, but I never did. Note, I haven't tested libquadmath in a long time. To compile C/C++ code where long double is IEEE 128-bit use: -mabi=ieeelongdouble -Wno-psabi -mno-gnu-attribute For Fortran code, I think you have to remove the -Wno-psabi. But it may be buggy. Similarly to force long double to be IBM 128-bit, no matter what the defaults are use: -mabi=iibmlongdouble -Wno-psabi -mno-gnu-attribute The no-gnu-attribute says to disable setting the GNU attribute that says what the default long double type is. It is necessary when building libraries with both 128-bit types. -- Michael Meissner, IBM PO Box 98, Ayer, Massachusetts, USA, 01432 email: meiss...@linux.ibm.com
Re: [PATCH] PR fortran/91497 -- Silence conversion warnings for MIN1 and MAX1
Am 13.12.21 um 13:29 schrieb Martin Liška: > On 12/13/21 12:18, Manfred Schwarb via Fortran wrote: >> could you commit it for me? I do not have commit access. > > I can definitely do that, but please attach the patches as output of git > format-patch > so that git am can be directly used. > Thanks. I do not have much experience with git, and I developed the patch the old-fashioned way. I tried "git format-patch", but this simply returned nothing. Sorry, I gave up for now. Cheers, Manfred > Cheers, > Martin >
Adjust 'gfortran.dg/goacc/privatization-1-*' [PR103576, PR103697] (was: [Patch] Fortran: Handle compare in OpenMP atomic)
Hi Tobias!
On 2021-12-13T12:19:50+0100, Tobias Burnus wrote:
> Implement the 'compare' part in trans-openmp of OpenMP 5.1's atomic changes
> plus a couple of bugfixes throughout.
Hmm, I wonder why you didn't see the few regressions in your testing?
Pushed to master branch commit 228d64af4e244faabab5c47506920a1bde85d74e
"Adjust 'gfortran.dg/goacc/privatization-1-*' [PR103576, PR103697]", see
attached.
Grüße
Thomas
-
Siemens Electronic Design Automation GmbH; Anschrift: Arnulfstraße 201, 80634
München; Gesellschaft mit beschränkter Haftung; Geschäftsführer: Thomas
Heurung, Frank Thürauf; Sitz der Gesellschaft: München; Registergericht
München, HRB 106955
>From 228d64af4e244faabab5c47506920a1bde85d74e Mon Sep 17 00:00:00 2001
From: Thomas Schwinge
Date: Tue, 14 Dec 2021 07:03:52 +0100
Subject: [PATCH] Adjust 'gfortran.dg/goacc/privatization-1-*' [PR103576,
PR103697]
... for the recent commit 494ebfa7c9aacaeb6ec1fccc47a0e49f31eb2bb8
"Fortran: Handle compare in OpenMP atomic", which changes the GIMPLE IR
such that a temporary is no longer used; 'original' dump:
x = *a;
-{
- integer(kind=4) D.4237;
-
- D.4237 = *a;
#pragma omp atomic relaxed
-&y = D.4237;
-}
+ &y = *a;
}
(I'm not familiar to comment whether that's correct; but it appears that the
difference again disappears in later compiler passes.)
These OpenACC test cases verify behavior re OpenACC privatization levels, and
have to be adjusted accordingly.
gcc/testsuite/
PR fortran/103576
PR testsuite/103697
* gfortran.dg/goacc/privatization-1-compute-loop.f90: Adjust.
* gfortran.dg/goacc/privatization-1-compute.f90: Likewise.
* gfortran.dg/goacc/privatization-1-routine_gang-loop.f90:
Likewise.
* gfortran.dg/goacc/privatization-1-routine_gang.f90: Likewise.
---
gcc/testsuite/gfortran.dg/goacc/privatization-1-compute-loop.f90 | 1 -
gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90 | 1 -
.../gfortran.dg/goacc/privatization-1-routine_gang-loop.f90 | 1 -
gcc/testsuite/gfortran.dg/goacc/privatization-1-routine_gang.f90 | 1 -
4 files changed, 4 deletions(-)
diff --git a/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute-loop.f90 b/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute-loop.f90
index bcd7159ae5b..47ba5baf439 100644
--- a/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute-loop.f90
+++ b/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute-loop.f90
@@ -50,7 +50,6 @@ contains
! { dg-note {variable 'x' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop }
! { dg-note {variable 'y' in 'private' clause is candidate for adjusting OpenACC privatization level} "" { target *-*-* } l_loop$c_loop }
! { dg-note {variable 'C\.[0-9]+' declared in block potentially has improper OpenACC privatization level: 'const_decl'} "TODO" { target *-*-* } l_loop$c_loop }
-! { dg-note {variable 'D\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop }
! { dg-note {variable 'y' ought to be adjusted for OpenACC privatization level: 'vector'} "" { target *-*-* } l_loop$c_loop }
!$acc end parallel
end subroutine f
diff --git a/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90 b/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90
index 31f998dfc92..4813e44a233 100644
--- a/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90
+++ b/gcc/testsuite/gfortran.dg/goacc/privatization-1-compute.f90
@@ -43,6 +43,5 @@ contains
! { dg-note {variable 'j' in 'private' clause potentially has improper OpenACC privatization level: 'parm_decl'} "TODO3" { xfail *-*-* } l_compute$c_compute }
! { dg-note {variable 'a' in 'private' clause potentially has improper OpenACC privatization level: 'parm_decl'} "TODO4" { xfail *-*-* } l_compute$c_compute }
! { dg-note {variable 'C\.[0-9]+' declared in block potentially has improper OpenACC privatization level: 'const_decl'} "TODO" { target *-*-* } l_compute$c_compute }
-! { dg-note {variable 'D\.[0-9]+' declared in block isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_compute$c_compute }
end subroutine f
end module m
diff --git a/gcc/testsuite/gfortran.dg/goacc/privatization-1-routine_gang-loop.f90 b/gcc/testsuite/gfortran.dg/goacc/privatization-1-routine_gang-loop.f90
index db6d8226ed0..36f2a886e47 100644
--- a/gcc/testsuite/gfortran.dg/goacc/privatization-1-routine_gang-loop.f90
+++ b/gcc/testsuite/gfortran.dg/goacc/privatization-1-routine_gang-loop.f90
@@ -50,7 +50,6 @@ contains
! { dg-note {variable 'x' in 'private' clause isn't candidate for adjusting OpenACC privatization level: not addressable} "" { target *-*-* } l_loop$c_loop }
! { dg-note {variable 'y' in
