Experimental Physics and Industrial Control System
|
On Nov 28, 2006, at 1:09 PM, Andrew Johnson wrote:
Eric Norum wrote:
On Nov 28, 2006, at 9:50 AM, Kay-Uwe Kasemir wrote:
For which we have to know where it all affects us: - register
access, I/O buffer encoding/decoding via mapped structures -
do-it-yourself inheritance from dbCommon to xyzRecord What else?
I think that I/O buffer encoding/decoding via *any* cast, not just
via mapped structures might be at risk.
I'm still not convinced that this is quite as big a problem as Eric
does. In his example, the code is breaking this C99 rule:
An object shall have its stored value accessed only by an lvalue
expression that has one of the following types: 74)
- a type compatible with the effective type of the object,
- a qualified version of a type compatible with the effective type of
the object,
- a type that is the signed or unsigned type corresponding to the
effective type of the object,
- a type that is the signed or unsigned type corresponding to a
qualified version of the effective type of the object,
- an aggregate or union type that includes one of the aforementioned
types among its members (including, recursively, a member of a
subaggregate or contained union), or
- a character type.
74) The intent of this list is to specify those circumstances in
which an object may or may not be aliased.
Note that the rule is only talking about accessing the stored value
of an object, it says nothing about how you do that, so I think the
pointer casting may be a bit of a red herring (it seemed to make no
difference in Eric's tests if he passed the value in using a char*,
which would make sense given the above rules - he never accessed
the value as a char and that's the only other unrelated type the
above rules allow).
I don't think the code in Base breaks that rule very often if at
all, although it may not be particularly obvious since we do cast
pointers to char*, void* or void** and back. However, we never
actually use a double* to actually read a value from a long*, and
that's where strict aliasing optimization would be entitled to
clobber our code. I think our dbCommon* casts for record types all
fall into the first option in the rule, so I don't see them as
being a problem.
I'm not saying that we have no aliasing problems, but I don't think
they'll be as widespread as you might think. For now we should
turn on -fno-strict-aliasing on those targets that use gcc 3.x or
later, and keep running and improving our test suite with it off to
try and detect any aliasing problems that gcc doesn't warn us about.
So where's the best place to make the addition? To configure/
CONFIG.gnuCommon in the OPT....YES macros?
OPT_CFLAGS_YES = -O3 -fno-strict-aliasing
OPT_CXXFLAGS_YES = -O3 -fno-strict-aliasing
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
- Replies:
- Re: C strict aliasing rules Andrew Johnson
- References:
- C strict aliasing rules Eric Norum
- Re: C strict aliasing rules Benjamin Franksen
- Re: C strict aliasing rules Eric Norum
- Re: C strict aliasing rules Benjamin Franksen
- Re: C strict aliasing rules Kay-Uwe Kasemir
- Re: C strict aliasing rules Marty Kraimer
- Re: C strict aliasing rules Eric Norum
- Re: C strict aliasing rules Kay-Uwe Kasemir
- Re: C strict aliasing rules Eric Norum
- Re: C strict aliasing rules Andrew Johnson
- Navigate by Date:
- Prev:
Re: C strict aliasing rules Andrew Johnson
- Next:
Re: C strict aliasing rules Andrew Johnson
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
- Navigate by Thread:
- Prev:
Re: C strict aliasing rules Andrew Johnson
- Next:
Re: C strict aliasing rules Andrew Johnson
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|
ANJ, 02 Feb 2012 |
·
Home
·
News
·
About
·
Base
·
Modules
·
Extensions
·
Distributions
·
Download
·
·
Search
·
EPICS V4
·
IRMIS
·
Talk
·
Bugs
·
Documents
·
Links
·
Licensing
·
|