siddhesh

Frederic Berat writes about the mass prebuilder he has been working on to test changes to compilers and toolchain components.

It's not a runtime flag, you'll have to patch redhat-rpm-config to use _FORTIFY_SOURCE=3 instead of 2 and then build packages with it.

Of course if you only want to build your application with _FORTIFY_SOURCE=3, you can do it right away even on Fedora 36. The Fedora change will be to build the distribution (or at least a subset of packages) with _FORGIFY_SOURCE=3.

Yes.

It's on my TODO list. Watch out for Fedora change proposals for (hopefully) Fedora 38.

OpenSUSE already enables it across the distribution; they were the first to do it. I believe Gentoo either already has or is in the process of doing it. I'll make a proposal for Fedora once I have a better idea of the code size and performance impact.

You mean, like this?

https://imgur.com/a/unKuOoK

Snark aside, most text based editors have some giveaway or another. Even the GUI ones show syntax highlighting quirks that show that something is wrong.

This is only really relevant in unicode-aware terminals, without syntax highlighting and when you don't get to scroll between characters. IOW, it's really quite hard to do.

That was my second fallback until a couple of months ago and in fact I did some work for openresty too for luajit. Openresty luajit2 however has a bunch of extensions that are incompatible with Lua and luajit, making it unsuitable as the stock luajit replacement. It would be possible to make those extensions conditional on build flags but the blocker there was the fact that the maintainers did not seem keen on doing releases and more importantly, moving too far away from luajit. Overall it was just simpler to start doing releases myself to fulfill a need (a more central place to maintain fixes for distributions) and then work towards a convergence.

The v2.1 branch of moonjit specifically aims to remain "luajit-like" in the sense that it is the explicit goal to make sure we don't add incompatible features and we definitely don't make it so that if Mike Pall decides to continue development after a year (which he appears to have done, although one can never be sure given his record over the past few years), we can easily enough merge patches.

The master branch is where moonjit development is more active with people adding 5.2 and 5.3 features and new architectures too. It is in a way a different direction from luajit (since Mike specifically stated that he intends to remain incompatible with stock Lua because his dialect is better) and hence may not necessary converge with luajit if it ever actually comes back to life.

FWIW, if RaptorJIT had not ripped out arm64, I would have ended up recommending replacing Luajit with RaptorJIT in Fedora and not bothered with forking moonjit.

> 17:24:53 < derf> They reset the rounding modes on entrance and exit of expf(), for example, regardless of whether or not they're already correctly set up.

I fixed this around the same time I worked on the mp improvements:

commit 2506109403de69bd454de27835d42e6eb6ec3abc Author: Siddhesh Poyarekar <[email protected]> Date: Wed Jun 12 10:36:48 2013 +0530

    Set/restore rounding mode only when needed
    
    The most common use case of math functions is with default rounding
    mode, i.e. rounding to nearest.  Setting and restoring rounding mode
    is an unnecessary overhead for this, so I've added support for a
    context, which does the set/restore only if the FP status needs a
    change.  The code is written such that only x86 uses these.  Other
    architectures should be unaffected by it, but would definitely benefit
    if the set/restore has as much overhead relative to the rest of the
    code, as the x86 bits do.

These are all the changes I made in math during 2.18. They're almost all mp stuff with some code cleanup thrown in.

git log --author=siddhesh release/2.18/master -- sysdeps/ieee754/dbl-64

We have had this in our todo list for a while. The leading idea currently is to provide compiler selectable function variants that don't fall into the multiple precision abyss. The biggest challenge here is to come up with data about accuracy of results without the mp path.

Yes the link is incorrect. I am working on getting that fixed.

The crlibm code is terrible to read and hence maintain. I had considered including crlibm too during my work but decided against it because it would be a lot more work.

Also, crlibm functions are provably correctly rounded only for univariate transcendentals (thanks to the worst case paper I cited in the blog). There is no such proof available for bivariate functions, which is why computing at an arbitrary very large precision (the way glibc does) is the only way to increase the likelihood of correctly rounded results. IIRC crlibm does not even try for bivariates.

I believe some documentation on the crlibm website cites benchmark numbers where IIRC glibc performs better (although not by much) in the fast paths of most functions they mention but gets hit really badly in the slow path. Slow path inputs are usually quite rare, but if your application/benchmark hits them regularly enough (especially sice the slow path is a factor of 1000 times worse) then you'll obviously conclude that the performance sucks and that crlibm is better.