From simon.peytonjones at gmail.com Mon Sep 5 16:24:48 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 5 Sep 2022 17:24:48 +0100 Subject: CI failures Message-ID: Matthew, Ben, Bryan CI is failing in in "lint-ci-config".. See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8916 or https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7847 What's up? Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Sep 5 16:48:03 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 05 Sep 2022 12:48:03 -0400 Subject: CI failures In-Reply-To: References: Message-ID: <878rmxlqdp.fsf@smart-cactus.org> Simon Peyton Jones writes: > Matthew, Ben, Bryan > > CI is failing in in "lint-ci-config".. > > See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8916 > or https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7847 > I'll investigate. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Mon Sep 5 17:11:12 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 05 Sep 2022 13:11:12 -0400 Subject: CI failures In-Reply-To: <878rmxlqdp.fsf@smart-cactus.org> References: <878rmxlqdp.fsf@smart-cactus.org> Message-ID: <875yi1lpba.fsf@smart-cactus.org> Ben Gamari writes: > Simon Peyton Jones writes: > >> Matthew, Ben, Bryan >> >> CI is failing in in "lint-ci-config".. >> >> See https://gitlab.haskell.org/ghc/ghc/-/merge_requests/8916 >> or https://gitlab.haskell.org/ghc/ghc/-/merge_requests/7847 >> > I'll investigate. > I believe this should be fixed by !8943. Perhaps you could try rebasing on top of this? Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simon.peytonjones at gmail.com Mon Sep 5 19:33:42 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 5 Sep 2022 20:33:42 +0100 Subject: Updating haddock Message-ID: Dear devs I'm working on !8750, which has some knock-on changes that are needed on the Haddock repo. So - in the main repo I have wip/T21623 - in the utils/haddock repo have branch wip/spj-T21623 Periodically I need to rebase on master. Question: what is the Blessed Sequence of Commands that I should use to push the right changes to haddock? I think it is something like: 1. In the main GHC repo, on branch wip/T21623 1. git fetch 2. git rebase origin/master 2. In utils/haddock, 1. identify the set of patches P1..Pn between the trunk and my haddock tip, the changes that I need to haddock. 2. Somehow check out the haddock commit K that corresponds to origin/master 3. Apply P1..Pn on top of K 4. Force-push to origin/wip/spj-T21623 3. Move to the main GHC repo 1. git add utils/haddock 2. Create a patch for that change 3. Push to main repo But I am not sure how to do step 2.2, nor what is an efficient way to do 2.3. I would welcome very precise instructions. Thank you! Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon Sep 5 19:51:22 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 5 Sep 2022 20:51:22 +0100 Subject: Tags Message-ID: I love emacs' tags-query-replace function, which allows me to do a search-and-replace across an entire repo. But to do that I need a TAGS file that, at least, lists all the Hsakell files in GHC. What is the approved way to construct a TAGS file for a bunch of Haskell modules? Is this documented anywhere? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From alan.zimm at gmail.com Mon Sep 5 20:05:14 2022 From: alan.zimm at gmail.com (Alan & Kim Zimmerman) Date: Mon, 5 Sep 2022 21:05:14 +0100 Subject: Tags In-Reply-To: References: Message-ID: I generally use hasktags (install via cabal-install), and you can give it a list of directories to index. I normally do it in the GHC/compiler directory, so it has just the GHC source Alan On Mon, 5 Sept 2022 at 20:51, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > I love emacs' tags-query-replace function, which allows me to do a > search-and-replace across an entire repo. But to do that I need a TAGS > file that, at least, lists all the Hsakell files in GHC. > > What is the approved way to construct a TAGS file for a bunch of Haskell > modules? Is this documented anywhere? > > Thanks > > Simon > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Sep 5 20:19:24 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 05 Sep 2022 16:19:24 -0400 Subject: Tags In-Reply-To: References: Message-ID: <8735d5lglk.fsf@smart-cactus.org> Simon Peyton Jones writes: > I love emacs' tags-query-replace function, which allows me to do a > search-and-replace across an entire repo. But to do that I need a TAGS > file that, at least, lists all the Hsakell files in GHC. > > What is the approved way to construct a TAGS file for a bunch of Haskell > modules? Is this documented anywhere? > I haven't tried this recently on GHC but my first instinct would be to use hasktags [1]: $ cabal install hasktags $ hasktags --etags ./compiler At some point in the past I would have said that ideally Hadrian would be able to build such a thing. However, at this point TAGS files are slowly falling out of fashion in favor of language servers. Another way to reach a similar end would be to rather search-and-replace across all git-tracked files. However, somewhat surprisingly, a bit of Googling didn't turn up any easy way of accomplishing this. The closest I can find is [1]. Cheers, - Ben [1] https://emacs.stackexchange.com/questions/37286/find-and-replace-a-text-among-the-files-of-a-project -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From ben at smart-cactus.org Mon Sep 5 20:29:42 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 05 Sep 2022 16:29:42 -0400 Subject: Updating haddock In-Reply-To: References: Message-ID: <87zgfdk1jw.fsf@smart-cactus.org> Simon Peyton Jones writes: > Dear devs > > I'm working on !8750, which has some knock-on changes that are needed on > the Haddock repo. So > > - in the main repo I have wip/T21623 > - in the utils/haddock repo have branch wip/spj-T21623 > > Periodically I need to rebase on master. > > Question: what is the Blessed Sequence of Commands that I should use to > push the right changes to haddock? I think it is something like: > > > 1. In the main GHC repo, on branch wip/T21623 > 1. git fetch > 2. git rebase origin/master > > 2. In utils/haddock, > 1. identify the set of patches P1..Pn between the trunk and my haddock > tip, the changes that I need to haddock. > 2. Somehow check out the haddock commit K that corresponds to > origin/master > 3. Apply P1..Pn on top of K > 4. Force-push to origin/wip/spj-T21623 > 3. Move to the main GHC repo > 1. git add utils/haddock > 2. Create a patch for that change > 3. Push to main repo > > > But I am not sure how to do step 2.2, nor what is an efficient way to do > 2.3. > In general GHC `master` should always refer to the `ghc-head` branch in the Haddock repository. The easiest way would be to use `git rebase`. Specifically, given a history like: W --- X --- Y --- Z <-- origin/ghc-head \ \--- A --- B <-- wip/spj-T21623 Running: git rebase origin/ghc-head while on wip/spj-T21623 will result in: W --- X --- Y --- Z <-- origin/ghc-head \ \--- A --- B <-- wip/spj-T21623 Do be sure to update your local tracking branches before doing this (using `git remote update origin`). Overall, this would look something like: $ cd utils/haddock $ git remote update origin # update local tracking branches $ git checkout wip/spj-T21623 # ensure you are on your WIP branch $ git rebase origin/ghc-head $ git push -f origin wip/spj-T21623 # push your Haddock branch $ cd ../.. $ git commit utils/haddock $ git push -f origin wip/TspjT21623 # push your GHC branch Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From dburke.gw at gmail.com Tue Sep 6 13:02:27 2022 From: dburke.gw at gmail.com (Doug Burke) Date: Tue, 6 Sep 2022 09:02:27 -0400 Subject: possible regression in GHC 9.2.4: hang in simplifier (?) when building a test executable Message-ID: I have a test executable which will build with ghc 9.2.3 (and many older versions) but which appears to hang with GHC 9.2.4. I have exhausted what little I know of in debugging this, so any help in identifying the problem would be appreciated. Unfortunately it's a relatively large application, so the following reproducer requires some time/disk space. Thanks fo ryour time, Doug ----------------------------------------------------------------------------------------------------------------- I am on a linux machine (ubuntu 22.04) and have seen this with builds either with stack or nix. % git clone https://gitlab.com/dburke/swish temp % cd temp % git rev-parse HEAD 09c92e0fbbea9be86cac5c8e273e1d5915a9eeae Added to get the timings, but it's not strictly necessary: % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal First a check of a successful build (with stack, GHC 9.0.2): % stack test --resolver lts-19.22 :test-rdfproof ... wait a while [2 of 2] Compiling Main *** Parser [Main]: Parser [Main]: alloc=27576560 time=8.702 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=61957416 time=85.052 *** Desugar [Main]: Desugar [Main]: alloc=19485576 time=16.095 *** Simplifier [Main]: Simplifier [Main]: alloc=1024590752 time=937.479 *** Specialise [Main]: Specialise [Main]: alloc=49779464 time=30.480 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=243444904 time=287.934 *** Simplifier [Main]: Simplifier [Main]: alloc=959971736 time=844.707 *** Simplifier [Main]: Simplifier [Main]: alloc=816465992 time=727.244 *** Simplifier [Main]: Simplifier [Main]: alloc=914290184 time=835.805 Float inwards [Main]: alloc=17448 time=0.007 Called arity analysis [Main]: alloc=19288 time=0.008 *** Float inwards [Main]: *** Called arity analysis [Main]: *** Simplifier [Main]: *** Demand analysis [Main]: Simplifier [Main]: alloc=492772800 time=396.191 Demand analysis [Main]: alloc=435384136 time=234.248 *** Constructed Product Result analysis [Main]: Constructed Product Result analysis [Main]: alloc=67395816 time=27.498 *** Worker Wrapper binds [Main]: Worker Wrapper binds [Main]: alloc=10456160 time=10.538 *** Simplifier [Main]: Simplifier [Main]: alloc=675869616 time=624.538 Exitification transformation [Main]: alloc=20416 time=0.007 *** Exitification transformation [Main]: *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Main]: alloc=212059304 time=172.872 Common sub-expression [Main]: alloc=18768 time=0.008 Float inwards [Main]: alloc=17448 time=0.006 *** Common sub-expression [Main]: *** Float inwards [Main]: *** Simplifier [Main]: Simplifier [Main]: alloc=430634768 time=397.868 *** Demand analysis [Main]: Demand analysis [Main]: alloc=144629272 time=70.451 *** CoreTidy [Main]: CoreTidy [Main]: alloc=48438688 time=44.112 *** CorePrep [Main]: *** CodeGen [Main]: CorePrep [Main]: alloc=15032 time=0.012 CodeGen [Main]: alloc=1738308168 time=1051.197 *** systool:as: systool:as: alloc=118376 time=0.481 *** initializing unit database: initializing unit database: alloc=15393080 time=21.985 *** initializing unit database: initializing unit database: alloc=3745512 time=2.507 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=213016 time=0.552 Chasing dependencies: alloc=11345152 time=5.353 Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.1.0/build/test-rdfproof/test-rdfproof ... ... ... then it goes on to run the test ... With 9.2.4 it will not build % ... similar to above but with some information about the versions not ... fully tested with stack ... *** Parser [Main]: Parser [Main]: alloc=24346008 time=8.730 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=58415776 time=44.077 *** Desugar [Main]: Desugar [Main]: alloc=22148416 time=15.693 *** Simplifier [Main]: Simplifier [Main]: alloc=651048904 time=530.123 *** Specialise [Main]: Specialise [Main]: alloc=44412080 time=31.885 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=207753368 time=259.238 *** Simplifier [Main]: Simplifier [Main]: alloc=599788216 time=548.107 *** Simplifier [Main]: Simplifier [Main]: alloc=562910904 time=474.847 *** Simplifier [Main]: Simplifier [Main]: alloc=725093584 time=643.255 Float inwards [Main]: alloc=23720 time=0.011 Called arity analysis [Main]: alloc=25856 time=0.012 *** Float inwards [Main]: *** Called arity analysis [Main]: *** Simplifier [Main]: At this point it just makes my laptop fan spin faster wit h one of my CPUs pegged at 100%, but it never seems to print anything more. For those that prefer nix, you can try the following which shows the same behavior (these are using the same mangled cabal file to get the timings): % nix-shell --argstr compiler ghc923 % cabal test test-rdfproof ... [2 of 2] Compiling Main ( tests/RDFProofTest.hs, /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o ) *** Parser [Main]: Parser [Main]: alloc=25233912 time=9.910 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=57027880 time=45.911 *** Desugar [Main]: Desugar [Main]: alloc=21808096 time=54.569 *** Simplifier [Main]: Simplifier [Main]: alloc=936319072 time=880.189 *** Specialise [Main]: Specialise [Main]: alloc=41599784 time=23.425 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=204955224 time=226.189 *** Simplifier [Main]: Simplifier [Main]: alloc=610153728 time=654.735 *** Simplifier [Main]: Simplifier [Main]: alloc=566346328 time=549.298 *** Simplifier [Main]: Simplifier [Main]: alloc=801330080 time=802.428 *** Float inwards [Main]: Float inwards [Main]: alloc=23160 time=0.012 *** Called arity analysis [Main]: Called arity analysis [Main]: alloc=25296 time=0.013 *** Simplifier [Main]: Simplifier [Main]: alloc=423629864 time=320.611 *** Demand analysis [Main]: Demand analysis [Main]: alloc=253018800 time=175.884 *** Constructed Product Result analysis [Main]: Constructed Product Result analysis [Main]: alloc=74681224 time=28.675 *** Worker Wrapper binds [Main]: Worker Wrapper binds [Main]: alloc=8622264 time=7.070 *** Simplifier [Main]: Simplifier [Main]: alloc=598294440 time=554.802 *** Exitification transformation [Main]: Exitification transformation [Main]: alloc=26712 time=0.013 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) [Main]: alloc=179540608 time=226.938 *** Common sub-expression [Main]: Common sub-expression [Main]: alloc=24800 time=0.014 *** Float inwards [Main]: Float inwards [Main]: alloc=23168 time=0.010 *** Simplifier [Main]: Simplifier [Main]: alloc=382679152 time=318.224 *** Demand analysis [Main]: Demand analysis [Main]: alloc=84192056 time=50.989 *** CoreTidy [Main]: CoreTidy [Main]: alloc=45347360 time=44.571 *** CorePrep [Main]: CorePrep [Main]: alloc=34753448 time=10.917 *** CoreToStg [Main]: CoreToStg [Main]: alloc=108293568 time=114.768 *** CodeGen [Main]: CodeGen [Main]: alloc=1475393208 time=858.854 *** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: alloc=3732816 time=3.044 *** systool:as: systool:as: alloc=132384 time=0.456 *** initializing unit database: initializing unit database: alloc=7386016 time=4.306 *** initializing unit database: initializing unit database: alloc=4000384 time=12.125 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=313896 time=0.486 Chasing dependencies: alloc=12822240 time=6.459 Linking /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof ... ... versus % nix-shell --argstr compiler ghc924 cabal test test-rdfproof Warning: The package list for 'hackage.haskell.org' is 20 days old. Run 'cabal update' to get the latest list of available packages. Resolving dependencies... Build profile: -w ghc-9.2.4 -O1 In order, the following will be built (use -v for more details): - swish-0.10.2.0 (test:test-rdfproof) (first run) Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. Building test suite 'test-rdfproof' for swish-0.10.2.0.. *** initializing unit database: initializing unit database: alloc=7389248 time=4.462 *** initializing unit database: initializing unit database: alloc=4001312 time=11.664 *** Chasing dependencies: *** systool:cpp: systool:cpp: alloc=319464 time=0.481 Chasing dependencies: alloc=12861208 time=6.331 [2 of 2] Compiling Main ( tests/RDFProofTest.hs, /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o ) *** Parser [Main]: Parser [Main]: alloc=25236056 time=23.982 *** Renamer/typechecker [Main]: Renamer/typechecker [Main]: alloc=101830968 time=97.529 *** Desugar [Main]: Desugar [Main]: alloc=24617072 time=19.187 *** Simplifier [Main]: Simplifier [Main]: alloc=665051592 time=558.078 *** Specialise [Main]: Specialise [Main]: alloc=44894576 time=30.341 *** Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) [Main]: alloc=208060752 time=245.458 *** Simplifier [Main]: Simplifier [Main]: alloc=602721856 time=555.073 *** Simplifier [Main]: Simplifier [Main]: alloc=563887832 time=529.865 *** Simplifier [Main]: Simplifier [Main]: alloc=727381840 time=606.367 *** Float inwards [Main]: Float inwards [Main]: alloc=23720 time=0.012 *** Called arity analysis [Main]: Called arity analysis [Main]: alloc=25848 time=0.012 *** Simplifier [Main]: which again hangs From simon.peytonjones at gmail.com Tue Sep 6 14:18:49 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 6 Sep 2022 15:18:49 +0100 Subject: possible regression in GHC 9.2.4: hang in simplifier (?) when building a test executable In-Reply-To: References: Message-ID: Maybe open GHC ticket? How can I repro with a *particular* GHC, for example my build of HEAD? And how can I find the command line that finally hung, so I can try it repeatedly? Simon On Tue, 6 Sept 2022 at 14:02, Doug Burke wrote: > I have a test executable which will build with ghc 9.2.3 (and many > older versions) but which appears to hang with GHC 9.2.4. I have > exhausted what little I know of in debugging this, so any help in > identifying the problem would be appreciated. Unfortunately it's a > relatively large application, so the following reproducer requires > some time/disk space. > > Thanks fo ryour time, > Doug > > > ----------------------------------------------------------------------------------------------------------------- > > I am on a linux machine (ubuntu 22.04) and have seen this with builds > either with stack or nix. > > % git clone https://gitlab.com/dburke/swish temp > % cd temp > % git rev-parse HEAD > 09c92e0fbbea9be86cac5c8e273e1d5915a9eeae > > Added to get the timings, but it's not strictly necessary: > > % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal > > First a check of a successful build (with stack, GHC 9.0.2): > > % stack test --resolver lts-19.22 :test-rdfproof > ... wait a while > [2 of 2] Compiling Main > *** Parser [Main]: > Parser [Main]: alloc=27576560 time=8.702 > *** Renamer/typechecker [Main]: > Renamer/typechecker [Main]: alloc=61957416 time=85.052 > *** Desugar [Main]: > Desugar [Main]: alloc=19485576 time=16.095 > *** Simplifier [Main]: > Simplifier [Main]: alloc=1024590752 time=937.479 > *** Specialise [Main]: > Specialise [Main]: alloc=49779464 time=30.480 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = False}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > [Main]: alloc=243444904 time=287.934 > *** Simplifier [Main]: > Simplifier [Main]: alloc=959971736 time=844.707 > *** Simplifier [Main]: > Simplifier [Main]: alloc=816465992 time=727.244 > *** Simplifier [Main]: > Simplifier [Main]: alloc=914290184 time=835.805 > Float inwards [Main]: alloc=17448 time=0.007 > Called arity analysis [Main]: alloc=19288 time=0.008 > *** Float inwards [Main]: > *** Called arity analysis [Main]: > *** Simplifier [Main]: > *** Demand analysis [Main]: > Simplifier [Main]: alloc=492772800 time=396.191 > Demand analysis [Main]: alloc=435384136 time=234.248 > *** Constructed Product Result analysis [Main]: > Constructed Product Result analysis [Main]: alloc=67395816 time=27.498 > *** Worker Wrapper binds [Main]: > Worker Wrapper binds [Main]: alloc=10456160 time=10.538 > *** Simplifier [Main]: > Simplifier [Main]: alloc=675869616 time=624.538 > Exitification transformation [Main]: alloc=20416 time=0.007 > *** Exitification transformation [Main]: > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = True}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) > [Main]: alloc=212059304 time=172.872 > Common sub-expression [Main]: alloc=18768 time=0.008 > Float inwards [Main]: alloc=17448 time=0.006 > *** Common sub-expression [Main]: > *** Float inwards [Main]: > *** Simplifier [Main]: > Simplifier [Main]: alloc=430634768 time=397.868 > *** Demand analysis [Main]: > Demand analysis [Main]: alloc=144629272 time=70.451 > *** CoreTidy [Main]: > CoreTidy [Main]: alloc=48438688 time=44.112 > *** CorePrep [Main]: > *** CodeGen [Main]: > CorePrep [Main]: alloc=15032 time=0.012 > CodeGen [Main]: alloc=1738308168 time=1051.197 > *** systool:as: > systool:as: alloc=118376 time=0.481 > *** initializing unit database: > initializing unit database: alloc=15393080 time=21.985 > *** initializing unit database: > initializing unit database: alloc=3745512 time=2.507 > *** Chasing dependencies: > *** systool:cpp: > systool:cpp: alloc=213016 time=0.552 > Chasing dependencies: alloc=11345152 time=5.353 > Linking > .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.1.0/build/test-rdfproof/test-rdfproof > ... > ... > ... then it goes on to run the test > ... > > With 9.2.4 it will not build > > % > ... similar to above but with some information about the versions not > ... fully tested with stack > ... > *** Parser [Main]: > Parser [Main]: alloc=24346008 time=8.730 > *** Renamer/typechecker [Main]: > Renamer/typechecker [Main]: alloc=58415776 time=44.077 > *** Desugar [Main]: > Desugar [Main]: alloc=22148416 time=15.693 > *** Simplifier [Main]: > Simplifier [Main]: alloc=651048904 time=530.123 > *** Specialise [Main]: > Specialise [Main]: alloc=44412080 time=31.885 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = False}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > [Main]: alloc=207753368 time=259.238 > *** Simplifier [Main]: > Simplifier [Main]: alloc=599788216 time=548.107 > *** Simplifier [Main]: > Simplifier [Main]: alloc=562910904 time=474.847 > *** Simplifier [Main]: > Simplifier [Main]: alloc=725093584 time=643.255 > Float inwards [Main]: alloc=23720 time=0.011 > Called arity analysis [Main]: alloc=25856 time=0.012 > *** Float inwards [Main]: > *** Called arity analysis [Main]: > *** Simplifier [Main]: > > > At this point it just makes my laptop fan spin faster wit h one of my > CPUs pegged at 100%, but it never seems to print anything more. > > For those that prefer nix, you can try the following which shows the > same behavior (these are using the same mangled cabal file to get the > timings): > > % nix-shell --argstr compiler ghc923 > % cabal test test-rdfproof > ... > [2 of 2] Compiling Main ( tests/RDFProofTest.hs, > > /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o > ) > *** Parser [Main]: > Parser [Main]: alloc=25233912 time=9.910 > *** Renamer/typechecker [Main]: > Renamer/typechecker [Main]: alloc=57027880 time=45.911 > *** Desugar [Main]: > Desugar [Main]: alloc=21808096 time=54.569 > *** Simplifier [Main]: > Simplifier [Main]: alloc=936319072 time=880.189 > *** Specialise [Main]: > Specialise [Main]: alloc=41599784 time=23.425 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = False}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > [Main]: alloc=204955224 time=226.189 > *** Simplifier [Main]: > Simplifier [Main]: alloc=610153728 time=654.735 > *** Simplifier [Main]: > Simplifier [Main]: alloc=566346328 time=549.298 > *** Simplifier [Main]: > Simplifier [Main]: alloc=801330080 time=802.428 > *** Float inwards [Main]: > Float inwards [Main]: alloc=23160 time=0.012 > *** Called arity analysis [Main]: > Called arity analysis [Main]: alloc=25296 time=0.013 > *** Simplifier [Main]: > Simplifier [Main]: alloc=423629864 time=320.611 > *** Demand analysis [Main]: > Demand analysis [Main]: alloc=253018800 time=175.884 > *** Constructed Product Result analysis [Main]: > Constructed Product Result analysis [Main]: alloc=74681224 time=28.675 > *** Worker Wrapper binds [Main]: > Worker Wrapper binds [Main]: alloc=8622264 time=7.070 > *** Simplifier [Main]: > Simplifier [Main]: alloc=598294440 time=554.802 > *** Exitification transformation [Main]: > Exitification transformation [Main]: alloc=26712 time=0.013 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = True}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) > [Main]: alloc=179540608 time=226.938 > *** Common sub-expression [Main]: > Common sub-expression [Main]: alloc=24800 time=0.014 > *** Float inwards [Main]: > Float inwards [Main]: alloc=23168 time=0.010 > *** Simplifier [Main]: > Simplifier [Main]: alloc=382679152 time=318.224 > *** Demand analysis [Main]: > Demand analysis [Main]: alloc=84192056 time=50.989 > *** CoreTidy [Main]: > CoreTidy [Main]: alloc=45347360 time=44.571 > *** CorePrep [Main]: > CorePrep [Main]: alloc=34753448 time=10.917 > *** CoreToStg [Main]: > CoreToStg [Main]: alloc=108293568 time=114.768 > *** CodeGen [Main]: > CodeGen [Main]: alloc=1475393208 time=858.854 > *** WriteIface > [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: > WriteIface > [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: > alloc=3732816 time=3.044 > *** systool:as: > systool:as: alloc=132384 time=0.456 > *** initializing unit database: > initializing unit database: alloc=7386016 time=4.306 > *** initializing unit database: > initializing unit database: alloc=4000384 time=12.125 > *** Chasing dependencies: > *** systool:cpp: > systool:cpp: alloc=313896 time=0.486 > Chasing dependencies: alloc=12822240 time=6.459 > Linking > /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof > ... > ... > > versus > > % nix-shell --argstr compiler ghc924 > cabal test test-rdfproof > Warning: The package list for 'hackage.haskell.org' is 20 days old. > Run 'cabal update' to get the latest list of available packages. > Resolving dependencies... > Build profile: -w ghc-9.2.4 -O1 > In order, the following will be built (use -v for more details): > - swish-0.10.2.0 (test:test-rdfproof) (first run) > Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. > Building test suite 'test-rdfproof' for swish-0.10.2.0.. > *** initializing unit database: > initializing unit database: alloc=7389248 time=4.462 > *** initializing unit database: > initializing unit database: alloc=4001312 time=11.664 > *** Chasing dependencies: > *** systool:cpp: > systool:cpp: alloc=319464 time=0.481 > Chasing dependencies: alloc=12861208 time=6.331 > [2 of 2] Compiling Main ( tests/RDFProofTest.hs, > > /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o > ) > *** Parser [Main]: > Parser [Main]: alloc=25236056 time=23.982 > *** Renamer/typechecker [Main]: > Renamer/typechecker [Main]: alloc=101830968 time=97.529 > *** Desugar [Main]: > Desugar [Main]: alloc=24617072 time=19.187 > *** Simplifier [Main]: > Simplifier [Main]: alloc=665051592 time=558.078 > *** Specialise [Main]: > Specialise [Main]: alloc=44894576 time=30.341 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = False}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > [Main]: alloc=208060752 time=245.458 > *** Simplifier [Main]: > Simplifier [Main]: alloc=602721856 time=555.073 > *** Simplifier [Main]: > Simplifier [Main]: alloc=563887832 time=529.865 > *** Simplifier [Main]: > Simplifier [Main]: alloc=727381840 time=606.367 > *** Float inwards [Main]: > Float inwards [Main]: alloc=23720 time=0.012 > *** Called arity analysis [Main]: > Called arity analysis [Main]: alloc=25848 time=0.012 > *** Simplifier [Main]: > > which again hangs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dburke.gw at gmail.com Tue Sep 6 15:03:44 2022 From: dburke.gw at gmail.com (Doug Burke) Date: Tue, 6 Sep 2022 11:03:44 -0400 Subject: possible regression in GHC 9.2.4: hang in simplifier (?) when building a test executable In-Reply-To: References: Message-ID: On Tue, Sep 6, 2022 at 10:17 AM Simon Peyton Jones wrote: The following two are great questions which I do not know the answer to. > How can I repro with a *particular* GHC, for example my build of HEAD? > > And how can I find the command line that finally hung, so I can try it repeatedly? > > Simon > > On Tue, 6 Sept 2022 at 14:02, Doug Burke wrote: >> >> I have a test executable which will build with ghc 9.2.3 (and many >> older versions) but which appears to hang with GHC 9.2.4. I have >> exhausted what little I know of in debugging this, so any help in >> identifying the problem would be appreciated. Unfortunately it's a >> relatively large application, so the following reproducer requires >> some time/disk space. >> >> Thanks fo ryour time, >> Doug >> >> ----------------------------------------------------------------------------------------------------------------- >> >> I am on a linux machine (ubuntu 22.04) and have seen this with builds >> either with stack or nix. >> >> % git clone https://gitlab.com/dburke/swish temp >> % cd temp >> % git rev-parse HEAD >> 09c92e0fbbea9be86cac5c8e273e1d5915a9eeae >> >> Added to get the timings, but it's not strictly necessary: >> >> % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal >> >> First a check of a successful build (with stack, GHC 9.0.2): >> >> % stack test --resolver lts-19.22 :test-rdfproof >> ... wait a while >> [2 of 2] Compiling Main >> *** Parser [Main]: >> Parser [Main]: alloc=27576560 time=8.702 >> *** Renamer/typechecker [Main]: >> Renamer/typechecker [Main]: alloc=61957416 time=85.052 >> *** Desugar [Main]: >> Desugar [Main]: alloc=19485576 time=16.095 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=1024590752 time=937.479 >> *** Specialise [Main]: >> Specialise [Main]: alloc=49779464 time=30.480 >> *** Float out(FOS {Lam = Just 0, >> Consts = True, >> OverSatApps = False}) [Main]: >> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) >> [Main]: alloc=243444904 time=287.934 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=959971736 time=844.707 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=816465992 time=727.244 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=914290184 time=835.805 >> Float inwards [Main]: alloc=17448 time=0.007 >> Called arity analysis [Main]: alloc=19288 time=0.008 >> *** Float inwards [Main]: >> *** Called arity analysis [Main]: >> *** Simplifier [Main]: >> *** Demand analysis [Main]: >> Simplifier [Main]: alloc=492772800 time=396.191 >> Demand analysis [Main]: alloc=435384136 time=234.248 >> *** Constructed Product Result analysis [Main]: >> Constructed Product Result analysis [Main]: alloc=67395816 time=27.498 >> *** Worker Wrapper binds [Main]: >> Worker Wrapper binds [Main]: alloc=10456160 time=10.538 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=675869616 time=624.538 >> Exitification transformation [Main]: alloc=20416 time=0.007 >> *** Exitification transformation [Main]: >> *** Float out(FOS {Lam = Just 0, >> Consts = True, >> OverSatApps = True}) [Main]: >> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) >> [Main]: alloc=212059304 time=172.872 >> Common sub-expression [Main]: alloc=18768 time=0.008 >> Float inwards [Main]: alloc=17448 time=0.006 >> *** Common sub-expression [Main]: >> *** Float inwards [Main]: >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=430634768 time=397.868 >> *** Demand analysis [Main]: >> Demand analysis [Main]: alloc=144629272 time=70.451 >> *** CoreTidy [Main]: >> CoreTidy [Main]: alloc=48438688 time=44.112 >> *** CorePrep [Main]: >> *** CodeGen [Main]: >> CorePrep [Main]: alloc=15032 time=0.012 >> CodeGen [Main]: alloc=1738308168 time=1051.197 >> *** systool:as: >> systool:as: alloc=118376 time=0.481 >> *** initializing unit database: >> initializing unit database: alloc=15393080 time=21.985 >> *** initializing unit database: >> initializing unit database: alloc=3745512 time=2.507 >> *** Chasing dependencies: >> *** systool:cpp: >> systool:cpp: alloc=213016 time=0.552 >> Chasing dependencies: alloc=11345152 time=5.353 >> Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.1.0/build/test-rdfproof/test-rdfproof >> ... >> ... >> ... then it goes on to run the test >> ... >> >> With 9.2.4 it will not build >> >> % >> ... similar to above but with some information about the versions not >> ... fully tested with stack >> ... >> *** Parser [Main]: >> Parser [Main]: alloc=24346008 time=8.730 >> *** Renamer/typechecker [Main]: >> Renamer/typechecker [Main]: alloc=58415776 time=44.077 >> *** Desugar [Main]: >> Desugar [Main]: alloc=22148416 time=15.693 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=651048904 time=530.123 >> *** Specialise [Main]: >> Specialise [Main]: alloc=44412080 time=31.885 >> *** Float out(FOS {Lam = Just 0, >> Consts = True, >> OverSatApps = False}) [Main]: >> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) >> [Main]: alloc=207753368 time=259.238 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=599788216 time=548.107 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=562910904 time=474.847 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=725093584 time=643.255 >> Float inwards [Main]: alloc=23720 time=0.011 >> Called arity analysis [Main]: alloc=25856 time=0.012 >> *** Float inwards [Main]: >> *** Called arity analysis [Main]: >> *** Simplifier [Main]: >> >> >> At this point it just makes my laptop fan spin faster wit h one of my >> CPUs pegged at 100%, but it never seems to print anything more. >> >> For those that prefer nix, you can try the following which shows the >> same behavior (these are using the same mangled cabal file to get the >> timings): >> >> % nix-shell --argstr compiler ghc923 >> % cabal test test-rdfproof >> ... >> [2 of 2] Compiling Main ( tests/RDFProofTest.hs, >> /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o >> ) >> *** Parser [Main]: >> Parser [Main]: alloc=25233912 time=9.910 >> *** Renamer/typechecker [Main]: >> Renamer/typechecker [Main]: alloc=57027880 time=45.911 >> *** Desugar [Main]: >> Desugar [Main]: alloc=21808096 time=54.569 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=936319072 time=880.189 >> *** Specialise [Main]: >> Specialise [Main]: alloc=41599784 time=23.425 >> *** Float out(FOS {Lam = Just 0, >> Consts = True, >> OverSatApps = False}) [Main]: >> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) >> [Main]: alloc=204955224 time=226.189 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=610153728 time=654.735 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=566346328 time=549.298 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=801330080 time=802.428 >> *** Float inwards [Main]: >> Float inwards [Main]: alloc=23160 time=0.012 >> *** Called arity analysis [Main]: >> Called arity analysis [Main]: alloc=25296 time=0.013 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=423629864 time=320.611 >> *** Demand analysis [Main]: >> Demand analysis [Main]: alloc=253018800 time=175.884 >> *** Constructed Product Result analysis [Main]: >> Constructed Product Result analysis [Main]: alloc=74681224 time=28.675 >> *** Worker Wrapper binds [Main]: >> Worker Wrapper binds [Main]: alloc=8622264 time=7.070 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=598294440 time=554.802 >> *** Exitification transformation [Main]: >> Exitification transformation [Main]: alloc=26712 time=0.013 >> *** Float out(FOS {Lam = Just 0, >> Consts = True, >> OverSatApps = True}) [Main]: >> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) >> [Main]: alloc=179540608 time=226.938 >> *** Common sub-expression [Main]: >> Common sub-expression [Main]: alloc=24800 time=0.014 >> *** Float inwards [Main]: >> Float inwards [Main]: alloc=23168 time=0.010 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=382679152 time=318.224 >> *** Demand analysis [Main]: >> Demand analysis [Main]: alloc=84192056 time=50.989 >> *** CoreTidy [Main]: >> CoreTidy [Main]: alloc=45347360 time=44.571 >> *** CorePrep [Main]: >> CorePrep [Main]: alloc=34753448 time=10.917 >> *** CoreToStg [Main]: >> CoreToStg [Main]: alloc=108293568 time=114.768 >> *** CodeGen [Main]: >> CodeGen [Main]: alloc=1475393208 time=858.854 >> *** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: >> WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: >> alloc=3732816 time=3.044 >> *** systool:as: >> systool:as: alloc=132384 time=0.456 >> *** initializing unit database: >> initializing unit database: alloc=7386016 time=4.306 >> *** initializing unit database: >> initializing unit database: alloc=4000384 time=12.125 >> *** Chasing dependencies: >> *** systool:cpp: >> systool:cpp: alloc=313896 time=0.486 >> Chasing dependencies: alloc=12822240 time=6.459 >> Linking /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof >> ... >> ... >> >> versus >> >> % nix-shell --argstr compiler ghc924 >> cabal test test-rdfproof >> Warning: The package list for 'hackage.haskell.org' is 20 days old. >> Run 'cabal update' to get the latest list of available packages. >> Resolving dependencies... >> Build profile: -w ghc-9.2.4 -O1 >> In order, the following will be built (use -v for more details): >> - swish-0.10.2.0 (test:test-rdfproof) (first run) >> Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. >> Building test suite 'test-rdfproof' for swish-0.10.2.0.. >> *** initializing unit database: >> initializing unit database: alloc=7389248 time=4.462 >> *** initializing unit database: >> initializing unit database: alloc=4001312 time=11.664 >> *** Chasing dependencies: >> *** systool:cpp: >> systool:cpp: alloc=319464 time=0.481 >> Chasing dependencies: alloc=12861208 time=6.331 >> [2 of 2] Compiling Main ( tests/RDFProofTest.hs, >> /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o >> ) >> *** Parser [Main]: >> Parser [Main]: alloc=25236056 time=23.982 >> *** Renamer/typechecker [Main]: >> Renamer/typechecker [Main]: alloc=101830968 time=97.529 >> *** Desugar [Main]: >> Desugar [Main]: alloc=24617072 time=19.187 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=665051592 time=558.078 >> *** Specialise [Main]: >> Specialise [Main]: alloc=44894576 time=30.341 >> *** Float out(FOS {Lam = Just 0, >> Consts = True, >> OverSatApps = False}) [Main]: >> Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) >> [Main]: alloc=208060752 time=245.458 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=602721856 time=555.073 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=563887832 time=529.865 >> *** Simplifier [Main]: >> Simplifier [Main]: alloc=727381840 time=606.367 >> *** Float inwards [Main]: >> Float inwards [Main]: alloc=23720 time=0.012 >> *** Called arity analysis [Main]: >> Called arity analysis [Main]: alloc=25848 time=0.012 >> *** Simplifier [Main]: >> >> which again hangs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simon.peytonjones at gmail.com Tue Sep 6 15:53:16 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 6 Sep 2022 16:53:16 +0100 Subject: Unix library apparently broken Message-ID: My !8750 builds are failing in the Unix library with the "pattern match is redundant" message below. And indeed the pattern match is redundant. Here's the .hs version of the file unpackRLimit :: CRLim -> ResourceLimit unpackRLimit (18446744073709551615) = ResourceLimitInfinity {-# LINE 101 "libraries/unix/System/Posix/Resource.hsc" #-} unpackRLimit other {-# LINE 103 "libraries/unix/System/Posix/Resource.hsc" #-} | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && {-# LINE 104 "libraries/unix/System/Posix/Resource.hsc" #-} other == (18446744073709551615) = ResourceLimitUnknown {-# LINE 105 "libraries/unix/System/Posix/Resource.hsc" #-} {-# LINE 106 "libraries/unix/System/Posix/Resource.hsc" #-} {-# LINE 107 "libraries/unix/System/Posix/Resource.hsc" #-} | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && {-# LINE 108 "libraries/unix/System/Posix/Resource.hsc" #-} other == (18446744073709551615) = ResourceLimitUnknown {-# LINE 109 "libraries/unix/System/Posix/Resource.hsc" #-} {-# LINE 110 "libraries/unix/System/Posix/Resource.hsc" #-} | otherwise = ResourceLimit (fromIntegral other) The red line means that the blue lines will fail. So the warning looks correct. But it's stopping my CI from working. I have no idea why this doesn't happen in HEAD. Can anyone help? Thanks Simon Command line: _build/stage0/bin/aarch64-linux-gnu-ghc -Wall -Wcompat -fdiagnostics-color=never -dynamic-too -hisuf hi -osuf o -hcsuf hc -static -hide-all-packages -no-user-package-db '-package-env -' '-package-db _build/stage1/lib/package.conf.d' '-this-unit-id unix-2.7.2.2' '-package-id base-4.17.0.0' '-package-id bytestring-0.11.3.1' '-package-id time-1.12.2' -i -i/builds/ghc/ghc/_build/stage1/libraries/unix/build -i/builds/ghc/ghc/_build/stage1/libraries/unix/build/autogen -i/builds/ghc/ghc/libraries/unix -Irts/include -I_build/stage1/libraries/unix/build -I_build/stage1/libraries/unix/build/include -Ilibraries/unix/include -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/time-1.12.2/include -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/bytestring-0.11.3.1/include -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/base-4.17.0.0/include -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/ghc-bignum-1.3/include -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/rts-1.0.2/include -optP-include -optP_build/stage1/libraries/unix/build/autogen/cabal_macros.h -outputdir _build/stage1/libraries/unix/build -Wnoncanonical-monad-instances -optc-Wno-error=inline -optP-Wno-nonportable-include-path -c _build/stage1/libraries/unix/build/System/Posix/Resource.hs -o _build/stage1/libraries/unix/build/System/Posix/Resource.o -fllvm-fill-undef-with-garbage -dno-debug-output -Wall -XHaskell2010 -no-global-package-db -package-db=/builds/ghc/ghc/_build/stage1/lib/package.conf.d -ghcversion-file=rts/include/ghcversion.h -ghcversion-file=rts/include/ghcversion.h -O -Wno-deprecated-flags -Werror -dlint ===> Command failed with error code: 1 libraries/unix/System/Posix/Resource.hsc:107:7: error: [-Woverlapping-patterns, -Werror=overlapping-patterns] Pattern match is redundant In an equation for ‘unpackRLimit’: unpackRLimit other | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && other == (18446744073709551615) = ... | 107 | | ((#const RLIM_SAVED_CUR) :: CRLim) /= (#const RLIM_INFINITY) && | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.derbyshire at gmail.com Tue Sep 6 16:27:21 2022 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Tue, 6 Sep 2022 18:27:21 +0200 Subject: Unix library apparently broken In-Reply-To: References: Message-ID: Hi Simon, This is due to my patch 4786acf7 landing, which means GHC does better at recognising the redundant pattern match. That MR also updated the unix submodule, in order to suppress that pattern match warning. So I would guess that you have not updated the unix submodule after rebasing your MR; perhaps try "git submodule update"? The unix submodule is currently on commit 2a6079a2 . Hope that helps, Sam On Tue, 6 Sept 2022 at 17:52, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > My !8750 builds are failing in the Unix library with the "pattern match is > redundant" message below. > > And indeed the pattern match is redundant. Here's the .hs version of the > file > > unpackRLimit :: CRLim -> ResourceLimit > unpackRLimit (18446744073709551615) = ResourceLimitInfinity > {-# LINE 101 "libraries/unix/System/Posix/Resource.hsc" #-} > unpackRLimit other > > {-# LINE 103 "libraries/unix/System/Posix/Resource.hsc" #-} > | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && > {-# LINE 104 "libraries/unix/System/Posix/Resource.hsc" #-} > other == (18446744073709551615) = ResourceLimitUnknown > {-# LINE 105 "libraries/unix/System/Posix/Resource.hsc" #-} > > {-# LINE 106 "libraries/unix/System/Posix/Resource.hsc" #-} > > {-# LINE 107 "libraries/unix/System/Posix/Resource.hsc" #-} > | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && > {-# LINE 108 "libraries/unix/System/Posix/Resource.hsc" #-} > other == (18446744073709551615) = ResourceLimitUnknown > {-# LINE 109 "libraries/unix/System/Posix/Resource.hsc" #-} > > {-# LINE 110 "libraries/unix/System/Posix/Resource.hsc" #-} > | otherwise = ResourceLimit (fromIntegral other) > > The red line means that the blue lines will fail. > > So the warning looks correct. But it's stopping my CI from working. I > have no idea why this doesn't happen in HEAD. Can anyone help? > > Thanks > > Simon > > > Command line: _build/stage0/bin/aarch64-linux-gnu-ghc -Wall -Wcompat > -fdiagnostics-color=never -dynamic-too -hisuf hi -osuf o -hcsuf hc -static > -hide-all-packages -no-user-package-db '-package-env -' '-package-db > _build/stage1/lib/package.conf.d' '-this-unit-id unix-2.7.2.2' '-package-id > base-4.17.0.0' '-package-id bytestring-0.11.3.1' '-package-id time-1.12.2' > -i -i/builds/ghc/ghc/_build/stage1/libraries/unix/build > -i/builds/ghc/ghc/_build/stage1/libraries/unix/build/autogen > -i/builds/ghc/ghc/libraries/unix -Irts/include > -I_build/stage1/libraries/unix/build > -I_build/stage1/libraries/unix/build/include -Ilibraries/unix/include > -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/time-1.12.2/include > -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/bytestring-0.11.3.1/include > -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/base-4.17.0.0/include > -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/ghc-bignum-1.3/include > -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/rts-1.0.2/include > -optP-include > -optP_build/stage1/libraries/unix/build/autogen/cabal_macros.h -outputdir > _build/stage1/libraries/unix/build -Wnoncanonical-monad-instances > -optc-Wno-error=inline -optP-Wno-nonportable-include-path -c > _build/stage1/libraries/unix/build/System/Posix/Resource.hs -o > _build/stage1/libraries/unix/build/System/Posix/Resource.o > -fllvm-fill-undef-with-garbage -dno-debug-output -Wall -XHaskell2010 > -no-global-package-db > -package-db=/builds/ghc/ghc/_build/stage1/lib/package.conf.d > -ghcversion-file=rts/include/ghcversion.h > -ghcversion-file=rts/include/ghcversion.h -O -Wno-deprecated-flags -Werror > -dlint > ===> Command failed with error code: 1 > libraries/unix/System/Posix/Resource.hsc:107:7: error: > [-Woverlapping-patterns, -Werror=overlapping-patterns] > Pattern match is redundant > In an equation for ‘unpackRLimit’: > unpackRLimit other | ((18446744073709551615) :: CRLim) > /= (18446744073709551615) > && other == (18446744073709551615) = ... > | > 107 | | ((#const RLIM_SAVED_CUR) :: CRLim) /= (#const RLIM_INFINITY) && > | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From oleg.grenrus at iki.fi Tue Sep 6 18:14:55 2022 From: oleg.grenrus at iki.fi (Oleg Grenrus) Date: Tue, 6 Sep 2022 21:14:55 +0300 Subject: possible regression in GHC 9.2.4: hang in simplifier (?) when building a test executable In-Reply-To: References: Message-ID: <72aca27e-4567-5324-aab3-dc1696c49081@iki.fi> I quickly tried with with {-# OPTIONS_GHC  -ddump-timings -ddump-simpl-trace -ddump-to-file #-} in RDFProofTest.hs and at some point simplifier does nothing. The simpl-trace file doesn't grow. The GHC just seems to spin. After that - I checked out the `ghc-9.2.4-release` tag, - built it --flavour=default+profiled_ghc+no_dynamic_ghc - built the swish using cabal pointing to GHC used (on my machine: cabal build -w /code/ghc/_build_ghc-9.2/stage1/bin/ghc test-rdfproof -v3) - copy pasted the command cabal used to execute ghc, which is long, and added +RTS -xc -RTS there After that, if I ^C when GHC seems to be spinning, the stack trace is consistently the same: ^C*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace:   GHC.Core.Opt.Pipeline.CallArity,   called from GHC.Driver.Main.Core2Core,   called from GHC.Driver.Main.hscSimplify',   called from GHC.Driver.Main.finish,   called from GHC.Driver.Main.hscIncrementalCompile,   called from GHC.Driver.Make.upsweep_mod.compile_it,   called from GHC.Driver.Make.upsweep_mod,   called from GHC.Driver.Make.upsweep.upsweep',   called from GHC.Driver.Make.upsweep,   called from GHC.Driver.Make.withDeferredDiagnostics,   called from GHC.Driver.Make.load'.checkHowMuch,   called from GHC.Driver.Make.load',   called from GHC.Driver.Make.load,   called from GHC.withCleanupSession,   called from GHC.runGhc,   called from GHC.defaultErrorHandler Hopefully this illustrates how to reproduce with your own GHC. I also tried with GHC-9.4.1 (using --allow-newer=base) and GHC panics: [ 6 of 55] Compiling Swish.GraphMatch : error:     panic! (the 'impossible' happened)   GHC version 9.4.1:     funResultTy   GenLabelMap lb_adrG LabelIndex   Call stack:       CallStack (from HasCallStack):         callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in ghc:GHC.Utils.Panic         pprPanic, called at compiler/GHC/Core/Type.hs:1334:49 in ghc:GHC.Core.Type GHC-9.4.2 panics in the same way. Maybe these failures are related? - Oleg On 6.9.2022 16.02, Doug Burke wrote: > I have a test executable which will build with ghc 9.2.3 (and many > older versions) but which appears to hang with GHC 9.2.4. I have > exhausted what little I know of in debugging this, so any help in > identifying the problem would be appreciated. Unfortunately it's a > relatively large application, so the following reproducer requires > some time/disk space. > > Thanks fo ryour time, > Doug > > ----------------------------------------------------------------------------------------------------------------- > > I am on a linux machine (ubuntu 22.04) and have seen this with builds > either with stack or nix. > > % git clone https://gitlab.com/dburke/swish temp > % cd temp > % git rev-parse HEAD > 09c92e0fbbea9be86cac5c8e273e1d5915a9eeae > > Added to get the timings, but it's not strictly necessary: > > % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal > > First a check of a successful build (with stack, GHC 9.0.2): > > % stack test --resolver lts-19.22 :test-rdfproof > ... wait a while > [2 of 2] Compiling Main > *** Parser [Main]: > Parser [Main]: alloc=27576560 time=8.702 > *** Renamer/typechecker [Main]: > Renamer/typechecker [Main]: alloc=61957416 time=85.052 > *** Desugar [Main]: > Desugar [Main]: alloc=19485576 time=16.095 > *** Simplifier [Main]: > Simplifier [Main]: alloc=1024590752 time=937.479 > *** Specialise [Main]: > Specialise [Main]: alloc=49779464 time=30.480 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = False}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > [Main]: alloc=243444904 time=287.934 > *** Simplifier [Main]: > Simplifier [Main]: alloc=959971736 time=844.707 > *** Simplifier [Main]: > Simplifier [Main]: alloc=816465992 time=727.244 > *** Simplifier [Main]: > Simplifier [Main]: alloc=914290184 time=835.805 > Float inwards [Main]: alloc=17448 time=0.007 > Called arity analysis [Main]: alloc=19288 time=0.008 > *** Float inwards [Main]: > *** Called arity analysis [Main]: > *** Simplifier [Main]: > *** Demand analysis [Main]: > Simplifier [Main]: alloc=492772800 time=396.191 > Demand analysis [Main]: alloc=435384136 time=234.248 > *** Constructed Product Result analysis [Main]: > Constructed Product Result analysis [Main]: alloc=67395816 time=27.498 > *** Worker Wrapper binds [Main]: > Worker Wrapper binds [Main]: alloc=10456160 time=10.538 > *** Simplifier [Main]: > Simplifier [Main]: alloc=675869616 time=624.538 > Exitification transformation [Main]: alloc=20416 time=0.007 > *** Exitification transformation [Main]: > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = True}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) > [Main]: alloc=212059304 time=172.872 > Common sub-expression [Main]: alloc=18768 time=0.008 > Float inwards [Main]: alloc=17448 time=0.006 > *** Common sub-expression [Main]: > *** Float inwards [Main]: > *** Simplifier [Main]: > Simplifier [Main]: alloc=430634768 time=397.868 > *** Demand analysis [Main]: > Demand analysis [Main]: alloc=144629272 time=70.451 > *** CoreTidy [Main]: > CoreTidy [Main]: alloc=48438688 time=44.112 > *** CorePrep [Main]: > *** CodeGen [Main]: > CorePrep [Main]: alloc=15032 time=0.012 > CodeGen [Main]: alloc=1738308168 time=1051.197 > *** systool:as: > systool:as: alloc=118376 time=0.481 > *** initializing unit database: > initializing unit database: alloc=15393080 time=21.985 > *** initializing unit database: > initializing unit database: alloc=3745512 time=2.507 > *** Chasing dependencies: > *** systool:cpp: > systool:cpp: alloc=213016 time=0.552 > Chasing dependencies: alloc=11345152 time=5.353 > Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.1.0/build/test-rdfproof/test-rdfproof > ... > ... > ... then it goes on to run the test > ... > > With 9.2.4 it will not build > > % > ... similar to above but with some information about the versions not > ... fully tested with stack > ... > *** Parser [Main]: > Parser [Main]: alloc=24346008 time=8.730 > *** Renamer/typechecker [Main]: > Renamer/typechecker [Main]: alloc=58415776 time=44.077 > *** Desugar [Main]: > Desugar [Main]: alloc=22148416 time=15.693 > *** Simplifier [Main]: > Simplifier [Main]: alloc=651048904 time=530.123 > *** Specialise [Main]: > Specialise [Main]: alloc=44412080 time=31.885 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = False}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > [Main]: alloc=207753368 time=259.238 > *** Simplifier [Main]: > Simplifier [Main]: alloc=599788216 time=548.107 > *** Simplifier [Main]: > Simplifier [Main]: alloc=562910904 time=474.847 > *** Simplifier [Main]: > Simplifier [Main]: alloc=725093584 time=643.255 > Float inwards [Main]: alloc=23720 time=0.011 > Called arity analysis [Main]: alloc=25856 time=0.012 > *** Float inwards [Main]: > *** Called arity analysis [Main]: > *** Simplifier [Main]: > > > At this point it just makes my laptop fan spin faster wit h one of my > CPUs pegged at 100%, but it never seems to print anything more. > > For those that prefer nix, you can try the following which shows the > same behavior (these are using the same mangled cabal file to get the > timings): > > % nix-shell --argstr compiler ghc923 > % cabal test test-rdfproof > ... > [2 of 2] Compiling Main ( tests/RDFProofTest.hs, > /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o > ) > *** Parser [Main]: > Parser [Main]: alloc=25233912 time=9.910 > *** Renamer/typechecker [Main]: > Renamer/typechecker [Main]: alloc=57027880 time=45.911 > *** Desugar [Main]: > Desugar [Main]: alloc=21808096 time=54.569 > *** Simplifier [Main]: > Simplifier [Main]: alloc=936319072 time=880.189 > *** Specialise [Main]: > Specialise [Main]: alloc=41599784 time=23.425 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = False}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > [Main]: alloc=204955224 time=226.189 > *** Simplifier [Main]: > Simplifier [Main]: alloc=610153728 time=654.735 > *** Simplifier [Main]: > Simplifier [Main]: alloc=566346328 time=549.298 > *** Simplifier [Main]: > Simplifier [Main]: alloc=801330080 time=802.428 > *** Float inwards [Main]: > Float inwards [Main]: alloc=23160 time=0.012 > *** Called arity analysis [Main]: > Called arity analysis [Main]: alloc=25296 time=0.013 > *** Simplifier [Main]: > Simplifier [Main]: alloc=423629864 time=320.611 > *** Demand analysis [Main]: > Demand analysis [Main]: alloc=253018800 time=175.884 > *** Constructed Product Result analysis [Main]: > Constructed Product Result analysis [Main]: alloc=74681224 time=28.675 > *** Worker Wrapper binds [Main]: > Worker Wrapper binds [Main]: alloc=8622264 time=7.070 > *** Simplifier [Main]: > Simplifier [Main]: alloc=598294440 time=554.802 > *** Exitification transformation [Main]: > Exitification transformation [Main]: alloc=26712 time=0.013 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = True}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) > [Main]: alloc=179540608 time=226.938 > *** Common sub-expression [Main]: > Common sub-expression [Main]: alloc=24800 time=0.014 > *** Float inwards [Main]: > Float inwards [Main]: alloc=23168 time=0.010 > *** Simplifier [Main]: > Simplifier [Main]: alloc=382679152 time=318.224 > *** Demand analysis [Main]: > Demand analysis [Main]: alloc=84192056 time=50.989 > *** CoreTidy [Main]: > CoreTidy [Main]: alloc=45347360 time=44.571 > *** CorePrep [Main]: > CorePrep [Main]: alloc=34753448 time=10.917 > *** CoreToStg [Main]: > CoreToStg [Main]: alloc=108293568 time=114.768 > *** CodeGen [Main]: > CodeGen [Main]: alloc=1475393208 time=858.854 > *** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: > WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: > alloc=3732816 time=3.044 > *** systool:as: > systool:as: alloc=132384 time=0.456 > *** initializing unit database: > initializing unit database: alloc=7386016 time=4.306 > *** initializing unit database: > initializing unit database: alloc=4000384 time=12.125 > *** Chasing dependencies: > *** systool:cpp: > systool:cpp: alloc=313896 time=0.486 > Chasing dependencies: alloc=12822240 time=6.459 > Linking /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof > ... > ... > > versus > > % nix-shell --argstr compiler ghc924 > cabal test test-rdfproof > Warning: The package list for 'hackage.haskell.org' is 20 days old. > Run 'cabal update' to get the latest list of available packages. > Resolving dependencies... > Build profile: -w ghc-9.2.4 -O1 > In order, the following will be built (use -v for more details): > - swish-0.10.2.0 (test:test-rdfproof) (first run) > Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. > Building test suite 'test-rdfproof' for swish-0.10.2.0.. > *** initializing unit database: > initializing unit database: alloc=7389248 time=4.462 > *** initializing unit database: > initializing unit database: alloc=4001312 time=11.664 > *** Chasing dependencies: > *** systool:cpp: > systool:cpp: alloc=319464 time=0.481 > Chasing dependencies: alloc=12861208 time=6.331 > [2 of 2] Compiling Main ( tests/RDFProofTest.hs, > /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o > ) > *** Parser [Main]: > Parser [Main]: alloc=25236056 time=23.982 > *** Renamer/typechecker [Main]: > Renamer/typechecker [Main]: alloc=101830968 time=97.529 > *** Desugar [Main]: > Desugar [Main]: alloc=24617072 time=19.187 > *** Simplifier [Main]: > Simplifier [Main]: alloc=665051592 time=558.078 > *** Specialise [Main]: > Specialise [Main]: alloc=44894576 time=30.341 > *** Float out(FOS {Lam = Just 0, > Consts = True, > OverSatApps = False}) [Main]: > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > [Main]: alloc=208060752 time=245.458 > *** Simplifier [Main]: > Simplifier [Main]: alloc=602721856 time=555.073 > *** Simplifier [Main]: > Simplifier [Main]: alloc=563887832 time=529.865 > *** Simplifier [Main]: > Simplifier [Main]: alloc=727381840 time=606.367 > *** Float inwards [Main]: > Float inwards [Main]: alloc=23720 time=0.012 > *** Called arity analysis [Main]: > Called arity analysis [Main]: alloc=25848 time=0.012 > *** Simplifier [Main]: > > which again hangs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simon.peytonjones at gmail.com Tue Sep 6 18:40:34 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 6 Sep 2022 19:40:34 +0100 Subject: Unix library apparently broken In-Reply-To: References: Message-ID: Thanks, good to know. Yes, I did git submodule update. I'll look again tomorrow S On Tue, 6 Sept 2022 at 17:27, Sam Derbyshire wrote: > Hi Simon, > > This is due to my patch 4786acf7 > > landing, which means GHC does better at recognising the redundant pattern > match. > That MR also updated the unix submodule, in order to suppress that pattern > match warning. > > So I would guess that you have not updated the unix submodule after > rebasing your MR; perhaps try "git submodule update"? > The unix submodule is currently on commit 2a6079a2 > > . > > Hope that helps, > > Sam > > On Tue, 6 Sept 2022 at 17:52, Simon Peyton Jones < > simon.peytonjones at gmail.com> wrote: > >> My !8750 builds are failing in the Unix library with the "pattern match >> is redundant" message below. >> >> And indeed the pattern match is redundant. Here's the .hs version of the >> file >> >> unpackRLimit :: CRLim -> ResourceLimit >> unpackRLimit (18446744073709551615) = ResourceLimitInfinity >> {-# LINE 101 "libraries/unix/System/Posix/Resource.hsc" #-} >> unpackRLimit other >> >> {-# LINE 103 "libraries/unix/System/Posix/Resource.hsc" #-} >> | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && >> {-# LINE 104 "libraries/unix/System/Posix/Resource.hsc" #-} >> other == (18446744073709551615) = ResourceLimitUnknown >> {-# LINE 105 "libraries/unix/System/Posix/Resource.hsc" #-} >> >> {-# LINE 106 "libraries/unix/System/Posix/Resource.hsc" #-} >> >> {-# LINE 107 "libraries/unix/System/Posix/Resource.hsc" #-} >> | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && >> {-# LINE 108 "libraries/unix/System/Posix/Resource.hsc" #-} >> other == (18446744073709551615) = ResourceLimitUnknown >> {-# LINE 109 "libraries/unix/System/Posix/Resource.hsc" #-} >> >> {-# LINE 110 "libraries/unix/System/Posix/Resource.hsc" #-} >> | otherwise = ResourceLimit (fromIntegral other) >> >> The red line means that the blue lines will fail. >> >> So the warning looks correct. But it's stopping my CI from working. I >> have no idea why this doesn't happen in HEAD. Can anyone help? >> >> Thanks >> >> Simon >> >> >> Command line: _build/stage0/bin/aarch64-linux-gnu-ghc -Wall -Wcompat >> -fdiagnostics-color=never -dynamic-too -hisuf hi -osuf o -hcsuf hc -static >> -hide-all-packages -no-user-package-db '-package-env -' '-package-db >> _build/stage1/lib/package.conf.d' '-this-unit-id unix-2.7.2.2' '-package-id >> base-4.17.0.0' '-package-id bytestring-0.11.3.1' '-package-id time-1.12.2' >> -i -i/builds/ghc/ghc/_build/stage1/libraries/unix/build >> -i/builds/ghc/ghc/_build/stage1/libraries/unix/build/autogen >> -i/builds/ghc/ghc/libraries/unix -Irts/include >> -I_build/stage1/libraries/unix/build >> -I_build/stage1/libraries/unix/build/include -Ilibraries/unix/include >> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/time-1.12.2/include >> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/bytestring-0.11.3.1/include >> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/base-4.17.0.0/include >> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/ghc-bignum-1.3/include >> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/rts-1.0.2/include >> -optP-include >> -optP_build/stage1/libraries/unix/build/autogen/cabal_macros.h -outputdir >> _build/stage1/libraries/unix/build -Wnoncanonical-monad-instances >> -optc-Wno-error=inline -optP-Wno-nonportable-include-path -c >> _build/stage1/libraries/unix/build/System/Posix/Resource.hs -o >> _build/stage1/libraries/unix/build/System/Posix/Resource.o >> -fllvm-fill-undef-with-garbage -dno-debug-output -Wall -XHaskell2010 >> -no-global-package-db >> -package-db=/builds/ghc/ghc/_build/stage1/lib/package.conf.d >> -ghcversion-file=rts/include/ghcversion.h >> -ghcversion-file=rts/include/ghcversion.h -O -Wno-deprecated-flags -Werror >> -dlint >> ===> Command failed with error code: 1 >> libraries/unix/System/Posix/Resource.hsc:107:7: error: >> [-Woverlapping-patterns, -Werror=overlapping-patterns] >> Pattern match is redundant >> In an equation for ‘unpackRLimit’: >> unpackRLimit other | ((18446744073709551615) :: CRLim) >> /= (18446744073709551615) >> && other == (18446744073709551615) = ... >> | >> 107 | | ((#const RLIM_SAVED_CUR) :: CRLim) /= (#const RLIM_INFINITY) && >> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From dburke.gw at gmail.com Tue Sep 6 19:24:44 2022 From: dburke.gw at gmail.com (Doug Burke) Date: Tue, 6 Sep 2022 15:24:44 -0400 Subject: possible regression in GHC 9.2.4: hang in simplifier (?) when building a test executable In-Reply-To: <72aca27e-4567-5324-aab3-dc1696c49081@iki.fi> References: <72aca27e-4567-5324-aab3-dc1696c49081@iki.fi> Message-ID: Oleg, Thanks for doing this. Doug On Tue, Sep 6, 2022 at 2:15 PM Oleg Grenrus wrote: > > I quickly tried with with {-# OPTIONS_GHC -ddump-timings > -ddump-simpl-trace -ddump-to-file #-} in RDFProofTest.hs and at some > point simplifier does nothing. The simpl-trace file doesn't grow. The > GHC just seems to spin. > > After that > - I checked out the `ghc-9.2.4-release` tag, > - built it --flavour=default+profiled_ghc+no_dynamic_ghc > - built the swish using cabal pointing to GHC used (on my machine: cabal > build -w /code/ghc/_build_ghc-9.2/stage1/bin/ghc test-rdfproof -v3) > - copy pasted the command cabal used to execute ghc, which is long, and > added +RTS -xc -RTS there > > After that, if I ^C when GHC seems to be spinning, the stack trace is > consistently the same: > > ^C*** Exception (reporting due to +RTS -xc): (THUNK_STATIC), stack trace: > GHC.Core.Opt.Pipeline.CallArity, > called from GHC.Driver.Main.Core2Core, > called from GHC.Driver.Main.hscSimplify', > called from GHC.Driver.Main.finish, > called from GHC.Driver.Main.hscIncrementalCompile, > called from GHC.Driver.Make.upsweep_mod.compile_it, > called from GHC.Driver.Make.upsweep_mod, > called from GHC.Driver.Make.upsweep.upsweep', > called from GHC.Driver.Make.upsweep, > called from GHC.Driver.Make.withDeferredDiagnostics, > called from GHC.Driver.Make.load'.checkHowMuch, > called from GHC.Driver.Make.load', > called from GHC.Driver.Make.load, > called from GHC.withCleanupSession, > called from GHC.runGhc, > called from GHC.defaultErrorHandler > > Hopefully this illustrates how to reproduce with your own GHC. > > I also tried with GHC-9.4.1 (using --allow-newer=base) and GHC panics: > > [ 6 of 55] Compiling Swish.GraphMatch > > : error: > panic! (the 'impossible' happened) > GHC version 9.4.1: > funResultTy > GenLabelMap lb_adrG LabelIndex > Call stack: > CallStack (from HasCallStack): > callStackDoc, called at compiler/GHC/Utils/Panic.hs:182:37 in > ghc:GHC.Utils.Panic > pprPanic, called at compiler/GHC/Core/Type.hs:1334:49 in > ghc:GHC.Core.Type > > GHC-9.4.2 panics in the same way. > > Maybe these failures are related? > > - Oleg > > On 6.9.2022 16.02, Doug Burke wrote: > > I have a test executable which will build with ghc 9.2.3 (and many > > older versions) but which appears to hang with GHC 9.2.4. I have > > exhausted what little I know of in debugging this, so any help in > > identifying the problem would be appreciated. Unfortunately it's a > > relatively large application, so the following reproducer requires > > some time/disk space. > > > > Thanks fo ryour time, > > Doug > > > > ----------------------------------------------------------------------------------------------------------------- > > > > I am on a linux machine (ubuntu 22.04) and have seen this with builds > > either with stack or nix. > > > > % git clone https://gitlab.com/dburke/swish temp > > % cd temp > > % git rev-parse HEAD > > 09c92e0fbbea9be86cac5c8e273e1d5915a9eeae > > > > Added to get the timings, but it's not strictly necessary: > > > > % sed -i -e "s/-Wall /-Wall -ddump-timings /" swish.cabal > > > > First a check of a successful build (with stack, GHC 9.0.2): > > > > % stack test --resolver lts-19.22 :test-rdfproof > > ... wait a while > > [2 of 2] Compiling Main > > *** Parser [Main]: > > Parser [Main]: alloc=27576560 time=8.702 > > *** Renamer/typechecker [Main]: > > Renamer/typechecker [Main]: alloc=61957416 time=85.052 > > *** Desugar [Main]: > > Desugar [Main]: alloc=19485576 time=16.095 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=1024590752 time=937.479 > > *** Specialise [Main]: > > Specialise [Main]: alloc=49779464 time=30.480 > > *** Float out(FOS {Lam = Just 0, > > Consts = True, > > OverSatApps = False}) [Main]: > > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > > [Main]: alloc=243444904 time=287.934 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=959971736 time=844.707 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=816465992 time=727.244 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=914290184 time=835.805 > > Float inwards [Main]: alloc=17448 time=0.007 > > Called arity analysis [Main]: alloc=19288 time=0.008 > > *** Float inwards [Main]: > > *** Called arity analysis [Main]: > > *** Simplifier [Main]: > > *** Demand analysis [Main]: > > Simplifier [Main]: alloc=492772800 time=396.191 > > Demand analysis [Main]: alloc=435384136 time=234.248 > > *** Constructed Product Result analysis [Main]: > > Constructed Product Result analysis [Main]: alloc=67395816 time=27.498 > > *** Worker Wrapper binds [Main]: > > Worker Wrapper binds [Main]: alloc=10456160 time=10.538 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=675869616 time=624.538 > > Exitification transformation [Main]: alloc=20416 time=0.007 > > *** Exitification transformation [Main]: > > *** Float out(FOS {Lam = Just 0, > > Consts = True, > > OverSatApps = True}) [Main]: > > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) > > [Main]: alloc=212059304 time=172.872 > > Common sub-expression [Main]: alloc=18768 time=0.008 > > Float inwards [Main]: alloc=17448 time=0.006 > > *** Common sub-expression [Main]: > > *** Float inwards [Main]: > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=430634768 time=397.868 > > *** Demand analysis [Main]: > > Demand analysis [Main]: alloc=144629272 time=70.451 > > *** CoreTidy [Main]: > > CoreTidy [Main]: alloc=48438688 time=44.112 > > *** CorePrep [Main]: > > *** CodeGen [Main]: > > CorePrep [Main]: alloc=15032 time=0.012 > > CodeGen [Main]: alloc=1738308168 time=1051.197 > > *** systool:as: > > systool:as: alloc=118376 time=0.481 > > *** initializing unit database: > > initializing unit database: alloc=15393080 time=21.985 > > *** initializing unit database: > > initializing unit database: alloc=3745512 time=2.507 > > *** Chasing dependencies: > > *** systool:cpp: > > systool:cpp: alloc=213016 time=0.552 > > Chasing dependencies: alloc=11345152 time=5.353 > > Linking .stack-work/dist/x86_64-linux-tinfo6/Cabal-3.4.1.0/build/test-rdfproof/test-rdfproof > > ... > > ... > > ... then it goes on to run the test > > ... > > > > With 9.2.4 it will not build > > > > % > > ... similar to above but with some information about the versions not > > ... fully tested with stack > > ... > > *** Parser [Main]: > > Parser [Main]: alloc=24346008 time=8.730 > > *** Renamer/typechecker [Main]: > > Renamer/typechecker [Main]: alloc=58415776 time=44.077 > > *** Desugar [Main]: > > Desugar [Main]: alloc=22148416 time=15.693 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=651048904 time=530.123 > > *** Specialise [Main]: > > Specialise [Main]: alloc=44412080 time=31.885 > > *** Float out(FOS {Lam = Just 0, > > Consts = True, > > OverSatApps = False}) [Main]: > > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > > [Main]: alloc=207753368 time=259.238 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=599788216 time=548.107 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=562910904 time=474.847 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=725093584 time=643.255 > > Float inwards [Main]: alloc=23720 time=0.011 > > Called arity analysis [Main]: alloc=25856 time=0.012 > > *** Float inwards [Main]: > > *** Called arity analysis [Main]: > > *** Simplifier [Main]: > > > > > > At this point it just makes my laptop fan spin faster wit h one of my > > CPUs pegged at 100%, but it never seems to print anything more. > > > > For those that prefer nix, you can try the following which shows the > > same behavior (these are using the same mangled cabal file to get the > > timings): > > > > % nix-shell --argstr compiler ghc923 > > % cabal test test-rdfproof > > ... > > [2 of 2] Compiling Main ( tests/RDFProofTest.hs, > > /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o > > ) > > *** Parser [Main]: > > Parser [Main]: alloc=25233912 time=9.910 > > *** Renamer/typechecker [Main]: > > Renamer/typechecker [Main]: alloc=57027880 time=45.911 > > *** Desugar [Main]: > > Desugar [Main]: alloc=21808096 time=54.569 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=936319072 time=880.189 > > *** Specialise [Main]: > > Specialise [Main]: alloc=41599784 time=23.425 > > *** Float out(FOS {Lam = Just 0, > > Consts = True, > > OverSatApps = False}) [Main]: > > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > > [Main]: alloc=204955224 time=226.189 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=610153728 time=654.735 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=566346328 time=549.298 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=801330080 time=802.428 > > *** Float inwards [Main]: > > Float inwards [Main]: alloc=23160 time=0.012 > > *** Called arity analysis [Main]: > > Called arity analysis [Main]: alloc=25296 time=0.013 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=423629864 time=320.611 > > *** Demand analysis [Main]: > > Demand analysis [Main]: alloc=253018800 time=175.884 > > *** Constructed Product Result analysis [Main]: > > Constructed Product Result analysis [Main]: alloc=74681224 time=28.675 > > *** Worker Wrapper binds [Main]: > > Worker Wrapper binds [Main]: alloc=8622264 time=7.070 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=598294440 time=554.802 > > *** Exitification transformation [Main]: > > Exitification transformation [Main]: alloc=26712 time=0.013 > > *** Float out(FOS {Lam = Just 0, > > Consts = True, > > OverSatApps = True}) [Main]: > > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = True}) > > [Main]: alloc=179540608 time=226.938 > > *** Common sub-expression [Main]: > > Common sub-expression [Main]: alloc=24800 time=0.014 > > *** Float inwards [Main]: > > Float inwards [Main]: alloc=23168 time=0.010 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=382679152 time=318.224 > > *** Demand analysis [Main]: > > Demand analysis [Main]: alloc=84192056 time=50.989 > > *** CoreTidy [Main]: > > CoreTidy [Main]: alloc=45347360 time=44.571 > > *** CorePrep [Main]: > > CorePrep [Main]: alloc=34753448 time=10.917 > > *** CoreToStg [Main]: > > CoreToStg [Main]: alloc=108293568 time=114.768 > > *** CodeGen [Main]: > > CodeGen [Main]: alloc=1475393208 time=858.854 > > *** WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: > > WriteIface [/home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.hi]: > > alloc=3732816 time=3.044 > > *** systool:as: > > systool:as: alloc=132384 time=0.456 > > *** initializing unit database: > > initializing unit database: alloc=7386016 time=4.306 > > *** initializing unit database: > > initializing unit database: alloc=4000384 time=12.125 > > *** Chasing dependencies: > > *** systool:cpp: > > systool:cpp: alloc=313896 time=0.486 > > Chasing dependencies: alloc=12822240 time=6.459 > > Linking /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.3/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof > > ... > > ... > > > > versus > > > > % nix-shell --argstr compiler ghc924 > > cabal test test-rdfproof > > Warning: The package list for 'hackage.haskell.org' is 20 days old. > > Run 'cabal update' to get the latest list of available packages. > > Resolving dependencies... > > Build profile: -w ghc-9.2.4 -O1 > > In order, the following will be built (use -v for more details): > > - swish-0.10.2.0 (test:test-rdfproof) (first run) > > Preprocessing test suite 'test-rdfproof' for swish-0.10.2.0.. > > Building test suite 'test-rdfproof' for swish-0.10.2.0.. > > *** initializing unit database: > > initializing unit database: alloc=7389248 time=4.462 > > *** initializing unit database: > > initializing unit database: alloc=4001312 time=11.664 > > *** Chasing dependencies: > > *** systool:cpp: > > systool:cpp: alloc=319464 time=0.481 > > Chasing dependencies: alloc=12861208 time=6.331 > > [2 of 2] Compiling Main ( tests/RDFProofTest.hs, > > /home/dburke/rdf/temp/dist-newstyle/build/x86_64-linux/ghc-9.2.4/swish-0.10.2.0/t/test-rdfproof/build/test-rdfproof/test-rdfproof-tmp/Main.o > > ) > > *** Parser [Main]: > > Parser [Main]: alloc=25236056 time=23.982 > > *** Renamer/typechecker [Main]: > > Renamer/typechecker [Main]: alloc=101830968 time=97.529 > > *** Desugar [Main]: > > Desugar [Main]: alloc=24617072 time=19.187 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=665051592 time=558.078 > > *** Specialise [Main]: > > Specialise [Main]: alloc=44894576 time=30.341 > > *** Float out(FOS {Lam = Just 0, > > Consts = True, > > OverSatApps = False}) [Main]: > > Float out(FOS {Lam = Just 0, Consts = True, OverSatApps = False}) > > [Main]: alloc=208060752 time=245.458 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=602721856 time=555.073 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=563887832 time=529.865 > > *** Simplifier [Main]: > > Simplifier [Main]: alloc=727381840 time=606.367 > > *** Float inwards [Main]: > > Float inwards [Main]: alloc=23720 time=0.012 > > *** Called arity analysis [Main]: > > Called arity analysis [Main]: alloc=25848 time=0.012 > > *** Simplifier [Main]: > > > > which again hangs > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simon.peytonjones at gmail.com Wed Sep 7 10:47:40 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Wed, 7 Sep 2022 11:47:40 +0100 Subject: Unix library apparently broken In-Reply-To: References: Message-ID: Thanks Sam. As you'll see on !8750 pointing to the right commit seems to have fixed !8750. I think I must have inadvertently committed a wrong unix-library submodule change. I'm not very clear on - Given a particular 'master' commit C from the main GHC repo (e.g. I've rebased my patch on C) - How do I identify the 'unix' commit that C needs? It might not be the head of the unix repo. Simon On Tue, 6 Sept 2022 at 19:40, Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Thanks, good to know. Yes, I did git submodule update. I'll look again > tomorrow > > S > > On Tue, 6 Sept 2022 at 17:27, Sam Derbyshire > wrote: > >> Hi Simon, >> >> This is due to my patch 4786acf7 >> >> landing, which means GHC does better at recognising the redundant pattern >> match. >> That MR also updated the unix submodule, in order to suppress that >> pattern match warning. >> >> So I would guess that you have not updated the unix submodule after >> rebasing your MR; perhaps try "git submodule update"? >> The unix submodule is currently on commit 2a6079a2 >> >> . >> >> Hope that helps, >> >> Sam >> >> On Tue, 6 Sept 2022 at 17:52, Simon Peyton Jones < >> simon.peytonjones at gmail.com> wrote: >> >>> My !8750 builds are failing in the Unix library with the "pattern match >>> is redundant" message below. >>> >>> And indeed the pattern match is redundant. Here's the .hs version of >>> the file >>> >>> unpackRLimit :: CRLim -> ResourceLimit >>> unpackRLimit (18446744073709551615) = ResourceLimitInfinity >>> {-# LINE 101 "libraries/unix/System/Posix/Resource.hsc" #-} >>> unpackRLimit other >>> >>> {-# LINE 103 "libraries/unix/System/Posix/Resource.hsc" #-} >>> | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && >>> {-# LINE 104 "libraries/unix/System/Posix/Resource.hsc" #-} >>> other == (18446744073709551615) = ResourceLimitUnknown >>> {-# LINE 105 "libraries/unix/System/Posix/Resource.hsc" #-} >>> >>> {-# LINE 106 "libraries/unix/System/Posix/Resource.hsc" #-} >>> >>> {-# LINE 107 "libraries/unix/System/Posix/Resource.hsc" #-} >>> | ((18446744073709551615) :: CRLim) /= (18446744073709551615) && >>> {-# LINE 108 "libraries/unix/System/Posix/Resource.hsc" #-} >>> other == (18446744073709551615) = ResourceLimitUnknown >>> {-# LINE 109 "libraries/unix/System/Posix/Resource.hsc" #-} >>> >>> {-# LINE 110 "libraries/unix/System/Posix/Resource.hsc" #-} >>> | otherwise = ResourceLimit (fromIntegral other) >>> >>> The red line means that the blue lines will fail. >>> >>> So the warning looks correct. But it's stopping my CI from working. I >>> have no idea why this doesn't happen in HEAD. Can anyone help? >>> >>> Thanks >>> >>> Simon >>> >>> >>> Command line: _build/stage0/bin/aarch64-linux-gnu-ghc -Wall -Wcompat >>> -fdiagnostics-color=never -dynamic-too -hisuf hi -osuf o -hcsuf hc -static >>> -hide-all-packages -no-user-package-db '-package-env -' '-package-db >>> _build/stage1/lib/package.conf.d' '-this-unit-id unix-2.7.2.2' '-package-id >>> base-4.17.0.0' '-package-id bytestring-0.11.3.1' '-package-id time-1.12.2' >>> -i -i/builds/ghc/ghc/_build/stage1/libraries/unix/build >>> -i/builds/ghc/ghc/_build/stage1/libraries/unix/build/autogen >>> -i/builds/ghc/ghc/libraries/unix -Irts/include >>> -I_build/stage1/libraries/unix/build >>> -I_build/stage1/libraries/unix/build/include -Ilibraries/unix/include >>> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/time-1.12.2/include >>> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/bytestring-0.11.3.1/include >>> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/base-4.17.0.0/include >>> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/ghc-bignum-1.3/include >>> -I/builds/ghc/ghc/_build/stage1/lib/aarch64-linux-ghc-9.5.20220906/rts-1.0.2/include >>> -optP-include >>> -optP_build/stage1/libraries/unix/build/autogen/cabal_macros.h -outputdir >>> _build/stage1/libraries/unix/build -Wnoncanonical-monad-instances >>> -optc-Wno-error=inline -optP-Wno-nonportable-include-path -c >>> _build/stage1/libraries/unix/build/System/Posix/Resource.hs -o >>> _build/stage1/libraries/unix/build/System/Posix/Resource.o >>> -fllvm-fill-undef-with-garbage -dno-debug-output -Wall -XHaskell2010 >>> -no-global-package-db >>> -package-db=/builds/ghc/ghc/_build/stage1/lib/package.conf.d >>> -ghcversion-file=rts/include/ghcversion.h >>> -ghcversion-file=rts/include/ghcversion.h -O -Wno-deprecated-flags -Werror >>> -dlint >>> ===> Command failed with error code: 1 >>> libraries/unix/System/Posix/Resource.hsc:107:7: error: >>> [-Woverlapping-patterns, -Werror=overlapping-patterns] >>> Pattern match is redundant >>> In an equation for ‘unpackRLimit’: >>> unpackRLimit other | ((18446744073709551615) :: CRLim) >>> /= (18446744073709551615) >>> && other == (18446744073709551615) = ... >>> | >>> 107 | | ((#const RLIM_SAVED_CUR) :: CRLim) /= (#const RLIM_INFINITY) && >>> | ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^... >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From pi.boy.travis at gmail.com Fri Sep 9 17:14:18 2022 From: pi.boy.travis at gmail.com (Travis Whitaker) Date: Fri, 9 Sep 2022 10:14:18 -0700 Subject: When do we get loads/stores with volatile semantics (if we get them at all)? Message-ID: Hello Haskell Friends, Recently I noticed some strange behavior in a program that uses peek/poke to manipulate memory mapped hardware registers, that smells a lot like missing volatile semantics to me. It hadn’t occurred to me that peek/poke might not have volatile semantics (they return an IO, and that IO has to happen, right?), but naturally once they’re lowered all such bets are off. This made me wonder: - Do we have a type like #Addr whose loads/stores have volatile semantics? - Do we have any primops with volatile semantics at all? - Are there any tricks one could use to get volatile semantics out of base’s peek/poke functions? Poking around, I’m afraid the answer to all three of these is “no.” If so, I’d be very interested in contributing volatile load/store primops and working out some way to make them easily available from Foreign.Storable. Does no such thing currently exist or am I missing something? Thanks for all your ongoing efforts, Travis -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Fri Sep 9 17:26:56 2022 From: cheng.shao at tweag.io (Cheng Shao) Date: Fri, 9 Sep 2022 19:26:56 +0200 Subject: When do we get loads/stores with volatile semantics (if we get them at all)? In-Reply-To: References: Message-ID: Hi Travis, - Do we have a type like #Addr whose loads/stores have volatile semantics? Nope - Do we have any primops with volatile semantics at all? We have atomicReadIntArray#, atomicWriteIntArray# prim ops, the read/write on MutableByteArray# will introduce proper memory barriers. However there's no Addr# equivalent yet. - Are there any tricks one could use to get volatile semantics out of base’s peek/poke functions? It's always possible to write cbits for volatile load/store. To avoid the overhead of unsafe foreign ccalls, the proper thing to do would be to add primops, and lower them to MO_AtomicRead/MO_AtomicWrite at the Cmm level. Cheers, Cheng On Fri, Sep 9, 2022 at 7:14 PM Travis Whitaker wrote: > > Hello Haskell Friends, > > Recently I noticed some strange behavior in a program that uses peek/poke to manipulate memory mapped hardware registers, that smells a lot like missing volatile semantics to me. It hadn’t occurred to me that peek/poke might not have volatile semantics (they return an IO, and that IO has to happen, right?), but naturally once they’re lowered all such bets are off. This made me wonder: > > - Do we have a type like #Addr whose loads/stores have volatile semantics? > > - Do we have any primops with volatile semantics at all? > > - Are there any tricks one could use to get volatile semantics out of base’s peek/poke functions? > > Poking around, I’m afraid the answer to all three of these is “no.” If so, I’d be very interested in contributing volatile load/store primops and working out some way to make them easily available from Foreign.Storable. Does no such thing currently exist or am I missing something? > > Thanks for all your ongoing efforts, > > Travis > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From ben at well-typed.com Fri Sep 9 18:19:00 2022 From: ben at well-typed.com (Ben Gamari) Date: Fri, 09 Sep 2022 14:19:00 -0400 Subject: When do we get loads/stores with volatile semantics (if we get them at all)? In-Reply-To: References: Message-ID: <87y1usl8cd.fsf@smart-cactus.org> Travis Whitaker writes: > Hello Haskell Friends, > > Recently I noticed some strange behavior in a program that uses peek/poke > to manipulate memory mapped hardware registers, that smells a lot like > missing volatile semantics to me. It hadn’t occurred to me that peek/poke > might not have volatile semantics (they return an IO, and that IO has to > happen, right?), but naturally once they’re lowered all such bets are off. > This made me wonder: > > - Do we have a type like #Addr whose loads/stores have volatile semantics? > We don't. > - Do we have any primops with volatile semantics at all? > I have in the past wanted to introduce acquire/release accesses in Cmm (instead of the arbitrary barriers that we use today), but I have never considered adding volatile. The semantics of the {read,write}*Addr# family of primops are a bit under-specified. However, I think you are right that it would be reasonable to assume them to have semantics similar to those of non-atomic access in C (or slightly stronger since we *do* guarantee that the access will actually reach memory such that it will be visible to a non-Haskell program eventually). I'd be interested in knowing more about your application is here. In general accessing memory mapped registers from user-space requires extreme care (typically with cooperation from the kernel since you need write-through physical memory mappings); volatile alone isn't sufficient. What concretely are you doing? > - Are there any tricks one could use to get volatile semantics out of > base’s peek/poke functions? > I don't believe so. In your situation I would likely introduce a set of foreign functions which provides a volatile reads/writes. However, as noted above, just `volatile` alone won't be sufficient to guarantee robust access to memory-mapped registers. > Poking around, I’m afraid the answer to all three of these is “no.” If so, > I’d be very interested in contributing volatile load/store primops and > working out some way to make them easily available from Foreign.Storable. > Does no such thing currently exist or am I missing something? > I think the first thing to ask is what you want from your "volatile" primops. I'd be somewhat reluctant to add a primops for memory mapped IO since, as noted above, "volatile" is only half of the story and the other half is highly platform dependent. However, I am happy to discuss. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simon.peytonjones at gmail.com Sun Sep 11 13:10:03 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Sun, 11 Sep 2022 14:10:03 +0100 Subject: GHC compiler perf CI Message-ID: Dear devs I used to use the build *x86_64-linux-deb10-int_native-validate* as the place to look for compiler/bytes-allocated changes in perf/compiler. But now it doesn't show those results any more, only runtime/bytes-allocated in perf/should_run. - Should we not run perf/compiler in every build? - Why has it gone from the build above - Which build should I look at to see perf/compiler data Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From lanablack at amok.cc Tue Sep 13 15:21:25 2022 From: lanablack at amok.cc (Lana Black) Date: Tue, 13 Sep 2022 15:21:25 +0000 Subject: Runtime linker Message-ID: <5013805.31r3eYUQgx@glow> Hello, My personal project involves making a port of GHC for an almost bare-bones environment, which doesn't provide runtime linking support. GHC configure script sets `TargetHasRTSLinker` flag, but it seems to be ignored in RTS itself, and the linker is built regardless. Is this a regression, perhaps due to the migration from Makefiles to Hadrian? Or is building RTS without runtime linker no longer supported? Thank you. From ben at smart-cactus.org Tue Sep 13 19:18:45 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Tue, 13 Sep 2022 15:18:45 -0400 Subject: Runtime linker In-Reply-To: <5013805.31r3eYUQgx@glow> References: <5013805.31r3eYUQgx@glow> Message-ID: <87leqnhym6.fsf@smart-cactus.org> Lana Black writes: > Hello, > > My personal project involves making a port of GHC for an almost bare-bones > environment, which doesn't provide runtime linking support. GHC configure > script sets `TargetHasRTSLinker` flag, but it seems to be ignored in RTS > itself, and the linker is built regardless. > Just to confirm: By "runtime linking" do you mean dynamic linking or support in the RTS's own linker? In general GHC uses "runtime linking" to mean the latter. > Is this a regression, perhaps due to the migration from Makefiles to Hadrian? > Or is building RTS without runtime linker no longer supported? I suspect what you are observing is expected behavior: The linker is built regardless of whether TargetHasRTSLinker is set. This field is really only used by the testsuite driver to skip tests which would require the RTS linker. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From lanablack at amok.cc Tue Sep 13 20:08:17 2022 From: lanablack at amok.cc (Lana Black) Date: Tue, 13 Sep 2022 20:08:17 +0000 Subject: Runtime linker In-Reply-To: <87leqnhym6.fsf@smart-cactus.org> References: <5013805.31r3eYUQgx@glow> <87leqnhym6.fsf@smart-cactus.org> Message-ID: <4954724.LvFx2qVVIh@glow> On Tuesday, 13 September 2022 19:18:45 UTC Ben Gamari wrote: > Just to confirm: By "runtime linking" do you mean dynamic linking or support > in the RTS's own linker? In general GHC uses "runtime linking" to mean the > latter. Indeed, I mean the latter. Specifically, the code in `rts/linker` in the GHC tree. > I suspect what you are observing is expected behavior: The linker is > built regardless of whether TargetHasRTSLinker is set. This field is > really only used by the testsuite driver to skip tests which would > require the RTS linker. Makes sense. Thank you! From csaba.hruska at gmail.com Wed Sep 14 16:11:56 2022 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Wed, 14 Sep 2022 18:11:56 +0200 Subject: Alternative to isTypeLevPoly Message-ID: Hello GHC Devs, I've noticed that the `isTypeLevPoly` function has been removed from GHC since 9.4. I used it to decide the validity of querying the representation type of every value in the STG IR. It was mandatory to prevent GHC panics, because there are a lot of partial functions in GHC. Is there an alternative to `isTypeLevPoly` in GHC 9.4? Best regards, Csaba Hruska -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.derbyshire at gmail.com Wed Sep 14 16:19:35 2022 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Wed, 14 Sep 2022 18:19:35 +0200 Subject: Alternative to isTypeLevPoly In-Reply-To: References: Message-ID: Hi Csaba, I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type. Best, Sam On Wed, 14 Sept 2022 at 18:12, Csaba Hruska wrote: > Hello GHC Devs, > > I've noticed that the `isTypeLevPoly` function has been removed from GHC > since 9.4. > I used it to decide the validity of querying the representation type of > every value in the STG IR. > It was mandatory to prevent GHC panics, because there are a lot of partial > functions in GHC. > Is there an alternative to `isTypeLevPoly` in GHC 9.4? > > Best regards, > Csaba Hruska > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Wed Sep 14 16:40:07 2022 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Wed, 14 Sep 2022 18:40:07 +0200 Subject: Alternative to isTypeLevPoly In-Reply-To: References: Message-ID: Hi, Thanks for the tip, I've tried it and it behaves differently than isTypeLevPoly. I can get panic when querying the reptype for fixed reptypes. That means isTypeLevPoly semantically is not the same as the negated result of typeHasFixedRuntimeRep. On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, wrote: > Hi Csaba, > > I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type. > > Best, > > Sam > > On Wed, 14 Sept 2022 at 18:12, Csaba Hruska > wrote: > >> Hello GHC Devs, >> >> I've noticed that the `isTypeLevPoly` function has been removed from GHC >> since 9.4. >> I used it to decide the validity of querying the representation type of >> every value in the STG IR. >> It was mandatory to prevent GHC panics, because there are a lot of >> partial functions in GHC. >> Is there an alternative to `isTypeLevPoly` in GHC 9.4? >> >> Best regards, >> Csaba Hruska >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From sam.derbyshire at gmail.com Wed Sep 14 16:44:26 2022 From: sam.derbyshire at gmail.com (Sam Derbyshire) Date: Wed, 14 Sep 2022 18:44:26 +0200 Subject: Alternative to isTypeLevPoly In-Reply-To: References: Message-ID: Hmm, that's strange, both isTypeLevPoly and typeHasFixedRuntimeRep have the same precondition: the kind of the type is of the form TYPE rep. So they should panic in the same circumstances. Can you give a bit more information? What panics are you running into? On Wed, 14 Sept 2022 at 18:40, Csaba Hruska wrote: > Hi, > Thanks for the tip, I've tried it and it behaves differently than > isTypeLevPoly. I can get panic when querying the reptype for fixed > reptypes. That means isTypeLevPoly semantically is not the same as the > negated result of typeHasFixedRuntimeRep. > > On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, > wrote: > >> Hi Csaba, >> >> I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type. >> >> Best, >> >> Sam >> >> On Wed, 14 Sept 2022 at 18:12, Csaba Hruska >> wrote: >> >>> Hello GHC Devs, >>> >>> I've noticed that the `isTypeLevPoly` function has been removed from GHC >>> since 9.4. >>> I used it to decide the validity of querying the representation type of >>> every value in the STG IR. >>> It was mandatory to prevent GHC panics, because there are a lot of >>> partial functions in GHC. >>> Is there an alternative to `isTypeLevPoly` in GHC 9.4? >>> >>> Best regards, >>> Csaba Hruska >>> _______________________________________________ >>> ghc-devs mailing list >>> ghc-devs at haskell.org >>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>> >> -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Thu Sep 15 11:12:23 2022 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Thu, 15 Sep 2022 13:12:23 +0200 Subject: Alternative to isTypeLevPoly In-Reply-To: References: Message-ID: I've investigated a bit more. You are right `typeHasFixedRuntimeRep` works fine, the panic was caused by querying the representation type of `LitRubbish` type argument. In some cases `getRuntimeRep` causes GHC panic for `LitRubbish` type arguments. I did solve the issue with special casing the LitRubbish type argument handling by using only the `runtimeRepPrimRep` function. In the general case I tested the type with `isUnboxedTupleType` and `isUnboxedSumType` which rely on `getRuntimeRep`. Thanks for the tips and feedback. Regards, Csaba On Wed, Sep 14, 2022 at 6:44 PM Sam Derbyshire wrote: > Hmm, that's strange, both isTypeLevPoly and typeHasFixedRuntimeRep have > the same precondition: the kind of the type is of the form TYPE rep. So > they should panic in the same circumstances. Can you give a bit more > information? What panics are you running into? > > On Wed, 14 Sept 2022 at 18:40, Csaba Hruska > wrote: > >> Hi, >> Thanks for the tip, I've tried it and it behaves differently than >> isTypeLevPoly. I can get panic when querying the reptype for fixed >> reptypes. That means isTypeLevPoly semantically is not the same as the >> negated result of typeHasFixedRuntimeRep. >> >> On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, >> wrote: >> >>> Hi Csaba, >>> >>> I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type. >>> >>> Best, >>> >>> Sam >>> >>> On Wed, 14 Sept 2022 at 18:12, Csaba Hruska >>> wrote: >>> >>>> Hello GHC Devs, >>>> >>>> I've noticed that the `isTypeLevPoly` function has been removed from >>>> GHC since 9.4. >>>> I used it to decide the validity of querying the representation type of >>>> every value in the STG IR. >>>> It was mandatory to prevent GHC panics, because there are a lot of >>>> partial functions in GHC. >>>> Is there an alternative to `isTypeLevPoly` in GHC 9.4? >>>> >>>> Best regards, >>>> Csaba Hruska >>>> _______________________________________________ >>>> ghc-devs mailing list >>>> ghc-devs at haskell.org >>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >>>> >>> -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Sep 15 13:03:03 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 15 Sep 2022 14:03:03 +0100 Subject: Haskell program coverage Message-ID: Matthias, David, David Binder apparently has some PRs for GHC's HPC program coverage stuff that have somehow languished un-merged for some time. David, can you point us to them, so we can look? Matthias wants to extend HPC in a number of ways. See here and here . Maybe you want to talk to each other? You are both here at ICFP! And it would be great to have a little team that cared about HPC more generally, and could look after it. Thanks. Apologies if I have misunderstood anyone. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From krz.gogolewski at gmail.com Thu Sep 15 15:36:01 2022 From: krz.gogolewski at gmail.com (Krzysztof Gogolewski) Date: Thu, 15 Sep 2022 17:36:01 +0200 Subject: Alternative to isTypeLevPoly In-Reply-To: References: Message-ID: The type argument to LitRubbish should be a fixed RuntimeRep. If it is not, you can file a bug. I have fixed a related bug in f435d55fe969e7. Krzysztof On Thu, Sep 15, 2022 at 1:12 PM Csaba Hruska wrote: > > I've investigated a bit more. You are right `typeHasFixedRuntimeRep` works fine, the panic was caused by querying the representation type of `LitRubbish` type argument. In some cases `getRuntimeRep` causes GHC panic for `LitRubbish` type arguments. > I did solve the issue with special casing the LitRubbish type argument handling by using only the `runtimeRepPrimRep` function. In the general case I tested the type with `isUnboxedTupleType` and `isUnboxedSumType` which rely on `getRuntimeRep`. > Thanks for the tips and feedback. > Regards, > Csaba > > On Wed, Sep 14, 2022 at 6:44 PM Sam Derbyshire wrote: >> >> Hmm, that's strange, both isTypeLevPoly and typeHasFixedRuntimeRep have the same precondition: the kind of the type is of the form TYPE rep. So they should panic in the same circumstances. Can you give a bit more information? What panics are you running into? >> >> On Wed, 14 Sept 2022 at 18:40, Csaba Hruska wrote: >>> >>> Hi, >>> Thanks for the tip, I've tried it and it behaves differently than isTypeLevPoly. I can get panic when querying the reptype for fixed reptypes. That means isTypeLevPoly semantically is not the same as the negated result of typeHasFixedRuntimeRep. >>> >>> On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, wrote: >>>> >>>> Hi Csaba, >>>> >>>> I think you want the function typeHasFixedRuntimeRep from GHC.Core.Type. >>>> >>>> Best, >>>> >>>> Sam >>>> >>>> On Wed, 14 Sept 2022 at 18:12, Csaba Hruska wrote: >>>>> >>>>> Hello GHC Devs, >>>>> >>>>> I've noticed that the `isTypeLevPoly` function has been removed from GHC since 9.4. >>>>> I used it to decide the validity of querying the representation type of every value in the STG IR. >>>>> It was mandatory to prevent GHC panics, because there are a lot of partial functions in GHC. >>>>> Is there an alternative to `isTypeLevPoly` in GHC 9.4? >>>>> >>>>> Best regards, >>>>> Csaba Hruska >>>>> _______________________________________________ >>>>> ghc-devs mailing list >>>>> ghc-devs at haskell.org >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From simon.peytonjones at gmail.com Thu Sep 15 20:14:43 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 15 Sep 2022 21:14:43 +0100 Subject: Alternative to isTypeLevPoly In-Reply-To: References: Message-ID: > > The type argument to LitRubbish should be a fixed RuntimeRep. If it is > not, you can file a bug > Yes! Please file a bug if you find this. On Thu, 15 Sept 2022 at 16:36, Krzysztof Gogolewski < krz.gogolewski at gmail.com> wrote: > The type argument to LitRubbish should be a fixed RuntimeRep. If it is > not, you can file a bug. I have fixed a related bug in f435d55fe969e7. > > Krzysztof > > On Thu, Sep 15, 2022 at 1:12 PM Csaba Hruska > wrote: > > > > I've investigated a bit more. You are right `typeHasFixedRuntimeRep` > works fine, the panic was caused by querying the representation type of > `LitRubbish` type argument. In some cases `getRuntimeRep` causes GHC panic > for `LitRubbish` type arguments. > > I did solve the issue with special casing the LitRubbish type argument > handling by using only the `runtimeRepPrimRep` function. In the general > case I tested the type with `isUnboxedTupleType` and `isUnboxedSumType` > which rely on `getRuntimeRep`. > > Thanks for the tips and feedback. > > Regards, > > Csaba > > > > On Wed, Sep 14, 2022 at 6:44 PM Sam Derbyshire > wrote: > >> > >> Hmm, that's strange, both isTypeLevPoly and typeHasFixedRuntimeRep have > the same precondition: the kind of the type is of the form TYPE rep. So > they should panic in the same circumstances. Can you give a bit more > information? What panics are you running into? > >> > >> On Wed, 14 Sept 2022 at 18:40, Csaba Hruska > wrote: > >>> > >>> Hi, > >>> Thanks for the tip, I've tried it and it behaves differently than > isTypeLevPoly. I can get panic when querying the reptype for fixed > reptypes. That means isTypeLevPoly semantically is not the same as the > negated result of typeHasFixedRuntimeRep. > >>> > >>> On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, > wrote: > >>>> > >>>> Hi Csaba, > >>>> > >>>> I think you want the function typeHasFixedRuntimeRep from > GHC.Core.Type. > >>>> > >>>> Best, > >>>> > >>>> Sam > >>>> > >>>> On Wed, 14 Sept 2022 at 18:12, Csaba Hruska > wrote: > >>>>> > >>>>> Hello GHC Devs, > >>>>> > >>>>> I've noticed that the `isTypeLevPoly` function has been removed from > GHC since 9.4. > >>>>> I used it to decide the validity of querying the representation type > of every value in the STG IR. > >>>>> It was mandatory to prevent GHC panics, because there are a lot of > partial functions in GHC. > >>>>> Is there an alternative to `isTypeLevPoly` in GHC 9.4? > >>>>> > >>>>> Best regards, > >>>>> Csaba Hruska > >>>>> _______________________________________________ > >>>>> ghc-devs mailing list > >>>>> ghc-devs at haskell.org > >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > > > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From csaba.hruska at gmail.com Fri Sep 16 12:05:10 2022 From: csaba.hruska at gmail.com (Csaba Hruska) Date: Fri, 16 Sep 2022 14:05:10 +0200 Subject: Alternative to isTypeLevPoly In-Reply-To: References: Message-ID: As I see there is no bug at all. I just did not read the description comment for `LitRubbish`. I have misunderstood the meaning of the `Type` argument. According to the comment it is more like `RuntimeRepType` or even `FRRType`. https://github.com/ghc/ghc/blob/master/compiler/GHC/Types/Literal.hs#L134-L142 https://github.com/ghc/ghc/blob/master/compiler/GHC/Core/TyCo/Rep.hs#L116-L121 > LitRubbish Type -- ^ A nonsense value of the given > -- representation. See Note [Rubbish literals]. > -- > -- The Type argument, rr, is of kind RuntimeRep. > -- The type of the literal is forall (a:TYPE rr). a > Regards, Csaba On Thu, Sep 15, 2022 at 10:14 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > The type argument to LitRubbish should be a fixed RuntimeRep. If it is >> not, you can file a bug >> > > Yes! Please file a bug if you find this. > > On Thu, 15 Sept 2022 at 16:36, Krzysztof Gogolewski < > krz.gogolewski at gmail.com> wrote: > >> The type argument to LitRubbish should be a fixed RuntimeRep. If it is >> not, you can file a bug. I have fixed a related bug in f435d55fe969e7. >> >> Krzysztof >> >> On Thu, Sep 15, 2022 at 1:12 PM Csaba Hruska >> wrote: >> > >> > I've investigated a bit more. You are right `typeHasFixedRuntimeRep` >> works fine, the panic was caused by querying the representation type of >> `LitRubbish` type argument. In some cases `getRuntimeRep` causes GHC panic >> for `LitRubbish` type arguments. >> > I did solve the issue with special casing the LitRubbish type argument >> handling by using only the `runtimeRepPrimRep` function. In the general >> case I tested the type with `isUnboxedTupleType` and `isUnboxedSumType` >> which rely on `getRuntimeRep`. >> > Thanks for the tips and feedback. >> > Regards, >> > Csaba >> > >> > On Wed, Sep 14, 2022 at 6:44 PM Sam Derbyshire < >> sam.derbyshire at gmail.com> wrote: >> >> >> >> Hmm, that's strange, both isTypeLevPoly and typeHasFixedRuntimeRep >> have the same precondition: the kind of the type is of the form TYPE rep. >> So they should panic in the same circumstances. Can you give a bit more >> information? What panics are you running into? >> >> >> >> On Wed, 14 Sept 2022 at 18:40, Csaba Hruska >> wrote: >> >>> >> >>> Hi, >> >>> Thanks for the tip, I've tried it and it behaves differently than >> isTypeLevPoly. I can get panic when querying the reptype for fixed >> reptypes. That means isTypeLevPoly semantically is not the same as the >> negated result of typeHasFixedRuntimeRep. >> >>> >> >>> On Wed, 14 Sep 2022, 18:19 Sam Derbyshire, >> wrote: >> >>>> >> >>>> Hi Csaba, >> >>>> >> >>>> I think you want the function typeHasFixedRuntimeRep from >> GHC.Core.Type. >> >>>> >> >>>> Best, >> >>>> >> >>>> Sam >> >>>> >> >>>> On Wed, 14 Sept 2022 at 18:12, Csaba Hruska >> wrote: >> >>>>> >> >>>>> Hello GHC Devs, >> >>>>> >> >>>>> I've noticed that the `isTypeLevPoly` function has been removed >> from GHC since 9.4. >> >>>>> I used it to decide the validity of querying the representation >> type of every value in the STG IR. >> >>>>> It was mandatory to prevent GHC panics, because there are a lot of >> partial functions in GHC. >> >>>>> Is there an alternative to `isTypeLevPoly` in GHC 9.4? >> >>>>> >> >>>>> Best regards, >> >>>>> Csaba Hruska >> >>>>> _______________________________________________ >> >>>>> ghc-devs mailing list >> >>>>> ghc-devs at haskell.org >> >>>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> _______________________________________________ >> ghc-devs mailing list >> ghc-devs at haskell.org >> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs >> > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Thu Sep 22 16:37:55 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Thu, 22 Sep 2022 17:37:55 +0100 Subject: Tier 1 architectures Message-ID: Ben, Matthew, Moritz, and friends Is this wiki page about architectures still accurate? https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms For example, ARM is not Tier 1, or "apple silicon". Yet I know some of our developers have invested lots of effort in other architectures, so maybe those efforts are not reflected here. Relevant is Moritz's post about 32-bit architectures . We should in due course add Javascript and Web Assembly as Tier 1 back ends? Are we saying "if your customer bases uses Tier 2 architectures, you can't rely on GHC from one release to the next"? I wonder if there are companies for which Tier-2 architectures are mission-critical. Mis-aligned expectations cause upset. I mention all this because it is relevant to our stability guarantees. Every time we release we should point to this list. Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at well-typed.com Thu Sep 22 19:21:50 2022 From: ben at well-typed.com (Ben Gamari) Date: Thu, 22 Sep 2022 15:21:50 -0400 Subject: Tier 1 architectures In-Reply-To: References: Message-ID: <87r103gqq2.fsf@smart-cactus.org> Simon Peyton Jones writes: > Ben, Matthew, Moritz, and friends > > Is this wiki page about architectures still accurate? > https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms > Hi Simon, Indeed there were a few inaccuracies on that page; I have fixed these and generally cleaned up the page. > For example, ARM is not Tier 1, or "apple silicon". > > Yet I know some of our developers have invested lots of effort in other > architectures, so maybe those efforts are not reflected here. > Fairly recently there has been work on RISC-V (rv64) and PowerPC (ppc64le), as well as some work on s390x via LLVM. However, I wouldn't consider any of these Tier 1. > Relevant is Moritz's post about 32-bit architectures > > . > > We should in due course add Javascript and Web Assembly as Tier 1 back ends? > Indeed, that is the plan although 9.6 will rather ship these as Tier 2 targets. > Are we saying "if your customer bases uses Tier 2 architectures, you can't > rely on GHC from one release to the next"? I wonder if there are companies > for which Tier-2 architectures are mission-critical. Mis-aligned > expectations cause upset. > I have heard that some people are using amd64/FreeBSD, although that can very nearly be promoted to a Tier 1 now. Bodigrim once mentioned that he was considering deploying Haskell on s390x, although I'm not sure what became of that. Otherwise I would be quite surprised if any commercial customers are relying on any of the other Tier 2 or Tier 3 platforms. > I mention all this because it is relevant to our stability guarantees. > Every time we release we should point to this list. > My sense is that this list should ideally rather live in the users guide since it changes from release to release. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From moritz.angermann at gmail.com Thu Sep 22 23:09:55 2022 From: moritz.angermann at gmail.com (Moritz Angermann) Date: Fri, 23 Sep 2022 07:09:55 +0800 Subject: Tier 1 architectures In-Reply-To: <87r103gqq2.fsf@smart-cactus.org> References: <87r103gqq2.fsf@smart-cactus.org> Message-ID: Thanks Ben! Just FYI: We do have folks actively deploying to iOS and Android 🙈 at simplex chat. I do agree that we want this to be in the user guide though; as it’s quite version dependent. Cheers, Moritz On Fri, 23 Sep 2022 at 3:22 AM, Ben Gamari wrote: > Simon Peyton Jones writes: > > > Ben, Matthew, Moritz, and friends > > > > Is this wiki page about architectures still accurate? > > https://gitlab.haskell.org/ghc/ghc/-/wikis/platforms > > > Hi Simon, > > Indeed there were a few inaccuracies on that page; I have fixed > these and generally cleaned up the page. > > > For example, ARM is not Tier 1, or "apple silicon". > > > > Yet I know some of our developers have invested lots of effort in other > > architectures, so maybe those efforts are not reflected here. > > > Fairly recently there has been work on RISC-V (rv64) and PowerPC > (ppc64le), as well as some work on s390x via LLVM. However, I wouldn't > consider any of these Tier 1. > > > Relevant is Moritz's post about 32-bit architectures > > < > https://discourse.haskell.org/t/running-project-built-on-raspberry-pi-with-cabal-gives-weird-errors/2429/6 > > > > . > > > > We should in due course add Javascript and Web Assembly as Tier 1 back > ends? > > > Indeed, that is the plan although 9.6 will rather ship these as Tier 2 > targets. > > > Are we saying "if your customer bases uses Tier 2 architectures, you > can't > > rely on GHC from one release to the next"? I wonder if there are > companies > > for which Tier-2 architectures are mission-critical. Mis-aligned > > expectations cause upset. > > > I have heard that some people are using amd64/FreeBSD, although that can > very > nearly be promoted to a Tier 1 now. Bodigrim once mentioned that he was > considering deploying Haskell on s390x, although I'm not sure what > became of that. Otherwise I would be quite surprised if any commercial > customers are relying on any of the other Tier 2 or Tier 3 platforms. > > > I mention all this because it is relevant to our stability guarantees. > > Every time we release we should point to this list. > > > My sense is that this list should ideally rather live in the users guide > since it changes from release to release. > > Cheers, > > - Ben > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon Sep 26 08:31:26 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 26 Sep 2022 09:31:26 +0100 Subject: Warnings in RTS Message-ID: Whenever I compile the RTS I get these warnings. Are they necessary? Simon In file included from rts/Schedule.c:16:0: error: rts/Schedule.c: In function ‘schedule’: rts/Schedule.h:143:1: error: warning: inlining failed in call to ‘appendToRunQueue’: call is unlikely and code size would grow [-Winline] 143 | appendToRunQueue (Capability *cap, StgTSO *tso) | ^~~~~~~~~~~~~~~~ | 143 | appendToRunQueue (Capability *cap, StgTSO *tso) | ^ rts/Schedule.c:1226:9: error: note: called from here 1226 | appendToRunQueue(cap,t); | ^~~~~~~~~~~~~~~~~~~~~~~ | 1226 | appendToRunQueue(cap,t); | ^ In file included from rts/Schedule.c:16:0: error: rts/Schedule.h:164:1: error: warning: inlining failed in call to ‘pushOnRunQueue’: call is unlikely and code size would grow [-Winline] 164 | pushOnRunQueue (Capability *cap, StgTSO *tso) | ^~~~~~~~~~~~~~ | 164 | pushOnRunQueue (Capability *cap, StgTSO *tso) | ^ rts/Schedule.c:1228:9: error: note: called from here 1228 | pushOnRunQueue(cap,t); | ^~~~~~~~~~~~~~~~~~~~~ | 1228 | pushOnRunQueue(cap,t); | ^ rts/Schedule.c: At top level: cc1: warning: unrecognized command line option ‘-Wno-nonportable-include-path’ -------------- next part -------------- An HTML attachment was scrubbed... URL: From simon.peytonjones at gmail.com Mon Sep 26 12:50:54 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Mon, 26 Sep 2022 13:50:54 +0100 Subject: GItlab search Message-ID: Friends I'm struggling with GitLab search. eg I was looking for #22200 I wen to https://gitlab.haskell.org/ghc/ghc/-/issues, and put "-DEEBUG" and "slow" in the search box. No #22200. Yet both of those strings appear in the title of the ticket. Looking for DEBUG or *DEBUG also fails. I find that DDEBUG succeeds. What are the rules? Thanks Simon -------------- next part -------------- An HTML attachment was scrubbed... URL: From ben at smart-cactus.org Mon Sep 26 13:47:24 2022 From: ben at smart-cactus.org (Ben Gamari) Date: Mon, 26 Sep 2022 09:47:24 -0400 Subject: GItlab search In-Reply-To: References: Message-ID: <87o7v2gsdp.fsf@smart-cactus.org> Simon Peyton Jones writes: > Friends > > I'm struggling with GitLab search. > > eg I was looking for #22200 > > I wen to https://gitlab.haskell.org/ghc/ghc/-/issues, and put "-DEEBUG" and > "slow" in the search box. No #22200. Yet both of those strings appear in > the title of the ticket. > Oh dear, indeed. The problem is that GitLab paused indexing due to a version incompatibility. I have fixed the issue and unpaused the indexer. Searching for '"-DDEBUG" slow' now turns up #22200 as the first result. Cheers, - Ben -------------- next part -------------- A non-text attachment was scrubbed... Name: signature.asc Type: application/pgp-signature Size: 487 bytes Desc: not available URL: From simon.peytonjones at gmail.com Tue Sep 27 07:49:53 2022 From: simon.peytonjones at gmail.com (Simon Peyton Jones) Date: Tue, 27 Sep 2022 08:49:53 +0100 Subject: Pushing to nofib Message-ID: Friends How do I push to the nofib/ repository? I just wanted to add some documentation. I'm on branch 'master' and tried to push. Got this below. What next? Thanks Simon bash$ git push Enumerating objects: 5, done. Counting objects: 100% (5/5), done. Delta compression using up to 24 threads Compressing objects: 100% (3/3), done. Writing objects: 100% (3/3), 543 bytes | 543.00 KiB/s, done. Total 3 (delta 2), reused 0 (delta 0) remote: GitLab: You are not allowed to push code to protected branches on this project. To gitlab.haskell.org:ghc/nofib.git ! [remote rejected] master -> master (pre-receive hook declined) error: failed to push some refs to 'git at gitlab.haskell.org:ghc/nofib.git' simonpj at LHR-WD-22561:~/code/HEAD-1/nofib$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From sgraf1337 at gmail.com Tue Sep 27 07:51:40 2022 From: sgraf1337 at gmail.com (Sebastian Graf) Date: Tue, 27 Sep 2022 07:51:40 +0000 Subject: Pushing to nofib In-Reply-To: References: Message-ID: Hi Simon, Similar to the policy for the main GHC repo, you have to push to a wip/ branch (or your personal fork) and then open a MR against the NoFib repo. Fortunately, the quality requirements for NoFib aren't high and it's likely your MR can be merged instantly. Cheers, Sebastian ------ Originalnachricht ------ Von: "Simon Peyton Jones" An: "GHC developers" Gesendet: 27.09.2022 09:49:53 Betreff: Pushing to nofib >Friends > >How do I push to the nofib/ repository? I just wanted to add some >documentation. I'm on branch 'master' and tried to push. Got this >below. What next? > >Thanks > >Simon > >bash$ git push >Enumerating objects: 5, done. >Counting objects: 100% (5/5), done. >Delta compression using up to 24 threads >Compressing objects: 100% (3/3), done. >Writing objects: 100% (3/3), 543 bytes | 543.00 KiB/s, done. >Total 3 (delta 2), reused 0 (delta 0) >remote: GitLab: You are not allowed to push code to protected branches >on this project. >To gitlab.haskell.org:ghc/nofib.git > ! [remote rejected] master -> master (pre-receive hook declined) >error: failed to push some refs to >'git at gitlab.haskell.org:ghc/nofib.git' >simonpj at LHR-WD-22561:~/code/HEAD-1/nofib$ -------------- next part -------------- An HTML attachment was scrubbed... URL: From bryan at haskell.foundation Wed Sep 28 07:57:33 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Wed, 28 Sep 2022 10:57:33 +0300 Subject: Consistent CI failure in job nightly-i386-linux-deb9-validate Message-ID: Hi all, For the past week or so, nightly-i386-linux-deb9-validate has been failing consistently. They show up on the failure dashboard because the logs contain the phrase "Cannot allocate memory". I haven't looked yet to see if they always fail in the same place, but I'll do that soon. The first example I looked at, however, has the line "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the problem. As a consequence of showing up on the dashboard, the jobs get restarted. Since they fail consistently, they keep getting restarted. Since the jobs keep getting restarted, the pipelines stay alive. When I checked just now, there were 8 nightly runs still running. :) Thus I'm going to cancel the still-running nightly-i386-linux-deb9-validate jobs and let the pipelines die in peace. You can still find all examples of failed jobs on the dashboard: https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2&from=now-90d&to=now&refresh=5m&var-types=cannot_allocate To prevent future problems, it would be good if someone could help me look into this. Otherwise I'll just disable the job. :( -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Wed Sep 28 08:46:17 2022 From: cheng.shao at tweag.io (Cheng Shao) Date: Wed, 28 Sep 2022 10:46:17 +0200 Subject: Consistent CI failure in job nightly-i386-linux-deb9-validate In-Reply-To: References: Message-ID: Hi Bryan, This may be an unintended fallout of !8940. Would you try starting an i386 pipeline with it reversed to see if it solves the issue, in which case we should revert or fix it in master? On Wed, Sep 28, 2022 at 9:58 AM Bryan Richter via ghc-devs wrote: > > Hi all, > > For the past week or so, nightly-i386-linux-deb9-validate has been failing consistently. > > They show up on the failure dashboard because the logs contain the phrase "Cannot allocate memory". > > I haven't looked yet to see if they always fail in the same place, but I'll do that soon. The first example I looked at, however, has the line "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the problem. > > As a consequence of showing up on the dashboard, the jobs get restarted. Since they fail consistently, they keep getting restarted. Since the jobs keep getting restarted, the pipelines stay alive. When I checked just now, there were 8 nightly runs still running. :) Thus I'm going to cancel the still-running nightly-i386-linux-deb9-validate jobs and let the pipelines die in peace. You can still find all examples of failed jobs on the dashboard: > > https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2&from=now-90d&to=now&refresh=5m&var-types=cannot_allocate > > To prevent future problems, it would be good if someone could help me look into this. Otherwise I'll just disable the job. :( > _______________________________________________ > ghc-devs mailing list > ghc-devs at haskell.org > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From bryan at haskell.foundation Wed Sep 28 11:00:11 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Wed, 28 Sep 2022 14:00:11 +0300 Subject: Consistent CI failure in job nightly-i386-linux-deb9-validate In-Reply-To: References: Message-ID: Yep, it seems to mostly be xz that is running out of memory. (All recent builds that I sampled, but not all builds through all time.) Thanks for pointing it out! I can revert the change. On Wed, Sep 28, 2022 at 11:46 AM Cheng Shao wrote: > Hi Bryan, > > This may be an unintended fallout of !8940. Would you try starting an > i386 pipeline with it reversed to see if it solves the issue, in which > case we should revert or fix it in master? > > On Wed, Sep 28, 2022 at 9:58 AM Bryan Richter via ghc-devs > wrote: > > > > Hi all, > > > > For the past week or so, nightly-i386-linux-deb9-validate has been > failing consistently. > > > > They show up on the failure dashboard because the logs contain the > phrase "Cannot allocate memory". > > > > I haven't looked yet to see if they always fail in the same place, but > I'll do that soon. The first example I looked at, however, has the line > "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the > problem. > > > > As a consequence of showing up on the dashboard, the jobs get restarted. > Since they fail consistently, they keep getting restarted. Since the jobs > keep getting restarted, the pipelines stay alive. When I checked just now, > there were 8 nightly runs still running. :) Thus I'm going to cancel the > still-running nightly-i386-linux-deb9-validate jobs and let the pipelines > die in peace. You can still find all examples of failed jobs on the > dashboard: > > > > > https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2&from=now-90d&to=now&refresh=5m&var-types=cannot_allocate > > > > To prevent future problems, it would be good if someone could help me > look into this. Otherwise I'll just disable the job. :( > > _______________________________________________ > > ghc-devs mailing list > > ghc-devs at haskell.org > > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Wed Sep 28 11:02:10 2022 From: cheng.shao at tweag.io (Cheng Shao) Date: Wed, 28 Sep 2022 13:02:10 +0200 Subject: Consistent CI failure in job nightly-i386-linux-deb9-validate In-Reply-To: References: Message-ID: Sure, in which case pls revert it. Apologies for the impact, though I'm still a bit curious, the i386 job did pass in the original MR. On Wed, Sep 28, 2022 at 1:00 PM Bryan Richter wrote: > > Yep, it seems to mostly be xz that is running out of memory. (All recent builds that I sampled, but not all builds through all time.) Thanks for pointing it out! > > I can revert the change. > > On Wed, Sep 28, 2022 at 11:46 AM Cheng Shao wrote: >> >> Hi Bryan, >> >> This may be an unintended fallout of !8940. Would you try starting an >> i386 pipeline with it reversed to see if it solves the issue, in which >> case we should revert or fix it in master? >> >> On Wed, Sep 28, 2022 at 9:58 AM Bryan Richter via ghc-devs >> wrote: >> > >> > Hi all, >> > >> > For the past week or so, nightly-i386-linux-deb9-validate has been failing consistently. >> > >> > They show up on the failure dashboard because the logs contain the phrase "Cannot allocate memory". >> > >> > I haven't looked yet to see if they always fail in the same place, but I'll do that soon. The first example I looked at, however, has the line "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the problem. >> > >> > As a consequence of showing up on the dashboard, the jobs get restarted. Since they fail consistently, they keep getting restarted. Since the jobs keep getting restarted, the pipelines stay alive. When I checked just now, there were 8 nightly runs still running. :) Thus I'm going to cancel the still-running nightly-i386-linux-deb9-validate jobs and let the pipelines die in peace. You can still find all examples of failed jobs on the dashboard: >> > >> > https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2&from=now-90d&to=now&refresh=5m&var-types=cannot_allocate >> > >> > To prevent future problems, it would be good if someone could help me look into this. Otherwise I'll just disable the job. :( >> > _______________________________________________ >> > ghc-devs mailing list >> > ghc-devs at haskell.org >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From bryan at haskell.foundation Wed Sep 28 11:21:41 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Wed, 28 Sep 2022 14:21:41 +0300 Subject: Consistent CI failure in job nightly-i386-linux-deb9-validate In-Reply-To: References: Message-ID: Aha: while i386-linux-deb9-validate sets no extra XZ options, *nightly*-i386-linux-deb9-validate (the failing job) sets "XZ_OPT = 9". A revert would fix the problem, but presumably so would tweaking that option. Does anyone have information that would lead to a better decision here? On Wed, Sep 28, 2022 at 2:02 PM Cheng Shao wrote: > Sure, in which case pls revert it. Apologies for the impact, though > I'm still a bit curious, the i386 job did pass in the original MR. > > On Wed, Sep 28, 2022 at 1:00 PM Bryan Richter > wrote: > > > > Yep, it seems to mostly be xz that is running out of memory. (All recent > builds that I sampled, but not all builds through all time.) Thanks for > pointing it out! > > > > I can revert the change. > > > > On Wed, Sep 28, 2022 at 11:46 AM Cheng Shao wrote: > >> > >> Hi Bryan, > >> > >> This may be an unintended fallout of !8940. Would you try starting an > >> i386 pipeline with it reversed to see if it solves the issue, in which > >> case we should revert or fix it in master? > >> > >> On Wed, Sep 28, 2022 at 9:58 AM Bryan Richter via ghc-devs > >> wrote: > >> > > >> > Hi all, > >> > > >> > For the past week or so, nightly-i386-linux-deb9-validate has been > failing consistently. > >> > > >> > They show up on the failure dashboard because the logs contain the > phrase "Cannot allocate memory". > >> > > >> > I haven't looked yet to see if they always fail in the same place, > but I'll do that soon. The first example I looked at, however, has the line > "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the > problem. > >> > > >> > As a consequence of showing up on the dashboard, the jobs get > restarted. Since they fail consistently, they keep getting restarted. Since > the jobs keep getting restarted, the pipelines stay alive. When I checked > just now, there were 8 nightly runs still running. :) Thus I'm going to > cancel the still-running nightly-i386-linux-deb9-validate jobs and let the > pipelines die in peace. You can still find all examples of failed jobs on > the dashboard: > >> > > >> > > https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2&from=now-90d&to=now&refresh=5m&var-types=cannot_allocate > >> > > >> > To prevent future problems, it would be good if someone could help me > look into this. Otherwise I'll just disable the job. :( > >> > _______________________________________________ > >> > ghc-devs mailing list > >> > ghc-devs at haskell.org > >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Wed Sep 28 11:38:35 2022 From: cheng.shao at tweag.io (Cheng Shao) Date: Wed, 28 Sep 2022 13:38:35 +0200 Subject: Consistent CI failure in job nightly-i386-linux-deb9-validate In-Reply-To: References: Message-ID: I believe we can either modify ci.sh to disable parallel compression for i386, or modify .gitlab/gen_ci.hs and .gitlab/jobs.yaml to disable XZ_OPT=-9 for i386. On Wed, Sep 28, 2022 at 1:21 PM Bryan Richter wrote: > > Aha: while i386-linux-deb9-validate sets no extra XZ options, nightly-i386-linux-deb9-validate (the failing job) sets "XZ_OPT = 9". > > A revert would fix the problem, but presumably so would tweaking that option. Does anyone have information that would lead to a better decision here? > > > On Wed, Sep 28, 2022 at 2:02 PM Cheng Shao wrote: >> >> Sure, in which case pls revert it. Apologies for the impact, though >> I'm still a bit curious, the i386 job did pass in the original MR. >> >> On Wed, Sep 28, 2022 at 1:00 PM Bryan Richter wrote: >> > >> > Yep, it seems to mostly be xz that is running out of memory. (All recent builds that I sampled, but not all builds through all time.) Thanks for pointing it out! >> > >> > I can revert the change. >> > >> > On Wed, Sep 28, 2022 at 11:46 AM Cheng Shao wrote: >> >> >> >> Hi Bryan, >> >> >> >> This may be an unintended fallout of !8940. Would you try starting an >> >> i386 pipeline with it reversed to see if it solves the issue, in which >> >> case we should revert or fix it in master? >> >> >> >> On Wed, Sep 28, 2022 at 9:58 AM Bryan Richter via ghc-devs >> >> wrote: >> >> > >> >> > Hi all, >> >> > >> >> > For the past week or so, nightly-i386-linux-deb9-validate has been failing consistently. >> >> > >> >> > They show up on the failure dashboard because the logs contain the phrase "Cannot allocate memory". >> >> > >> >> > I haven't looked yet to see if they always fail in the same place, but I'll do that soon. The first example I looked at, however, has the line "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the problem. >> >> > >> >> > As a consequence of showing up on the dashboard, the jobs get restarted. Since they fail consistently, they keep getting restarted. Since the jobs keep getting restarted, the pipelines stay alive. When I checked just now, there were 8 nightly runs still running. :) Thus I'm going to cancel the still-running nightly-i386-linux-deb9-validate jobs and let the pipelines die in peace. You can still find all examples of failed jobs on the dashboard: >> >> > >> >> > https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2&from=now-90d&to=now&refresh=5m&var-types=cannot_allocate >> >> > >> >> > To prevent future problems, it would be good if someone could help me look into this. Otherwise I'll just disable the job. :( >> >> > _______________________________________________ >> >> > ghc-devs mailing list >> >> > ghc-devs at haskell.org >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From bryan at haskell.foundation Thu Sep 29 07:25:13 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Thu, 29 Sep 2022 10:25:13 +0300 Subject: Consistent CI failure in job nightly-i386-linux-deb9-validate In-Reply-To: References: Message-ID: Matthew pointed out that the build system already parallelizes jobs, so it's risky to force parallelization of any individual job. That means I should just revert. On Wed, Sep 28, 2022 at 2:38 PM Cheng Shao wrote: > I believe we can either modify ci.sh to disable parallel compression > for i386, or modify .gitlab/gen_ci.hs and .gitlab/jobs.yaml to disable > XZ_OPT=-9 for i386. > > On Wed, Sep 28, 2022 at 1:21 PM Bryan Richter > wrote: > > > > Aha: while i386-linux-deb9-validate sets no extra XZ options, > nightly-i386-linux-deb9-validate (the failing job) sets "XZ_OPT = 9". > > > > A revert would fix the problem, but presumably so would tweaking that > option. Does anyone have information that would lead to a better decision > here? > > > > > > On Wed, Sep 28, 2022 at 2:02 PM Cheng Shao wrote: > >> > >> Sure, in which case pls revert it. Apologies for the impact, though > >> I'm still a bit curious, the i386 job did pass in the original MR. > >> > >> On Wed, Sep 28, 2022 at 1:00 PM Bryan Richter > wrote: > >> > > >> > Yep, it seems to mostly be xz that is running out of memory. (All > recent builds that I sampled, but not all builds through all time.) Thanks > for pointing it out! > >> > > >> > I can revert the change. > >> > > >> > On Wed, Sep 28, 2022 at 11:46 AM Cheng Shao > wrote: > >> >> > >> >> Hi Bryan, > >> >> > >> >> This may be an unintended fallout of !8940. Would you try starting an > >> >> i386 pipeline with it reversed to see if it solves the issue, in > which > >> >> case we should revert or fix it in master? > >> >> > >> >> On Wed, Sep 28, 2022 at 9:58 AM Bryan Richter via ghc-devs > >> >> wrote: > >> >> > > >> >> > Hi all, > >> >> > > >> >> > For the past week or so, nightly-i386-linux-deb9-validate has been > failing consistently. > >> >> > > >> >> > They show up on the failure dashboard because the logs contain the > phrase "Cannot allocate memory". > >> >> > > >> >> > I haven't looked yet to see if they always fail in the same place, > but I'll do that soon. The first example I looked at, however, has the line > "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the > problem. > >> >> > > >> >> > As a consequence of showing up on the dashboard, the jobs get > restarted. Since they fail consistently, they keep getting restarted. Since > the jobs keep getting restarted, the pipelines stay alive. When I checked > just now, there were 8 nightly runs still running. :) Thus I'm going to > cancel the still-running nightly-i386-linux-deb9-validate jobs and let the > pipelines die in peace. You can still find all examples of failed jobs on > the dashboard: > >> >> > > >> >> > > https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2&from=now-90d&to=now&refresh=5m&var-types=cannot_allocate > >> >> > > >> >> > To prevent future problems, it would be good if someone could help > me look into this. Otherwise I'll just disable the job. :( > >> >> > _______________________________________________ > >> >> > ghc-devs mailing list > >> >> > ghc-devs at haskell.org > >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs > -------------- next part -------------- An HTML attachment was scrubbed... URL: From cheng.shao at tweag.io Thu Sep 29 07:40:52 2022 From: cheng.shao at tweag.io (Cheng Shao) Date: Thu, 29 Sep 2022 09:40:52 +0200 Subject: Consistent CI failure in job nightly-i386-linux-deb9-validate In-Reply-To: References: Message-ID: When hadrian builds the binary-dist job, invoking tar and xz is already the last step and there'll be no other ongoing jobs. But I do agree with reverting, this minor optimization I proposed has caused more trouble than its worth :/ On Thu, Sep 29, 2022 at 9:25 AM Bryan Richter wrote: > > Matthew pointed out that the build system already parallelizes jobs, so it's risky to force parallelization of any individual job. That means I should just revert. > > On Wed, Sep 28, 2022 at 2:38 PM Cheng Shao wrote: >> >> I believe we can either modify ci.sh to disable parallel compression >> for i386, or modify .gitlab/gen_ci.hs and .gitlab/jobs.yaml to disable >> XZ_OPT=-9 for i386. >> >> On Wed, Sep 28, 2022 at 1:21 PM Bryan Richter wrote: >> > >> > Aha: while i386-linux-deb9-validate sets no extra XZ options, nightly-i386-linux-deb9-validate (the failing job) sets "XZ_OPT = 9". >> > >> > A revert would fix the problem, but presumably so would tweaking that option. Does anyone have information that would lead to a better decision here? >> > >> > >> > On Wed, Sep 28, 2022 at 2:02 PM Cheng Shao wrote: >> >> >> >> Sure, in which case pls revert it. Apologies for the impact, though >> >> I'm still a bit curious, the i386 job did pass in the original MR. >> >> >> >> On Wed, Sep 28, 2022 at 1:00 PM Bryan Richter wrote: >> >> > >> >> > Yep, it seems to mostly be xz that is running out of memory. (All recent builds that I sampled, but not all builds through all time.) Thanks for pointing it out! >> >> > >> >> > I can revert the change. >> >> > >> >> > On Wed, Sep 28, 2022 at 11:46 AM Cheng Shao wrote: >> >> >> >> >> >> Hi Bryan, >> >> >> >> >> >> This may be an unintended fallout of !8940. Would you try starting an >> >> >> i386 pipeline with it reversed to see if it solves the issue, in which >> >> >> case we should revert or fix it in master? >> >> >> >> >> >> On Wed, Sep 28, 2022 at 9:58 AM Bryan Richter via ghc-devs >> >> >> wrote: >> >> >> > >> >> >> > Hi all, >> >> >> > >> >> >> > For the past week or so, nightly-i386-linux-deb9-validate has been failing consistently. >> >> >> > >> >> >> > They show up on the failure dashboard because the logs contain the phrase "Cannot allocate memory". >> >> >> > >> >> >> > I haven't looked yet to see if they always fail in the same place, but I'll do that soon. The first example I looked at, however, has the line "xz: (stdin): Cannot allocate memory", so it's not GHC (alone) causing the problem. >> >> >> > >> >> >> > As a consequence of showing up on the dashboard, the jobs get restarted. Since they fail consistently, they keep getting restarted. Since the jobs keep getting restarted, the pipelines stay alive. When I checked just now, there were 8 nightly runs still running. :) Thus I'm going to cancel the still-running nightly-i386-linux-deb9-validate jobs and let the pipelines die in peace. You can still find all examples of failed jobs on the dashboard: >> >> >> > >> >> >> > https://grafana.gitlab.haskell.org/d/167r9v6nk/ci-spurious-failures?orgId=2&from=now-90d&to=now&refresh=5m&var-types=cannot_allocate >> >> >> > >> >> >> > To prevent future problems, it would be good if someone could help me look into this. Otherwise I'll just disable the job. :( >> >> >> > _______________________________________________ >> >> >> > ghc-devs mailing list >> >> >> > ghc-devs at haskell.org >> >> >> > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs From bryan at haskell.foundation Fri Sep 30 07:03:38 2022 From: bryan at haskell.foundation (Bryan Richter) Date: Fri, 30 Sep 2022 10:03:38 +0300 Subject: Overnight CI failures In-Reply-To: References: Message-ID: (Adding ghc-devs) Are these fragile tests? 1. T14346 got a "bad file descriptor" on Darwin 2. linker_unload got some gold errors on Linux Neither of these have been reported to me before, so I don't know much about them. Nor have I looked deeply (or at all) at the tests themselves, yet. On Thu, Sep 29, 2022 at 3:37 PM Simon Peyton Jones < simon.peytonjones at gmail.com> wrote: > Bryan > > These failed overnight > > On !8897 > > - https://gitlab.haskell.org/ghc/ghc/-/jobs/1185519 > - https://gitlab.haskell.org/ghc/ghc/-/jobs/1185520 > > I think it's extremely unlikely that this had anything to do with my patch. > > Simon > -------------- next part -------------- An HTML attachment was scrubbed... URL: