[HN Gopher] GHC 9.4.2 regresses being able to do math on aarch64
___________________________________________________________________
GHC 9.4.2 regresses being able to do math on aarch64
Author : nequo
Score : 92 points
Date : 2022-10-12 13:48 UTC (9 hours ago)
(HTM) web link (gitlab.haskell.org)
(TXT) w3m dump (gitlab.haskell.org)
| carterschonwald wrote:
| Ouch, this is a nasty bug. Looks like it's a secondary
| consequence of some arm specific issue in the 9.4 support for
| sized word primitive unlifted types. Good thing folks caught it
| relatively early in the life cycle of ghc 9.4! (Ghc 8.10.7 is the
| most recent bug fix release in the 8.10 series, and I try to make
| sure I support it in my own hackery)
|
| This looks to have a pretty straightforward fix hopefully.
|
| In the space of miscompilation bugs this seems pretty easy to
| catch. A pretty nasty one happened in ghc 7.6/7.8 , where the
| register allocator didn't realize float and double registers were
| the same registers, so code that mixed the type had total
| garbage!
| ysangkok wrote:
| Interesting property test proposed which would catch this:
| https://gitlab.haskell.org/ghc/ghc/-/merge_requests/9149/dif...
| sidkshatriya wrote:
| Sometimes when a codebase becomes too complex to comprehend, it
| starts failing in embarrassing ways.
|
| It is time to ask if GHC itself has become too complicated.
| whateveracct wrote:
| I hate this kind of talk. Feels very FUD-y to me.
|
| It isn't time to ask that question though. At least, I don't
| think so and I've been using GHC Haskell for a decade now and
| for many different commercial use-cases to boot.
| nh23423fefe wrote:
| yeah zero value question. empty assertions of complexity and
| complication with faux modesty of just asking questions.
| sidkshatriya wrote:
| Complexity is positively correlated with bugs. Many studies
| have shown that.
|
| GHC is complex, perhaps too complex. I don't track GHC
| closely but it seems GHC does seem to suffer from more than
| a fair share of embarrassing compilation bugs. This feeling
| is derived anecdotally so I may be wrong. Happy to be
| corrected.
|
| Someone more conversant with GHC will have to chime in and
| agree/disagree. Don't let your love of Haskell get in the
| way of providing an objective opinion :-)
| remram wrote:
| This happens in a released version? Without tests catching it?
| chowells wrote:
| Would your aarch64 test suite have caught it? Testing is fine
| and all, but it can only find bugs the test authors predicted.
| There will always be some issues that test suites miss.
|
| It's obvious to add regression tests for this and related
| issues now that they've been found. And great! That's what
| regression tests are for. But testing is always going to be
| fundamentally incomplete in that it can only cover non-obvious
| things after they've already been encountered.
| remram wrote:
| The issue is that basic math doesn't work. I don't dispute
| that no test suite can catch everything, but yes I do expect
| that any reasonable test suite that compiles and runs code
| would have caught this.
| Dylan16807 wrote:
| Basic math that does multiple operations on the same 8 or
| 16 bit value.
| gus_massa wrote:
| I agree.
|
| I'm still confused, but I hope this is correct. IIUC the
| problem here is that they do something like
| (a // b ) * b
|
| where // is the integer division. They are not breaking
| all math operations, just math operations that have a
| very specific pattern.
|
| Also, I'm not sure if it's important that 128 <= b <=
| 255, because the main problem seams to be they are
| extending a number and the leading 1 in the binary
| representation is a problem (???).
|
| So you must test a very specific math pattern, with very
| specific numbers, and then hope that other parts of the
| optimizer don't optimize the problem away before the bug
| in the compiler makes a mistake.
|
| I don't know too much about the automatic test suit in
| Haskell, but I know more about the automatic test suit in
| Racket. In Racket there are a lot of test written
| manually, and some randomized test, and also tests for
| many of the packages. But I really doubt there is a test
| somewhere for this specific case.
|
| [Is there a cross language regression test collection?
| Something that collects weird cases, so other languages
| maintainers can take a look, translate the code and add
| it to the tests.]
| mort96 wrote:
| I would've expected a compiler to have a huge
| integration/regression test suite which just consists of
| other pieces of software's test suites. Grab the N most
| popular Haskell programs with test suites, compile them, run
| their test suites, verify that they still pass on the new
| version.
| sandermvanvliet wrote:
| Isn't rust doing something like that? Can't seem to find
| the article right now but I remember reading something
| about this approach.
| estebank wrote:
| > Crater is a tool for compiling and running tests for
| every crate on crates.io (and a few on GitHub). It is
| mainly used for checking the extent of breakage when
| implementing potentially breaking changes and ensuring
| lack of breakage by running beta vs stable compiler
| versions.
|
| https://rustc-dev-guide.rust-lang.org/tests/crater.html
|
| https://github.com/rust-lang/crater
|
| https://crater.rust-lang.org/
|
| Even then such a bug as GHC's can conceivably not be
| detected.
| moomin wrote:
| It would be much harder to achieve this with GHC since
| the package manager is far from deterministic.
| steveklabnik wrote:
| Yes, "crater" is the name of the tool.
| whateveracct wrote:
| nixpkgs
| Confiks wrote:
| Issue created 3 months ago [1]:
|
| "CCall testsuite doesn't test `signed` arguments and results.
| This would have helped catch [a previous ghc regression on
| aarch64]".
|
| https://gitlab.haskell.org/ghc/test-primops/-/issues/3
| T-R wrote:
| Alexis also just posted a video on the GHC optimization pipeline:
|
| https://www.youtube.com/watch?v=fdyh3YQ-ZWI
| NextHendrix wrote:
| Are there significant projects that run Haskell on arm
| specifically? Smartphone apps or just new Macs?
| lynguist wrote:
| Almost every newly deployed datacenter CPU is ARM.
| hardwaresofton wrote:
| Do you have a source on this? Would love to learn how much
| this has shifted...
___________________________________________________________________
(page generated 2022-10-12 23:01 UTC)