On Tue, Nov 19, 2013 at 1:10 AM, Anton Khirnov <[email protected]> wrote:
> > Hi, > On Mon, 18 Nov 2013 21:59:52 -0800, Martynas Venckus <[email protected]> > wrote: > > > It defines {FLT,DBL}_{MAX,MIN} macros, even though float.h is supposed > > > to do that. > > > > Nope. In OpenBSD, only if you #define _XOPEN_SOURCE < 600, as it's > > required by XPG3 - XPG5v2. > > I admit I only tested on NetBSD and assumed it would be pretty much the > same on > OpenBSD, as the failures are the same there. > > On NetBSD, those values are under > #if defined(_XOPEN_SOURCE) || defined(_NETBSD_SOURCE) > Libav configure defines _XOPEN_SOURCE=600, so they get exported. > martynas:24$ echo "#include <limits.h>" | gcc -D_XOPEN_SOURCE=600 -dM -E - | grep DBL_MAX[^_] martynas:25$ > > > > > > Those values are not exactly representable double/float as > > > the specification mandates, which breaks code (e.g. in vf_fps) like > > > > > > double f = DBL_MAX; > > > [...] > > > if (f == DBL_MAX) { // f has not been changed yet > > > [....] > > > } > > > > So this is the exact same snippet running on OpenBSD/i386 (tested with > -O0, > > -O1, -O2): > > > > martynas:64$ cat a.c > > #include <float.h> > > int > > main(void) > > { > > double f = DBL_MAX; > > if (f == DBL_MAX) { > > return (1); > > } > > return (0); > > } > > martynas:65$ gcc a.c > > martynas:66$ > > ./a.out > > > > martynas:67$ echo $? > > 1 > > > > Can you help me reproduce this bug? > > > > Only happens on 32bit and with -std=c99 (more precisely > -fexcess-precision=standard, which is enabled by -std=c99). > You also have to #include <limits.h> after <float.h>. > martynas:25$ cat a.c #include <float.h> int main(void) { double f = DBL_MAX; if (f == DBL_MAX) { return (1); } return (0); } martynas:26$ gcc -std=c99 a.c martynas:27$ ./a.out martynas:28$ echo $? 1 martynas:29$ arch OpenBSD.i386 > > > > compat/bsd/limits.h | 41 +++++++++++++++++++++++++++++++++++++++++ > > > configure | 2 ++ > > > 2 files changed, 43 insertions(+) > > > create mode 100644 compat/bsd/limits.h > > > > Whoa, instead of patching things around, can we do this right and fix it > > upstream? It's not like the upstream is uncooperative. > > > > We probably still want to make it work on all the current versions of > {Net,Open}BSD. I was going to poke the upstreams eventually, but I > appreciate > that you contacted us first. > > > > Fixed the description of the cause -- a patched gcc that violates the > > standard > > > also collaborates on the breakage. > > > > Can you point me to the gcc patch that violates the standard? > > I did not look at the patches you have directly, but > - the C99 standard specifies that unqualified floating point literals must > be > treated as double (6.4.4.2.4) > - the version of gcc on NetBSD clearly does the comparison in extended > precision, so gcc must violate the standard. I assume OpenBSD behaves the > same, since it fails in the same way. > - the vanilla gcc behaves correctly > from this I conclude that you probably have some patches which break this. > > -- > Anton Khirnov > _______________________________________________ libav-devel mailing list [email protected] https://lists.libav.org/mailman/listinfo/libav-devel
