This is the mail archive of the
gcc@gcc.gnu.org
mailing list for the GCC project.
Re: type based aliasing again
- To: craig at jcb-sc dot com
- Subject: Re: type based aliasing again
- From: jlarmour at cygnus dot co dot uk (Jonathan Larmour)
- Date: Sat, 11 Sep 1999 02:23:38 +0100
- Cc: jbuck at synopsys dot COM, rms at gnu dot org, gcc at gcc dot gnu dot org
- Newsgroups: cygnus.egcs
- Organization: Cygnus Solutions Ltd, UK
- References: <199909100708.AAA00030@atrus.synopsys.com>
In article <19990910152622.9143.qmail@deer> you write:
>But every one of them can be applied to the *current* situation,
>where we have *no* warnings, -fstrict-aliasing is the default,
>and users have the -fno-strict-aliasing option:
Just to add a bit of extra spice, I don't believe users do have the
-fno-strict-aliasing option as a panacea. User code can fail if it casts
between struct/union types and scalar types, but not because of the alias
analysis (so -fno-strict-aliasing doesn't help).
Instead the scheduler performs some optimizations based on MEM_IN_STRUCT
vs. MEM_SCALAR_P tests. If the user code casts between structs and scalars,
the instructions can be reordered the wrong way round.
So, even with -fno-strict-aliasing this class of problem can't necessarily
be worked around.
Jifl
--
Cygnus Solutions, 35 Cambridge Place, Cambridge, UK. Tel: +44 (1223) 728762
"I used to have an open mind but || Get yer free open source RTOS's here...
my brains kept falling out." || http://sourceware.cygnus.com/ecos
Help fight spam! http://spam.abuse.net/ These opinions are all my own fault