#10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: new Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1170 -------------------------------------+------------------------------------- Changes (by erikd): * differential: => Phab:D1170 -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10791#comment:2> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: patch Priority: normal | Milestone: 7.12.1 Component: Build System | Version: 7.11 Resolution: | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Revisions: Phab:D1170 -------------------------------------+------------------------------------- Comment (by Erik de Castro Lopo <erikd@…>): In [changeset:"fba724ccabd295fc37e71ba6c4f892822a831d19/ghc" fba724cc/ghc]: {{{ #!CommitTicketReference repository="ghc" revision="fba724ccabd295fc37e71ba6c4f892822a831d19" configure.ac: Allow disabling of large-address-space Recent changes (commit 0d1a8d09f4) for 64 bit platforms allowed GHC to mmap one huge (currently 1 terrabyte) memory region from which to do its own allocations. This is enabled by default, but it would be nice (even just from the point of view of testing) to be able to disable this at configure time. Test Plan: configure and grep mk/config.h for USE_LARGE_ADDRESS_SPACE Reviewers: austin, ezyang, bgamari, rwbarton Subscribers: thomie Differential Revision: https://phabricator.haskell.org/D1170 GHC Trac Issues: #10791 }}} -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10791#comment:4> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler

#10791: Add a --disable-large-memory-space configure option -------------------------------------+------------------------------------- Reporter: erikd | Owner: erikd Type: feature request | Status: closed Priority: normal | Milestone: 8.0.1 Component: Build System | Version: 7.11 Resolution: fixed | Keywords: Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: None/Unknown | Test Case: Blocked By: | Blocking: Related Tickets: | Differential Rev(s): Phab:D1170 Wiki Page: | -------------------------------------+------------------------------------- Comment (by Ericson2314): This code is very hard to read, and the behavior very hard to intuit. - Folding together the `=yes` and no-flag case *outside* the `"$ac_cv_sizeof_void_p" -eq 8` branch falsely implies the default is unconditionally/constantly true. - `=yes` will be silently ignored on non-Darwin if the test doesn't pass. - Ignoring `--enable/disable-large-address-space` on 32-bit is more harmful than helpful. The fact is, most (all?) people blindly cargo cult and copy paste configure flags, and this will give them a false intuition. (Postel's law hurts us by hiding bugs with gratuitous complexity.) Crucially and unlike many such similar things, it's not necessary for backwards compatibility since this flag is new. Granted, I could be persuaded on the 3rd point that on 32-bit the large and small address spaces both morally exist but are the same, rather than the large one not existing, so the laxer handling of the flags is justified. But, at the very least a warning is due on the ignored/superfluous flags, and the code restructured to properly separate sanitizing user input, checking whether expectations are met, and providing a default value. Sorry to lash out on random 3 year old issue, but this is a perfect example of the sort of "diff golf" / incremental change that leads to impenetrable and every-growing configure scripts (or build systems in general). 5 minutes of what might seem silly OCD by the original author cleaning up what's there can save far more time for the next person. And in fact, writing a truth table a is great first step, without which I would have spent longer being confused. -- Ticket URL: <http://ghc.haskell.org/trac/ghc/ticket/10791#comment:7> GHC <http://www.haskell.org/ghc/> The Glasgow Haskell Compiler