[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [csmith-dev] Floating-point support in csmith
Yes, people should be able to tweak Csmith to output C programs which depend on certain libraries to compile or execute. That's totally fine with me.
Thanks for the clarification. I look forward to the splitted pull requests.
Sent from my phone
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?
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
> 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.
> On 14/11/2015 15:08, Eitan Adler wrote:
>> On 14 November 2015 at 01:53, John Regehr > wrote:<mailto:<email@example.com>
>>> In general the conflict here is between research software, which
>>> tends to
>>> accumulate a lot of bits and pieces and weirdnesses, and production
>>> 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`.