Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures
On 02/08/2018 12:49 PM, Bill Allombert wrote: > On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote: >> Source: pari >> Version: 2.9.4-1 >> Severity: normal >> >> Hi there, >> >> one of the tests of cypari2 failed on the mips architectures (at least mips >> and mips64el) and the problem is in pari itself (this was on mips): >> >> ? G=galoisinit(x^6 + 108) >> %1 = [x^6 + 108, [31, 11, 25408476896404831], [12621652611058331, >> 20536155253519755, 17659145928231576, 7749330968173255, 4872321642885076, >> 12786824285346500]~, [78732, 78732, 78732, 78732, 78732, 78732; >> 5076109892172044, 10233067611024537, 10099299393208250, 15309177503196581, >> 15175409285380294, 20332367004232787; 18565751806301230, 20562176763619678, >> 11689025222888754, 11689025222888754, 20562176763619678, 18565751806301230; >> 1987912437694300, 1987912437694300, 1987912437694300, 23420564458710531, >> 23420564458710531, 23420564458710531; 24004326414261023, 17218050680994121, >> 9594576697554518, 9594576697554518, 17218050680994121, 24004326414261023; >> 22092359933430354, 20144189062948895, 8580404796430413, 16828072099974418, >> 5264287833455936, 3316116962974477], 472392, [Vecsmall([1, 2, 3, 4, 5, 6]), >> Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([3, 1, 2, 6, 4, 5]), Vecsmall([4, 6, >> 5, 1, 3, 2]), Vecsmall([5, 4, 6, 2, 1, 3]), Vecsmall([6, 5, 4, 3, 2, 1])], >> [Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([4, 6, 5, 1, 3, 2])], Vecsmall([3, >> 2])] >> ? galoissubfields(G,2,z) >> *** at top-level: galoissubfields(G,2, >> *** ^ >> *** galoissubfields: unknown type 64. >> *** Break loop: type 'break' to go back to GP prompt > OK, so now upstream and I have patches to fix all the issues in the PARI > test-suite on mipsel and mipsel64. > > Do you like to try the patches ? > > Do you like me to update the package now or can you wait for the new > usptream version (in May) ? > > Cheers, Cool thanks! Since you were able to reproduce it I don't need to test the fix myself. You can decide when to fix it in Debian. I already disabled the test in cypari2 and will restore it once this bug is closed. Best, Tobias
Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures
On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote: > Source: pari > Version: 2.9.4-1 > Severity: normal > > Hi there, > > one of the tests of cypari2 failed on the mips architectures (at least mips > and mips64el) and the problem is in pari itself (this was on mips): > > ? G=galoisinit(x^6 + 108) > %1 = [x^6 + 108, [31, 11, 25408476896404831], [12621652611058331, > 20536155253519755, 17659145928231576, 7749330968173255, 4872321642885076, > 12786824285346500]~, [78732, 78732, 78732, 78732, 78732, 78732; > 5076109892172044, 10233067611024537, 10099299393208250, 15309177503196581, > 15175409285380294, 20332367004232787; 18565751806301230, 20562176763619678, > 11689025222888754, 11689025222888754, 20562176763619678, 18565751806301230; > 1987912437694300, 1987912437694300, 1987912437694300, 23420564458710531, > 23420564458710531, 23420564458710531; 24004326414261023, 17218050680994121, > 9594576697554518, 9594576697554518, 17218050680994121, 24004326414261023; > 22092359933430354, 20144189062948895, 8580404796430413, 16828072099974418, > 5264287833455936, 3316116962974477], 472392, [Vecsmall([1, 2, 3, 4, 5, 6]), > Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([3, 1, 2, 6, 4, 5]), Vecsmall([4, 6, > 5, 1, 3, 2]), Vecsmall([5, 4, 6, 2, 1, 3]), Vecsmall([6, 5, 4, 3, 2, 1])], > [Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([4, 6, 5, 1, 3, 2])], Vecsmall([3, > 2])] > ? galoissubfields(G,2,z) > *** at top-level: galoissubfields(G,2, > *** ^ > *** galoissubfields: unknown type 64. > *** Break loop: type 'break' to go back to GP prompt OK, so now upstream and I have patches to fix all the issues in the PARI test-suite on mipsel and mipsel64. Do you like to try the patches ? Do you like me to update the package now or can you wait for the new usptream version (in May) ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures
On Tue, Feb 06, 2018 at 12:31:00AM +0100, Tobias Hansen wrote: > On 02/05/2018 11:23 PM, Bill Allombert wrote: > > On Mon, Feb 05, 2018 at 06:05:50PM +0100, Tobias Hansen wrote: > >> On 02/05/2018 06:03 PM, Bill Allombert wrote: > >>> On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote: > Source: pari > Version: 2.9.4-1 > Severity: normal > > Hi there, > > one of the tests of cypari2 failed on the mips architectures (at least > mips and mips64el) and the problem is in pari itself (this was on > mips): > >> Cool. Yes it is, on all other architectures the test ran fine: > >> > >> https://buildd.debian.org/status/package.php?p=cypari2&suite=experimental > > Some ieee754 operations give unexpected results: > > > > The attached program give on mipsel: > > a=inf ai=2147483647 b=-inf bi=2147483647 > > while > > a=inf ai=-2147483648 b=-inf bi=-2147483648 > > is expected (and seen on other plateforms). > > Where does it say that this is expected? It is certainy expected by the PARI code... > I would say it's undefined. From the c0x standard: > > When a finite value of real floating type is converted to an integer > type other than _Bool, the fractional part is discarded (i.e., the > value is truncated toward zero). If the value of the integral part > cannot be represented by the integer type, the behavior is undefined. > > http://c0x.coding-guidelines.com/6.3.1.4.html Oh, I agree with you. I was trying to explain why it only occurs on mips. Cheers, -- Bill. Imagine a large red swirl here.
Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures
On 02/05/2018 11:23 PM, Bill Allombert wrote: > On Mon, Feb 05, 2018 at 06:05:50PM +0100, Tobias Hansen wrote: >> On 02/05/2018 06:03 PM, Bill Allombert wrote: >>> On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote: Source: pari Version: 2.9.4-1 Severity: normal Hi there, one of the tests of cypari2 failed on the mips architectures (at least mips and mips64el) and the problem is in pari itself (this was on mips): >> Cool. Yes it is, on all other architectures the test ran fine: >> >> https://buildd.debian.org/status/package.php?p=cypari2&suite=experimental > Some ieee754 operations give unexpected results: > > The attached program give on mipsel: > a=inf ai=2147483647 b=-inf bi=2147483647 > while > a=inf ai=-2147483648 b=-inf bi=-2147483648 > is expected (and seen on other plateforms). > > Cheers, Where does it say that this is expected? I would say it's undefined. From the c0x standard: When a finite value of real floating type is converted to an integer type other than _Bool, the fractional part is discarded (i.e., the value is truncated toward zero). If the value of the integral part cannot be represented by the integer type, the behavior is undefined. http://c0x.coding-guidelines.com/6.3.1.4.html Best, Tobias
Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures
On Mon, Feb 05, 2018 at 06:05:50PM +0100, Tobias Hansen wrote:
> On 02/05/2018 06:03 PM, Bill Allombert wrote:
> > On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote:
> >> Source: pari
> >> Version: 2.9.4-1
> >> Severity: normal
> >>
> >> Hi there,
> >>
> >> one of the tests of cypari2 failed on the mips architectures (at least
> >> mips and mips64el) and the problem is in pari itself (this was on
> >> mips):
>
> Cool. Yes it is, on all other architectures the test ran fine:
>
> https://buildd.debian.org/status/package.php?p=cypari2&suite=experimental
Some ieee754 operations give unexpected results:
The attached program give on mipsel:
a=inf ai=2147483647 b=-inf bi=2147483647
while
a=inf ai=-2147483648 b=-inf bi=-2147483648
is expected (and seen on other plateforms).
Cheers,
--
Bill.
Imagine a large red swirl here.
#include
int
main(void)
{
double a = 1./0.;
long ai = (long) a;
double b = -a;
long bi = (long) b;
printf("a=%g ai=%ld b=%g bi=%ld\n",a,ai,b,bi);
}
Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures
On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote: > Source: pari > Version: 2.9.4-1 > Severity: normal > > Hi there, > > one of the tests of cypari2 failed on the mips architectures (at least > mips and mips64el) and the problem is in pari itself (this was on > mips): > > ? G=galoisinit(x^6 + 108) > %1 = [x^6 + 108, [31, 11, 25408476896404831], [12621652611058331, > 20536155253519755, 17659145928231576, 7749330968173255, 4872321642885076, > 12786824285346500]~, [78732, 78732, 78732, 78732, 78732, 78732; > 5076109892172044, 10233067611024537, 10099299393208250, 15309177503196581, > 15175409285380294, 20332367004232787; 18565751806301230, 20562176763619678, > 11689025222888754, 11689025222888754, 20562176763619678, 18565751806301230; > 1987912437694300, 1987912437694300, 1987912437694300, 23420564458710531, > 23420564458710531, 23420564458710531; 24004326414261023, 17218050680994121, > 9594576697554518, 9594576697554518, 17218050680994121, 24004326414261023; > 22092359933430354, 20144189062948895, 8580404796430413, 16828072099974418, > 5264287833455936, 3316116962974477], 472392, [Vecsmall([1, 2, 3, 4, 5, 6]), > Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([3, 1, 2, 6, 4, 5]), Vecsmall([4, 6, > 5, 1, 3, 2]), Vecsmall([5, 4, 6, 2, 1, 3]), Vecsmall([6, 5, 4, 3, 2, 1])], > [Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([4, 6, 5, 1, 3, 2])], Vecsmall([3, > 2])] > ? galoissubfields(G,2,z) > *** at top-level: galoissubfields(G,2, > *** ^ > *** galoissubfields: unknown type 64. > *** Break loop: type 'break' to go back to GP prompt > > Could you please have a look? Doing that now... mipsel has the same bug. Is it mips specific ? Cheers, -- Bill. Imagine a large red swirl here.
Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures
On 02/05/2018 06:03 PM, Bill Allombert wrote: > On Mon, Feb 05, 2018 at 05:35:12PM +0100, Tobias Hansen wrote: >> Source: pari >> Version: 2.9.4-1 >> Severity: normal >> >> Hi there, >> >> one of the tests of cypari2 failed on the mips architectures (at least >> mips and mips64el) and the problem is in pari itself (this was on >> mips): >> >> ? G=galoisinit(x^6 + 108) >> %1 = [x^6 + 108, [31, 11, 25408476896404831], [12621652611058331, >> 20536155253519755, 17659145928231576, 7749330968173255, 4872321642885076, >> 12786824285346500]~, [78732, 78732, 78732, 78732, 78732, 78732; >> 5076109892172044, 10233067611024537, 10099299393208250, 15309177503196581, >> 15175409285380294, 20332367004232787; 18565751806301230, 20562176763619678, >> 11689025222888754, 11689025222888754, 20562176763619678, 18565751806301230; >> 1987912437694300, 1987912437694300, 1987912437694300, 23420564458710531, >> 23420564458710531, 23420564458710531; 24004326414261023, 17218050680994121, >> 9594576697554518, 9594576697554518, 17218050680994121, 24004326414261023; >> 22092359933430354, 20144189062948895, 8580404796430413, 16828072099974418, >> 5264287833455936, 3316116962974477], 472392, [Vecsmall([1, 2, 3, 4, 5, 6]), >> Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([3, 1, 2, 6, 4, 5]), Vecsmall([4, 6, >> 5, 1, 3, 2]), Vecsmall([5, 4, 6, 2, 1, 3]), Vecsmall([6, 5, 4, 3, 2, 1])], >> [Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([4, 6, 5, 1, 3, 2])], Vecsmall([3, >> 2])] >> ? galoissubfields(G,2,z) >> *** at top-level: galoissubfields(G,2, >> *** ^ >> *** galoissubfields: unknown type 64. >> *** Break loop: type 'break' to go back to GP prompt >> >> Could you please have a look? > Doing that now... mipsel has the same bug. > Is it mips specific ? > > Cheers, Cool. Yes it is, on all other architectures the test ran fine: https://buildd.debian.org/status/package.php?p=cypari2&suite=experimental Best, Tobias
Bug#889674: pari: Error ("unknown type 64") for galoissubfields on mips architectures
Source: pari Version: 2.9.4-1 Severity: normal Hi there, one of the tests of cypari2 failed on the mips architectures (at least mips and mips64el) and the problem is in pari itself (this was on mips): ? G=galoisinit(x^6 + 108) %1 = [x^6 + 108, [31, 11, 25408476896404831], [12621652611058331, 20536155253519755, 17659145928231576, 7749330968173255, 4872321642885076, 12786824285346500]~, [78732, 78732, 78732, 78732, 78732, 78732; 5076109892172044, 10233067611024537, 10099299393208250, 15309177503196581, 15175409285380294, 20332367004232787; 18565751806301230, 20562176763619678, 11689025222888754, 11689025222888754, 20562176763619678, 18565751806301230; 1987912437694300, 1987912437694300, 1987912437694300, 23420564458710531, 23420564458710531, 23420564458710531; 24004326414261023, 17218050680994121, 9594576697554518, 9594576697554518, 17218050680994121, 24004326414261023; 22092359933430354, 20144189062948895, 8580404796430413, 16828072099974418, 5264287833455936, 3316116962974477], 472392, [Vecsmall([1, 2, 3, 4, 5, 6]), Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([3, 1, 2, 6, 4, 5]), Vecsmall([4, 6, 5, 1, 3, 2]), Vecsmall([5, 4, 6, 2, 1, 3]), Vecsmall([6, 5, 4, 3, 2, 1])], [Vecsmall([2, 3, 1, 5, 6, 4]), Vecsmall([4, 6, 5, 1, 3, 2])], Vecsmall([3, 2])] ? galoissubfields(G,2,z) *** at top-level: galoissubfields(G,2, *** ^ *** galoissubfields: unknown type 64. *** Break loop: type 'break' to go back to GP prompt Could you please have a look? Best, Tobias
