Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Michael Niedermayer]

On Tue, Dec 01, 2015 at 11:02:07AM -0500, Ganesh Ajjanagadde wrote:
> On Tue, Dec 1, 2015 at 10:38 AM, Nicolas George  wrote:
> > Le primidi 11 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> >> nicolas are you ok with this being applied ? (IIRC you objected to it)
> >
> > I am not really satisfied but I do not object. Hopefully it will not break
> > again.
> 
> same here - it seems like the heart of the matter is really not well
> understood, and someone down the road may see the code and wonder why
> the cast is being done. Hopefully the git blame still points to this
> change.

i hope it will solve the issue long term, if not its still a step
forward and we eliminated one option in that case

patch applied

thanks

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

No great genius has ever existed without some touch of madness. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Michael Niedermayer]

On Mon, Nov 30, 2015 at 08:03:41PM -0800, Muhammad Faiz wrote:
> On Mon, Nov 30, 2015 at 12:06 PM, Michael Niedermayer  
> wrote:
> > On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote:
> >> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> >> > > ISO/IEC 9899:TC3
> >> > > 5.2.4.2.2 Characteristics of floating types 
> >> > >
> >> > > 8 Except for assignment and cast (which remove all extra range and 
> >> > > precision), the values
> >> > > of operations with floating operands and values subject to the 
> >> > > usual arithmetic
> >> > > conversions and of floating constants are evaluated to a format 
> >> > > whose range and precision
> >> > > may be greater than required by the type. The use of evaluation 
> >> > > formats is characterized
> >> > > by the implementation-defined value of FLT_EVAL_METHOD:19)
> >> > > -1   indeterminable;
> >> > > 0   evaluate all operations and constants just to the 
> >> > > range and precision of the
> >> > > type;
> >> > > 1   evaluate operations and constants of type float and 
> >> > > double to the
> >> > > range and precision of the double type, evaluate long 
> >> > > double
> >> > > operations and constants to the range and precision of 
> >> > > the long double
> >> > > type;
> >> > > 2   evaluate all operations and constants to the range and 
> >> > > precision of the
> >> > > long double type.
> >> > > All other negative values for FLT_EVAL_METHOD characterize 
> >> > > implementation-defined
> >> > > behavior.
> >> >
> >> > a few more related parts:
> >> > 5 The accuracy of the floating-point operations (+, -, *, /) and of 
> >> > the library functions in
> >> >  and  that return floating-point results is 
> >> > implementation-
> >> > defined, as is the accuracy of the conversion between floating-point 
> >> > internal
> >> > representations and string representations performed by the library 
> >> > functions in
> >> > , , and . The implementation may state 
> >> > that the
> >> > accuracy is unknown.
> >> >
> >> > 6.4.4.2 Floating constants
> >> > 7 The translation-time conversion of floating constants should match 
> >> > the execution-time
> >> > conversion of character strings by library functions, such as 
> >> > strtod, given matching
> >> > inputs suitable for both conversions, the same result format, and 
> >> > default execution-time
> >> > rounding.64)
> >>
> >> I am not sure why you quoting this. Are you implying this is not a compiler
> >> bug, the compiler is actually allowed to do that? Possible. But still, I do
> >
> > yes, i suspect that is not a compiler bug but i certainly do not have
> > deep enough knowledge of C to say that for sure
> >
> >
> >> not think we should apply this unless we actually understand what is going
> >> on here, why a cast that should not change anything does change the result.
> >> Otherwise, it could just be a coincidence, and break in a different way on 
> >> a
> >> different compiler.
> >
> > I would not be surprised if a strict and litteral reading of C would
> > allow that still to fail, but then theres the question if such
> > equals check is even possible in C in such a strict reading of the
> > standard.
> > and theres also IEEE ...
> 
> But at least the standard said:
> 'Except for assignment and cast (which remove all extra range and precision)'
> so we can be sure that BASEFREQ is in double precision
> when casted to double.
> So, this patch should be OK
> 
> >
> > One could use a special value as default like -1 and check for that
> > which may be less likely to cause problems with float accuracy and
> > rounding in case the cast does not work on some real world case or
> > if the risk of it failing on some obscure plaform should be avoided
> 
> Unless the platform which makes this patch useless is reported,
> the patch should be OK for workaround.

