[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2019-02-06 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

--- Comment #14 from Rainer Orth  ---
Author: ro
Date: Wed Feb  6 18:54:16 2019
New Revision: 268588

URL: https://gcc.gnu.org/viewcvs?rev=268588&root=gcc&view=rev
Log:
Fix gcc.dg/debug/dwarf2/inline5.c with Solaris as (PR debug/87451)

PR debug/87451
* gcc.dg/debug/dwarf2/inline5.c: Allow for non-comment before
"(DIE (0x[0-9a-f]*) DW_TAG_variable".
xfail scan-assembler-not with Solaris as.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2019-02-01 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

--- Comment #13 from Richard Biener  ---
Author: rguenth
Date: Fri Feb  1 09:08:55 2019
New Revision: 268446

URL: https://gcc.gnu.org/viewcvs?rev=268446&root=gcc&view=rev
Log:
2019-02-01  Richard Biener  

PR testsuite/87451
* gcc.dg/debug/dwarf2/inline5.c: Allow more comment variants.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2019-02-01 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

Richard Biener  changed:

   What|Removed |Added

 Status|REOPENED|RESOLVED
 Resolution|--- |FIXED

--- Comment #12 from Richard Biener  ---
Fixed again.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2019-01-31 Thread sje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

--- Comment #11 from Steve Ellcey  ---
(In reply to Richard Biener from comment #10)
> (In reply to Steve Ellcey from comment #9)

> Looks like that's because of different expected comment characters,
> # vs. // in your file.  The pattern for the comment stuff is
> 
> \[^#/!\]*\[#/!\] DW
> 
> skip until first comment-char (ok), then consume comment (bogus).  Adding
> + might help.  Can you check that?

Yes, that patch fixed the failure I was seeing on aarch64.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2019-01-30 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

--- Comment #10 from Richard Biener  ---
(In reply to Steve Ellcey from comment #9)
> Created attachment 45559 [details]
> Assembly output from aarch64-linux-gnu
> 
> This test is still failing on aarch64.  Attached is the .s file from a
> top-of-tree GCC build on aarch64-linux-gnu.

Looks like that's because of different expected comment characters,
# vs. // in your file.  The pattern for the comment stuff is

\[^#/!\]*\[#/!\] DW

skip until first comment-char (ok), then consume comment (bogus).  Adding
+ might help.  Can you check that?

Index: gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c
===
--- gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c (revision 268383)
+++ gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c (working copy)
@@ -4,13 +4,13 @@
 /* { dg-options "-O -gdwarf -dA" } */
 /* { dg-do compile } */
 /* { dg-final { scan-assembler-times "DW_TAG_inlined_subroutine" 2 } } */
-/* { dg-final { scan-assembler-times "DW_TAG_lexical_block\\)\[^#/!\]*\[#/!\]
DW_AT_abstract_origin" 2 } } */
-/* { dg-final { scan-assembler-times "DW_TAG_lexical_block\\)\[^#/!\]*\[#/!\]
\\(DIE \\(0x\[0-9a-f\]*\\) DW_TAG_variable" 1 } } */
+/* { dg-final { scan-assembler-times "DW_TAG_lexical_block\\)\[^#/!\]*\[#/!\]+
DW_AT_abstract_origin" 2 } } */
+/* { dg-final { scan-assembler-times "DW_TAG_lexical_block\\)\[^#/!\]*\[#/!\]+
\\(DIE \\(0x\[0-9a-f\]*\\) DW_TAG_variable" 1 } } */
 /* 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" } } */
-/* { 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" } } */
+/* { 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" } } */
+/* { 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)
 {

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2019-01-29 Thread sje at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

Steve Ellcey  changed:

   What|Removed |Added

 CC||sje at gcc dot gnu.org

--- Comment #9 from Steve Ellcey  ---
Created attachment 45559
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=45559&action=edit
Assembly output from aarch64-linux-gnu

This test is still failing on aarch64.  Attached is the .s file from a
top-of-tree GCC build on aarch64-linux-gnu.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2018-09-28 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

--- Comment #8 from Rainer Orth  ---
Created attachment 44763
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44763&action=edit
i386-pc-solaris2.11 inline5.s

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2018-09-28 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

--- Comment #7 from Rainer Orth  ---
Created attachment 44762
  --> https://gcc.gnu.org/bugzilla/attachment.cgi?id=44762&action=edit
sparc-sun-solaris2.11 -m32 inline5.s

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2018-09-28 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

Rainer Orth  changed:

   What|Removed |Added

 Status|RESOLVED|REOPENED
 Resolution|FIXED   |---

--- Comment #6 from Rainer Orth  ---
Unfortunately, while the previous failures are gone on Solaris, I've got two
new
ones now:

FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-not (DIE
(0x([0-9a-f]*)) DW_TAG_lexical_block)[^#/!]*[#/!]
[^(].*DW_TAG_lexical_block)[^#/!x]*x1[^#/!]*[#/!] DW_AT_abstract_origin
FAIL: gcc.dg/debug/dwarf2/inline5.c scan-assembler-times
DW_TAG_lexical_block)[^#/!]*[#/!] (DIE (0x[0-9a-f]*)
DW_TAG_variable 1

Again, both 32 and 64-bit sparc and x86.

The latter seems to be due to the fact that the Solaris assemblers don't
support
.uleb, so we have

  x86:

.byte   0xc / uleb128 0xc; (DIE (0x19f) DW_TAG_lexical_block)
.byte   0xd / uleb128 0xd; (DIE (0x1a0) DW_TAG_variable)

  sparc:

.byte   0xc ! uleb128 0xc; (DIE (0x18b) DW_TAG_lexical_block)
.byte   0xd ! uleb128 0xd; (DIE (0x18c) DW_TAG_variable)

which needs to be accounted for.

The former is probably caused by Tcl doing multiline matches by default, so
"." in a regex also matches newline.

I'm attaching the sparc and x86 assembler output for reference.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2018-09-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

--- Comment #5 from Richard Biener  ---
Author: rguenth
Date: Thu Sep 27 14:17:52 2018
New Revision: 264668

URL: https://gcc.gnu.org/viewcvs?rev=264668&root=gcc&view=rev
Log:
2018-09-27  Richard Biener  

PR testsuite/87451
* gcc.dg/debug/dwarf2/inline5.c: Deal with different comment
characters.

Modified:
trunk/gcc/testsuite/ChangeLog
trunk/gcc/testsuite/gcc.dg/debug/dwarf2/inline5.c

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2018-09-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

Richard Biener  changed:

   What|Removed |Added

 Status|ASSIGNED|RESOLVED
 Resolution|--- |FIXED

--- Comment #4 from Richard Biener  ---
Fixed.

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c

2018-09-27 Thread ro at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

Rainer Orth  changed:

   What|Removed |Added

 Target|aarch64, arm|aarch64,
   ||arm,sparc-sun-solaris2.*,i3
   ||86-pc-solaris2.*
 CC||ro at gcc dot gnu.org
Summary|FAIL:   |FAIL:
   |gcc.dg/debug/dwarf2/inline5 |gcc.dg/debug/dwarf2/inline5
   |.c on aarch64 and arm   |.c

--- Comment #3 from Rainer Orth  ---
The test also FAILs on Solaris/SPARC and x86 with /bin/as, which have different
comment signs:

  x86:

.byte   0x6 / uleb128 0x6; (DIE (0x160) DW_TAG_lexical_block)
.byte   0xc / uleb128 0xc; (DIE (0x19f) DW_TAG_lexical_block)
.byte   0x6 / uleb128 0x6; (DIE (0x1c3) DW_TAG_lexical_block)
.byte   0xb / uleb128 0xb; (TAG: DW_TAG_lexical_block)
.byte   0xb / uleb128 0xb; (TAG: DW_TAG_lexical_block)

  sparc:

.byte   0x6 ! uleb128 0x6; (DIE (0x14c) DW_TAG_lexical_block)
.byte   0xc ! uleb128 0xc; (DIE (0x18b) DW_TAG_lexical_block)
.byte   0x6 ! uleb128 0x6; (DIE (0x1b0) DW_TAG_lexical_block)
.byte   0xb ! uleb128 0xb; (TAG: DW_TAG_lexical_block)
.byte   0xb ! uleb128 0xb; (TAG: DW_TAG_lexical_block)

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c on aarch64 and arm

2018-09-27 Thread rguenth at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

Richard Biener  changed:

   What|Removed |Added

 Status|UNCONFIRMED |ASSIGNED
   Last reconfirmed||2018-09-27
Version|unknown |9.0
   Assignee|unassigned at gcc dot gnu.org  |rguenth at gcc dot 
gnu.org
 Ever confirmed|0   |1

--- Comment #2 from Richard Biener  ---
Hmm, looks like the test depends on the fix for PR87440 to go in.  So let's
just wait until Jason approves that.  As you can see the testcase is named
inline5.c
and the mentioned adds inline4.c which means I expected to install them in the
other way around ...

[Bug debug/87451] FAIL: gcc.dg/debug/dwarf2/inline5.c on aarch64 and arm

2018-09-27 Thread ktkachov at gcc dot gnu.org
https://gcc.gnu.org/bugzilla/show_bug.cgi?id=87451

ktkachov at gcc dot gnu.org changed:

   What|Removed |Added

   Target Milestone|--- |9.0
Summary|[9 Regression] FAIL:|FAIL:
   |gcc.dg/debug/dwarf2/inline5 |gcc.dg/debug/dwarf2/inline5
   |.c on aarch64 and arm   |.c on aarch64 and arm
  Known to fail||9.0

--- Comment #1 from ktkachov at gcc dot gnu.org ---
Not a regression I guess since it's a new test.