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

Fix apple clang build #1479

Merged
merged 1 commit into from
Dec 10, 2022
Merged

Fix apple clang build #1479

merged 1 commit into from
Dec 10, 2022

Conversation

DenisYaroshevskiy
Copy link
Collaborator

@DenisYaroshevskiy DenisYaroshevskiy commented Dec 9, 2022

It works!

  • apple clang does not like size_t and ptrdiff_t much
  • had some hard errors in concepts - hence wide_cardinal concept
  • aligned alloc needs no less than 8 bytes alignment

What does not work?
#1478

Square is not precise enough. I don't know what to do with this one.

[X] - Check behavior of sqr on wide
  >  with [T = eve::wide<double, eve::fixed<4>>]
    [sqr.cpp:45] - ** FAILURE ** : Expected: eve::sqr(z_t{a0,a1}) == z*z but (506.392-47099.3i, -802.259+298.873i, -9748.24-276.767i, -43749.8+1229.74i) == (506.392-47099.3i, -802.259+298.873i, -9748.24-276.767i, -43749.8+1229.74i) within 15.50 ULP when 2.00 ULP was expected.
  >  with [T = eve::wide<double, eve::fixed<4>>]
    [sqr.cpp:47] - ** FAILURE ** : Expected: eve::pedantic(eve::sqr)(z) == z*z but (506.392-47099.3i, -802.259+298.873i, -9748.24-276.767i, -43749.8+1229.74i) == (506.392-47099.3i, -802.259+298.873i, -9748.24-276.767i, -43749.8+1229.74i) within 16.50 ULP when 6.00 ULP was expected.

UPD: fixed square by putting 18.0 (according ot @jfalcou ).

@@ -72,11 +74,13 @@ namespace eve

void * allocate_aligned(std::size_t n, std::size_t a)
{
if (a < 8U) a = 8U;
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

a = std::min(a,8U); ?

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

max. I thought about it but I figured I can not bring algorithm.

Also size_t and U are different types on apple clang - I'd have to cast

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried - because of the cast I don't want to.

@@ -82,8 +79,6 @@ TTS_CASE("Check for arithmetic_scalar_value on plain_scalar_value" )
TTS_EXPECT( eve::arithmetic_scalar_value<std::uint16_t> );
TTS_EXPECT( eve::arithmetic_scalar_value<std::uint32_t> );
TTS_EXPECT( eve::arithmetic_scalar_value<std::uint64_t> );
TTS_EXPECT( eve::arithmetic_scalar_value<std::size_t> );
Copy link
Owner

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I need to get more info on what Apple Clang doesn't liek about those.
size_t and ptrdiff_t are common type people will want to use.

Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So is char. But it doesn't work.

If we want to support all of the weird types that are not actually the same, we have to solve it as a separate problem.

Copy link
Collaborator Author

@DenisYaroshevskiy DenisYaroshevskiy left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

I think that they size_t ptrdifft char and so on are a separate prolbem.
We should solve it as a dedicated thing: #1481

@@ -72,11 +74,13 @@ namespace eve

void * allocate_aligned(std::size_t n, std::size_t a)
{
if (a < 8U) a = 8U;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Tried - because of the cast I don't want to.

@@ -42,7 +42,7 @@ reverse_evaluate_rational(const T num, const U den, V z) noexcept
z = rec(z);
auto r = reverse_horner(z, num) / reverse_horner(z, den);
if( size(den) == size(num) ) return r;
else return r * pow(z, size(num) - size(den));
else return r * pow(z, (std::uint64_t) size(num) - size(den));
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this pops up because size_t is not passing the concept. And going to pow is not working.

@@ -82,8 +79,6 @@ TTS_CASE("Check for arithmetic_scalar_value on plain_scalar_value" )
TTS_EXPECT( eve::arithmetic_scalar_value<std::uint16_t> );
TTS_EXPECT( eve::arithmetic_scalar_value<std::uint32_t> );
TTS_EXPECT( eve::arithmetic_scalar_value<std::uint64_t> );
TTS_EXPECT( eve::arithmetic_scalar_value<std::size_t> );
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

So is char. But it doesn't work.

If we want to support all of the weird types that are not actually the same, we have to solve it as a separate problem.

@@ -97,7 +97,7 @@ namespace eve::algo::views

EVE_FORCEINLINE friend T tagged_dispatch(eve::tag::read_, iota_with_step_iterator self)
{
return self.base + eve::convert(self.i * self.step, eve::as<T>{});
return self.base + (T)self.i * self.step;
Copy link
Collaborator Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This cast is because you can't eve::convert ptrdifft

@jfalcou jfalcou merged commit 9a22377 into main Dec 10, 2022
@jfalcou jfalcou deleted the apple_clang_build branch December 10, 2022 17:38
@meftunca
Copy link

Please Update Conan Package

@meftunca
Copy link

I am Getting these errors

ERROR: There are invalid packages (packages that cannot exist for this configuration):
jfalcou-eve/v2022.09.1: Invalid ID: EVE does not support apple Clang due to an incomplete libcpp.

@jfalcou
Copy link
Owner

jfalcou commented Dec 23, 2022

This will be done for next release.

@meftunca
Copy link

When will the new version be released?

@jfalcou
Copy link
Owner

jfalcou commented Jan 26, 2023

Probably early february

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

Successfully merging this pull request may close these issues.

3 participants