Did anything happen with these NDS32 patches?
Is there any effort to add support for it?

In D77168#2070083, @MaskRay wrote:

In D77168#2070049, @jcai19 wrote:

In D77168#2069783, @MaskRay wrote:

Do we have a mechanism bisecting pragmas? If yes, we can let that tool add #pragma clang attribute push([[clang::uninitialized]], apply_to = variable)

Not that I am aware of unfortunately. The whole point of having this patch is to add the ability to bisect programmatically, along the approach of using pragma as introduced in https://reviews.llvm.org/D78693.

If we have a mechanism bisecting pragmas, this option will not be needed.

We are seeing instances of an assert failing while building rsync and boost on Chrome OS. Bug https://crbug.com/1087678

In D77168#1988138, @srhines wrote:

In D77168#1988122, @jfb wrote:

In D77168#1988049, @srhines wrote:

pragma clang attribute is interesting, but how do you apply that in a selective fashion to local variables (especially in a way that can be automated)? At first, I didn't think the goal for this should be to create a frequently used option for most end users, but I do think that it could be quite useful for more folks when debugging, especially if it is easy to automate (which optimization-fuel approaches are, while pragmas are not).

__attribute__((uninitialized)) for more selectiveness :)

Of course, not automated. In general we don't really automate compiler things of this sort, say UBSan. OptRemarks is the best we really have to dig into these things. One other option would be to truly randomize the init pattern: emit a handful of different byte patterns, and then see the crash caused by a different pattern, and track it back to which local variable got that byte pattern.

That's just it though. This technique is tried and true in other compilers/tools. Why should we let past history dictate whether to facilitate automation in the present/future? Rather than having to "track it back", you can let the tooling do it for you. It gets you at least a breakage related to this transformation, and the best part is you can fix that one, and then run it again to chase down further issues. All without modifying source code. I feel like I can't be the only one who has used these kinds of tools for debugging transformations before, hence why I feel so invested in making this easy for everyone (compiler devs and regular users). UBSan isn't as relevant as it can provide diagnostics for the particular instance in which it was tripped. If we wanted to do something similar for initialization, we would have to mark the uninitialized value and track down any potential use of it, which seems like a lot more complexity and decreased performance too.

Is there any progress on this?