[llvm][unittests] Don't call raw_string_ostream::flush() (NFC)

raw_string_ostream::flush() is essentially a no-op (also specified in docs).
Don't call it in tests that aren't meant to test 'raw_stri

[llvm][unittests] Don't call raw_string_ostream::flush() (NFC)

raw_string_ostream::flush() is essentially a no-op (also specified in docs).
Don't call it in tests that aren't meant to test 'raw_string_ostream' itself.

p.s. remove a few redundant calls to raw_string_ostream::str()

show more ...

[Support] Fix LEB128 test when building with MSVC (#93184)

The VALUE expansion might be compiled in the different ways, because of
string pooling which isn't always enabled/guaranteed. When buildin

[Support] Fix LEB128 test when building with MSVC (#93184)

The VALUE expansion might be compiled in the different ways, because of
string pooling which isn't always enabled/guaranteed. When building with
MSVC, previously I was seeing for example empty strings `""` pointing to
different addresses, thus the negative offsets below in the log.

Previous test log:
```
Note: Google Test filter = LEB128Test.DecodeInvalidULEB128
[==========] Running 1 test from 1 test suite.
[----------] Global test environment set-up.
[----------] 1 test from LEB128Test
[ RUN ] LEB128Test.DecodeInvalidULEB128
C:\src\git\llvm-project\llvm\unittests\Support\LEB128Test.cpp(167): error: Expected equality of these values:
0u
Which is: 0
Value - reinterpret_cast<const uint8_t *>("")
Which is: -5

C:\src\git\llvm-project\llvm\unittests\Support\LEB128Test.cpp(168): error: Expected equality of these values:
1u
Which is: 1
Value - reinterpret_cast<const uint8_t *>("\x80")
Which is: -167

C:\src\git\llvm-project\llvm\unittests\Support\LEB128Test.cpp(171): error: Expected equality of these values:
9u
Which is: 9
Value - reinterpret_cast<const uint8_t *>("\x80\x80\x80\x80\x80\x80\x80\x80\x80\x02")
Which is: -167

C:\src\git\llvm-project\llvm\unittests\Support\LEB128Test.cpp(172): error: Expected equality of these values:
10u
Which is: 10
Value - reinterpret_cast<const uint8_t *>("\x80\x80\x80\x80\x80\x80\x80\x80\x80\x80\x02")
Which is: -166

[ FAILED ] LEB128Test.DecodeInvalidULEB128 (2 ms)
[----------] 1 test from LEB128Test (2 ms total)

[----------] Global test environment tear-down
[==========] 1 test from 1 test suite ran. (4 ms total)
[ PASSED ] 0 tests.
[ FAILED ] 1 test, listed below:
[ FAILED ] LEB128Test.DecodeInvalidULEB128

1 FAILED TEST
```

show more ...

[Support] Add end/error to decode[US]LEB128AndInc

Follow-up to #85739 to encourage error checking. We make `end` mandatory
and add decodeULEB128AndIncUnsafe to be used without `end`.

Pull Request:

[Support] Add end/error to decode[US]LEB128AndInc

Follow-up to #85739 to encourage error checking. We make `end` mandatory
and add decodeULEB128AndIncUnsafe to be used without `end`.

Pull Request: https://github.com/llvm/llvm-project/pull/90006

show more ...

[Support] Add decodeULEB128AndInc/decodeSLEB128AndInc

Many decodeULEB128/decodeSLEB128 users need to increment the pointer.
Add helpers to simplify this common pattern. We don't add `end` and
`error

[Support] Add decodeULEB128AndInc/decodeSLEB128AndInc

Many decodeULEB128/decodeSLEB128 users need to increment the pointer.
Add helpers to simplify this common pattern. We don't add `end` and
`error` parameters at present because many users don't need them.

Pull Request: https://github.com/llvm/llvm-project/pull/85739

show more ...

[unittest][Support] Fix bad negation of signed integer in LEB128Test.SLEB128Size (#72700)

I came across an undefined behavior when running Support unit tests with
UBSAN on Windows.
```bash
[ RUN

[unittest][Support] Fix bad negation of signed integer in LEB128Test.SLEB128Size (#72700)

I came across an undefined behavior when running Support unit tests with
UBSAN on Windows.
```bash
[ RUN ] LEB128Test.SLEB128Size
C:\llvm\unittests\Support\LEB128Test.cpp:382:3: runtime error: negation of -9223372036854775808 cannot be represented in type 'long long'; cast to an unsigned type to negate this value to itself
SUMMARY: UndefinedBehaviorSanitizer: undefined-behavior C:\llvm\unittests\Support\LEB128Test.cpp:382:3 in
```

UBSAN did not report the same error on macOS, but the negation still
seemed invalid (`0x8000000000000000LL == -0x8000000000000000LL`
evaluated to `true`).
I can confirm that `-0x7fffffffffffffffLL - 1` results in the expected
value on both platforms.

show more ...

Diagnose if a SLEB128 is too large to fit in an int64_t.

Previously we'd hit UB due to an invalid left shift operand.

Also fix the WASM emitter to properly use SLEB128 encoding instead of
ULEB128 e

Diagnose if a SLEB128 is too large to fit in an int64_t.

Previously we'd hit UB due to an invalid left shift operand.

Also fix the WASM emitter to properly use SLEB128 encoding instead of
ULEB128 encoding for signed fields so that negative numbers don't
result in overly-large values that we can't read back any more.

In passing, don't diagnose a non-canonical ULEB128 that fits in a uint64_t but
has redundant trailing zero bytes.

Reviewed By: dblaikie, aardappel

Differential Revision: https://reviews.llvm.org/D95510

show more ...

[llvm/Support] Don't crash on empty nullptr ranges when decoding LEBs

Summary:
If the decoding functions are called with both start and end pointers
being nullptr, the function will crash due to a n

[llvm/Support] Don't crash on empty nullptr ranges when decoding LEBs

Summary:
If the decoding functions are called with both start and end pointers
being nullptr, the function will crash due to a nullptr dereference.
This happens because the function does not recognise nullptr as a valid
end pointer.

Obviously, nobody is going to pass null pointers here deliberately, but
it can happen indirectly (as it did for me), when calling these
functions on an ArrayRef, as a default-initialized empty ArrayRef will
have both begin() and end() pointers equal to nullptr.

The fix is to simply remove the nullptr check. Passing nullptr for "end"
with a valid "begin" pointer will still work, as one cannot reach
nullptr by incrementing a valid pointer without triggerring UB.

Reviewers: dblaikie

Subscribers: llvm-commits

Tags: #llvm

Differential Revision: https://reviews.llvm.org/D77304

show more ...

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the ne

Update the file headers across all of the LLVM projects in the monorepo
to reflect the new license.

We understand that people may be surprised that we're moving the header
entirely to discuss the new license. We checked this carefully with the
Foundation's lawyer and we believe this is the correct approach.

Essentially, all code in the project is now made available by the LLVM
project under our new license, so you will see that the license headers
include that license only. Some of our contributors have contributed
code under our old license, and accordingly, we have retained a copy of
our old license notice in the top-level files in each project and
repository.

llvm-svn: 351636

show more ...

Change encodeU/SLEB128 to pad to certain number of bytes

Previously the 'Padding' argument was the number of padding
bytes to add. However most callers that use 'Padding' know
how many overall bytes

Change encodeU/SLEB128 to pad to certain number of bytes

Previously the 'Padding' argument was the number of padding
bytes to add. However most callers that use 'Padding' know
how many overall bytes they need to write. With the previous
code this would mean encoding the LEB once to find out how
many bytes it would occupy and then using this to calulate
the 'Padding' value.

See: https://reviews.llvm.org/D36595

Differential Revision: https://reviews.llvm.org/D37494

llvm-svn: 313393

show more ...

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consi

Re-sort #include lines for unittests. This uses a slightly modified
clang-format (https://reviews.llvm.org/D33932) to keep primary headers
at the top and handle new utility headers like 'gmock' consistently with
other utility headers.

No other change was made. I did no manual edits, all of this is
clang-format.

This should allow other changes to have more clear and focused diffs,
and is especially motivated by moving some headers into more focused
libraries.

llvm-svn: 304786

show more ...

[Support] Extend SLEB128 encoding support.

Add support for padded SLEB128 values, and support for writing SLEB128
values to buffers rather than to ostreams, similar to the existing
ULEB128 support.

[Support] Extend SLEB128 encoding support.

Add support for padded SLEB128 values, and support for writing SLEB128
values to buffers rather than to ostreams, similar to the existing
ULEB128 support.

llvm-svn: 294675

show more ...

[Support] add decodeSLEB128()

We already have routines to encode SLEB128 as well as encode/decode ULEB128.
This last function fills out the matrix. I'll need this for some llvm-objdump
work I am do

[Support] add decodeSLEB128()

We already have routines to encode SLEB128 as well as encode/decode ULEB128.
This last function fills out the matrix. I'll need this for some llvm-objdump
work I am doing.

llvm-svn: 217830

show more ...

[Support] Fix the overflow bug in ULEB128 decoding.

Differential Revision: http://reviews.llvm.org/D5029

llvm-svn: 216268

Move get[S|U]LEB128Size() to LEB128.h.

This commit moves getSLEB128Size() and getULEB128Size() from
MCAsmInfo to LEB128.h and removes some copy-and-paste code.

Besides, this commit also adds some u

Move get[S|U]LEB128Size() to LEB128.h.

This commit moves getSLEB128Size() and getULEB128Size() from
MCAsmInfo to LEB128.h and removes some copy-and-paste code.

Besides, this commit also adds some unit tests for the LEB128
functions.

llvm-svn: 201937

show more ...