EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
<== Date ==> <== Thread ==>

Subject: Re: Fix for building 3.15.4 on windows-x64-static
From: Andrew Johnson <[email protected]>
To: Mark Rivers <[email protected]>, "[email protected]" <[email protected]>
Date: Tue, 18 Oct 2016 16:46:38 -0500
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

References:
Fix for building 3.15.4 on windows-x64-static Mark Rivers
RE: Fix for building 3.15.4 on windows-x64-static Mark Rivers
Re: Fix for building 3.15.4 on windows-x64-static Ralph Lange
RE: Fix for building 3.15.4 on windows-x64-static Mark Rivers
Re: Fix for building 3.15.4 on windows-x64-static Ralph Lange
RE: Fix for building 3.15.4 on windows-x64-static Mark Rivers
Re: Fix for building 3.15.4 on windows-x64-static Andrew Johnson
RE: Fix for building 3.15.4 on windows-x64-static Mark Rivers

Navigate by Date:
Prev: Jenkins build is back to normal : epics-base-3.14-win32s #146 APS Jenkins
Next: Build failed in Jenkins: epics-base-3.15-win32-test #76 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
Navigate by Thread:
Prev: Re: Fix for building 3.15.4 on windows-x64-static Heinz Junkes
Next: Build failed in Jenkins: epics-base-3.16-mac-test #64 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022 
ANJ, 20 Oct 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·