yes
nicolas are you ok with this being applied ? (IIRC you objected to it)

language lawyering note: in a strict reading the standard the 2
occurances of the constant do probably not need to be parsed with teh
same precission nor with precission better or equal than "double".
In that case the code from the patch can fail and probably more or
less every clean alternative could too

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

The bravest are surely those who have the clearest vision
of what is before them, glory and danger alike, and yet
notwithstanding go out to meet it. -- Thucydides


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Nicolas George]

Le primidi 11 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> nicolas are you ok with this being applied ? (IIRC you objected to it)

I am not really satisfied but I do not object. Hopefully it will not break
again.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Ganesh Ajjanagadde]

On Tue, Dec 1, 2015 at 10:38 AM, Nicolas George  wrote:
> Le primidi 11 frimaire, an CCXXIV, Michael Niedermayer a écrit :
>> nicolas are you ok with this being applied ? (IIRC you objected to it)
>
> I am not really satisfied but I do not object. Hopefully it will not break
> again.

same here - it seems like the heart of the matter is really not well
understood, and someone down the road may see the code and wonder why
the cast is being done. Hopefully the git blame still points to this
change.

>
> Regards,
>
> --
>   Nicolas George
>
> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel
>
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Muhammad Faiz]

On Mon, Nov 30, 2015 at 11:09 PM, Nicolas George  wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
>> double basefreq = BASEFREQ, endfreq = ENDFREQ;
>> if (basefreq == BASEFREQ && endfreq == ENDFREQ)
>> printf("equal\n");
>> else
>> printf("inequal\n");
>>
>> I try with gcc -std=c89 / -std=c99 on mingw 32-bit
>> the result is inequal.
>
> That looks like a compiler bug. Could you post the generated assembly code,
> with and without the cast? (and with just one comparison, no need to make
> things complicated)

#include 

#define BASEFREQ20.01523126408007475

double basefreq = BASEFREQ;

int
main(int argc, char** argv)
{
if (basefreq == BASEFREQ)
printf("equal\n");
else printf("inequal\n");
return 0;
}


gcc -c -std=c89 -O2

without cast:
 <_main>:
   0: 55   push   %ebp
   1: 89 e5 mov%esp,%ebp
   3: 83 e4 f0 and$0xfff0,%esp
   6: 83 ec 10 sub$0x10,%esp
   9: e8 00 00 00 00   call   e <_main+0xe>
   e: dd 05 00 00 00 00 fldl   0x0
  14: db 2d 10 00 00 00 fldt   0x10
  1a: d9 c9 fxch   %st(1)
  1c: df e9 fucomip %st(1),%st
  1e: dd d8 fstp   %st(0)
  20: 7a 02 jp 24 <_main+0x24>
  22: 74 10 je 34 <_main+0x34>
  24: c7 04 24 06 00 00 00 movl   $0x6,(%esp)
  2b: e8 00 00 00 00   call   30 <_main+0x30>
  30: 31 c0 xor%eax,%eax
  32: c9   leave
  33: c3   ret
  34: c7 04 24 00 00 00 00 movl   $0x0,(%esp)
  3b: e8 00 00 00 00   call   40 <_main+0x40>
  40: eb ee jmp30 <_main+0x30>


with cast:
 <_main>:
   0: 55   push   %ebp
   1: 89 e5 mov%esp,%ebp
   3: 83 e4 f0 and$0xfff0,%esp
   6: 83 ec 10 sub$0x10,%esp
   9: e8 00 00 00 00   call   e <_main+0xe>
   e: dd 05 00 00 00 00 fldl   0x0
  14: dd 05 10 00 00 00 fldl   0x10
  1a: d9 c9 fxch   %st(1)
  1c: df e9 fucomip %st(1),%st
  1e: dd d8 fstp   %st(0)
  20: 7a 02 jp 24 <_main+0x24>
  22: 74 10 je 34 <_main+0x34>
  24: c7 04 24 06 00 00 00 movl   $0x6,(%esp)
  2b: e8 00 00 00 00   call   30 <_main+0x30>
  30: 31 c0 xor%eax,%eax
  32: c9   leave
  33: c3   ret
  34: c7 04 24 00 00 00 00 movl   $0x0,(%esp)
  3b: e8 00 00 00 00   call   40 <_main+0x40>
  40: eb ee jmp30 <_main+0x30>


