public inbox for fortran@gcc.gnu.org
 help / color / mirror / Atom feed
* [PATCH] testsuite: fix scan-tree-dump patterns [PR83904,PR100297]
@ 2023-04-18 19:39 Harald Anlauf
  2023-04-19  1:03 ` Jerry D
  0 siblings, 1 reply; 4+ messages in thread
From: Harald Anlauf @ 2023-04-18 19:39 UTC (permalink / raw)
  To: fortran, gcc-patches

[-- Attachment #1: Type: text/plain, Size: 403 bytes --]

Dear all,

the attached patch adjusts the scan-tree-dump patterns of the
reported testcases which likely were run in a location such
that a path in an error message showing in the tree-dump might
have accidentally matched "free" or "data", respectively.

For the testcase gfortran.dg/reshape_8.f90 I checked with a
failing gfortran-11 that the pattern is appropriate.

OK for mainline?

Thanks,
Harald


[-- Warning: decoded text below may be mangled, UTF-8 assumed --]
[-- Attachment #2: pr83904.diff --]
[-- Type: text/x-patch, Size: 1683 bytes --]

From ad7ea82929f65ef34a13dea5a0fe23d567f220e8 Mon Sep 17 00:00:00 2001
From: Harald Anlauf <anlauf@gmx.de>
Date: Tue, 18 Apr 2023 21:24:20 +0200
Subject: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904,PR100297]

Adjust scan-tree-dump patterns so that they do not accidentally match a
valid path.

gcc/testsuite/ChangeLog:

	PR testsuite/83904
	PR fortran/100297
	* gfortran.dg/allocatable_function_1.f90: Use "__builtin_free "
	instead of the naive "free".
	* gfortran.dg/reshape_8.f90: Extend pattern from a simple "data".
---
 gcc/testsuite/gfortran.dg/allocatable_function_1.f90 | 2 +-
 gcc/testsuite/gfortran.dg/reshape_8.f90              | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/gcc/testsuite/gfortran.dg/allocatable_function_1.f90 b/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
index f96ebc499e8..e38953bd777 100644
--- a/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
+++ b/gcc/testsuite/gfortran.dg/allocatable_function_1.f90
@@ -107,4 +107,4 @@ contains
     end function bar

 end program alloc_fun
-! { dg-final { scan-tree-dump-times "free" 10 "original" } }
+! { dg-final { scan-tree-dump-times "__builtin_free " 10 "original" } }
diff --git a/gcc/testsuite/gfortran.dg/reshape_8.f90 b/gcc/testsuite/gfortran.dg/reshape_8.f90
index 01799ac5c19..56812124cb8 100644
--- a/gcc/testsuite/gfortran.dg/reshape_8.f90
+++ b/gcc/testsuite/gfortran.dg/reshape_8.f90
@@ -11,4 +11,4 @@ program test
   a = reshape([1,2,3,4], [2,0])
   print *, a
 end
-! { dg-final { scan-tree-dump-times "data" 4 "original" } }
+! { dg-final { scan-tree-dump-not "data..0. =" "original" } }
--
2.35.3


^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904,PR100297]
  2023-04-18 19:39 [PATCH] testsuite: fix scan-tree-dump patterns [PR83904,PR100297] Harald Anlauf
@ 2023-04-19  1:03 ` Jerry D
  2023-04-19 15:14   ` [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297] Bernhard Reutner-Fischer
  0 siblings, 1 reply; 4+ messages in thread
From: Jerry D @ 2023-04-19  1:03 UTC (permalink / raw)
  To: Harald Anlauf, fortran, gcc-patches

On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
> Dear all,
> 
> the attached patch adjusts the scan-tree-dump patterns of the
> reported testcases which likely were run in a location such
> that a path in an error message showing in the tree-dump might
> have accidentally matched "free" or "data", respectively.
> 
> For the testcase gfortran.dg/reshape_8.f90 I checked with a
> failing gfortran-11 that the pattern is appropriate.
> 
> OK for mainline?
> 
> Thanks,
> Harald
> 
Yes, OK

Thanks

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297]
  2023-04-19  1:03 ` Jerry D
