[FFmpeg-devel] [PATCH 4/7] Use alias-safe types in AV_[RW] macros

Michael Niedermayer michaelni
Thu Feb 18 16:37:16 CET 2010


On Fri, Jan 29, 2010 at 03:43:08AM +0000, M?ns Rullg?rd wrote:
> Michael Niedermayer <michaelni at gmx.at> writes:
> 
> > On Fri, Jan 29, 2010 at 02:12:11AM +0000, Mans Rullgard wrote:
> >> ---
> >>  libavutil/intreadwrite.h |   14 +++++++-------
> >>  1 files changed, 7 insertions(+), 7 deletions(-)
> >
> > id like to see some benchmark done with the latest gcc release
> > and h264/h263/aac decoding as well as mpeg4 encoding on x86_64 (codecs
> > randomly picked based more on what is used alot than what uses alot of funny
> > accesses)

ping


> > if nothing gets slower then iam not against this otherwise i think
> > more investigation is needed
> >
> > Also how does this stuff interact with restrict ?
> > Which overrides the other? can we still use restrict to make sure the
> > gcc is aware that aliasing does not happen?
> 
> This is the opposite of restrict.  Qualifying a pointer with restrict
> informs the compiler that aliasing will *never* happen even with the
> normal type rules would allow it.  This is to be used in cases where

i know that, my question was if restrict overrides av_alias or av_alias
restrict?


> we *intentionally* violate the basic aliasing rules.  This is causing
> actual errors with some compilers on some targets.

we do violate them and i dont doubt that some compilers generate non
functional code. It does not mean though these 2 are related.

also the C standard defines a solution via unions, i do not understand
why may_alias is needed. You can just have an union of a packed struct
and a second type to indicate posible aliasing between them i think.
(this requires fewer non standard attributes)

[...]
-- 
Michael     GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Frequently ignored awnser#1 FFmpeg bugs should be sent to our bugtracker. User
questions about the command line tools should be sent to the ffmpeg-user ML.
And questions about how to use libav* should be sent to the libav-user ML.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 189 bytes
Desc: Digital signature
URL: <http://lists.mplayerhq.hu/pipermail/ffmpeg-devel/attachments/20100218/b4222421/attachment.pgp>



More information about the ffmpeg-devel mailing list