Pushed patches 1-4
/Tomas
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
https://ffmpeg.org/mailman/listinfo/ffmpeg-devel
To unsubscribe, visit link above, or email
ffmpeg-devel-requ...@ffmpeg.org with subject "unsubscribe".
On Mon, Jun 03, 2024 at 10:32:17AM +0300, Rémi Denis-Courmont wrote:
>
>
> Le 31 mai 2024 04:03:24 GMT+03:00, Michael Niedermayer
> a écrit :
> >> Are you imitating Thilo and grand-standing by putting words in my mouth?
> >
> >That seems unneccesarily insulting towards Thilo
>
> This is not an
Le 31 mai 2024 04:03:24 GMT+03:00, Michael Niedermayer
a écrit :
>> Are you imitating Thilo and grand-standing by putting words in my mouth?
>
>That seems unneccesarily insulting towards Thilo
This is not an insult in the first place, and besides Thilo did put words in
mouth to discredit me a
tor 2024-05-30 klockan 20:49 +0300 skrev Rémi Denis-Courmont:
> Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit
> > It is not a "theoretical" UB - that's not how UB works.
>
> It is a *theoretical* UB if you can not prove that it leads to
> misbehaviour in
> any *practical*
On Thu, May 30, 2024 at 06:38:42PM +0300, Rémi Denis-Courmont wrote:
> Le torstaina 30. toukokuuta 2024, 18.32.19 EEST Tomas Härdin a écrit :
> > Are you saying that UB is acceptable?
>
no, thats not what Remi meant IIUC
> Are you imitating Thilo and grand-standing by putting words in my mouth?
Le torstaina 30. toukokuuta 2024, 22.07.13 EEST Michael Niedermayer a écrit :
> If the function doesnt get called with values triggering UB then its not UB.
As Tomas pointed out, that statement is actually false. Specifically, if the
compiler can prove that the function can be called with values
On Thu, May 30, 2024 at 08:49:12PM +0300, Rémi Denis-Courmont wrote:
> Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit :
> > > > Are you saying that UB is acceptable? You know the compiler is free
> > > > to
> > > > assume signed arithmetic doesn't overflow, right? If so then w
Le torstaina 30. toukokuuta 2024, 19.48.13 EEST Tomas Härdin a écrit :
> > > Are you saying that UB is acceptable? You know the compiler is free
> > > to
> > > assume signed arithmetic doesn't overflow, right? If so then what
> > > other
> > > UB might we accept?
> >
> > He did not say that... He
tor 2024-05-30 klockan 12:42 -0300 skrev James Almer:
> On 5/30/2024 12:32 PM, Tomas Härdin wrote:
> > tor 2024-05-30 klockan 17:28 +0300 skrev Rémi Denis-Courmont:
> > >
> > >
> > > Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin"
> > > a
> > > écrit :
> > > > > We should depend on punning as
On 5/30/2024 12:32 PM, Tomas Härdin wrote:
tor 2024-05-30 klockan 17:28 +0300 skrev Rémi Denis-Courmont:
Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin" a
écrit :
We should depend on punning as long as it conforms to the
standard.
My mistake, I forgot type punning is allowed in C. It's U
Le torstaina 30. toukokuuta 2024, 18.32.19 EEST Tomas Härdin a écrit :
> Are you saying that UB is acceptable?
Are you imitating Thilo and grand-standing by putting words in my mouth?
Yes and so -1 for you.
--
レミ・デニ-クールモン
http://www.remlab.net/
___
tor 2024-05-30 klockan 17:28 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin" a
> écrit :
> > > We should depend on punning as long as it conforms to the
> > > standard.
> >
> > My mistake, I forgot type punning is allowed in C. It's UB in C++
> >
> > >
Le 30 mai 2024 17:07:21 GMT+03:00, "Tomas Härdin" a écrit :
>> We should depend on punning as long as it conforms to the standard.
>
>My mistake, I forgot type punning is allowed in C. It's UB in C++
>
>> > The standard compliant way
>> > is to use memcpy()
>>
>> That's way worse than union in
tor 2024-05-30 klockan 14:50 +0300 skrev Rémi Denis-Courmont:
>
>
> Le 30 mai 2024 12:40:20 GMT+03:00, "Tomas Härdin" a
> écrit :
> > tor 2024-05-30 klockan 09:41 +0300 skrev Rémi Denis-Courmont:
> > > Hi,
> > >
> > > Le 30 mai 2024 01:13:14 GMT+03:00, "Tomas Härdin"
> > > a
> > > écrit :
> >
Le 30 mai 2024 12:40:20 GMT+03:00, "Tomas Härdin" a écrit :
>tor 2024-05-30 klockan 09:41 +0300 skrev Rémi Denis-Courmont:
>> Hi,
>>
>> Le 30 mai 2024 01:13:14 GMT+03:00, "Tomas Härdin" a
>> écrit :
>> > The entire patchset passes FATE
>>
>> Is the version in riscv/intmath.h safe? It looks to
tor 2024-05-30 klockan 00:31 +0200 skrev Andreas Rheinhardt:
> Tomas Härdin:
> > */
> > static av_always_inline av_const int32_t av_clipl_int32_c(int64_t
> > a)
> > {
> > - if ((a+0x8000u) & ~UINT64_C(0x)) return
> > (int32_t)((a>>63) ^ 0x7FFF);
> > - else
tor 2024-05-30 klockan 09:41 +0300 skrev Rémi Denis-Courmont:
> Hi,
>
> Le 30 mai 2024 01:13:14 GMT+03:00, "Tomas Härdin" a
> écrit :
> > The entire patchset passes FATE
>
> Is the version in riscv/intmath.h safe? It looks to me that the GCC
> codegen for not only RV64 but also AArch{32,64} and
Hi,
Le 30 mai 2024 01:13:14 GMT+03:00, "Tomas Härdin" a écrit :
>The entire patchset passes FATE
Is the version in riscv/intmath.h safe? It looks to me that the GCC codegen for
not only RV64 but also AArch{32,64} and x86-64 is better than this.
___
ff
Tomas Härdin:
> */
> static av_always_inline av_const int32_t av_clipl_int32_c(int64_t a)
> {
> -if ((a+0x8000u) & ~UINT64_C(0x)) return (int32_t)((a>>63) ^
> 0x7FFF);
> -else return (int32_t)a;
> +if ((a+UINT64_C(0x8000))
19 matches
Mail list logo
