#15068: Small number of test case failures on Ubuntu Bionic (GCC 7.3) -------------------------------------+------------------------------------- Reporter: jrp | Owner: (none) Type: bug | Status: merge Priority: highest | Milestone: 8.6.1 Component: Compiler | Version: 8.4.1 (CodeGen) | Resolution: fixed | Keywords: Operating System: Linux | Architecture: x86_64 | (amd64) Type of failure: Incorrect result | Test Case: T13658 at runtime | T14779a T14779b T14868 debug | parsing001 Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D4654 Wiki Page: | -------------------------------------+------------------------------------- Comment (by hvr): Sven, I still believe you're not seeing the point I'm making and trying to get back into a line of argument that's besides the point (don't get me started on the validity of those "statistics" you quote) and would only detract from the technical arguments that are pertinent to this issue. Please stop bringing up the irrelevant claims about Stack's (questionable) popularity and thus Stack would be too-big-to-fail that we have to adjust the surrounding ecosystem to Stack's needs, or even your (questionable) subjective perception about what a "happy Haskell life" constitutes, unless you really want me to get into an extended off-topic rant about of Stack's negative impact on Haskell's ecosystem and community and now even reaching into teaching (e.g. the popular data61 fp-course publicly getting attacked and its course materials even forked over Stack ideology)... But let's try to get back on-topic. Maybe I'm not explaining myself well enough to get across the technical point, that rushing a GHC 8.4.3 quickfix just to workaround bad decisions made in Stack won't be enough and that Stack will need to address this on their end or Stack users will be still be "broken" with GHC 8.2.1, 8.2.2, 8.4.1 and 8.4.2 based install- plans on their end; and that we should rather focus our limited resources on letting GHC 8.4.2 mature a bit more (which is essentially a quickfixed/proper GHC 8.4.1 which is what some communities would declare a "NUKED" release; iow, for all practical purposes GHC 8.4.1 should be considered as if it never happened). To summarise, this bug has been present in GHC since GHC 8.2.1. If we follow your logic, Stack's mere existence would require us to make a GHC 8.2.3 point release as well rather than to fix this in Stack, in order not to leave those unfortunate GHC 8.2/Stack/Ubuntu18 users out in the rain. Moreover, the most principled and thus recommended way to install and manage GHC on Debian or Ubuntu if you need a version that's not packaged by Debian/Ubuntu is via the instructions mentioned on http://downloads.haskell.org/debian/ which provides non-generic bindists specifically configured and built for the respective distribution release (this may not be so relevant on OSX or Windows, but for Linux's ABI compat story it is); this btw also means that a redundant(!) GHC 8.4.3 release would cause me a lot of busy work to "fix" something that my packaging doesn't even suffer from as I'd need to package up 8.4.3 and build it for various non-EOL'ed distros; not to mention I'd have to scrap the rather costly/time-consuming builds of a GHC 8.4.2 bindist for AIX I was working on, and start over w/ GHC 8.4.3, as well as having to carefully prepare Hackage releases of a couple GHC bootlibs and their associated Haddocks. Finally, this doesn't affect non-Stack users, unless they are on a just released Ubuntu 18 release (NB: there's currently 3 LTS releases of Ubuntu that aren't EOL'ed; nobody is forced to use the still very infantly young new Ubuntu LTS yet) *and* don't use the packages provided either by Ubuntu or by my Ubuntu PPA (or aren't capable of building GHC from source) *and* use a non-default flag which is only relevant if you actually intend and know how to debug a Haskell program at a low-level via a debugger such as GDB. I seriously doubt this is a large enough group of people to demand this urgency. I for one I can't use (nor do I recommend) using GHC 8.4.x for anything mission critical until it has matured at least 2 more months and seen more field testing, and we've had time to accumulate fixes and release a non-redundant GHC 8.4.3 with those, to get it to the same level of confidence the GHC 8.2.2 release has. I've already written more about this that I wanted to; I haven't heard any compelling reason yet that would justify rushing a redundant GHC 8.4.3 release only to keep Stack from fixing its bad choice of defaults. This is like asking to move a mountain because you don't feel like going around it. I'd rather want to see a GHC 8.4.3 released shortly before its support-window closes (which is in a couple months from now when GHC 8.6 becomes a thing), and releasing a GHC 8.4.3 now would make it more likely we won't see a GHC 8.4.4, thereby leaving us with a potentially less- reliable GHC 8.4.3 than it would be if it had had more time to mature and collect more fixes. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/15068#comment:33 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler