[PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality
This patch add -fno-tree-fre to dg-options in gcc.dg/guality/sra-1.c, to make the following testcases passed. FAIL: gcc.dg/guality/sra-1.c -Og -DPREVENT_OPTIMIZATION line 43 a.i == 4 FAIL: gcc.dg/guality/sra-1.c -Og -DPREVENT_OPTIMIZATION line 43 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 21 a.j == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 32 a[1] == 14 FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 43 a.j == 14 The detail error logs like this: > Spawning: gdb -nx -nw -quiet -batch -x sra-1.gdb ./sra-1.exe > > spawn gdb -nx -nw -quiet -batch -x sra-1.gdb ./sra-1.exe > > Breakpoint 1 at 0x40074c: file > /home/build_gcc/gcc-a64fx-1-a/gcc/testsuite/gcc.dg/guality/sra-1.c, line 43. > > Breakpoint 1, f3 (k=k@entry=7) at > /home/build_gcc/gcc-a64fx-1-a/gcc/testsuite/gcc.dg/guality/sra-1.c:43 > 43bar (a.j);/* { dg-final { gdb-test . "a.j" "14" } } */ > $1 = > $2 = 4 > != 4 Tested on aarch64. Regards! hujp --- gcc/testsuite/gcc.dg/guality/sra-1.c | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/gcc/testsuite/gcc.dg/guality/sra-1.c b/gcc/testsuite/gcc.dg/guality/sra-1.c index 8ad57cf3f8e..94ea29dd727 100644 --- a/gcc/testsuite/gcc.dg/guality/sra-1.c +++ b/gcc/testsuite/gcc.dg/guality/sra-1.c @@ -1,6 +1,6 @@ /* PR debug/43983 */ /* { dg-do run } */ -/* { dg-options "-g -fno-ipa-icf" } */ +/* { dg-options "-g -fno-tree-fre -fno-ipa-icf" } */ struct A { int i; int j; }; struct B { int : 4; int i : 12; int j : 12; int : 4; }; -- 2.17.1
Re: [PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality
On Thu, Aug 27, 2020 at 3:38 AM Hu Jiangping wrote: > > This patch add -fno-tree-fre to dg-options in gcc.dg/guality/sra-1.c, > to make the following testcases passed. > > FAIL: gcc.dg/guality/sra-1.c -Og -DPREVENT_OPTIMIZATION line 43 a.i == 4 > FAIL: gcc.dg/guality/sra-1.c -Og -DPREVENT_OPTIMIZATION line 43 a.j == 14 > FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 21 a.j == 14 > FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 32 a[1] == 14 > FAIL: gcc.dg/guality/sra-1.c -O2 -flto -fuse-linker-plugin > -fno-fat-lto-objects -DPREVENT_OPTIMIZATION line 43 a.j == 14 > > The detail error logs like this: > > Spawning: gdb -nx -nw -quiet -batch -x sra-1.gdb ./sra-1.exe > > spawn gdb -nx -nw -quiet -batch -x sra-1.gdb ./sra-1.exe > > Breakpoint 1 at 0x40074c: file > > /home/build_gcc/gcc-a64fx-1-a/gcc/testsuite/gcc.dg/guality/sra-1.c, line 43. > > > > Breakpoint 1, f3 (k=k@entry=7) at > > /home/build_gcc/gcc-a64fx-1-a/gcc/testsuite/gcc.dg/guality/sra-1.c:43 > > 43bar (a.j);/* { dg-final { gdb-test . "a.j" "14" } } */ > > $1 = > > $2 = 4 > > != 4 > > Tested on aarch64. Huh well - I guess it should be XFAILed instead? But then we see XPASSes. Disabling FRE doesn't look correct - we _do_ want the test to succeed here. Did you analyze why it fails? It looks like we assign 'a' a register at RTL expansion time for -Og but do not perform any fancy tracking of components of it then. On GIMPLE we assume it's eventually memory and thus wouldn't bother with any debug stmts. So it's a genuine FAIL for -Og at least. That said, the logic is simple - both a.i and a.j need to be available for a.i + a.j to be evaluated. For some reasons we fail to record where their value resides. For -Og they are in %rbp, resp. %rbx. But obviously some elaborate DWARF is necessary to convey that info. Richard. > Regards! > hujp > > --- > gcc/testsuite/gcc.dg/guality/sra-1.c | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/gcc/testsuite/gcc.dg/guality/sra-1.c > b/gcc/testsuite/gcc.dg/guality/sra-1.c > index 8ad57cf3f8e..94ea29dd727 100644 > --- a/gcc/testsuite/gcc.dg/guality/sra-1.c > +++ b/gcc/testsuite/gcc.dg/guality/sra-1.c > @@ -1,6 +1,6 @@ > /* PR debug/43983 */ > /* { dg-do run } */ > -/* { dg-options "-g -fno-ipa-icf" } */ > +/* { dg-options "-g -fno-tree-fre -fno-ipa-icf" } */ > > struct A { int i; int j; }; > struct B { int : 4; int i : 12; int j : 12; int : 4; }; > -- > 2.17.1 > > >
RE: [PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality
Hi, Richard, Jakub Thanks for reply. I'm not sure about if the case should fail. So, I add Jakub who committed this testcase. I thought the case should success, but for changes of gcc of years, now it failed. So I think that may be some optimization are unnecessary for this testcase, and I found the FRE. > Huh well - I guess it should be XFAILed instead? But then we see > XPASSes. Disabling > FRE doesn't look correct - we _do_ want the test to succeed here. Did > you analyze > why it fails? Do you mean the reason may be in gcc, not in this testcase? If so, I'll do more debug. > > It looks like we assign 'a' a register at RTL expansion time for -Og > but do not perform any > fancy tracking of components of it then. On GIMPLE we assume it's > eventually > memory and thus wouldn't bother with any debug stmts. > > So it's a genuine FAIL for -Og at least. That said, the logic is simple - > both > a.i and a.j need to be available for a.i + a.j to be evaluated. For > some reasons > we fail to record where their value resides. For -Og they are in > %rbp, resp. %rbx. > But obviously some elaborate DWARF is necessary to convey that info. I tried -gdwarf options, but it makes no difference. Jakub, what do you think? Regards! Hujp > > Richard. > > > Regards! > > hujp > > > > --- > > gcc/testsuite/gcc.dg/guality/sra-1.c | 2 +- > > 1 file changed, 1 insertion(+), 1 deletion(-) > > > > diff --git a/gcc/testsuite/gcc.dg/guality/sra-1.c > b/gcc/testsuite/gcc.dg/guality/sra-1.c > > index 8ad57cf3f8e..94ea29dd727 100644 > > --- a/gcc/testsuite/gcc.dg/guality/sra-1.c > > +++ b/gcc/testsuite/gcc.dg/guality/sra-1.c > > @@ -1,6 +1,6 @@ > > /* PR debug/43983 */ > > /* { dg-do run } */ > > -/* { dg-options "-g -fno-ipa-icf" } */ > > +/* { dg-options "-g -fno-tree-fre -fno-ipa-icf" } */ > > > > struct A { int i; int j; }; > > struct B { int : 4; int i : 12; int j : 12; int : 4; }; > > -- > > 2.17.1 > > > > > > >
Re: [PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality
On Thu, Aug 27, 2020 at 11:13:50AM +, Hu, Jiangping wrote: > I'm not sure about if the case should fail. > So, I add Jakub who committed this testcase. > > I thought the case should success, but for changes of gcc of > years, now it failed. So I think that may be some optimization > are unnecessary for this testcase, and I found the FRE. The intent of the guality testsuite is to track regressions in debug info quality. Because the testing matrix is huge (different targets x different -O* options x different gdb versions), it isn't really feasible to keep xfails for them accurately, so all we care about is whether we don't regress compared to older gcc releases for the same target, same -O* options and same gdb version. If we do regress e.g. because of some added optimization, the intent is that it is analyzed why it regressed and if possible some improvements in the debug info generation are added to deal with the optimization if possible. So adding -fno-tree-* is not the right solution, the majority of people will not use such options in their codes and so they will observe the debug info quality degradation there. Jakub
RE: [PATCH] testsuite: add -fno-tree-fre in gcc.dg/guality
Hi, Jakub Thank you for your detailed explanation. I will try to compare the results of rtl expand as Richard have suggested, to see if I can find anything. May be I can make another patch. Thanks again. Regards! Hujp > On Thu, Aug 27, 2020 at 11:13:50AM +, Hu, Jiangping wrote: > > I'm not sure about if the case should fail. > > So, I add Jakub who committed this testcase. > > > > I thought the case should success, but for changes of gcc of > > years, now it failed. So I think that may be some optimization > > are unnecessary for this testcase, and I found the FRE. > > The intent of the guality testsuite is to track regressions in debug info > quality. Because the testing matrix is huge > (different targets x different -O* options x different gdb versions), > it isn't really feasible to keep xfails for them accurately, so all we > care > about is whether we don't regress compared to older gcc releases for the > same target, same -O* options and same gdb version. > If we do regress e.g. because of some added optimization, the intent is > that it is analyzed why it regressed and if possible some improvements > in the debug info generation are added to deal with the optimization if > possible. > So adding -fno-tree-* is not the right solution, the majority of people > will > not use such options in their codes and so they will observe the debug > info > quality degradation there. > > Jakub > >