without cast with -std=gnu89:
 <_main>:
   0: 55   push   %ebp
   1: 89 e5 mov%esp,%ebp
   3: 83 e4 f0 and$0xfff0,%esp
   6: 83 ec 10 sub$0x10,%esp
   9: e8 00 00 00 00   call   e <_main+0xe>
   e: dd 05 00 00 00 00 fldl   0x0
  14: dd 05 10 00 00 00 fldl   0x10
  1a: d9 c9 fxch   %st(1)
  1c: df e9 fucomip %st(1),%st
  1e: dd d8 fstp   %st(0)
  20: 7a 02 jp 24 <_main+0x24>
  22: 74 10 je 34 <_main+0x34>
  24: c7 04 24 06 00 00 00 movl   $0x6,(%esp)
  2b: e8 00 00 00 00   call   30 <_main+0x30>
  30: 31 c0 xor%eax,%eax
  32: c9   leave
  33: c3   ret
  34: c7 04 24 00 00 00 00 movl   $0x0,(%esp)
  3b: e8 00 00 00 00   call   40 <_main+0x40>
  40: eb ee jmp30 <_main+0x30>

without cast and use -std=c89, gcc uses fldt instead of fldl
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Michael Niedermayer]

On Mon, Nov 30, 2015 at 04:52:20PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> > -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> > +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) 
> > ENDFREQ) {
> 
> Looks wrong to me. Since s->basefreq is double and operands are always
> converted to the largest type before comparison, the cast would be implicit.
> And BASEFREQ and ENDFREQ are double anyway.
> 
> The problem, if any, is somewhere else.

ISO/IEC 9899:TC3
5.2.4.2.2 Characteristics of floating types 

8 Except for assignment and cast (which remove all extra range and 
precision), the values
of operations with floating operands and values subject to the usual 
arithmetic
conversions and of floating constants are evaluated to a format whose range 
and precision
may be greater than required by the type. The use of evaluation formats is 
characterized
by the implementation-defined value of FLT_EVAL_METHOD:19)
-1   indeterminable;
0   evaluate all operations and constants just to the range and 
precision of the
type;
1   evaluate operations and constants of type float and double to 
the
range and precision of the double type, evaluate long double
operations and constants to the range and precision of the long 
double
type;
2   evaluate all operations and constants to the range and 
precision of the
long double type.
All other negative values for FLT_EVAL_METHOD characterize 
implementation-defined
behavior.


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Republics decline into democracies and democracies degenerate into
despotisms. -- Aristotle


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Muhammad Faiz]

On Mon, Nov 30, 2015 at 10:52 PM, Nicolas George  wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
>> -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
>> +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) ENDFREQ) 
>> {
>
> Looks wrong to me. Since s->basefreq is double and operands are always
> converted to the largest type before comparison, the cast would be implicit.
> And BASEFREQ and ENDFREQ are double anyway.
>
> The problem, if any, is somewhere else.
>

double basefreq = BASEFREQ, endfreq = ENDFREQ;
if (basefreq == BASEFREQ && endfreq == ENDFREQ)
printf("equal\n");
else
printf("inequal\n");

I try with gcc -std=c89 / -std=c99 on mingw 32-bit
the result is inequal.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Nicolas George]

Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> double basefreq = BASEFREQ, endfreq = ENDFREQ;
> if (basefreq == BASEFREQ && endfreq == ENDFREQ)
> printf("equal\n");
> else
> printf("inequal\n");
> 
> I try with gcc -std=c89 / -std=c99 on mingw 32-bit
> the result is inequal.

