| Message ID | orsg3bvj4c.fsf@lxoliva.fsfla.org |
|---|---|
| State | New |
| Headers | show |
| Series | fix asm-not pattern in dwarf2/inline5.c | expand |
On Apr 27, 2021, at 8:32 AM, Alexandre Oliva <oliva@adacore.com> wrote: > > The test is supposed to check that the abstract lexical block of a > function that was inlined doesn't have attributes, and that the > concrete inlined lexical block does. > The problem is that '[.../...]+ +[^(].*' matches '/ (DIE...', because > '[^(]' may match the second blank, and after that anything goes. > Ok to install? Ok.
On 4/27/2021 9:32 AM, Alexandre Oliva wrote: > The test is supposed to check that the abstract lexical block of a > function that was inlined doesn't have attributes, and that the > concrete inlined lexical block does. > > There are two patterns to verify the absence of attributes in the > abstract lexical block, one for the case in which the concrete block > appears after the abstract one, and another for the case in which it's > before. > > The former has a problem that is not visible when asm comments start > with a single character, but that becomes apparent when they start > with "/ ". > > The pattern starts by matching the abstract DW_TAG_lexical_block DIE > header, and checking that the next line has, after any of the > comment-starter characters (e.g. '/'), there are one or more blanks ' > +', and then a character other than the '(' that would start another > DIE. > > The problem is that '[.../...]+ +[^(].*' matches '/ (DIE...', because > '[^(]' may match the second blank, and after that anything goes. So > we end up recognizing the pattern, as if it was an abstract lexical > block with an attribute. > > This could be minimally fixed by changing '[^(]' to '[^ (]', but the > pattern that matches concrete before abstract checks for an explicit > DW_AT after the abstract DIE, so I'm using that in the other pattern > as well. > > For reference, the lines that start the unwanted match are: > .uleb128 0xc / (DIE (0xa4) DW_TAG_lexical_block) > .uleb128 0xd / (DIE (0xa5) DW_TAG_variable) > > Regstrapped on x86-64-linux-gnu, also tested with a cross to x86-vx7r2. > Ok to install? > > > for gcc/testsuite/ChangeLog > > * gcc.dg/debug/dwarf2/inline5.c: Adjust pattern to avoid > mismatch when asm comments start with "/ ". OK jeff
diff --git a/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c b/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c index bd34f0da5a6bb..3b50e9f261735 100644 --- a/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c +++ b/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c @@ -9,7 +9,7 @@ /* We do not know which is output first so look for both invalid abstract origins on the lexical blocks (knowing that the abstract instance has no attribute following the DW_TAG_lexical_block. */ -/* { dg-final { scan-assembler-not "\\(DIE \\(0x(\[0-9a-f\]*)\\) DW_TAG_lexical_block\\)\[^#/!@;\\|\]*\[#/!@;\\|\]+ +\[^(\].*DW_TAG_lexical_block\\)\[^#/!@;\\|x\]*x\\1\[^#/!@;\\|\]*\[#/!@;\\|\] +DW_AT_abstract_origin" { xfail { { *-*-aix* || *-*-solaris2.* } && { ! gas } } } } } */ +/* { dg-final { scan-assembler-not "\\(DIE \\(0x(\[0-9a-f\]*)\\) DW_TAG_lexical_block\\)\[^#/!@;\\|\]*\[#/!@;\\|\]+ +DW_AT.*DW_TAG_lexical_block\\)\[^#/!@;\\|x\]*x\\1\[^#/!@;\\|\]*\[#/!@;\\|\] +DW_AT_abstract_origin" { xfail { { *-*-aix* || *-*-solaris2.* } && { ! gas } } } } } */ /* { dg-final { scan-assembler-not "DW_TAG_lexical_block\\)\[^#/!@;\\|x\]*x(\[0-9a-f\]*)\[^#/!@;\\|\]*\[#/!@;\\|\]+ +DW_AT_abstract_origin.*\\(DIE \\(0x\\1\\) DW_TAG_lexical_block\\)\[^#/!@;\\|\]*\[#/!@;\\|\]+ +DW_AT" } } */ int foo (int i)
The test is supposed to check that the abstract lexical block of a function that was inlined doesn't have attributes, and that the concrete inlined lexical block does. There are two patterns to verify the absence of attributes in the abstract lexical block, one for the case in which the concrete block appears after the abstract one, and another for the case in which it's before. The former has a problem that is not visible when asm comments start with a single character, but that becomes apparent when they start with "/ ". The pattern starts by matching the abstract DW_TAG_lexical_block DIE header, and checking that the next line has, after any of the comment-starter characters (e.g. '/'), there are one or more blanks ' +', and then a character other than the '(' that would start another DIE. The problem is that '[.../...]+ +[^(].*' matches '/ (DIE...', because '[^(]' may match the second blank, and after that anything goes. So we end up recognizing the pattern, as if it was an abstract lexical block with an attribute. This could be minimally fixed by changing '[^(]' to '[^ (]', but the pattern that matches concrete before abstract checks for an explicit DW_AT after the abstract DIE, so I'm using that in the other pattern as well. For reference, the lines that start the unwanted match are: .uleb128 0xc / (DIE (0xa4) DW_TAG_lexical_block) .uleb128 0xd / (DIE (0xa5) DW_TAG_variable) Regstrapped on x86-64-linux-gnu, also tested with a cross to x86-vx7r2. Ok to install? for gcc/testsuite/ChangeLog * gcc.dg/debug/dwarf2/inline5.c: Adjust pattern to avoid mismatch when asm comments start with "/ ". --- gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-)