libstdc++'s |memcpy| and |memset| both state that their inputs should
never be a nullptr since this matches the C spec. Some compilers act on
these hints, so we shouldn't unconditionally call these as it would
signal to the compiler that they can't be nullptrs.
As an example, the following code will always call |do_something()|
when compiled with optimisations since GCC version 4.9:
```
void clear(void *ptr, int size) {
memset(ptr, 0, size);
}
void example(void *ptr, int size) {
clear(ptr, size);
if (ptr != nullptr) do_something();
}
```
The result of a left shift on a positive signed integer (Rune) must fit
into an unsigned integer otherwise it's undefined behaviour, as is left
shifting a negative integer by any amount. This code can only be hit if
|x >= 0xf0| and hence a left shift of 31 will always be undefined
unless the input is 0 or 1.
To avoid hitting this we can instead extend the lowest bit to be the
mask if we assume that ints are 2's complement, which we already do
elsewhere. This generates identical code in testing on Compiler
Explorer and the Odin test suite passes locally with this change.
Note that the original code would change to be defined behaviour in
C++20, however we are currently build with |-std=c++14| in the build
scripts.
If |result_count| is 0 then |results| will be a nullptr and hence the
access |results->Tuple| is undefined behaviour. There's already an
early return in the 0 branch so move that to be the first thing so that
we can guarantee that it's not a nullptr.
Note that technically we take the address of the result so it's not
actually dereferencing it, however UBSan doesn't care about that.
UBSan spotted that |src->Basic.kind| had a value outside the range of
|BasicKind| due to it actually being a |Type_Pointer|. Since these are
stored in a union there could be cases where the value of |kind| just
so happens to be |Basic_string|, in which case the branch would have
been taken when it shouldn't have been.
To fix this simply check that it's a |Type_Basic| before treating it as
a |Basic|.
For utterly unrealistic constant sizes, this still crashes on my system,
but it crashes fast due to the OOM killer, and people using rediculously
large exponents get what they deserve.
Do not memory map files; Windows cannot write to a file that is memory
mapped.
Write cache after llvm building. This ensures the cache won't have a
false positive if llvm fails.
gingerBill
jakubtomsu
Laytan Laats
bayo-code
Jeroen van Rijn
Morten Hauke Solvang
Dominik Pötzschke
0dminnimda
peachey2k2
bobsayshilol
Yawning Angel
Misomosi
Lucas Perlind