you re right after second thoughts it does not bring anything on the table.

Update unit test case.

well x29 and x30 registers are already used in fact ?

In D100700#2699281, @yln wrote:

Hi David, can you explain the motivation and mechanics of this change? I see that we #define aliases for registers, but they are never used?!

Ok that is fair.

In D89652#2341022, @vitalybuka wrote:

How likely we are going to remove it soon this as unused OpenBSD?
Are we going to have continuous builder?

In D89640#2338522, @hans wrote:

Follow-up to fix the Windows build, https://github.com/llvm/llvm-project/commit/a7acee89d68473183cc5021d952a56cdf0ae27d3

Focusing on ubsan change only

bring back builtins part

In D89631#2337028, @krytarowski wrote:

This contains unrelated code to ubsan/dragonflybsd. While there can you remove unsupported code for other OSs you introduced? That was never operational?

In D84046#2168732, @ro wrote:

Unfortunately I hadn't noticed that you'd silently changed the madvise prototype from the version I'd suggested (and tested on both Solaris 11.4 and OpenIndiana) to one using caddr_t instead of void * for the first arg, this way breaking the Solaris build. Now fixed in D84388.

Please don't do something like this: it just creates unnecessary work.

This is exactly the reason why I asked for a way to distinguish between Illumos and Solaris at compile time (e.g. by predefining __illumos__).
Fixing one by breaking the other just isn't an option.

Changes per feedback :
madvise prototype for access.

ping :-)

ping :-)

In D71923#1807577, @hans wrote:

But was there a bug before, or is this just an optimization? Maybe it could just be an array instead?

In D68723#1703379, @MaskRay wrote:

In D68723#1703322, @devnexen wrote:

@dim I LGTMed this but would it a real issue for you to take on a less disruptive approach proposed by MaskRay ?

I think we should do what @labath suggested (changing Expected to Optional) if that is not very difficult.

@dim I LGTMed this but would it a real issue for you to take on a less disruptive approach proposed by MaskRay ?

In D68723#1703098, @MaskRay wrote:

In D68723#1703051, @devnexen wrote:

LGTM otherwise.

I don't think this change should be reverted. It can just be repaired by adding some (void)!xxx;

LGTM otherwise.

In rL365761#695545, @dim wrote:

In rL365761#695543, @dim wrote:

@devnexen this appears to cause https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=241137, where simply launching a process in lldb triggers a failure:

Expected<T> must be checked before access or destruction.
Expected<T> value was in success state. (Note: Expected<T> values in success mode must still be checked prior to being destroyed).

Btw, note that this only happens when LLVM_ENABLE_ABI_BREAKING_CHECKS is on, but it is not entirely clear to me where that gets toggled. We have it in our pre-generated headers though, so it must come originally from some CMake logic...

In D68045#1699532, @jbeich wrote:

Can someone land this change? Only tested on FreeBSD because contributing guide didn't cover how to elsewhere i.e., on platforms one doesn't have access to.

You are right !