That looks like a compiler bug. Could you post the generated assembly code,
with and without the cast? (and with just one comparison, no need to make
things complicated)

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Nicolas George]

Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) ENDFREQ) {

Looks wrong to me. Since s->basefreq is double and operands are always
converted to the largest type before comparison, the cast would be implicit.
And BASEFREQ and ENDFREQ are double anyway.

The problem, if any, is somewhere else.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Nicolas George]

Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> > ISO/IEC 9899:TC3
> > 5.2.4.2.2 Characteristics of floating types 
> > 
> > 8 Except for assignment and cast (which remove all extra range and 
> > precision), the values
> > of operations with floating operands and values subject to the usual 
> > arithmetic
> > conversions and of floating constants are evaluated to a format whose 
> > range and precision
> > may be greater than required by the type. The use of evaluation formats 
> > is characterized
> > by the implementation-defined value of FLT_EVAL_METHOD:19)
> > -1   indeterminable;
> > 0   evaluate all operations and constants just to the range and 
> > precision of the
> > type;
> > 1   evaluate operations and constants of type float and double 
> > to the
> > range and precision of the double type, evaluate long double
> > operations and constants to the range and precision of the 
> > long double
> > type;
> > 2   evaluate all operations and constants to the range and 
> > precision of the
> > long double type.
> > All other negative values for FLT_EVAL_METHOD characterize 
> > implementation-defined
> > behavior.
> 
> a few more related parts:
> 5 The accuracy of the floating-point operations (+, -, *, /) and of the 
> library functions in
>  and  that return floating-point results is 
> implementation-
> defined, as is the accuracy of the conversion between floating-point 
> internal
> representations and string representations performed by the library 
> functions in
> , , and . The implementation may state that 
> the
> accuracy is unknown.
> 
> 6.4.4.2 Floating constants
> 7 The translation-time conversion of floating constants should match the 
> execution-time
> conversion of character strings by library functions, such as strtod, 
> given matching
> inputs suitable for both conversions, the same result format, and default 
> execution-time
> rounding.64)

I am not sure why you quoting this. Are you implying this is not a compiler
bug, the compiler is actually allowed to do that? Possible. But still, I do
not think we should apply this unless we actually understand what is going
on here, why a cast that should not change anything does change the result.
Otherwise, it could just be a coincidence, and break in a different way on a
different compiler.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Michael Niedermayer]

On Mon, Nov 30, 2015 at 06:25:15PM +0100, Michael Niedermayer wrote:
> On Mon, Nov 30, 2015 at 04:52:20PM +0100, Nicolas George wrote:
> > Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> > > -if (s->basefreq != BASEFREQ || s->endfreq != ENDFREQ) {
> > > +if (s->basefreq != (double) BASEFREQ || s->endfreq != (double) 
> > > ENDFREQ) {
> > 
> > Looks wrong to me. Since s->basefreq is double and operands are always
> > converted to the largest type before comparison, the cast would be implicit.
> > And BASEFREQ and ENDFREQ are double anyway.
> > 
> > The problem, if any, is somewhere else.
> 
> ISO/IEC 9899:TC3
> 5.2.4.2.2 Characteristics of floating types 
> 
> 8 Except for assignment and cast (which remove all extra range and 
> precision), the values
> of operations with floating operands and values subject to the usual 
> arithmetic
> conversions and of floating constants are evaluated to a format whose 
> range and precision
> may be greater than required by the type. The use of evaluation formats 
> is characterized
> by the implementation-defined value of FLT_EVAL_METHOD:19)
> -1   indeterminable;
> 0   evaluate all operations and constants just to the range and 
> precision of the
> type;
> 1   evaluate operations and constants of type float and double to 
> the
> range and precision of the double type, evaluate long double
> operations and constants to the range and precision of the 
> long double
> type;
> 2   evaluate all operations and constants to the range and 
> precision of the
> long double type.
> All other negative values for FLT_EVAL_METHOD characterize 
> implementation-defined
> behavior.

a few more related parts:
5 The accuracy of the floating-point operations (+, -, *, /) and of the 
library functions in
 and  that return floating-point results is 
implementation-
defined, as is the accuracy of the conversion between floating-point 
internal
representations and string representations performed by the library 
functions in
, , and . The implementation may state that the
accuracy is unknown.

6.4.4.2 Floating constants
7 The translation-time conversion of floating constants should match the 
execution-time
conversion of character strings by library functions, such as strtod, given 
matching
inputs suitable for both conversions, the same result format, and default 
execution-time
rounding.64)






