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

[Heinz Junkes <junkes@fhi-berlin.mpg.de>]

I run in exactly the same issue while porting EPICS 3.15  base to RTEMS 4.12.

I have to switch off the optimization in libCom/calc/postfix.c  to get 
libComTestHarness.boot to run successfully.


—— libCom/calc/postfix.c —	
/*************************************************************************\
* Copyright (c) 2010 UChicago Argonne LLC, as Operator of Argonne
*     National Laboratory.
* Copyright (c) 2002 The Regents of the University of California, as
*     Operator of Los Alamos National Laboratory.
* EPICS BASE is distributed subject to a Software License Agreement found
* in file LICENSE that is included with this distribution. 
\*************************************************************************/
/*
 * Subroutines used to convert an infix expression to a postfix expression
 *
 *      Original Author: Bob Dalesio
 *      Date:            12-12-86
*/

#include <stdio.h>
#include <string.h>
#include <ctype.h>

#define epicsExportSharedSymbols
#include "dbDefs.h"
#include "epicsAssert.h"
#include "epicsStdlib.h"
#include "epicsString.h"
#include "epicsTypes.h"
#include "postfix.h"
#include "postfixPvt.h"
#include "shareLib.h"


#pragma GCC push_options
#pragma GCC optimize ("O0")

/* declarations for postfix */

/* element types */
typedef enum {
	OPERAND,

…

	case ISNAN:
	    printf("\t%s, %d arg(s)\n", opcodes[(int) op], *++pinst);
	    pinst++;
	    break;
	default:
	    printf("\t%s\n", opcodes[(int) op]);
	    pinst++;
	}
    }
}

#pragma GCC pop_options

—— libCom/calc/postfix.c —	

As this is (until now) the only place I had to switch off -03 I would prefer solution 3

Heinz



> On 08 Sep 2016, at 18:26, Mark Rivers <rivers@cars.uchicago.edu> wrote:
> 
> It seems to me there are 4 ways to solve the problem:
> 
> 1) The existing 3.15.4. solution which is to set HOST_OPT=NO.  This solution is bad because it sets /MTd flag,  leading to different versions of the C runtime library from what is expected.  Note that the existing solution also has a #pragma optimize() in calcPerform.c but not in online_notify.c, so it is not consistent.  When was the #pragma optimize() added to calcPerform.c, and what is the commit comment? Why was the same thing not done for online_notify.c?
> 
> 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.  Modifying calcPerform.c removes the warning messages that are generated because of the #pragma optimize():
> 
> " base-3.15.4\src\libcom\calc\calcperform.c(47) warning C4748: /GS can not protect parameters and local variables from local buffer overrun because optimizations are disabled in function"
> 
> 3) Modify the Makefile in each directory that has a problem.  This has the advantage of not modifying the source code, yet allows being specific to a particular source file.  Disadvantages:
> - By redefining OPT_CFLAGS_YES or OPT_CXXFLAGS_YES these may be specific to a particular version of base.  
>  - It would require some additional changes to base to allow only doing this for Visual Studio 2010.    
>  - Since we don't know what triggers the compiler error small changes to a source file may introduce the problem into a file that previously compiled OK.  This may be done by someone who is not testing on VS 2010 with 64-bit static builds, and so may not be discovered until it is too late.  The Makefile would then need to be modified.
> 
> 4) Modify each source code file that has the problem to use #pragma optimize().  
>  Disadvantages:
>     - Requires changing 2  files in base, and at least 5 files in motor, perhaps many more, and perhaps more files in synApps that have not yet been tested because of the errors in motor.
>     - All that really needs to be done is to disable program-wide optimization (/GL flag), but I cannot find a #pragma to do this.  This means that local optimization must be disabled, which results in the following warning every time that function is linked into a program:
> "warning C4748: /GS can not protect parameters and local variables from local buffer overrun because optimizations are disabled in function"
>    - How do we only disable optimization for 3.15, not 3.14?  
>   - Since we don't know what triggers the compiler error small changes to a source file may introduce the problem into a file that previously compiled OK.  This may be done by someone who is not testing on VS 2010 with 64-bit static builds, and so may not be discovered until it is too late.
> 
> 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!
> 
> Mark
> 
> 
> -----Original Message-----
> From: core-talk-bounces@aps.anl.gov [mailto:core-talk-bounces@aps.anl.gov] On Behalf Of Andrew Johnson
> Sent: Thursday, September 08, 2016 10:34 AM
> To: core-talk@aps.anl.gov
> Subject: Re: Fix for building 3.15.4 on windows-x64-static
> 
> On 09/08/2016 09:20 AM, Mark Rivers wrote:
>> Searching for the presence of "Visual Studio 10.0" in the PATH
>> environment variable might work.
> 
> If the build system really needs to know which compiler version it's
> using I would much rather we have the user tell it that in their
> CONFIG_SITE.Common.win* file(s). The build system has to run any kind of
> per-compiler test every time it reads a Makefile, and calling out to a
> Perl script to do this kind of test every time is probably going to slow
> the build measurably.
> 
> On the other hand doing this kind of thing using the pre-processor and a
> #pragma optimize() setting is fast and localized, so I would much prefer
> that we stick with that solution if it can do what we need. You can tell
> whether you're building a dynamic binary there by the presence of the
> EPICS_BUILD_DLL macro.
> 
> - 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
>

Attachment: smime.p7s
Description: S/MIME cryptographic signature