- Oct 16, 2008
-
-
Sven Verdoolaege authored
The instructions were left in a confusing state by 68dc3f00 (Use bundled PolyLib by default).
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
- Oct 10, 2008
-
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
If two evalues are in essence the same, but not identical, e.g., when one of them has not been reduced, then evalue_level_cmp could in some cases return -1 on both a given call and a call with the arguments reversed, leading to an infinite recursion on eadd_rev. Arguably, the arguments should be reduced before calling evalue_level_cmp, but there is no reason it should fail this way if they are not.
-
- Oct 07, 2008
-
-
Sven Verdoolaege authored
-
- Sep 16, 2008
-
-
Sven Verdoolaege authored
-
- Sep 02, 2008
-
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
- Aug 28, 2008
-
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
Reported by Kostas Oikonomou
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
Apparently, Sun's compiler has a problem with those: "/solapplic/sun-studio-11/SUNWspro/prod/include/CC/Cstd/./map", line 251: Error: Multiple declaration for std::map<const std::vector<int>, const _new__evalue*, std::less<const std::vector<int>>, std::allocator<std::pair<const std::vector<int>, const _new__evalue*>>>::insert(const std::pair<const std::vector<int>, const _new__evalue*>&). "../../git/barvinok/laurent.cc", line 225: Where: While specializing "std::map<const std::vector<int>, const _new__evalue*, std::less<const std::vector<int>>, std::allocator<std::pair<const std::vector<int>, const _new__evalue*>>>". "../../git/barvinok/laurent.cc", line 225: Where: Specialized in non-template code.
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
Sun's compiler complained about the old code: "../../git/barvinok/genfun.cc", line 826: Error: Formal argument 3 of type extern "C" void(*)(void*,unsigned)* in call to __gmp_get_memory_functions(extern "C" void*(*)(unsigned)*, extern "C" void*(*)(void*,unsigned,unsigned)*, extern "C" void(*)(void*,unsigned)*) is being passed void(*)(void*,unsigned)*.
-
Sven Verdoolaege authored
-
- Aug 24, 2008
-
-
Sven Verdoolaege authored
-
- Jul 30, 2008
-
-
Sven Verdoolaege authored
-
- Jul 22, 2008
-
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
If GiNaC cannot be found, then libbarvinok simply references libbarvinok-core, without adding any new code, but darwin's ar apparently doesn't like it if no objects get added to an archive.
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
Sven Verdoolaege authored
-
- Jul 20, 2008
-
-
Sven Verdoolaege authored
(modulo GL_LINK_WARNING)
-
- Jul 02, 2008
-
-
Sven Verdoolaege authored
This change was missed in 562c5b13 (lattice_point.cc: multi_monom/lattice_points: return malloc'd evalue(s)).
-
- Jun 17, 2008
-
-
Sven Verdoolaege authored
-