[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [csmith-dev] Floating-point support in csmith



Ally, thanks for clarifying!

I think the proposed split sounds great (also because it's a really big pull req). The float support should be uncontroversial (and indeed much welcomed) by us Csmith folks.

If the boost dependency only kicks in when one wants to compile Csmith's output then that should not be a problem either, right Xuejun? All we are trying to do here is keep Csmith easy to use for everyone.

Thanks,

John


On 11/15/15 9:41 PM, Alastair Donaldson wrote:
Regarding the role of Boost: what Jacek did is adapted Csmth so that it
emits macros in place of the float type and float operators.

By default, these expand to the regular float type and float safe math
macros.

What Jacek worked on during his internship was providing an interval
arithmetic facility.  In this mode, the float type macro expands to a
struct that represents an interval of floats, and each floating point
operation becomes a call to a function that operates on, and returns,
interval structs.  He then implemented a wrapper library that implements
each of the floating point interval operations by delegating to the
Boost interval arithmetic library.  The idea is that for a Csmith float
program, one can use a reliable compiler in interval mode to get bounds
on the possible values of floating point results, and then check whether
results from another compiler are within these bounds.  This is useful
if one does not expect bit-precise equivalence between compilers but
does expect interval containment.

So, to summarise: one only needs Boost if one wants to compile and use
Jacek's wrapper library for interval arithmetic.

Jacek could split his pull request into two parts: one that fixes issues
related to floats in Csmith, and another that relates to the wrapper
library.  Given that not everyone would require the wrapper library,
perhaps it could be configured to build only if Boost is available?  It
would also be maintained as a separate project, but I think that since
it could well be useful to other folks interested in Csmith there might
be a case for adding it to the main code base.

Let me know what you think.

A


On 14/11/2015 15:08, Eitan Adler wrote:
On 14 November 2015 at 01:53, John Regehr <regehr@cs.utah.edu> wrote:
In general the conflict here is between research software, which
tends to
accumulate a lot of bits and pieces and weirdnesses, and production
software
that we try to keep streamlined and clean.  As an example of the
latter, if
anyone has installed Redis, you've seen what an exceptionally clean
piece of
production-grade open source software looks like: you just download
it and
type "make" and this always works.

Ally and Jacek, I wonder if you could comment a bit on the general
usefulness of this extension?  Has it been working well for you and
is it
something that a lot of Csmith users would appreciate?
General comment, but relevant: when it comes to issues like this
please try to optimize for package maintainers.   On modern operating
systems it should be a very rare event to download software and type
make.  Installing any piece of software (redis or csmith) ought to be
as simple as `pkg install csmith`.