From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from ffbox0-bg.mplayerhq.hu (ffbox0-bg.ffmpeg.org [79.124.17.100]) by master.gitmailbox.com (Postfix) with ESMTP id 7ED61420E1 for ; Tue, 25 Oct 2022 13:10:02 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id DA4CA68BADD; Tue, 25 Oct 2022 16:09:59 +0300 (EEST) Received: from wout5-smtp.messagingengine.com (wout5-smtp.messagingengine.com [64.147.123.21]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 7BC8068B20B for ; Tue, 25 Oct 2022 16:09:53 +0300 (EEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.west.internal (Postfix) with ESMTP id 4CE60320090B for ; Tue, 25 Oct 2022 09:09:51 -0400 (EDT) Received: from mailfrontend1 ([10.202.2.162]) by compute5.internal (MEProxy); Tue, 25 Oct 2022 09:09:51 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=itanimul.li; h= cc:content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to; s=fm1; t=1666703390; x=1666789790; bh=+xqfIk+kpX kZfZmWx8cwG41sP8mx//Yo6ZmL7OGuAL0=; b=JdCnCet9H+E3Fokpk0InaQLOUJ nFposgx2o8agg91TmUf6AR/XwCE5XYxkBapqjT3C6f8Mu/6bdiR2msPxg9NJoI7C z2YJNiPXSTQIr4ecTZUEZ+qBt9akJ75aiZzox2XWqPcNwziXFMs6+RjlRC3zWm0P SfTuYcx8bCbS7yi3AylU+xP93CVBi0xaJmEU+9vGIhAhj7A+Y+hEdwXxRV1doHyf El9iil2vRMs8o5urlgSRwE0LxvcfLyBZ9a86E+LXeOxnU66TI5JOt1g8vKE6lpom MGZ6+3lSJibwgc3lylg9JSow9j8UZxBsXrOgiEq1ZNjgz9MqTK4yyepfPhIw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-type:date:date:feedback-id :feedback-id:from:from:in-reply-to:in-reply-to:message-id :mime-version:references:reply-to:sender:subject:subject:to:to :x-me-proxy:x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s= fm3; t=1666703390; x=1666789790; bh=+xqfIk+kpXkZfZmWx8cwG41sP8mx //Yo6ZmL7OGuAL0=; b=ElFUA9P1/kC/BB6Gk0eJUhcBI+ai9mDvWsqqTHXkPsCS oE2yBJrwwugyfuFbjdnooxYjnxT4L4GVy9MY6mAWdg5OT8os5q6lWBXHIuI4Q1M6 IxDMRLKHYnS/cJOrk/rAcW3ksOzA8EVuLLcDYo7/mld5kp4J8r7tLuiLppT9h1B4 49J/50r/0SPatCPy+kjtecwmOBvCqChj/3Uju7tAWyiOsPaksMSZRkJSwug/Npcv TLY/rY0Ym4LpGS/hxIixmJ2lvFEDoB/hOxkuGyT54rTPVgQIECArKKsJIhV94jMl gIdBPdvnVTwwFPMJaJFahiNFa6gl2kunTgUB9EfnsQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvgedrtddtgdefvdcutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffokfgjfhggtgesthdtmhdtredttdenucfhrhhomhepfdflrdcuffgv khhkvghrfdcuoehjuggvkhesihhtrghnihhmuhhlrdhliheqnecuggftrfgrthhtvghrnh epuddvkeegtedvgeeiveetffetjeettedtleefkeejudevgfeuvddufeejkedtledunecu ffhomhgrihhnpehgnhhurdhorhhgnecuvehluhhsthgvrhfuihiivgeptdenucfrrghrrg hmpehmrghilhhfrhhomhepjhguvghksehithgrnhhimhhulhdrlhhi X-ME-Proxy: Feedback-ID: i84994747:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA for ; Tue, 25 Oct 2022 09:09:50 -0400 (EDT) From: "J. Dekker" To: FFmpeg development discussions and patches Date: Tue, 25 Oct 2022 15:09:34 +0200 X-Mailer: MailMate Trial (1.14r5918) Message-ID: In-Reply-To: References: MIME-Version: 1.0 Subject: Re: [FFmpeg-devel] [PATCH] avcodec/svq1enc: Workaround GCC bug 102513 X-BeenThere: ffmpeg-devel@ffmpeg.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: FFmpeg development discussions and patches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Reply-To: FFmpeg development discussions and patches Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7bit Errors-To: ffmpeg-devel-bounces@ffmpeg.org Sender: "ffmpeg-devel" Archived-At: List-Archive: List-Post: On 25 Oct 2022, at 14:48, Andreas Rheinhardt wrote: > GCC 11 has a bug: When it creates clones of recursive functions > (to inline some parameters), it clones a recursive function > eight times by default, even when this exceeds the recursion > depth. This happens with encode_block() in libavcodec/svq1enc.c > where a parameter level is always in the range 0..5; > but GCC 11 also creates functions corresponding to level UINT_MAX > and UINT_MAX - 1 (on -O3; -O2 is fine). > > Using such levels would produce undefined behaviour and because > of this GCC emits bogus -Warray-bounds warnings for these clones. > > Since commit d08b2900a9f0935959303da668cb00a8a7245228, certain > symbols that are accessed like ff_svq1_inter_multistage_vlc[level] > are declared with hidden visibility, which allows compilers > to bake the offset implied by level into the instructions > if level is a compile-time constant as it is in the clones. > Yet this leads to insane offsets for level == UINT_MAX which > can be incompatible with the supported offset ranges of relocations. > This happens in the small code model (the default code model for > AArch64). > > This commit therefore works around this bug by disabling cloning > recursive functions for GCC 10 and 11. GCC 10 is affected by the > underlying bug (see > https://gcc.gnu.org/bugzilla/show_bug.cgi?id=102513), so the workaround > also targets it, although it only produces three versions of > encode_block(), so it does not seem to trigger the actual issue here. > > The issue has been mitigated in GCC 12.1 (it no longer creates clones > for impossible values; see also commit > 1cb7fd317c84117bbb13b14851d62f77f57bb9ce), so the workaround > does not target it. > > Reported-by: Josh Dekker > Signed-off-by: Andreas Rheinhardt > --- > libavcodec/svq1enc.c | 6 ++++++ > 1 file changed, 6 insertions(+) > > diff --git a/libavcodec/svq1enc.c b/libavcodec/svq1enc.c > index 75adbe7ea0..7c9430a137 100644 > --- a/libavcodec/svq1enc.c > +++ b/libavcodec/svq1enc.c > @@ -46,6 +46,12 @@ > #include "libavutil/frame.h" > #include "libavutil/mem_internal.h" > > +// Workaround for GCC bug 102513 > +#if AV_GCC_VERSION_AT_LEAST(10, 0) && AV_GCC_VERSION_AT_MOST(12, 0) \ > + && !defined(__clang__) && !defined(__INTEL_COMPILER) > +#pragma GCC optimize ("no-ipa-cp-clone") > +#endif > + > typedef struct SVQ1EncContext { > /* FIXME: Needed for motion estimation, should not be used for anything > * else, the idea is to make the motion estimation eventually independent Discussed on IRC, LGTM & pushed. -- jd _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org https://ffmpeg.org/mailman/listinfo/ffmpeg-devel To unsubscribe, visit link above, or email ffmpeg-devel-request@ffmpeg.org with subject "unsubscribe".