Bug#835823: Polly's imath assumes little-endian

[James Clarke]

Hi Sylvestre,
For some reason I have yet to receive this (only saw it thanks to
Tobias’s reply).

On Sun, 28 Aug 2016 21:42:28 +0200 Sylvestre Ledru <sylvestre at debian.org> wrote:
> Le 28/08/2016 à 18:26, James Clarke a écrit :
>> The bundled copy of imath currently assumes little-endian in its
>> mpz_import and mpz_export functions (which provide a GMP-compatible
>> interface). I have submitted a pull request to upstream imath[0] which
>> provides a full implementation with respect to endianness.
> 
> OK, I will wait for this to be merge upstream before doing anything.
> Did you report that to upstream too? (cc Tobias)

Ok, I can understand that, it touches a fairly important bit of polly. I only
reported it to imath; my plan was to get isl updated with the new imath and
then polly with the new isl once merged. It’s all very complicated with
multiple upstreams...

>> With this
>> patch applied to the bundled imath (patch attached with subdirectories
>> fixed) check-polly succeeds on sparc64 (perhaps you could consider
>> making check-polly failures fatal on all architectures, and re-enabling
>> polly on powerpc and s390x?).
> 
> Sorry but I am afraid I won't, this is hard enough with llvm & clang only on i386 & amd64…

(Assuming you’re referring to making the failures fatal; unless there are other
issues with powerpc and s390x I see no reason why they should remain disabled.)

(Disclaimer: This is just my opinion as someone with no experience of packaging
llvm. I trust that your views are based on experience, unlike mine which are
merely theory-based, but I’ll offer them anyway.)

I can understand it’s a pain. Having said that, ignoring *all* test results
seems like an incredibly crude solution that can end up shipping broken
packages. The tests are there for a reason, and while the odd failure isn’t
necessarily a big deal, someone currently needs to check the logs for every
arch for every upload to make sure there aren’t regressions. It’s not *that*
much better than building everything with nocheck, and there’s a reason why
that’s (generally) only done in the early stages of a port.

Regards,
James