On Nov 30, 2016, at 5:04 AM, Pierre-Marie de Rodat <dero...@adacore.com> wrote:
> I recently added a testcase for PR78112's resolution. Unfortunately,
> what it tests changes from one platform to another and I even get
> different results for a single platform (see
> <https://gcc.gnu.org/bugzilla/show_bug.cgi?id=78112#c17>). As multiple
> developpers reported these errors and as the testcase relies on a
> compiler behavior that still looks bogous to me, I suggest to remove the
> testcase for now.
>
> Ok to commit?
So, I noticed this and didn't see who you wanted to review it so, since it was
C++, I thought I'd take a look at it. Ick. Complex issue.
One way to test this would be to have a internal check in the compiler for the
thing you don't want to happen as an assert, and then have the unpatched
compiler abort when given the test case before the work that cause fixed the
original PR. The test case then shows the failure, and should anyone break it,
the internal check will catch the problem and abort, thus causing the test case
to then fail (again). Then, you only need to compile the test case and expect
a non-zero output from the compilation. On darwin, the excess message from
dsymutil should be findable by dejagnu and should also be able to fail the test
case on darwin.
If you like that design (and a dwarf maintainer likes that design), then you
can fix this test case by removing:
> -/* { dg-final { scan-assembler-times DW_AT_inline 6 { xfail *-*-aix* } } } */
> -/* { dg-final { scan-assembler-times DW_AT_object_pointer 37 { xfail
> *-*-aix* } } } */
alone and otherwise keep the full test case. If that isn't done, this can be
fixed by making the test a darwin only test case, as on darwin I'm lead to
believe that the dsymutil output will cause the test case to fail. For that,
just add a target darwin* to the test case and then you can either remove the
two above lines or update them to be what is seen on darwin. And lastly, I'm
fine with you just punting the issue and removing the entire test case if you
feel it is best.
When looking at the test case, I wonder just how reduced it really was. The
last possible option would be to reduce the test case further and see if the
problem can be eliminated that way. Again, I'll pre-approve the test suite
part of any of those solutions you like best.
