EPICS Home

Experimental Physics and Industrial Control System


 
2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024  Index 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Is breaking strict-aliasing rules something to worry about?
From: Dirk Zimoch <[email protected]>
To: <[email protected]>
Date: Fri, 5 Oct 2018 10:25:22 +0200
Neither the vxWorks 6.3 compiler gcc 3.4.4 nor the vxWorks 6.6 compiler gcc 4.1.2 show the warning, nor does gcc 4.8.5 or any higher version that I have tested.

The only targets where I could see the warning use gcc 4.4.x.

I will simply use -fno-strict-aliasing for those target archs.

Dirk

On 04.10.2018 17:36, Johnson, Andrew N. wrote:
On 10/03/2018 05:47 PM, Michael Davidsaver wrote:
On 10/3/18 1:55 PM, Johnson, Andrew N. wrote:
I have no reason to doubt your statement. I am just wary of this topic given the amount of code we have that casts pointers between dbCommon, void* and/or some specific record type.

I'm not suggesting that we ignore these potential problems.
I just don't expect to discover major new problems of this
sort arising with older compilers.

Admittedly Dirk may have been talking about older compilers; I was
thinking about newer ones when I wrote "the latest language rules".

If I was going to spend time on compiler testing, it would be with newer
gcc/clang (and libc for that matter).  We know from past experience that
new issues will arise in this area.

At some point we might want to try and create tests to look for problems
that might be caused by compiler aliasing in the kinds of code
constructs and casts that we commonly use. I don't see these tests as a
high priority though.

eg. it's been in the back of my mind to build Base with latest gcc 8.x on travis-ci.

https://launchpad.net/~ubuntu-toolchain-r/+archive/ubuntu/test

https://www.google.com/search?q=ubuntu-toolchain-r-test+travis-ci

I don't know what gcc version(s) you run, but Red Hat provides builds of
binutils and and gcc-7 for RHEL and I have run the Base-7 self-tests
against those with no failures — gcc 7.2.1 20170829 (Red Hat 7.2.1-1)
and binutils 2.28 to be specific (there's even an ld.gold there, but I
haven't tried it). They don't have a devtoolset-8 yet to my knowledge.

- Andrew

I may have been reading this blog post or some of the items it links to: https://blog.regehr.org/archives/1621

- Andrew

--
Sent from my iPad

On Oct 3, 2018, at 1:49 PM, Michael Davidsaver <[email protected] <mailto:[email protected]>> wrote:

On 10/3/18 11:07 AM, Johnson, Andrew N. wrote:
Did I read recently that apparently even the use of a union (as shown by
Ben at the end of that thread) is no longer guaranteed to prevent
problems with the latest language rules? *That* would be somewhat
worrying if true...


References:
Is breaking strict-aliasing rules something to worry about? Dirk Zimoch
Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver
Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.
Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver
Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.
Re: Is breaking strict-aliasing rules something to worry about? Michael Davidsaver
Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.

Navigate by Date:
Prev: Re: EPICS_IOC_LOG_PORT value Jeong Han Lee
Next: Build failed in Jenkins: epics-base-3.15-vx55 #337 APS Jenkins
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Is breaking strict-aliasing rules something to worry about? Johnson, Andrew N.
Next: EPICS_IOC_LOG_PORT value Jeong Han Lee
Index: 2002  2003  2004  2005  2006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  <20182019  2020  2021  2022  2023  2024