vpathplus test 2 patch

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

vpathplus test 2 patch

Gnu - Make - Bugs mailing list
The new hashing mechanism hashes differently on big vs little endian.
This makes vpathplus test 2 fail, because the order of intermediate files
inter.b and inter.c is now dependent on endiannes.

regards, Dmitry

diff --git a/tests/scripts/features/vpathplus b/tests/scripts/features/vpathplus
index 8e723fe..3ab9c05 100644
--- a/tests/scripts/features/vpathplus
+++ b/tests/scripts/features/vpathplus
@@ -96,10 +96,12 @@ $make_name: *** [$makefile;13: notarget.b] Error 1

 push(@touchedfiles, "inter.a", "inter.b");

+my $be = pack("L", 1) eq pack("N", 1);
+my $intfiles = $be ? "inter.c inter.b" : "inter.b inter.c";
 $answer = "cat ${VP}inter.d > inter.c
 cat inter.c > inter.b 2>/dev/null || exit 1
 cat inter.b > inter.a
-rm inter.b inter.c
+rm $intfiles
 ";
 &compare_output($answer,&get_logfile(1));

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: vpathplus test 2 patch

Andreas Schwab
On Sep 10 2019, Dmitry Goncharov via Bug reports and discussion for GNU  make <[hidden email]> wrote:

> The new hashing mechanism hashes differently on big vs little endian.

Should this be considered as a bug?

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: vpathplus test 2 patch

Gnu - Make - Bugs mailing list
On Wed, Sep 11, 2019 at 2:51 AM Andreas Schwab <[hidden email]> wrote:
>
> > The new hashing mechanism hashes differently on big vs little endian.
>
> Should this be considered as a bug?

I don't think the order or removal of intermediate files was
specified. Do you have a specific use case in mind, Andreas?

regards, Dmitry

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: vpathplus test 2 patch

Andreas Schwab
On Sep 11 2019, Dmitry Goncharov <[hidden email]> wrote:

> On Wed, Sep 11, 2019 at 2:51 AM Andreas Schwab <[hidden email]> wrote:
>>
>> > The new hashing mechanism hashes differently on big vs little endian.
>>
>> Should this be considered as a bug?
>
> I don't think the order or removal of intermediate files was
> specified.

The testsuite obviously is depending on it.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: vpathplus test 2 patch

Paul Smith-20
On Thu, 2019-09-12 at 09:33 +0200, Andreas Schwab wrote:

> On Sep 11 2019, Dmitry Goncharov <[hidden email]> wrote:
> > On Wed, Sep 11, 2019 at 2:51 AM Andreas Schwab <[hidden email]> wrote:
> > > > The new hashing mechanism hashes differently on big vs little
> > > > endian.
> > >
> > > Should this be considered as a bug?
> >
> > I don't think the order or removal of intermediate files was
> > specified.
>
> The testsuite obviously is depending on it.

The test suite simply matches output strings, it's not very intelligent
about stuff like that (unfortunately).

I didn't apply this change because I'm not exactly sure where I want to
go with this yet.  I'm not excited about tweaking the test suite based
on the endianness of the underlying system but it seems silly to reduce
the performance of the hash to make it consistent across endianness as
well.

Will fix this before 4.3 is released though.


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: vpathplus test 2 patch

Andreas Schwab
On Sep 16 2019, Paul Smith <[hidden email]> wrote:

> On Thu, 2019-09-12 at 09:33 +0200, Andreas Schwab wrote:
>> On Sep 11 2019, Dmitry Goncharov <[hidden email]> wrote:
>> > On Wed, Sep 11, 2019 at 2:51 AM Andreas Schwab <[hidden email]> wrote:
>> > > > The new hashing mechanism hashes differently on big vs little
>> > > > endian.
>> > >
>> > > Should this be considered as a bug?
>> >
>> > I don't think the order or removal of intermediate files was
>> > specified.
>>
>> The testsuite obviously is depending on it.
>
> The test suite simply matches output strings, it's not very intelligent
> about stuff like that (unfortunately).
>
> I didn't apply this change because I'm not exactly sure where I want to
> go with this yet.  I'm not excited about tweaking the test suite based
> on the endianness of the underlying system but it seems silly to reduce
> the performance of the hash to make it consistent across endianness as
> well.

If the hash implementation is not defined, then the testsuite should
match any order, and not just based on endianess.

Andreas.

--
Andreas Schwab, SUSE Labs, [hidden email]
GPG Key fingerprint = 0196 BAD8 1CE9 1970 F4BE  1748 E4D4 88E3 0EEA B9D7
"And now for something completely different."

_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make
Reply | Threaded
Open this post in threaded view
|

Re: vpathplus test 2 patch

Paul Smith-20
On Mon, 2019-09-16 at 15:07 +0200, Andreas Schwab wrote:
> > I didn't apply this change because I'm not exactly sure where I want to
> > go with this yet.  I'm not excited about tweaking the test suite based
> > on the endianness of the underlying system but it seems silly to reduce
> > the performance of the hash to make it consistent across endianness as
> > well.
>
> If the hash implementation is not defined, then the testsuite should
> match any order, and not just based on endianess.

That would be ideal but as previously mentioned, the test framework for
GNU make is simply not capable of checks like that.  It would be great
if it were to be reworked to be more flexible and capable but...


_______________________________________________
Bug-make mailing list
[hidden email]
https://lists.gnu.org/mailman/listinfo/bug-make