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 6D4BB402D7 for ; Fri, 21 Jan 2022 04:24:31 +0000 (UTC) Received: from [127.0.1.1] (localhost [127.0.0.1]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTP id CC7B068B25D; Fri, 21 Jan 2022 06:24:28 +0200 (EET) Received: from mail-qk1-f169.google.com (mail-qk1-f169.google.com [209.85.222.169]) by ffbox0-bg.mplayerhq.hu (Postfix) with ESMTPS id 3D4BA68B1C8 for ; Fri, 21 Jan 2022 06:24:22 +0200 (EET) Received: by mail-qk1-f169.google.com with SMTP id z10so8663451qkf.7 for ; Thu, 20 Jan 2022 20:24:22 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20210112; h=date:from:to:subject:message-id:references:mime-version :content-disposition:in-reply-to; bh=KzBqck0F1C+Gw3/NmrneDUQi0m/YPY+5hGu2H0vILFw=; b=nFgFTZgSMsvgju5IfgBbYsYpWIKXDh35cv5pmyq97xkFHhs4Rr7KIbS8yHqV/UNTrP W2l3RAxD++vRJL5xz8+sBm9zYdRAKCipMccQHa1W1ouFcPkeNzlC1sgMwCnpvq2fnbfV 79QM3ZVJCQiKV01sCM4Ch329uZfZSiu6S0soghqJ5UmGNCBLFFQALLsXPLY6q8kk9a+Y jbn4AP2Tz0fyUyiN4r9qnmkiOKR+DM4wuyPHmSofRj5s5cOcLvrvNrp9piFvM5G7SJ76 FvFEnOduKb04vTmwGe5Mch7AWXfPJdYYVhwW+YpzOk6tWra0HBwKvNgRLdMPVuQgFj9u ZDFQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20210112; h=x-gm-message-state:date:from:to:subject:message-id:references :mime-version:content-disposition:in-reply-to; bh=KzBqck0F1C+Gw3/NmrneDUQi0m/YPY+5hGu2H0vILFw=; b=ckJpJSs9cF/jqQ5ffQzBAZ0KkTZvgZA7/YvJes5pOI3X3sfzNu2kNkB5MoISDjeTas B+s0AiEp0nOUK0g3DOgSXf9GCj52FKNVYG5PZD2U5E00zbci00uqrtm3qFNt4ZeOns9m jfA4YyGSNfU5jyeKzww+HCJ+vjH7Btahp80F5psf1VhA/6a6SBmejJ55Sn3Bpv2Kf6NL nH9J+kA1bWkXQyLMSm0ffy0TSL1u0xSKeWbv5RusLoJNE4FBjOpA7lUbZ+eZzn8UaEMA E/yy7oMyZe592fBRZXH7pHw6LFJszuJ8XVuvepPugsmHmXueGikUX9J8M813LAqxBOxr UOkw== X-Gm-Message-State: AOAM533CI7o1z0ZnMredd2L+HDlBhVYv5CqZPqODoUX/YKEQBFy5TVwn oNPQAKx9N5iCdDAVk1Pc/qE1r0GzSCE= X-Google-Smtp-Source: ABdhPJxU1O/kNQ6o3bphOBW7FHghI+9UfysiCG04HOH2fu317Hu812CnZYGjFA+EsUoc9gWsLiHOAg== X-Received: by 2002:a05:620a:4406:: with SMTP id v6mr1578857qkp.429.1642739060638; Thu, 20 Jan 2022 20:24:20 -0800 (PST) Received: from jackie (pool-108-20-201-137.bstnma.fios.verizon.net. [108.20.201.137]) by smtp.gmail.com with ESMTPSA id k22sm2429429qkh.44.2022.01.20.20.24.19 for (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Thu, 20 Jan 2022 20:24:20 -0800 (PST) Date: Thu, 20 Jan 2022 23:24:18 -0500 From: Andriy Gelman To: FFmpeg development discussions and patches Message-ID: <20220121042418.qahluvi7zjbbilkk@jackie> References: MIME-Version: 1.0 Content-Disposition: inline In-Reply-To: Subject: Re: [FFmpeg-devel] Patchwork FATE Errors 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 Fri, 21. Jan 01:44, Soft Works wrote: > > > > -----Original Message----- > > From: ffmpeg-devel On Behalf Of Andreas > > Rheinhardt > > Sent: Friday, January 21, 2022 2:31 AM > > To: ffmpeg-devel@ffmpeg.org > > Subject: Re: [FFmpeg-devel] Patchwork FATE Errors > > > > Soft Works: > > > > > > > > >> -----Original Message----- > > >> From: ffmpeg-devel On Behalf Of Andreas > > >> Rheinhardt > > >> Sent: Thursday, January 20, 2022 11:38 PM > > >> To: ffmpeg-devel@ffmpeg.org > > >> Subject: Re: [FFmpeg-devel] Patchwork FATE Errors > > >> > > >> Soft Works: > > >>> > > >>> > > >>>> -----Original Message----- > > >>>> From: ffmpeg-devel On Behalf Of > > Andreas > > >>>> Rheinhardt > > >>>> Sent: Thursday, January 20, 2022 10:22 PM > > >>>> To: ffmpeg-devel@ffmpeg.org > > >>>> Subject: Re: [FFmpeg-devel] Patchwork FATE Errors > > >>>> > > >>>> Soft Works: > > >>>>> > > >>>>> andriy/make_fate_ppc > > >>>>> > > >>>>> => Does it possibly need 'make fate-rsync'? > > >>>>> > > >>>> > > >>>> No. The test does not rely on need samples; > > >>> > > >>> It was just a very quick guess, because yesterday I rebased and > > >>> saw the test matroska-dovi-write-config7 failing which was fixed > > >>> after fate-rsync - that's why I though it might be the same reason > > >>> (with make -jX, it's probably not deterministic, which test will > > >>> fail first). > > >>> > > >>> > > >>>> and the other test that uses > > >>>> this sample works fine. Some time ago, someone else wrote FATE tests for > > >>>> AVDOVIDecoderConfigurationRecord in Matroska > > >>>> > > (https://patchwork.ffmpeg.org/project/ffmpeg/patch/20220101165153.440729- > > >> 6- > > >>>> tcChlisop0@gmail.com/). > > >>>> These were faulty and one of them relied on a sample that has apparently > > >>>> never been uploaded (but this test is actually redundant with the other > > >>>> test), so I investigated and saw that the test (presumably > > >>>> unintentially) reencoded audio, so I switched it to a pure copy test and > > >>>> applied it, believing that codec-copy tests could not possibly for some > > >>>> arches. That was a mistake and I am deeply sorry for this mess. > > >>> > > >>> Nevermind - things happen.. > > >>> > > >>> > > >>> BTW, I was thinking about submitting a patch for libavutil/tests/md5.c > > >>> > > >>> something like: > > >>> > > >>> #ifdef __GNUC__ > > >>> #pragma GCC diagnostic ignored "-Wdiscarded-qualifiers" > > >>> #endif > > >>> > > >>> #ifdef __clang__ > > >>> #pragma clang diagnostic ignored "-Wdiscarded-qualifiers" > > >>> #endif > > >>> > > >>> Would that make sense? > > >>> Those warnings are appearing in every single fate error output on > > >> patchwork, > > >>> possibly covering up more relevant things. > > >>> > > >> > > >> Instead of pragmas one should limit the volatile to those compilers > > >> which miscompile the code without them. > > >> (IMO one does not need to find the exact set of compilers that > > >> miscompile this; all that matters is that recent versions don't give > > >> warnings and old versions don't miscompile. If some compilers of medium > > >> age still show this warning afterwards without needing the volatile, so > > >> be it.) > > > > > > You mean like this? > > > > > > #if defined(__clang__) && defined(__clang_major__) && __clang_major__ < 4 > > > volatile uint8_t in[1000]; // volatile to workaround > > http://llvm.org/bugs/show_bug.cgi?id=20849 > > > #else > > > uint8_t in[1000]; > > > #endif > > > > > > > I would not use an else branch, but only put the volatile and the > > comment in the #if branch. > > > > > > > > It was fixed in 3.5.1, so "medium age" would be 3.5.1 to 4.0.0 > > > > > > > Fine by me if tested. > > I do not have a Clang setup locally, I'd assume at least one of the > Patchwork VMs uses Clang? They're all using gcc at the moment. I can try to add extra info about the runners and their status. Maybe to a grafana page. -- Andriy _______________________________________________ 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".