Re: Fix for building 3.15.4 on windows-x64-static

[Andrew Johnson <anj@aps.anl.gov>]

Hi Mark,

I've committed changes to the build system for this problem, initially
on the 3.14 branch but they will be merged into 3.15 soon.

What I have ended up doing is to introduce a configuration variable to
control the whole-program optimization flags (there's also one for the
linker -LTCG as well as the -GL compiler one you were removing), then
set that variable to NO for both 32-bit and 64-bit static targets in
their CONFIG_SITE.<arch>.<arch> file. Users with newer compilers than
2010 can try setting it to YES. The HOST_OPT=NO setting will be removed
from the windows-x64-static configuration file when I merge this into 3.15.

On 09/08/2016 11:26 AM, Mark Rivers wrote:
> 2) The solution I proposed yesterday.  As in the existing solution,
> this is in the CONFIG_SITE file, only for 64-bit static builds.  It
> is better than the existing solution because it only removes the -GL
> flag, and leaves other optimizations enabled.  It is clean because it
> requires no modification of any source code files, except removing
> the #pragma from calcPerform.c which is nice but not necessary.

Unfortunately removing that #pragma from calcPerform.c causes the
epicsCalcTest.exe program on the 3.14 branch to fail these 8 tests when
built with VS2010 for windows-x64-static:

> not ok 593 - 2863311530.1 OR 0
> # Expected result is 0xaaaaaaaa (2863311530), actually got 0x80000000 (214748364
> 8)
>         Double 2.86331e+009
>         Integer 0 (0x0)
>         BIT_OR

> not ok 597 - 2863311530.1 XOR 0
> # Expected result is 0xaaaaaaaa (2863311530), actually got 0x80000000 (214748364
> 8)
>         Double 2.86331e+009
>         Integer 0 (0x0)
>         BIT_EXCL_OR

> not ok 601 - 2863311530.1 AND 0xffffffff
> # Expected result is 0xaaaaaaaa (2863311530), actually got 0x80000000 (214748364
> 8)
>         Double 2.86331e+009
>         Integer -1 (0xffffffff)
>         BIT_AND

> not ok 605 - ~ 2863311530.1
> # Expected result is 0x55555555 (1431655765), actually got 0x7fffffff (214748364
> 7)
>         Double 2.86331e+009
>         BIT_NOT

> not ok 607 - 2863311530.1 >> 0
> # Expected result is 0xaaaaaaaa (2863311530), actually got 0x80000000 (214748364
> 8)
>         Double 2.86331e+009
>         Integer 0 (0x0)
>         RIGHT_SHIFT

> not ok 609 - 2863311530.1 >> 0.1
> # Expected result is 0xaaaaaaaa (2863311530), actually got 0x80000000 (214748364
> 8)
>         Double 2.86331e+009
>         Double 0.1
>         RIGHT_SHIFT

> not ok 611 - 2863311530.1 << 0
> # Expected result is 0xaaaaaaaa (2863311530), actually got 0x80000000 (214748364
> 8)
>         Double 2.86331e+009
>         Integer 0 (0x0)
>         LEFT_SHIFT

> not ok 613 - 2863311530.1 << 0.1
> # Expected result is 0xaaaaaaaa (2863311530), actually got 0x80000000 (214748364
> 8)
>         Double 2.86331e+009
>         Double 0.1
>         LEFT_SHIFT

I didn't try that on the other targets, this was almost certainly why I
had to disable optimization in that file. The optimizer in VS-2010 is
probably doing things to the calcPerform.c code which it shouldn't (this
isn't the first such issue we've come across).

> On balance I like solution 2.  It modifies only a single file (except
> removing the #pragma from calcPerform.c which is nice but not
> necessary), and appears to be robust against future modifications to
> source files.  But I'm open to persuasion!

My changes are effectively a superset of yours, I just wanted to hide
the specific flags from the user's configuration files.

- Andrew

-- 
Arguing for surveillance because you have nothing to hide is no
different than making the claim, "I don't care about freedom of
speech because I have nothing to say." -- Edward Snowdon