- User Since
- Jun 28 2017, 4:27 PM (64 w, 5 d)
Wed, Sep 19
Mon, Sep 17
Change is fine with me since Linux behavior is unchanged. @rnk can comment on whether this is the best approach for Windows or not.
Fri, Sep 14
Thu, Sep 13
- Call getUniqueModuleId once per module.
Tue, Sep 11
The error was actually caused by setting associated metadata for some arrays and not others. By always setting the metadata, we can avoid the issue.
- Do not set comdat for local-linkage functions without a unique module ID
- Rebase properly.
- Only set comdats for ELF.
- Fallback to using module ID when getUniqueModuleId fails.
- Add refactoring TODO.
Mon, Sep 10
- Fallback to counter suffix if getUniqueModuleId fails.
Thu, Sep 6
Wed, Sep 5
It seems reasonable to just check that argv is set, since this test is intended to check for LLVMFuzzerInitialize being called. There's plenty of other tests where libFuzzer must find a string.
Maybe I'm misunderstanding something, but I'm pretty sure memmem returns non-null on a match while strncmp returns 0 on match. Which would mean the ! should have been removed.
That patch broke the behavior of this test. Looks like we used to print "BINGO" when the input matched the binary name. Now we print "BINGO" when the input size matches but the names do not.
Maybe memcmp would be cleaner here.
Tue, Sep 4
Thu, Aug 30
Wed, Aug 29
Tue, Aug 28
Mon, Aug 27
We will need to disable failing tests for Windows. libFuzzer does run as part of check-all now.
Aug 23 2018
Aug 22 2018
Aug 21 2018
Aug 20 2018
Aug 16 2018
Aug 15 2018
Does this hit new coverage in the vectorizer?
Aug 14 2018
Ping. Can we submit this patch at least for consistency with PC tables and inline counters?
Another option would be to allow simple control flow within the loop itself.
Aug 13 2018
Does having multiple loops one after another change any coverage in the vectorizer?