Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297]
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
Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297]
On Wed, 19 Apr 2023 at 03:03, Jerry D via Fortran 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?
Re: [PATCH] testsuite: fix scan-tree-dump patterns [PR83904, PR100297]
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 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.