I'm forwarding this message from Till. The -fno-strict-aliasing
debate is in full swing on the RTEMS mailing lists so I thought I'd
spread some of the excitement here.
Begin forwarded message:
From: Till Straumann <[email protected]>
Date: November 30, 2006 7:16:47 PM CST
To: [email protected]
Cc: Ralf Corsepius <[email protected]>
Subject: More strict aliasing
Here's another example that breaks strict aliasing rules
but illustrates a scenario quite commonly found
in a OS/driver environment:
Assume we have a device (serial device, ethernet chip, fifo, ...)
that can only be accessed with 16-bit bus cycles and we code an
generic 'read' access routine:
typedef uint16_t PortType;
extern volatile PortType *fifo_port;
static inline void
rd_fifo(void *item, int n_words)
{
PortType *dst = item;
while (n_words--)
*dst++ = *fifo_port;
}
Then someone reads bigger items from the device
uint32_t readInt()
{
uint32_t val;
rd_fifo(&val, sizeof(val)/sizeof(PortType));
return val;
}
And *bang* they have violated the rule (because val is an uint32_t
and *dst is a uint16_t which must not alias).
Indeed, gcc (checked i386 disassembly) generates code that
doesn't produce the intended result. The store operation of the
second 16-bit word is optimized away.
OK, it would be easy to correct this particular example but
I find the alias rule extremely cumbersome at the OS / driver
level where you often deal with bit-representations etc.
Try to code an inlineable 'rd_fifo()' routine w/o knowledge
about the target objects where the data are to be deposited.
Plus, there are much more obscure cases [dig around in the C99
committee discussions for fun].
Basically, it makes 'serializing' [other than into a byte-stream]
almost impossible. Keep in mind that gcc doesn't fully enforce
the standard [e.g., it doesn't use the rule if the accessed object
is in a different compilation unit].
Another good example are checksums:
inline unsigned csum(void *data, int size);
struct blah xx;
xx.non_int_nor_char_field = value;
csum(&xx, sizeof(xx));
If the checksum is computed over 16-bit or 32-bit words
(as usually done in networking stacks)
then there is no guarantee that non_int_nor_char_field
is written before the checksum is computed since the
compiler can assume it doesn't alias to an 'int'.
I wish they had made this optional but *it is not*.
It is the C99 *standard*.
To me, the fact that many software packages 'just work'
doesn't indicate that they obey strictly to the rule but rather
that it is extremely hard to check and enforce. I suspect
that in many cases violation just goes undetected and doesn't
cause problems because the compiler doesn't use the rule for
optimization [because in many cases there is no gain].
-- Till
_______________________________________________
rtems-users mailing list
[email protected]
http://rtems.rtems.org/mailman/listinfo/rtems-users
--
Eric Norum <[email protected]>
Advanced Photon Source
Argonne National Laboratory
(630) 252-4793
- Replies:
- Re: More strict aliasing Kay-Uwe Kasemir
- Navigate by Date:
- Prev:
Re: Next R3.14.9 version: -pre2 or -RC1? Gasper Jansa
- Next:
Re: More strict aliasing Kay-Uwe Kasemir
- 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: help of epics on freebsd Artem Kazakov
- Next:
Re: More strict aliasing Kay-Uwe Kasemir
- Index:
2002
2003
2004
2005
<2006>
2007
2008
2009
2010
2011
2012
2013
2014
2015
2016
2017
2018
2019
2020
2021
2022
2023
2024
|