More ld testsuite tweaks

classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

More ld testsuite tweaks

Zack Weinberg

ld-scripts/align1 fails on arm-epoc-pe; this seems to be a genuine
bug, but not an important one; accordingly, XFAIL it.  OK to commit?

zw

        * ld-scripts/align.exp: XFAIL align1 on arm-epoc-pe.

===================================================================
Index: ld/testsuite/ld-scripts/align.exp
--- ld/testsuite/ld-scripts/align.exp 12 May 2005 07:32:08 -0000 1.6
+++ ld/testsuite/ld-scripts/align.exp 31 May 2005 22:54:06 -0000
@@ -29,6 +29,9 @@ if ![ld_assemble $as $srcdir/$subdir/ali
     return
 }
 
+# Doesn't work on arm-epoc-pe, appears to be a genuine bug.
+setup_xfail "arm-epoc-pe"
+
 if ![ld_simple_link $ld tmpdir/align "-T $srcdir/$subdir/align.t tmpdir/align.o"] {
     fail $testname
 } else {
Reply | Threaded
Open this post in threaded view
|

Re: More ld testsuite tweaks

Nick Clifton
Hi Zack,

> ld-scripts/align1 fails on arm-epoc-pe; this seems to be a genuine
> bug, but not an important one; accordingly, XFAIL it.  OK to commit?
>
>         * ld-scripts/align.exp: XFAIL align1 on arm-epoc-pe.

Not really no.  If it is a genuine bug it ought to be fixed.  If it
cannot be fixed, or you do not have the time to fix it, then the reason
for the failure at least ought to be documented in the comment.  If you
do not know why it is failing and you do not try to track it down then
you may well missing an opportunity to uncover a problem which is not
just specific to the arm-epoc-pe toolchain but possibly all arm
toolchains and maybe even every toolchain.

Cheers
   Nick
Reply | Threaded
Open this post in threaded view
|

Re: More ld testsuite tweaks

Zack Weinberg
Nick Clifton <[hidden email]> writes:

> Hi Zack,
>
>> ld-scripts/align1 fails on arm-epoc-pe; this seems to be a genuine
>> bug, but not an important one; accordingly, XFAIL it.  OK to commit?
>>         * ld-scripts/align.exp: XFAIL align1 on arm-epoc-pe.
>
> Not really no.  If it is a genuine bug it ought to be fixed.  If it
> cannot be fixed, or you do not have the time to fix it, then the
> reason for the failure at least ought to be documented in the comment.
> If you do not know why it is failing and you do not try to track it
> down then you may well missing an opportunity to uncover a problem
> which is not just specific to the arm-epoc-pe toolchain but possibly
> all arm toolchains and maybe even every toolchain.

I did try to track it down, but got nowhere.  (I'm still not very good
at tracing binutils' internal logic.)  Since I posted that patch, I've
determined that it is a general PECOFF problem, but I know no more
than that.  

Alan Modra already approved the (general PECOFF) xfail.  I'd prefer
not to take it back out again.  Over on the gcc side, we've found that
having a baseline state of no unexpected failures is a very desirable
thing - it means you can have confidence that any FAILs that show up
in testing are your fault.

zw
Reply | Threaded
Open this post in threaded view
|

Re: More ld testsuite tweaks

Nick Clifton
Hi Zack,

>>Not really no.  If it is a genuine bug it ought to be fixed.  If it
>>cannot be fixed, or you do not have the time to fix it, then the
>>reason for the failure at least ought to be documented in the comment.
>>If you do not know why it is failing and you do not try to track it
>>down then you may well missing an opportunity to uncover a problem
>>which is not just specific to the arm-epoc-pe toolchain but possibly
>>all arm toolchains and maybe even every toolchain.
>
>
> I did try to track it down, but got nowhere.  (I'm still not very good
> at tracing binutils' internal logic.)  Since I posted that patch, I've
> determined that it is a general PECOFF problem, but I know no more
> than that.  
>
> Alan Modra already approved the (general PECOFF) xfail.  I'd prefer
> not to take it back out again.  

No it is fine.  The reply above was sent before I saw your modified post
which addressed the problem in a broader fashion.

> Over on the gcc side, we've found that
> having a baseline state of no unexpected failures is a very desirable
> thing - it means you can have confidence that any FAILs that show up
> in testing are your fault.

True - but I would prefer that we achieve such a state for binutils by
fixing the existing bugs rather than just suppressing the tests that
reveal them.  (Actually I would prefer that for gcc too... :-)  The
problem I have found is that once a bug has been XFAILed in the
testsuite it is left and ignored until it trips up a user in the real
world and they report it.  I would prefer to never hear from users
because they never encounter bugs.  (Rather than because they never use
the binutils because they are so buggy...)

Cheers
   Nick