[WIP] pedantic and many more flags for GNU compiler

[psychocrypt]

Activate many compiler checks (pedantic, ...) for the GNU compiler
to avoid side effects, undefined behaviors and increase the code
quality.

• change timer variables from uin64_t to int64_t
• fix conversion issues form unsigned to signed
• remove usage of non C++ variable length arrays e.g int x[N] where N is a runtime value

Tests

• rebase against @fireice-uk timer zone shift bug fix
• test windows (compile and runtime)
• test clang (compiler)
• test NVIDIA and AMD runtime

@fireice-uk Do to the timer changes from uint64_t to int64_t this PR can conflict with you upcoming changes. This PR should be rebased against you changes. Maybe we should merge that PR not before the Xmas release to have a longer time to test the changes within the next dev branch.

[fireice-uk]

remove usage of non C++ variable length arrays e.g int x[N] where N is a runtime value

Don't think that's the case anywhere in the code, otherwise it wouldn't compile on MSVC

[psychocrypt]

It was part of gpu.cpp and for windows there was a workaround. I unified this to std::vector which is much more clean.

[XhmikosR]

This is very nice to see!

Have you guys thought about Travis CI for nix and AppVeyor for Windows CI? Scratch that, you already have this; I just didn't see any badges in README.md.

Also, how about running Coverity which is a static code analyzer on CI?

[fireice-uk]

@psychocrypt what's the rationale behind having signed time-stamps?

[psychocrypt]

@fireice-uk The reason is that int64_t is the default type used in the stl. This make sense else it would not be possible to define a negative offset i time.

[fireice-uk]

Timestamp is an absolute value and not an offset, confusion on that part is why I always use unsigned type for that. If those are the only grounds then I'm inclined to veto that part.

[psychocrypt]

@fireice-uk The offset was only a explanation by me. The reason is as I wrote that int64_t is the type used by the c++ STL.

[psychocrypt]

@fireice-uk do not forget that the timestamp is relative to a fixed point int time. Only for use the offset is positive becase the point in time is long long ago but this is not generic.

[fireice-uk]

Given that the value is never going to be negative it only serves to confuse. I prefer the way we are doing it now.

[psychocrypt]

Than I need to cast it explicit to a unsigned what is in general wrong. Because if I than substract two time stamps it is possible to get a negative value which than in our case result in an unsigned underflow. The risk should be not as high as long as our used time source is stady but it is not clean to use a unsigned value.

[psychocrypt]

I set this PR to WIP because I have still issues to get all compiling.