Skip to content

GitLab

  • Menu
Projects Groups Snippets
  • Help
    • Help
    • Support
    • Community forum
    • Submit feedback
  • Sign in / Register
  • GHC GHC
  • Project information
    • Project information
    • Activity
    • Labels
    • Members
  • Repository
    • Repository
    • Files
    • Commits
    • Branches
    • Tags
    • Contributors
    • Graph
    • Compare
    • Locked Files
  • Issues 4,977
    • Issues 4,977
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 479
    • Merge requests 479
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • Value stream
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #9315
Closed
Open
Created Jul 14, 2014 by Joachim Breitner@nomeataDeveloper

Weird change in allocation numbers of T9203

While trying to improve our handle on allocation numbers, I’m stuck with the test case T9203. On some machines, it allocates roughly 95747304 bytes (this includes travis and my laptop), on others 42946176 bytes (e.g. on the machine where I monitor benchmark performance). All machines are 64 bit Linux machines.

The output of -ddump-simpl, -ddump-stg and -ddump-cmm is identical (up to variable names). Even -ddump-asm looks the same, besides some jump target reordering. The binary runs too small to get a heap profile.

I’m a bit stuck here: What can be the cause for these differences?

(BTW, if have an up-to-date GHC tree, can you report the number you get? Run make -C testsuite VERBOSE=4 TEST=T9203 for that.)

Edited Mar 09, 2019 by jrp2014
To upload designs, you'll need to enable LFS and have an admin enable hashed storage. More information
Assignee
Assign to
Time tracking