Skip to content

GitLab

  • Menu
Projects Groups Snippets
    • Loading...
  • 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,828
    • Issues 4,828
    • List
    • Boards
    • Service Desk
    • Milestones
    • Iterations
  • Merge requests 447
    • Merge requests 447
  • CI/CD
    • CI/CD
    • Pipelines
    • Jobs
    • Schedules
    • Test Cases
  • Deployments
    • Deployments
    • Releases
  • Analytics
    • Analytics
    • CI/CD
    • Code review
    • Insights
    • Issue
    • Repository
    • Value stream
  • Wiki
    • Wiki
  • Snippets
    • Snippets
  • Activity
  • Graph
  • Create a new issue
  • Jobs
  • Commits
  • Issue Boards
Collapse sidebar
  • Glasgow Haskell Compiler
  • GHCGHC
  • Issues
  • #10518

Closed
Open
Created Jun 13, 2015 by Sergei Trofimovich@trofiReporter

unregisterised GHC generates incorrect 0xUL literals for certain onstants

jakzale reports: 21:47:27 < int-e> Oh, nice. Yes, indeed pprHexVal (2^32^) W32 (function from cmm/PprC.hs) would result in 0xU. 21:50:29 < jakzale> int-e: yes, truncInt takes module 2^32^, then go returns empty string (I guess)

Here comes the test:

$ cat a.cmm

foo() {
    bits64 a;
    a = 0x10000000000000000; // overflows 64 bits
    return (a);
}

$ inplace/bin/ghc-stage2 -c a.cmm
/tmp/ghc8580_0/ghc_2.hc: In function 'foo':

/tmp/ghc8580_0/ghc_2.hc:8:7: error:
     error: invalid suffix "xUL" on integer constant
     _c0 = 0xUL;
           ^

I've broke it with commit:43f1b2ec when introduced truncation that can generate more zeroes.

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