On Sat, Dec 19, 2015 at 8:06 AM, Ganesh Ajjanagadde <gajjanaga...@gmail.com> wrote: > On Sat, Dec 19, 2015 at 6:26 AM, Ronald S. Bultje <rsbul...@gmail.com> wrote: >> Hi, >> >> On Fri, Dec 18, 2015 at 3:47 PM, Ganesh Ajjanagadde <gajjanaga...@gmail.com> >> wrote: >>> >>> On Fri, Dec 18, 2015 at 12:41 PM, Ronald S. Bultje <rsbul...@gmail.com> >>> wrote: >>> > Hi, >>> > >>> > On Fri, Dec 18, 2015 at 2:18 PM, Ganesh Ajjanagadde >>> > <gajjanaga...@gmail.com> >>> > wrote: >>> >> >>> >> For systems with broken libms. >>> >> Tested with NAN, -NAN, INFINITY, -INFINITY, +/-x for regular double x >>> >> and >>> >> combinations of these. >>> >> >>> >> Signed-off-by: Ganesh Ajjanagadde <gajjanaga...@gmail.com> >>> >> --- >>> >> configure | 2 +- >>> >> libavutil/libm.h | 9 +++++++++ >>> >> 2 files changed, 10 insertions(+), 1 deletion(-) >>> >> >>> >> diff --git a/configure b/configure >>> >> index 123d1df..7917386 100755 >>> >> --- a/configure >>> >> +++ b/configure >>> >> @@ -2852,7 +2852,7 @@ cropdetect_filter_deps="gpl" >>> >> delogo_filter_deps="gpl" >>> >> deshake_filter_select="pixelutils" >>> >> drawtext_filter_deps="libfreetype" >>> >> -dynaudnorm_filter_deps="copysign erf" >>> >> +dynaudnorm_filter_deps="erf" >>> >> ebur128_filter_deps="gpl" >>> >> eq_filter_deps="gpl" >>> >> fftfilt_filter_deps="avcodec" >>> >> diff --git a/libavutil/libm.h b/libavutil/libm.h >>> >> index 6d8bd68..637de19 100644 >>> >> --- a/libavutil/libm.h >>> >> +++ b/libavutil/libm.h >>> >> @@ -62,6 +62,15 @@ static av_always_inline float cbrtf(float x) >>> >> } >>> >> #endif >>> >> >>> >> +#if !HAVE_COPYSIGN >>> >> +static av_always_inline double copysign(double x, double y) >>> >> +{ >>> >> + uint64_t vx = av_double2int(x); >>> >> + uint64_t vy = av_double2int(y); >>> >> + return av_int2double((vx & 0x7fffffffffffffff) | (vy & >>> >> 0x8000000000000000)); >>> >> +} >>> >> +#endif >>> > >>> > >>> > Don't these need type suffixes (e.g. UINT64_C(val)) on some systems? >>> >>> I believe not, see >>> http://en.cppreference.com/w/cpp/language/integer_literal >> >> >> That document confirms that it is indeed legal for a compiler to read the >> given literal on a 32bit or windows 64bit system as a 32bit max value, and >> your literals don't fit in 32bit. > > How, the standard clearly says that the literal will be in the type > int < unsigned int < long int < unsigned long int < long long int < > unsigned long long int, wherever it first fits, and this is also clear > from the link I sent. > > long long is at least 64 bits. I can't speak about broken > compilers/environments that lack long long.
This turns out to be the heart of the matter; as usual, Microsoft's toolchain is fundamentally broken: https://stackoverflow.com/questions/25626022/how-should-a-64-bit-integer-literal-be-represented-in-c. So later today I will push with the UINT64_C, in the absence of further comments. Thanks for the review. [...] _______________________________________________ ffmpeg-devel mailing list ffmpeg-devel@ffmpeg.org http://ffmpeg.org/mailman/listinfo/ffmpeg-devel