This is the mail archive of the gcc@gcc.gnu.org mailing list for the GCC project.


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]

Re: -Wstrict-aliasing in 2.95/6?


Patrick J. LoPresti wrote:
>  Jamie> Clearly unions of some kind are the right thing to use -- you
>  Jamie> can tell the compiler exactly what may alias and what can't.
>  Jamie> It's just (a) quite clunky,
> 
> Almost by definition, if it is "quite clunky" it is not the right
> thing.
> 
>  Jamie> (b) there is no solution for high-performance `memcpy' and
>  Jamie> more complicated things,
> 
> Does the "may_alias" adjective provide such a solution?

It solves the problem, but doesn't generate optimal code.
You want to be able to say "this 4 byte reference may alias type A
(but not other types)".  A union is the closest thing because it
actually mentions the types that can be aliased.

But may_alias is never worse than -fno-strict-aliasing or older
compilers, and people have been happy enough with that.  And correctness
is more important than some extreme performance tweak.

>  Jamie> and (c) there is a fix to (b) but it is GCC-specific, silently
>  Jamie> fails on a standard compiler, and not properly documented.
> 
> Well, at least "may_alias" would fail on other compilers.

Perhaps the following (ugly enough? ;-)

#define read_may_alias(addr)                  \
  ({ __typeof__(*(addr)) __result;            \
     __asm__ volatile ("" : : : "memory");    \
     __result = *(addr);                      \
     __asm__ volatile ("" : : : "memory");    \
     __result; })

#define write_may_alias(addr,value)           \
  ({ __asm__ volatile ("" : : : "memory");    \
     *(addr) = (value);                       \
     __asm__ volatile ("" : : : "memory"); })
     
-- Jamie


Index Nav: [Date Index] [Subject Index] [Author Index] [Thread Index]
Message Nav: [Date Prev] [Date Next] [Thread Prev] [Thread Next]