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  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Strict aliasing blog-post
From: "Johnson, Andrew N." <[email protected]>
To: Torsten Bögershausen <[email protected]>
Cc: EPICS core-talk <[email protected]>
Date: Wed, 16 Mar 2016 13:07:48 +0000
Hi Torsten,

Unfortunately every record type would probably need fixing, since I suspect that the very common casts from dbCommon* to the record pointer type and back are some of those places that are not strictly compliant. The same is probably true for various places in all the device support routines, and so on, thus I don't think it would be practical to fix this everywhere.

As for the multi-core question, we should be safe there since we have been running and supporting soft IOCs on SMP Linux and Windows for many years, and we have been very careful about locking all shared data structures. People have been running IOCs on ARM for quite a while too; I'm not sure what your point about the L2 caches refers to, it's possible that there may be performance enhancements that we could do there since I don't think we've tried to check or optimize on that platform at all.

I believe all the targets supported by 3.16 that use gcc have the -fno-strict-aliasing flag, so for now that might be sufficient, although I don't have access to a system with GCC5 or later on it myself. If anyone knows of equivalent flags for other compilers I'd be happy to hear them.

- Andrew

-- 
Sent from my iPad

> On Mar 16, 2016, at 1:56 AM, Torsten Bögershausen <[email protected]> wrote:
> 
> In general, yes.
> But: This is really compiler dependent.
> 
> 
> A better approach would be to go through the code base, and rework the problematic code,
> step by step.
> 
> And when this is done, have a look if there are „volatile“ missing,
> and/or if we need better support for multi-core, like synchronizing the L2 caches
> on some ARM platforms.
> (But I’m not sure, if anybody is running EPICS on this kind of hardware)
> 
> It may be good enough to enable it for gcc, if version >= 5.
> And what about clang ?
> 
> /Torsten
> 
> 
> 
>> Am 15.03.2016 um 19:08 schrieb Andrew Johnson <[email protected]>:
>> 
>> http://blog.regehr.org/archives/1307
>> 
>> Should we add the -fno-strict-aliasing flag to the EPICS build rules?
>> 
>> - Andrew
> 


Replies:
Re: Strict aliasing blog-post Torsten Bögershausen
References:
Strict aliasing blog-post Andrew Johnson
Re: Strict aliasing blog-post Torsten Bögershausen

Navigate by Date:
Prev: Re: Strict aliasing blog-post Torsten Bögershausen
Next: Re: Strict aliasing blog-post Torsten Bögershausen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Strict aliasing blog-post Torsten Bögershausen
Next: Re: Strict aliasing blog-post Torsten Bögershausen
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  <20162017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 16 Mar 2016 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·