- Dec 09, 2021
-
-
Alexis King authored
-
- Dec 08, 2021
-
-
Alexis King authored
* wip: Add ArrowEnv, ArrowStackTup, and ArrowEnvTup * wip: Use arrow wired-in families in typechecker * Rewrite arrow desugaring * Fix some arrow typing issues * Fix most of the remaining arrow tests * Reorganize arrow-related modules * Tidy up a few comments * Accept new type error output for now I want to improve the type error involving ArrowStackTup to hide the family from the error message, but that can come later. * Accept some more modified error output in tests These mostly arise from making Either a wired-in type. * Update two test cases for new control operator typing * Expand the wired-in arrow type families in type errors I am not sure that this is really the right place to do this expansion. It seems like it should probably go in the tidying/printing code, but it would be a significant expansion of the responsibility of tidying, so I don’t know if that makes sense yet. I will probably change this later. * Rename a few things and add some new Notes * Add another Note; rename some things; various minor refactorings
-
- Dec 03, 2021
- Dec 02, 2021
-
-
These generally expect a particular word size.
-
C11 rule 6.3.1.1 dictates that all small integers used in expressions be implicitly converted to `signed int`. However, Cmm semantics require that the width of the operands be preserved with zero-extension semantics. For this reason we must recast sub-word arithmetic results as unsigned.
-
As noted in Note [When in doubt, cast arguments as unsigned], we must ensure that arguments have the correct signedness since some operations (e.g. `%`) have different semantics depending upon signedness.
-
As noted in Note [Zero-extending sub-word signed results] we must explicitly zero-extend the results of sub-word-sized signed operations.
-
Under C's implicit widening rules, the result of an operation like (a >> b) where a::Word8 and b::Word will have type Word, yet we want Word.
-
Here we rework the handling of sub-word operations in the AArch64 backend, fixing a number of bugs and inconsistencies. In short, we now impose the invariant that all subword values are represented in registers in zero-extended form. Signed arithmetic operations are then responsible for sign-extending as necessary. Possible future work: * Use `CMP`s extended register form to avoid burning an instruction in sign-extending the second operand. * Track sign-extension state of registers to elide redundant sign extensions in blocks with frequent sub-word signed arithmetic.
-
This is necessary for lint-correctness since we no longer allow such shifts in Cmm.
-
We might be loading, e.g., a 16- or 8-bit value, in which case the register width is not reflective of the loaded element size.
-
There were found by the test-primops testsuite.
-
Previously primops.txt.pp stipulated that the word-size shift primops were only defined for shift offsets in [0, word_size). However, there was no further guidance for the definition of Cmm's sub-word size shift MachOps. Here we fix this by explicitly disallowing (checked in many cases by CmmLint) shift operations where the shift offset is larger than the shiftee. This is consistent with LLVM's shift operations, avoiding the miscompilation noted in #20637.
-
Previously we would emit the sign-extending LDS[HB] instructions for sub-word loads. However, this is wrong, as noted in #20638.
-
Previously the constant-folding behavior for MO_S_Quot and MO_S_Rem failed to narrow its arguments, meaning that a program like: %zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8)) would be miscompiled. Specifically, this program should reduce as %lobits8(0x00e1::bits16) == -31 %quot(%lobits8(0x00e1::bits16), 3::bits8) == -10 %zx64(%quot(%lobits8(0x00e1::bits16), 3::bits8)) == 246 However, with this bug the `%lobits8(0x00e1::bits16)` would instead be treated as `+31`, resulting in the incorrect result of `75`. (cherry picked from commit 94e197e3)
-
Handle the case of a shift larger than the width of the shifted value. This is necessary since x86 applies a mask of 0x1f to the shift amount, meaning that, e.g., `shr 47, $eax` will actually shift by 47 & 0x1f == 15. See #20626. (cherry picked from commit 31370f1a)
- Dec 01, 2021
-
-
Previously TSAN would report spurious data races due to the unsynchronized access of `exited`. I would have thought that using a relaxed load on `exited` would be enough to convince TSAN that the race was intentional, but apparently not. Closes #20690.
-
This makes a few things cleaner.
-
This ensures quiet configuring works.
-
When we give cabal a configure script, it seems to begin checking whether or not Stg.h is valid, and then gets tripped up on all the register stuff which evidentally requires obscure command line flags to go. We can side-step this by making the test header Rts.h instead, which is more normal. I was a bit sketched out making this change, as I don't know why the Cabal library would suddenly beging checking the header. But I did confirm even without my RTS configure script the header doesn't compile stand-alone, and also the Stg.h is a probably-arbitrary choice since it dates all the way back to 2002 in 2cc5b907.
-
-
This fixes the ./validate script on my machine. I also took the step to add some linters which would catch problems like these in future. Fixes #20506
-
As requested in #20702
-
As suggested in #20733.
-
-
Closes #20504.
-
-
Improve documentation, bump bounds and cabal-version.
-
Otherwise we end up with issues like #19631 when bootstrapping using GHC 9.2 and above. Fixes #19631.
-
Previously we could in some cases add empty paths to `cc`'s include file search path. See #20578.
-
Previously we relied on Sym_NeedsProto, but this gave the symbol a type which conflicts with the definition that may be provided by unistd.h. Fixes #20577.
-
A manual job for testing the non-tables-next-to-code configuration.
-
The goal here is to make the SRT selection logic a bit clearer and allow configurations which we currently don't support (e.g. using a full word in the info table even when TNTC is used).