> 
> 
> [...]
> 
> -- 
> Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB
> 
> Republics decline into democracies and democracies degenerate into
> despotisms. -- Aristotle



> ___
> ffmpeg-devel mailing list
> ffmpeg-devel@ffmpeg.org
> http://ffmpeg.org/mailman/listinfo/ffmpeg-devel


-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Freedom in capitalist society always remains about the same as it was in
ancient Greek republics: Freedom for slave owners. -- Vladimir Lenin


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Nicolas George]

Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
> gcc -c -std=c89 -O2

gcc -S would have been more useful: as is, it lacks the definition for
basefreq, and apparently also the other constant.

Regards,

-- 
  Nicolas George


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Michael Niedermayer]

On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote:
> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
> > > ISO/IEC 9899:TC3
> > > 5.2.4.2.2 Characteristics of floating types 
> > > 
> > > 8 Except for assignment and cast (which remove all extra range and 
> > > precision), the values
> > > of operations with floating operands and values subject to the usual 
> > > arithmetic
> > > conversions and of floating constants are evaluated to a format whose 
> > > range and precision
> > > may be greater than required by the type. The use of evaluation 
> > > formats is characterized
> > > by the implementation-defined value of FLT_EVAL_METHOD:19)
> > > -1   indeterminable;
> > > 0   evaluate all operations and constants just to the range 
> > > and precision of the
> > > type;
> > > 1   evaluate operations and constants of type float and 
> > > double to the
> > > range and precision of the double type, evaluate long 
> > > double
> > > operations and constants to the range and precision of 
> > > the long double
> > > type;
> > > 2   evaluate all operations and constants to the range and 
> > > precision of the
> > > long double type.
> > > All other negative values for FLT_EVAL_METHOD characterize 
> > > implementation-defined
> > > behavior.
> > 
> > a few more related parts:
> > 5 The accuracy of the floating-point operations (+, -, *, /) and of the 
> > library functions in
> >  and  that return floating-point results is 
> > implementation-
> > defined, as is the accuracy of the conversion between floating-point 
> > internal
> > representations and string representations performed by the library 
> > functions in
> > , , and . The implementation may state that 
> > the
> > accuracy is unknown.
> > 
> > 6.4.4.2 Floating constants
> > 7 The translation-time conversion of floating constants should match 
> > the execution-time
> > conversion of character strings by library functions, such as strtod, 
> > given matching
> > inputs suitable for both conversions, the same result format, and 
> > default execution-time
> > rounding.64)
> 
> I am not sure why you quoting this. Are you implying this is not a compiler
> bug, the compiler is actually allowed to do that? Possible. But still, I do

yes, i suspect that is not a compiler bug but i certainly do not have
deep enough knowledge of C to say that for sure


> not think we should apply this unless we actually understand what is going
> on here, why a cast that should not change anything does change the result.
> Otherwise, it could just be a coincidence, and break in a different way on a
> different compiler.

I would not be surprised if a strict and litteral reading of C would
allow that still to fail, but then theres the question if such
equals check is even possible in C in such a strict reading of the
standard.
and theres also IEEE ...

One could use a special value as default like -1 and check for that
which may be less likely to cause problems with float accuracy and
rounding in case the cast does not work on some real world case or
if the risk of it failing on some obscure plaform should be avoided


[...]

-- 
Michael GnuPG fingerprint: 9FF2128B147EF6730BADF133611EC787040B0FAB

Everything should be made as simple as possible, but not simpler.
-- Albert Einstein


signature.asc
Description: Digital signature
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Muhammad Faiz]

