svn commit: r251796 - head/sbin/hastd

[Ed Schouten]

Hello Pawel,

2013/6/16 Pawel Jakub Dawidek <pjd at freebsd.org>:
> Hmm, I don't like HAST to be a victim of bad LLVM import. This is not
> the kind of software you run on HEAD (so it might go unnoticed
> initially)  and this is the kind of software that when breaks can have
> serious consequences.
>
> What kind of breaks are we talking about? That HAST will stop compiling
> or HAST can start corrupting data?

My intent is that we shouldn't see a whole lot of C11 atomics in
FreeBSD appear before we have at least one stable branch that supports
it properly (10.0). The problem with this approach is that I've
noticed that if we import things into our base system that we hardly
use, it will get almost no coverage. This causes all sorts of breakage
that could have prevented easily. Good examples:

http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=251347&r2=251566
http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=250883&r2=251192
http://svnweb.freebsd.org/base/head/sys/sys/stdatomic.h?r1=228862&r2=228880

By at least letting a couple of pieces of code use C11, this is less
likely to regress again. The examples that I gave of course refer to
breakage of <stdatomic.h>, not regressions in LLVM itself. I merely
named regressions in LLVM as a worst-case example. My assumption would
be that any breakage in LLVM related to C11 atomics is as likely as
any other kind of regression.

If you want, I can revert this change. Still, I would actually prefer
it if we not only let HAST use C11 atomics, but also a small number of
other pieces of code. That way any kind of breakage would become
pretty visible.

Thoughts?

--
Ed Schouten <ed at 80386.nl>