- 17 Mar, 2017 1 commit
-
-
Andreas Marek authored
-
- 16 Mar, 2017 6 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
- 14 Mar, 2017 1 commit
-
-
Pavel Kus authored
-
- 11 Mar, 2017 1 commit
-
-
Andreas Marek authored
-
- 10 Mar, 2017 1 commit
-
-
Andreas Marek authored
-
- 20 Feb, 2017 4 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
- 19 Feb, 2017 1 commit
-
-
Andreas Marek authored
-
- 18 Feb, 2017 1 commit
-
-
Andreas Marek authored
-
- 17 Feb, 2017 5 commits
- 16 Feb, 2017 1 commit
-
-
Andreas Marek authored
-
- 15 Feb, 2017 3 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
- 14 Feb, 2017 8 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-
Lorenz Huedepohl authored
- execvp needs the programs name also as first argument in the argument list - len(files) == 1 (i.e. the normal case) was omitted in the last second when the error handling was improved
-
- 13 Feb, 2017 4 commits
-
-
Lorenz Huedepohl authored
For some reason, and only in certain cases, the built-in preprocessor of ifort cannot handle constructs such as #define FOO bar print *, "foo& &FOO& &baz" or more specifically #define DATATYPE double print *, some_& &DATATYPE& &_routine which, however, are quite handy. GCC seems to handle those as expected.
-
Andreas Marek authored
It could happen that ELPA stopped with an error but an exit code "0" was given, i.e. one could assume everything was fine when it was not! Now each Fortran "stop" was replaced with "stop 1" to prevent this
-
Andreas Marek authored
-
Andreas Marek authored
This gives a speed-up of up to a factor 2 in the complex version
-
- 12 Feb, 2017 3 commits
-
-
Andreas Marek authored
-
Andreas Marek authored
-
Andreas Marek authored
-