On Mon, Nov 30, 2015 at 10:00 AM, Nicolas George  wrote:
> Le decadi 10 frimaire, an CCXXIV, Muhammad Faiz a écrit :
>> gcc -c -std=c89 -O2
>
> gcc -S would have been more useful: as is, it lacks the definition for
> basefreq, and apparently also the other constant.
>

The strange behaviour is that gcc uses fldt instead of fldl
to load BASEFREQ. I think it is enough to detect the problem.

Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel

Re: [FFmpeg-devel] [PATCH] avfilter/showcqt: BASEFREQ and ENDFREQ cast to double

[Muhammad Faiz]

On Mon, Nov 30, 2015 at 12:06 PM, Michael Niedermayer  wrote:
> On Mon, Nov 30, 2015 at 07:02:47PM +0100, Nicolas George wrote:
>> Le decadi 10 frimaire, an CCXXIV, Michael Niedermayer a écrit :
>> > > ISO/IEC 9899:TC3
>> > > 5.2.4.2.2 Characteristics of floating types 
>> > >
>> > > 8 Except for assignment and cast (which remove all extra range and 
>> > > precision), the values
>> > > of operations with floating operands and values subject to the usual 
>> > > arithmetic
>> > > conversions and of floating constants are evaluated to a format 
>> > > whose range and precision
>> > > may be greater than required by the type. The use of evaluation 
>> > > formats is characterized
>> > > by the implementation-defined value of FLT_EVAL_METHOD:19)
>> > > -1   indeterminable;
>> > > 0   evaluate all operations and constants just to the range 
>> > > and precision of the
>> > > type;
>> > > 1   evaluate operations and constants of type float and 
>> > > double to the
>> > > range and precision of the double type, evaluate long 
>> > > double
>> > > operations and constants to the range and precision of 
>> > > the long double
>> > > type;
>> > > 2   evaluate all operations and constants to the range and 
>> > > precision of the
>> > > long double type.
>> > > All other negative values for FLT_EVAL_METHOD characterize 
>> > > implementation-defined
>> > > behavior.
>> >
>> > a few more related parts:
>> > 5 The accuracy of the floating-point operations (+, -, *, /) and of 
>> > the library functions in
>> >  and  that return floating-point results is 
>> > implementation-
>> > defined, as is the accuracy of the conversion between floating-point 
>> > internal
>> > representations and string representations performed by the library 
>> > functions in
>> > , , and . The implementation may state 
>> > that the
>> > accuracy is unknown.
>> >
>> > 6.4.4.2 Floating constants
>> > 7 The translation-time conversion of floating constants should match 
>> > the execution-time
>> > conversion of character strings by library functions, such as strtod, 
>> > given matching
>> > inputs suitable for both conversions, the same result format, and 
>> > default execution-time
>> > rounding.64)
>>
>> I am not sure why you quoting this. Are you implying this is not a compiler
>> bug, the compiler is actually allowed to do that? Possible. But still, I do
>
> yes, i suspect that is not a compiler bug but i certainly do not have
> deep enough knowledge of C to say that for sure
>
>
>> not think we should apply this unless we actually understand what is going
>> on here, why a cast that should not change anything does change the result.
>> Otherwise, it could just be a coincidence, and break in a different way on a
>> different compiler.
>
> I would not be surprised if a strict and litteral reading of C would
> allow that still to fail, but then theres the question if such
> equals check is even possible in C in such a strict reading of the
> standard.
> and theres also IEEE ...

But at least the standard said:
'Except for assignment and cast (which remove all extra range and precision)'
so we can be sure that BASEFREQ is in double precision
when casted to double.
So, this patch should be OK

>
> One could use a special value as default like -1 and check for that
> which may be less likely to cause problems with float accuracy and
> rounding in case the cast does not work on some real world case or
> if the risk of it failing on some obscure plaform should be avoided

Unless the platform which makes this patch useless is reported,
the patch should be OK for workaround.

Thank's.
___
ffmpeg-devel mailing list
ffmpeg-devel@ffmpeg.org
http://ffmpeg.org/mailman/listinfo/ffmpeg-devel