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 :-)
GHC is indeed a large piece of software and, like all software, has its share of bugs. Some of these bugs are indeed attributable to GHC's complexity or, rather, the complexity of its domain: compiling high-level languages to efficient machine code is not easy. To determine whether GHC is too complex we need a definition of what constitutes "too complex". I think a reasonable definition would be "too complex to be managed via abstraction". In general I think GHC does a reasonably good job here. There is a reason why Haskell programs passes through four different intermediate languages as it works its way through GHC. Each of these languages, and associated compiler passes, can focus on a specific set of needs constrained by a specific set of invariants.
Where this approach to encapsulating complexity can fall short is where we must maintain hard-to-check relationships between the state of the machine at runtime and the compiler. This is the source of many of the bugs which are most readily attributable to GHC's complexity (e.g. [#13615](https://gitlab.haskell.org/ghc/ghc/-/issues/13615) and [#14346](https://gitlab.haskell.org/ghc/ghc/-/issues/14346) come to mind here).
However, the sign-extension issue noted in this thread is, in my opinion, not one of these issues. In many ways it is a very boring bug, arising from a simple misunderstanding of the semantics of a function in the code generator (namely, that `getSomeReg` isn't guaranteed to return a fresh local register). There are a number of ways that this could have been caught: better code review, more thorough tests, better use of type safety in the backend. It's certainly an serious (and, frankly, embarrassing) bug, but I don't think it is a sign that the compiler has accrued more complexity than can be managed.
This is reductive thinking under the guise of "objectivity" imo.
What does "complex" even mean here? How do you measure it or quantify it? You can't - and then your "objective" house of cards comes tumbling down. You can't correlate anything with hand waves.
GHC is doing fine. I say this as someone more tuned into it than you. Moralizing and catastrophizing about this bug is a waste of everyone's time. The bug is fixed, the process inefficiencies that contributed to it happening are being corrected. It's software development 101.
do you feel the same way about other libraries or software? Do you have reasoning that you can articulate that GHC is unnecessarily complex in ways that other comparable software is not?
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 :-)