1. 12 Oct, 2019 2 commits
    • Vladislav Zavialov's avatar
      Escape stats file command (#13676) · f1ce3535
      Vladislav Zavialov authored
      f1ce3535
    • John Ericson's avatar
      Simplify Configure in a few ways · c2290596
      John Ericson authored
       - No need to distinguish between gcc-llvm and clang. First of all,
         gcc-llvm is quite old and surely unmaintained by now. Second of all,
         none of the code actually care about that distinction!
      
         Now, it does make sense to consider C multiple frontends for LLVMs in
         the form of clang vs clang-cl (same clang, yes, but tweaked
         interface). But this is better handled in terms of "gccish vs
         mvscish" and "is LLVM", yielding 4 combinations. Therefore, I don't
         think it is useful saving the existing code for that.
      
       - Get the remaining CC_LLVM_BACKEND, and also TABLES_NEXT_TO_CODE in
         mk/config.h the normal way, rather than hacking it post-hoc. No point
         keeping these special cases around for now reason.
      
       - Get rid of hand-rolled `die` function and just use `AC_MSG_ERROR`.
      
       - Abstract check + flag override for unregisterised and tables next to
         code.
      
      Oh, and as part of the above I also renamed/combined some variables
      where it felt appropriate.
      
       - GccIsClang -> CcLlvmBackend. This is for `AC_SUBST`, like the other
       Camal case ones. It was never about gcc-llvm, or Apple's renamed clang,
       to be clear.
      
       - llvm_CC_FLAVOR -> CC_LLVM_BACKEND. This is for `AC_DEFINE`, like the
       other all-caps snake case ones. llvm_CC_FLAVOR was just silly
       indirection *and* an odd name to boot.
      c2290596
  2. 07 Oct, 2019 1 commit
  3. 05 Oct, 2019 3 commits
    • Ben Gamari's avatar
      rts: Fix CNF dirtying logic · 241921a0
      Ben Gamari authored
      Previously due to a silly implementation bug CNFs would never have their
      dirty flag set, resulting in their being added again and again to the
      `mut_list`. Fix this.
      
      Fixes #17297.
      241921a0
    • Artem Pyanykh's avatar
      [linker, macho] Don't map/allocate zero size sections and segments · 0d31ccdd
      Artem Pyanykh authored
      Zero size sections are common even during regular build on MacOS. For
      instance:
      
      ```
      $ ar -xv libHSghc-prim-0.6.1.a longlong.o
      $ otool -l longlong.o
      longlong.o:
      Mach header
            magic cputype cpusubtype  caps    filetype ncmds sizeofcmds      flags
       0xfeedfacf 16777223          3  0x00           1     2        176 0x00002000
      Load command 0
            cmd LC_SEGMENT_64
        cmdsize 152
        segname
         vmaddr 0x0000000000000000
         vmsize 0x0000000000000000 <-- segment size = 0
        fileoff 208
       filesize 0
        maxprot 0x00000007
       initprot 0x00000007
         nsects 1
          flags 0x0
      Section
        sectname __text
         segname __TEXT
            addr 0x0000000000000000
            size 0x0000000000000000 <-- section size = 0
          offset 208
           align 2^0 (1)
          reloff 0
          nreloc 0
           flags 0x80000000
       reserved1 0
       reserved2 0
             cmd LC_BUILD_VERSION
         cmdsize 24
        platform macos
             sdk 10.14
           minos 10.14
          ntools 0
      ```
      
      The issue of `mmap`ing 0 bytes was resolved in !1050, but the problem
      remained. These 0 size segments and sections were still allocated in
      object code, which lead to failed `ASSERT(size > 0)` in
      `addProddableBlock` further down the road.
      
      With this change zero size segments **and** sections are not
      mapped/allocated at all.
      
      Test plan:
      
      1. Build statically linked GHC.
      
      2. Run `ghc --interactive`. Observe that REPL loads
      successfully (which was not the case before).
      
      3. Load several more compiled hs files into repl. No failures.
      0d31ccdd
    • John Ericson's avatar
      Per stage headers, ghc_boot_platform.h -> stage 0 ghcplatform.h · 05419e55
      John Ericson authored
      The generated headers are now generated per stage, which means we can
      skip hacks like `ghc_boot_platform.h` and just have that be the stage 0
      header as proper. In general, stages are to be embraced: freely generate
      everything in each stage but then just build what you depend on, and
      everything is symmetrical and efficient. Trying to avoid stages because
      bootstrapping is a mind bender just creates tons of bespoke
      mini-mind-benders that add up to something far crazier.
      
      Hadrian was pretty close to this "stage-major" approach already, and so
      was fairly easy to fix. Make needed more work, however: it did know
      about stages so at least there was a scaffold, but few packages except
      for the compiler cared, and the compiler used its own counting system.
      That said, make and Hadrian now work more similarly, which is good for
      the transition to Hadrian. The merits of embracing stage aside, the
      change may be worthy for easing that transition alone.
      05419e55
  4. 03 Oct, 2019 3 commits
    • Stefan Schulze Frielinghaus's avatar
      Extend argument of createIOThread to word size · d0924b15
      Stefan Schulze Frielinghaus authored
      Function createIOThread expects its second argument to be of size word.
      The natural size of the second parameter is 32bits. Thus for some 64bit
      architectures, where a write of the lower half of a register does not
      clear the upper half, the value must be zero extended.
      d0924b15
    • Tobias Guggenmos's avatar
      Add new debug flag -DZ · 47386fe8
      Tobias Guggenmos authored
      Zeros heap memory after gc freed it.
      47386fe8
    • Ömer Sinan Ağacan's avatar
      Fix new compact block allocation in allocateForCompact · 8a254d6b
      Ömer Sinan Ağacan authored
      allocateForCompact() is called when nursery of a compact region is
      full, to add new blocks to the compact. New blocks added to an existing
      region needs a StgCompactNFDataBlock header, not a StgCompactNFData.
      
      This fixes allocateForCompact() so that it now correctly allocates space
      for StgCompactNFDataBlock instead of StgCompactNFData as before.
      
      Fixes #17044.
      
      A regression test T17044 added.
      8a254d6b
  5. 25 Sep, 2019 1 commit
  6. 22 Sep, 2019 30 commits