In D68115#1820579, @aaron.ballman wrote:

In D68115#1820462, @vitalybuka wrote:

I would be happy to finish this patch if we agree on something.

So if I understand this the proposal is to have something like -fzero-union-padding which is off by default.
When it's OFF compiler will continue to do whatever it does now.
When it's ON it will set zeroes into padding with or without -ftrivial-auto-var-init.
Is this correct?

In general, I believe so, yes. To be clear, it only sets zeros into union padding, not *all* padding. I do not have an opinion on whether we want it to be -fzero-union-padding as opposed to -finit-union-padding that honors the pattern from -ftrivial-auto-init=pattern and defaults to zero if no pattern is specified.

In D68115#1819418, @aaron.ballman wrote:

In D68115#1811091, @lebedev.ri wrote:

In D68115#1811089, @hubert.reinterpretcast wrote:

In D68115#1810891, @lebedev.ri wrote:

Does this have to be an unilateral change,
likely penalizing non--ftrivial-auto-var-init= cases,
i.e. [why] can't it be only done for when -ftrivial-auto-var-init= is enabled?

We left off near that conclusion (https://reviews.llvm.org/D68115#1686887);

Would be great if @rsmith / @aaron.ballman could comment on that

I don't have super strong opinions on it, but I think a separate feature for zeroing union padding is what gives users the most flexibility.

In D68115#1811089, @hubert.reinterpretcast wrote:

A separate option to control zeroing for union padding would help in cases where the zeroing does not happen for reasons other than -ftrivial-auto-var-init.

Agreed.

This patch is causing problems on Window bot: http://lab.llvm.org:8011/builders/sanitizer-windows/builds/56324

Sanitizers should work for aarch64, we have build bot for that
http://lab.llvm.org:8011/builders/sanitizer-x86_64-linux-android

what is about clang-format?

nice

You can consider just to link needed code into small binary which will printout serialized inputs from the drive. And call that e.g. in the following way:

my_fuzzer  |& my_printer

Then my_printer will match "Test unit written" and printout content of corresponding file.

LGTM

Isn't this going to break our msan bots?

the rest is LGTM

In D51018#1709815, @dgg5503 wrote:

@vitalybuka I plan to debug this failure as soon as I can. I imagine I'd have to use QEmu to emulate ppc64/s390x since I don't have such a machine on hand. Thanks for committing my other diff though!

Reverted https://reviews.llvm.org/rL374636

nfc

In D51018#1702476, @dgg5503 wrote:

In D51018#1702330, @vitalybuka wrote:

In D51018#1700811, @dgg5503 wrote:

@vsk thanks for the review! It looks like the JSON support library implements what JSONWriter does in this tool. To reduce maintenance, I've updated sancov to use the JSON support library implementation instead. The only downside to this change is that the JSON text format differs compared to the original implementation. I'm open to reverting this diff and simply adding your suggested change which also worked. Let me know what you think.

EDIT:
I've also updated the title and description to better describe the changes in this diff.

I like the change.

Could you move JSONWriter -> JSON refactoring into separate patch and rebase win stuff ontop?
If you don't have commiter access, someone will need to commit it for you
So I don't mind to split the patch and commit myself.

Sure thing! Would I be creating a separate diff for review or would this be taken from the history? Also, I do not have commiter access so I will need someone to commit it for me.

In D51018#1700811, @dgg5503 wrote:

@vsk thanks for the review! It looks like the JSON support library implements what JSONWriter does in this tool. To reduce maintenance, I've updated sancov to use the JSON support library implementation instead. The only downside to this change is that the JSON text format differs compared to the original implementation. I'm open to reverting this diff and simply adding your suggested change which also worked. Let me know what you think.

EDIT:
I've also updated the title and description to better describe the changes in this diff.