- Jun 13, 2015
-
-
Christian Engwer authored
most of the tests work. std::complex<GMPField> does not work as expected, but this is perhaps something we don't want to support. As std::complex does not allow to initialize with other parameters than the data type itself, we can not initialize from int or other compatible scalar values. The smae problem occures when interacting with int values directly.
-
- May 28, 2015
-
-
Christoph Grüninger authored
Affected are older CMake versions 2.8.6 to 2.8.9 maybe even, newer versions.
-
- May 25, 2015
-
-
Christoph Grüninger authored
-
Christoph Grüninger authored
Fixes FS#FS#1649.
-
- May 21, 2015
-
-
Steffen Müthing authored
dune_library_add_sources() verifies the library name against the contents of DUNE_ENABLE_ALL_PACKAGES_MODULE_LIBRARIES. I accidentally broke this by converting dune_enable_all_packages (which defines the variable) from a macro to a function, which removed the variable from global scope. This patch fixes the problem by explicitly exporting the variable to the parent scope, making it available to dune_library_add_sources() again.
-
- May 20, 2015
-
-
Steffen Müthing authored
We have to call add_definitions() in a loop because add_definitions() is kind of broken: even though it is supposed to be *the* function for adding compile definitions, it does not prepend "-D" (as opposed to target_compile_definitions(), which does). Well, whatever...
-
Steffen Müthing authored
Thanks for spotting that, Dominic!
-
- May 19, 2015
-
-
Steffen Müthing authored
This branch resolves somes smaller problems with the dune_enable_all_packages() feature and importantly provides support for modules with libraries and CMake < 3.1. * feature/FS1654-improve-dune-enable-all-packages: [Release][CMake] Add support for compile options in DuneEnableAllPackages [Release][CMake][Bugfix] Use correct test in if() command [Release][CMake] Add dune_target_enable_all_packages() [Release][CMake][Bugfix] Remove stray unset() command [Release][CMake] Convert macros to functions in DuneEnableAllPackages [Release][CMake] Improve documentation in DuneEnableAllPackages.cmake
-
Steffen Müthing authored
We do not really support this combination of C++11 features, and the only time it should occur is when the user has a recent Intel Compiler and an outdated GCC (which the Intel Compiler uses for the C++ standard library). In that case, we emit a helpful error message at configuration time.
-
Steffen Müthing authored
-
Steffen Müthing authored
-
Steffen Müthing authored
This patch adds a new function dune_target_enable_all_packages() that works like dune_enable_all_packages(), but only acts on the given list of targets. This function is mostly needed to be able to use the new dune_enable_all_packages() feature in a DUNE module that defines its own libraries. Specifically, the "nice" default way of handling those libraries only works on CMake 3.1+. To be compatible with older CMake versions, the library has to be manually added in the top-level CMakeLists.txt file before the call to dune_enable_all_packages(). But the library also needs to get all the package flags from the DUNE modules the current one depends on, which can be done using the new function added by this patch.
-
Steffen Müthing authored
-
Steffen Müthing authored
All of the macros in DuneEnableAllPackage cause their side effects by modifying properties, so there is no point in having them as macros, which are more fragile than functions and pollute the outside variable scope.
-
Steffen Müthing authored
- Fix some typos - Improve wording - Try to be clearer about the distinction between CMake modules and DUNE modules
-
- May 13, 2015
- May 12, 2015
-
-
Ansgar Burchardt authored
This closes FS#1651.
-
Dominic Kempf authored
Passing multiple files to dune_symlink_to_source_files() was broken. While at it, I switched the given macros to be functions and have named arguments. Using positional arguments will result in a warning.
-
Oliver Sander authored
Viz., the question on whether all packages should be enabled by default. This fixes FS 1647.
-
Oliver Sander authored
-
- May 11, 2015
-
-
Ansgar Burchardt authored
ptrdiff_t is a signed integer type and so the expression (std::uintptr_t)(ptr) % page_size could become a negative value. In this case the page_ptr would be the address of the next page after the allocation. This wrong behaviour could be observed on (32bit) PowerPC: here ptr was 0xf78cfe00 and page_ptr was calculated as 0xf78d0000 instead of the correct 0xf78c0000.
-
Steffen Müthing authored
The std::numeric_limits specialization for bigunsignedint requires access to the internal state of bigunsignedint. Previously, the correct specialization of std::numeric_limits was a friend of bigunsignedint, but that creates problems on recent versions of clang with the alternative libc++ library, because that library declares the base template of std::numeric_limits as a class and clang subsequently complains if the friend declaration uses 'struct'. Unfortunately, libstdc++ uses a struct, making it impossible to keep clang happy for both standard libraries. So we introduce a helper class that provides access to the internal state and which now becomes a friend of bigunsignedint. The numeric_limits specialization inherits from the helper to use it.
-
Steffen Müthing authored
-
Steffen Müthing authored
According to the standard, all specializations of std::hash must export argument_type and result_type [20.8.12/1]. The version of libc++ (LLVM's alternative C++ standard library) tripped over this requirement on my machine, so this patch adds the typedefs.
-
Steffen Müthing authored
Ansgar fixed a bunch of problems in bigunsignedint - and improved the corresponding test! yeah! * p/ansgar/FS1644-bigunsignedint: Rework bigunsignedinttest.cc. bigunsignedint: Remove unneeded variable in operator%. bigunsignedint: Fix operator-. bigunsignedint: Throw an exception when constructing from a negative integer. bigunsignedint: make overload unambiguous for all integer types Use fixed-width integer types (C++11)
-
Ansgar Burchardt authored
-
Ansgar Burchardt authored
-
Ansgar Burchardt authored
-
Ansgar Burchardt authored
-
Ansgar Burchardt authored
With just the two overloaded constructors bigunsignedint(int) bigunsigendint(uintmax_t) trying to call the constructor with any integer type T different from int and uintmax_t results in an ambiguous call: the promotion of T to either int or uintmax_t are ranked the same. (Note that this does not depend on the specific choice of int and uintmax_t.) This patch provides a templated constructor for all signed integer types which is ranked over the constructor taking an uintmax_t, making overload resolution unambiguous for signed integer types. By also "hiding" it for unsigned types using enable_if, the overload resolution for unsigned integer types is also unambiguous; there is only a single viable candidate left: the one taking an uintmax_t.
-
Ansgar Burchardt authored
Use the fixed-width integer types introduced in C++11 instead of making assumptions on the size of integers. The following changes were implemented: unsigned short used to store the bigunsignedint: Changed type to uint16_t. The implementation requires this to be a 16-bit type. int, unsigned int used to store intermediates: Changed type to (u)int_fast32_t. This is enough to hold sums, products or differences of two uint16_t integers. std::size_t used as parameter in constructor and arithmetic operators: Changed type to uintmax_t. Any unsigned integer type should be usable in conjunction with bigunsignedint. Return value of touint() member function: Changed type to uint_least32_t. The current implementation only returns the last two "digits" (of 16 bits each).
-
Steffen Müthing authored
The test for __cxa_demangle(), which is used by Dune::className() to demangle type names, doesn't work on my clang 3.6. Apparently, clang requires the user to include <typeinfo> before <cxxabi.h>. While classname.hh already does this, the build system tests don't, causing the feature to get disabled on clang. Fixed by adding the include to the build system tests.
-
Dominic Kempf authored
A typo made it impossible to say 'no'. Furthermore, I changed the text shown to the user to point to the module documentation.
-
- May 08, 2015
-
-
Ansgar Burchardt authored
-
Ansgar Burchardt authored
-
- May 06, 2015
-
-
Ansgar Burchardt authored
-
Ansgar Burchardt authored
This change should make formatString safe to use in multi-threaded programs. This fixes FS#1636.
-
-