@ 2023-04-19 15:14   ` Bernhard Reutner-Fischer
  2023-04-19 16:34     ` Harald Anlauf
  0 siblings, 1 reply; 4+ messages in thread
From: Bernhard Reutner-Fischer @ 2023-04-19 15:14 UTC (permalink / raw)
  To: Jerry D; +Cc: Harald Anlauf, fortran, gcc-patches

On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran <fortran@gcc.gnu.org> wrote:
>
> On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
> > Dear all,
> >
> > the attached patch adjusts the scan-tree-dump patterns of the
> > reported testcases which likely were run in a location such
> > that a path in an error message showing in the tree-dump might
> > have accidentally matched "free" or "data", respectively.
> >
> > For the testcase gfortran.dg/reshape_8.f90 I checked with a
> > failing gfortran-11 that the pattern is appropriate.
> >
> > OK for mainline?
> >
> > Thanks,
> > Harald
> >
> Yes, OK

I'm certainly not opposed to this specific incarnation of such a fix.
These failures are really unpleasant :)
As proposed in https://inbox.sourceware.org/gcc-patches/20220426010029.2b476337@nbbrfq/
we could add a -fno-file to suppress the assembler .file output
(whatever the prefix looks like depends on the assembler dialect). Or
we could nuke the .file directives by a sed(1), but that would
probably be cumbersome for remote targets. I don't have a better idea
than -fno-file or -ffile=foo.c .
Fixing them case-by-case does not scale all that well IMHO.

Thoughts?

^ permalink raw reply	[flat|nested] 4+ messages in thread

* Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297]
  2023-04-19 15:14   ` [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297] Bernhard Reutner-Fischer
@ 2023-04-19 16:34     ` Harald Anlauf
  0 siblings, 0 replies; 4+ messages in thread
From: Harald Anlauf @ 2023-04-19 16:34 UTC (permalink / raw)
  To: Bernhard Reutner-Fischer, Jerry D; +Cc: fortran, gcc-patches

On 4/19/23 17:14, Bernhard Reutner-Fischer via Gcc-patches wrote:
> On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran <fortran@gcc.gnu.org> wrote:
>>
>> On 4/18/23 12:39 PM, Harald Anlauf via Fortran wrote:
>>> Dear all,
>>>
>>> the attached patch adjusts the scan-tree-dump patterns of the
>>> reported testcases which likely were run in a location such
>>> that a path in an error message showing in the tree-dump might
>>> have accidentally matched "free" or "data", respectively.
>>>
>>> For the testcase gfortran.dg/reshape_8.f90 I checked with a
>>> failing gfortran-11 that the pattern is appropriate.
>>>
>>> OK for mainline?
>>>
>>> Thanks,
>>> Harald
>>>
>> Yes, OK
>
> I'm certainly not opposed to this specific incarnation of such a fix.
> These failures are really unpleasant :)
> As proposed in https://inbox.sourceware.org/gcc-patches/20220426010029.2b476337@nbbrfq/
> we could add a -fno-file to suppress the assembler .file output
> (whatever the prefix looks like depends on the assembler dialect). Or
> we could nuke the .file directives by a sed(1), but that would
> probably be cumbersome for remote targets. I don't have a better idea
> than -fno-file or -ffile=foo.c .
> Fixing them case-by-case does not scale all that well IMHO.
>
> Thoughts?
>

?

It wasn't the tree-dumps being at fault, it was the scan patterns.


^ permalink raw reply	[flat|nested] 4+ messages in thread

end of thread, other threads:[~2023-04-19 16:34 UTC | newest]

Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2023-04-18 19:39 [PATCH] testsuite: fix scan-tree-dump patterns [PR83904,PR100297] Harald Anlauf
2023-04-19  1:03 ` Jerry D
2023-04-19 15:14   ` [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297] Bernhard Reutner-Fischer
2023-04-19 16:34     ` Harald Anlauf

This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).