Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

int128 on OSX and fedora #95

Open
ClementPernet opened this issue Feb 18, 2019 · 3 comments
Open

int128 on OSX and fedora #95

ClementPernet opened this issue Feb 18, 2019 · 3 comments
Assignees
Labels

Comments

@ClementPernet
Copy link
Member

ClementPernet commented Feb 18, 2019

The config detect scripts not only look for existence of __int128_t but also verifies whether std::make_unsigned<__int128_t>::type is defined.
This fails on OSX and fedora although both types __int128_t and __uint128_t are defined.
FFLAS-FFPACK decides whether it supports int128 based on Givaro's detection. As a consequence simd256<int64_t>::mulhi can not be defined although it does not use the std::make_unsigned machinery.

@ClementPernet
Copy link
Member Author

Suggestion:

  • decouple detection of int128_t from the capacity to do std::make_unsigned<int128_t>
  • when std::make_unsigned<int128_t> is not defined, couldn't we force define it in Givaro?

@ClementPernet
Copy link
Member Author

For the record, I have already decoupled FFLAS-FFPACK detection of int128 from that of Givaro, since fflas-ffpack does not require the ability to do std:make_unsigned<__int128_t>

@shobhittya
Copy link

fatal error: givaro/givzpz.h: No such file or directory
#include <givaro/givzpz.h>
how to remove this error?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

No branches or pull requests

5 participants