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: <CAJKmMz_O0Weau2BAZ555Dect+nYzXYkMh=9X0DxqO9PHALnVQQ@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220905/4baef47a/attachment.html>

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: <CAJKmMz_O0Weau2BAZ555Dect+nYzXYkMh=9X0DxqO9PHALnVQQ@mail.gmail.com>
References: <CAJKmMz_O0Weau2BAZ555Dect+nYzXYkMh=9X0DxqO9PHALnVQQ@mail.gmail.com>
Message-ID: <878rmxlqdp.fsf@smart-cactus.org>

Simon Peyton Jones <simon.peytonjones at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220905/1999f951/attachment.sig>

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: <CAJKmMz_O0Weau2BAZ555Dect+nYzXYkMh=9X0DxqO9PHALnVQQ@mail.gmail.com>
 <878rmxlqdp.fsf@smart-cactus.org>
Message-ID: <875yi1lpba.fsf@smart-cactus.org>

Ben Gamari <ben at smart-cactus.org> writes:

> Simon Peyton Jones <simon.peytonjones at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220905/9143c43d/attachment.sig>

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: <CAJKmMz87wWQJFYkesdwdUCKfDFfFRq3+tSmtSeEnUCuuAXDK5A@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220905/44044ee0/attachment.html>

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: <CAJKmMz-04nGq1i=3c-ApEU2yQrtRTRZGDTDh8kRF3E7kGoW45w@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220905/8adddd3e/attachment.html>

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: <CAJKmMz-04nGq1i=3c-ApEU2yQrtRTRZGDTDh8kRF3E7kGoW45w@mail.gmail.com>
References: <CAJKmMz-04nGq1i=3c-ApEU2yQrtRTRZGDTDh8kRF3E7kGoW45w@mail.gmail.com>
Message-ID: <CANma=H-+_wzD9WD+NmvVv-a=zZoeV5Skjbpy1eEa5kDxQCf3uw@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220905/91033981/attachment.html>

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: <CAJKmMz-04nGq1i=3c-ApEU2yQrtRTRZGDTDh8kRF3E7kGoW45w@mail.gmail.com>
References: <CAJKmMz-04nGq1i=3c-ApEU2yQrtRTRZGDTDh8kRF3E7kGoW45w@mail.gmail.com>
Message-ID: <8735d5lglk.fsf@smart-cactus.org>

Simon Peyton Jones <simon.peytonjones at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220905/2970203f/attachment.sig>

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: <CAJKmMz87wWQJFYkesdwdUCKfDFfFRq3+tSmtSeEnUCuuAXDK5A@mail.gmail.com>
References: <CAJKmMz87wWQJFYkesdwdUCKfDFfFRq3+tSmtSeEnUCuuAXDK5A@mail.gmail.com>
Message-ID: <87zgfdk1jw.fsf@smart-cactus.org>

Simon Peyton Jones <simon.peytonjones at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220905/2d6ca11b/attachment.sig>

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: <CALkjVLDW65nOnOsO-6RafiOqsGBQFBtKeU5mWyJb3V3ftckBqg@mail.gmail.com>

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: <CALkjVLDW65nOnOsO-6RafiOqsGBQFBtKeU5mWyJb3V3ftckBqg@mail.gmail.com>
References: <CALkjVLDW65nOnOsO-6RafiOqsGBQFBtKeU5mWyJb3V3ftckBqg@mail.gmail.com>
Message-ID: <CAJKmMz_ZzmGp-SqEo0v_JX7f5y4aGzN4_c2o1hcEPkdUvRvS-Q@mail.gmail.com>

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 <dburke.gw at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220906/93a769fa/attachment.html>

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: <CAJKmMz_ZzmGp-SqEo0v_JX7f5y4aGzN4_c2o1hcEPkdUvRvS-Q@mail.gmail.com>
References: <CALkjVLDW65nOnOsO-6RafiOqsGBQFBtKeU5mWyJb3V3ftckBqg@mail.gmail.com>
 <CAJKmMz_ZzmGp-SqEo0v_JX7f5y4aGzN4_c2o1hcEPkdUvRvS-Q@mail.gmail.com>
Message-ID: <CALkjVLCSRW_u5xTcYv9rxdatiXmNmToCi0zOEkqPrOahtpMXtA@mail.gmail.com>

On Tue, Sep 6, 2022 at 10:17 AM Simon Peyton Jones
<simon.peytonjones at gmail.com> 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 <dburke.gw at gmail.com> 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: <CAJKmMz87aO48b4EV0sTsec-7-FV5z2deawJVpDKcHoZx+S-V4Q@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220906/8f87c78f/attachment.html>

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: <CAJKmMz87aO48b4EV0sTsec-7-FV5z2deawJVpDKcHoZx+S-V4Q@mail.gmail.com>
References: <CAJKmMz87aO48b4EV0sTsec-7-FV5z2deawJVpDKcHoZx+S-V4Q@mail.gmail.com>
Message-ID: <CAA1CnJOXnGM5ZRjJ9iSXrs0cZ5Y4-iCT15dxB1CWbgmhP_=37w@mail.gmail.com>

Hi Simon,

This is due to my patch 4786acf7
<https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
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
<https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
.

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220906/543b1232/attachment.html>

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: <CALkjVLDW65nOnOsO-6RafiOqsGBQFBtKeU5mWyJb3V3ftckBqg@mail.gmail.com>
References: <CALkjVLDW65nOnOsO-6RafiOqsGBQFBtKeU5mWyJb3V3ftckBqg@mail.gmail.com>
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

<no location info>: 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: <CAA1CnJOXnGM5ZRjJ9iSXrs0cZ5Y4-iCT15dxB1CWbgmhP_=37w@mail.gmail.com>
References: <CAJKmMz87aO48b4EV0sTsec-7-FV5z2deawJVpDKcHoZx+S-V4Q@mail.gmail.com>
 <CAA1CnJOXnGM5ZRjJ9iSXrs0cZ5Y4-iCT15dxB1CWbgmhP_=37w@mail.gmail.com>
Message-ID: <CAJKmMz8Lvq_pjs_QFde1OpbJ-SdkTTnuWiKH-VFFR9eF4VSe4Q@mail.gmail.com>

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 <sam.derbyshire at gmail.com>
wrote:

> Hi Simon,
>
> This is due to my patch 4786acf7
> <https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
> 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
> <https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
> .
>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220906/207750fa/attachment.html>

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: <CALkjVLDW65nOnOsO-6RafiOqsGBQFBtKeU5mWyJb3V3ftckBqg@mail.gmail.com>
 <72aca27e-4567-5324-aab3-dc1696c49081@iki.fi>
Message-ID: <CALkjVLB48s_zZDjuKzi57R16oec44sPu-9Cd5LnMC5DHE0Aj4A@mail.gmail.com>

Oleg,

Thanks for doing this.

Doug

On Tue, Sep 6, 2022 at 2:15 PM Oleg Grenrus <oleg.grenrus at iki.fi> 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
>
> <no location info>: 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: <CAJKmMz8Lvq_pjs_QFde1OpbJ-SdkTTnuWiKH-VFFR9eF4VSe4Q@mail.gmail.com>
References: <CAJKmMz87aO48b4EV0sTsec-7-FV5z2deawJVpDKcHoZx+S-V4Q@mail.gmail.com>
 <CAA1CnJOXnGM5ZRjJ9iSXrs0cZ5Y4-iCT15dxB1CWbgmhP_=37w@mail.gmail.com>
 <CAJKmMz8Lvq_pjs_QFde1OpbJ-SdkTTnuWiKH-VFFR9eF4VSe4Q@mail.gmail.com>
Message-ID: <CAJKmMz_w7DAuTeOhg6SzYa8aHkqMbHe_-9b-NDKVO_o901v76g@mail.gmail.com>

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 <sam.derbyshire at gmail.com>
> wrote:
>
>> Hi Simon,
>>
>> This is due to my patch 4786acf7
>> <https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
>> 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
>> <https://gitlab.haskell.org/ghc/ghc/-/commit/4786acf758ef064d3b79593774d1672e294b0afb>
>> .
>>
>> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220907/a6e4093f/attachment.html>

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: <CAFxbpu7SOjnHuSUG3Lt3gEoT+O9WFQQSqB2ZEgKkaF9sCbmr9w@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220909/8d8c48f9/attachment.html>

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: <CAFxbpu7SOjnHuSUG3Lt3gEoT+O9WFQQSqB2ZEgKkaF9sCbmr9w@mail.gmail.com>
References: <CAFxbpu7SOjnHuSUG3Lt3gEoT+O9WFQQSqB2ZEgKkaF9sCbmr9w@mail.gmail.com>
Message-ID: <CALHrtF=4Ygt=9zNv_iyP7+dBFgoJoNDe=hC7_2xpc4auBadC+A@mail.gmail.com>

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 <pi.boy.travis at gmail.com> 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: <CAFxbpu7SOjnHuSUG3Lt3gEoT+O9WFQQSqB2ZEgKkaF9sCbmr9w@mail.gmail.com>
References: <CAFxbpu7SOjnHuSUG3Lt3gEoT+O9WFQQSqB2ZEgKkaF9sCbmr9w@mail.gmail.com>
Message-ID: <87y1usl8cd.fsf@smart-cactus.org>

Travis Whitaker <pi.boy.travis at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220909/4922461f/attachment.sig>

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: <CAJKmMz-kxXThSjZu3GniWOHEZHPsByP=6emwhSV+iG8JqJyB3g@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220911/4108a524/attachment.html>

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 <lanablack at amok.cc> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220913/f39b27e0/attachment.sig>

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: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220914/b8f25d44/attachment.html>

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: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>
References: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>
Message-ID: <CAA1CnJNAQa0iwj8TOpr_Xsr9BbH+FDGpsgm66YjeR4v16LLMNA@mail.gmail.com>

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 <csaba.hruska at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220914/cfb8732e/attachment.html>

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: <CAA1CnJNAQa0iwj8TOpr_Xsr9BbH+FDGpsgm66YjeR4v16LLMNA@mail.gmail.com>
References: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>
 <CAA1CnJNAQa0iwj8TOpr_Xsr9BbH+FDGpsgm66YjeR4v16LLMNA@mail.gmail.com>
Message-ID: <CANjChEoUfpPOqyr91X2zx9Szkad25EBey638z1oMETw3WSWa=w@mail.gmail.com>

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, <sam.derbyshire at gmail.com> 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 <csaba.hruska at gmail.com>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220914/abe075ab/attachment.html>

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: <CANjChEoUfpPOqyr91X2zx9Szkad25EBey638z1oMETw3WSWa=w@mail.gmail.com>
References: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>
 <CAA1CnJNAQa0iwj8TOpr_Xsr9BbH+FDGpsgm66YjeR4v16LLMNA@mail.gmail.com>
 <CANjChEoUfpPOqyr91X2zx9Szkad25EBey638z1oMETw3WSWa=w@mail.gmail.com>
Message-ID: <CAA1CnJNDUQPG0SNH=AigvYUwR9q_UFOqo9ziKgtK-o7=hztEYA@mail.gmail.com>

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 <csaba.hruska at gmail.com> 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, <sam.derbyshire at gmail.com>
> 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 <csaba.hruska at gmail.com>
>> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220914/1246a6e3/attachment.html>

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: <CAA1CnJNDUQPG0SNH=AigvYUwR9q_UFOqo9ziKgtK-o7=hztEYA@mail.gmail.com>
References: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>
 <CAA1CnJNAQa0iwj8TOpr_Xsr9BbH+FDGpsgm66YjeR4v16LLMNA@mail.gmail.com>
 <CANjChEoUfpPOqyr91X2zx9Szkad25EBey638z1oMETw3WSWa=w@mail.gmail.com>
 <CAA1CnJNDUQPG0SNH=AigvYUwR9q_UFOqo9ziKgtK-o7=hztEYA@mail.gmail.com>
Message-ID: <CANjChEoba=c50dCJZjY8eVpD4ZVOf9C-gz+LmG1kbsLiVz7-kA@mail.gmail.com>

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 <csaba.hruska at gmail.com>
> 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, <sam.derbyshire at gmail.com>
>> 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 <csaba.hruska at gmail.com>
>>> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220915/8f63c892/attachment.html>

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: <CAJKmMz__vVWOoNYYd8y95jj8WrvKSom3-TuUdpVzd8arDho-Vg@mail.gmail.com>

Matthias, David,

David Binder <http://ps.informatik.uni-tuebingen.de/team/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 <https://github.com/Tritlo>wants to extend HPC in a number of
ways.  See here
<https://github.mpg.is/posts/2022/04/26/better-hpc-traces.html>and here
<https://github.com/ghc-proposals/ghc-proposals/pull/539>.

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220915/80f53b6d/attachment.html>

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: <CANjChEoba=c50dCJZjY8eVpD4ZVOf9C-gz+LmG1kbsLiVz7-kA@mail.gmail.com>
References: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>
 <CAA1CnJNAQa0iwj8TOpr_Xsr9BbH+FDGpsgm66YjeR4v16LLMNA@mail.gmail.com>
 <CANjChEoUfpPOqyr91X2zx9Szkad25EBey638z1oMETw3WSWa=w@mail.gmail.com>
 <CAA1CnJNDUQPG0SNH=AigvYUwR9q_UFOqo9ziKgtK-o7=hztEYA@mail.gmail.com>
 <CANjChEoba=c50dCJZjY8eVpD4ZVOf9C-gz+LmG1kbsLiVz7-kA@mail.gmail.com>
Message-ID: <CA+h2Lzm=QYk8wtrFiq+wh5KQfkhSO1Ftn5fw7e0=qZrOr_1g-g@mail.gmail.com>

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 <csaba.hruska at gmail.com> 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 <csaba.hruska at gmail.com> 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, <sam.derbyshire at gmail.com> 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 <csaba.hruska at gmail.com> 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: <CA+h2Lzm=QYk8wtrFiq+wh5KQfkhSO1Ftn5fw7e0=qZrOr_1g-g@mail.gmail.com>
References: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>
 <CAA1CnJNAQa0iwj8TOpr_Xsr9BbH+FDGpsgm66YjeR4v16LLMNA@mail.gmail.com>
 <CANjChEoUfpPOqyr91X2zx9Szkad25EBey638z1oMETw3WSWa=w@mail.gmail.com>
 <CAA1CnJNDUQPG0SNH=AigvYUwR9q_UFOqo9ziKgtK-o7=hztEYA@mail.gmail.com>
 <CANjChEoba=c50dCJZjY8eVpD4ZVOf9C-gz+LmG1kbsLiVz7-kA@mail.gmail.com>
 <CA+h2Lzm=QYk8wtrFiq+wh5KQfkhSO1Ftn5fw7e0=qZrOr_1g-g@mail.gmail.com>
Message-ID: <CAJKmMz9wCmByqjNT3tUq5Y7hhS5CkBNWg-u-_fAUgzJqgLBNAA@mail.gmail.com>

>
> 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 <csaba.hruska at gmail.com>
> 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 <csaba.hruska at gmail.com>
> 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, <sam.derbyshire at gmail.com>
> 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 <csaba.hruska at gmail.com>
> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220915/d43999a8/attachment.html>

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: <CAJKmMz9wCmByqjNT3tUq5Y7hhS5CkBNWg-u-_fAUgzJqgLBNAA@mail.gmail.com>
References: <CANjChEoFrgMomLymquojV=b7wAvy1bkFMunnBw_s1WHR6e=htA@mail.gmail.com>
 <CAA1CnJNAQa0iwj8TOpr_Xsr9BbH+FDGpsgm66YjeR4v16LLMNA@mail.gmail.com>
 <CANjChEoUfpPOqyr91X2zx9Szkad25EBey638z1oMETw3WSWa=w@mail.gmail.com>
 <CAA1CnJNDUQPG0SNH=AigvYUwR9q_UFOqo9ziKgtK-o7=hztEYA@mail.gmail.com>
 <CANjChEoba=c50dCJZjY8eVpD4ZVOf9C-gz+LmG1kbsLiVz7-kA@mail.gmail.com>
 <CA+h2Lzm=QYk8wtrFiq+wh5KQfkhSO1Ftn5fw7e0=qZrOr_1g-g@mail.gmail.com>
 <CAJKmMz9wCmByqjNT3tUq5Y7hhS5CkBNWg-u-_fAUgzJqgLBNAA@mail.gmail.com>
Message-ID: <CANjChEpAt9Oa3Sr5r+JL=NQAvSV9+BG4HCfBqfsYzFTyqvgpMg@mail.gmail.com>

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 <csaba.hruska at gmail.com>
>> 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 <csaba.hruska at gmail.com>
>> 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, <sam.derbyshire at gmail.com>
>> 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 <csaba.hruska at gmail.com>
>> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220916/d0be3eee/attachment.html>

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: <CAJKmMz88AsOWWE80xEOMQ_7Vq=f_XF972maeLBY+nd_J0R_dcg@mail.gmail.com>

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
<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?

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220922/ec0e1477/attachment.html>

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: <CAJKmMz88AsOWWE80xEOMQ_7Vq=f_XF972maeLBY+nd_J0R_dcg@mail.gmail.com>
References: <CAJKmMz88AsOWWE80xEOMQ_7Vq=f_XF972maeLBY+nd_J0R_dcg@mail.gmail.com>
Message-ID: <87r103gqq2.fsf@smart-cactus.org>

Simon Peyton Jones <simon.peytonjones at gmail.com> 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
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220922/6a105e27/attachment.sig>

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: <CAJKmMz88AsOWWE80xEOMQ_7Vq=f_XF972maeLBY+nd_J0R_dcg@mail.gmail.com>
 <87r103gqq2.fsf@smart-cactus.org>
Message-ID: <CAKfdd-zAbxvQOpJesdri_8RB3_M_TQv2XLBe7BHW3ta=VfF=JQ@mail.gmail.com>

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 <ben at well-typed.com> wrote:

> Simon Peyton Jones <simon.peytonjones at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220923/dfb639cb/attachment.html>

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: <CAJKmMz-uky-KK=rykr4+0JDE4ZVG0aECSXWSw9+_LHdPvPLyLw@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220926/79e49a9b/attachment.html>

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: <CAJKmMz8KU8EY-uNigYmKc2FaudosvphMOaFAChbSYLgMjcQOwQ@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220926/0c21a352/attachment.html>

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: <CAJKmMz8KU8EY-uNigYmKc2FaudosvphMOaFAChbSYLgMjcQOwQ@mail.gmail.com>
References: <CAJKmMz8KU8EY-uNigYmKc2FaudosvphMOaFAChbSYLgMjcQOwQ@mail.gmail.com>
Message-ID: <87o7v2gsdp.fsf@smart-cactus.org>

Simon Peyton Jones <simon.peytonjones at gmail.com> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220926/b808d771/attachment.sig>

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: <CAJKmMz9ANuijyZf2pBuxH2T8Pwz_7EBYmqMH53Eth+DV4Z16rg@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220927/39e20d1a/attachment.html>

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: <CAJKmMz9ANuijyZf2pBuxH2T8Pwz_7EBYmqMH53Eth+DV4Z16rg@mail.gmail.com>
References: <CAJKmMz9ANuijyZf2pBuxH2T8Pwz_7EBYmqMH53Eth+DV4Z16rg@mail.gmail.com>
Message-ID: <em69a59ba5-76c4-4f1f-8e3a-f8d060fdf0d0@sebastian-pc>

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" <simon.peytonjones at gmail.com>
An: "GHC developers" <ghc-devs at haskell.org>
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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220927/bd476d73/attachment.html>

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: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>

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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220928/8a0ff5a6/attachment.html>

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: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>
References: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>
Message-ID: <CALHrtF=SBP-ODYhNckZsqfsv7fk52CYUUMSFhktpuBM4nGwh+w@mail.gmail.com>

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
<ghc-devs at haskell.org> 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: <CALHrtF=SBP-ODYhNckZsqfsv7fk52CYUUMSFhktpuBM4nGwh+w@mail.gmail.com>
References: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>
 <CALHrtF=SBP-ODYhNckZsqfsv7fk52CYUUMSFhktpuBM4nGwh+w@mail.gmail.com>
Message-ID: <CACUTo6zxRoLiOTS8614e8KTUp2omHWEojGLW0-2dAQn6kSRT9w@mail.gmail.com>

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 <cheng.shao at tweag.io> 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
> <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220928/08a84f97/attachment.html>

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: <CACUTo6zxRoLiOTS8614e8KTUp2omHWEojGLW0-2dAQn6kSRT9w@mail.gmail.com>
References: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>
 <CALHrtF=SBP-ODYhNckZsqfsv7fk52CYUUMSFhktpuBM4nGwh+w@mail.gmail.com>
 <CACUTo6zxRoLiOTS8614e8KTUp2omHWEojGLW0-2dAQn6kSRT9w@mail.gmail.com>
Message-ID: <CALHrtFnrbMx4E4Do6zEU6uvC7LuGft-MasmTXwAvjQQDavzOSA@mail.gmail.com>

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 <bryan at haskell.foundation> 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 <cheng.shao at tweag.io> 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
>> <ghc-devs at haskell.org> 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: <CALHrtFnrbMx4E4Do6zEU6uvC7LuGft-MasmTXwAvjQQDavzOSA@mail.gmail.com>
References: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>
 <CALHrtF=SBP-ODYhNckZsqfsv7fk52CYUUMSFhktpuBM4nGwh+w@mail.gmail.com>
 <CACUTo6zxRoLiOTS8614e8KTUp2omHWEojGLW0-2dAQn6kSRT9w@mail.gmail.com>
 <CALHrtFnrbMx4E4Do6zEU6uvC7LuGft-MasmTXwAvjQQDavzOSA@mail.gmail.com>
Message-ID: <CACUTo6yCWyas7NwWTC=5KjTqyv+f4U6L7aX1HkOWekbfqvjE_Q@mail.gmail.com>

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 <cheng.shao at tweag.io> 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 <bryan at haskell.foundation>
> 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 <cheng.shao at tweag.io> 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
> >> <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220928/a123d18a/attachment.html>

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: <CACUTo6yCWyas7NwWTC=5KjTqyv+f4U6L7aX1HkOWekbfqvjE_Q@mail.gmail.com>
References: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>
 <CALHrtF=SBP-ODYhNckZsqfsv7fk52CYUUMSFhktpuBM4nGwh+w@mail.gmail.com>
 <CACUTo6zxRoLiOTS8614e8KTUp2omHWEojGLW0-2dAQn6kSRT9w@mail.gmail.com>
 <CALHrtFnrbMx4E4Do6zEU6uvC7LuGft-MasmTXwAvjQQDavzOSA@mail.gmail.com>
 <CACUTo6yCWyas7NwWTC=5KjTqyv+f4U6L7aX1HkOWekbfqvjE_Q@mail.gmail.com>
Message-ID: <CALHrtF=vEz0ovF4678bcrcy=mp2KugWbzQMQ77ZmJMVjDW-KKw@mail.gmail.com>

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 <bryan at haskell.foundation> 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 <cheng.shao at tweag.io> 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 <bryan at haskell.foundation> 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 <cheng.shao at tweag.io> 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
>> >> <ghc-devs at haskell.org> 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: <CALHrtF=vEz0ovF4678bcrcy=mp2KugWbzQMQ77ZmJMVjDW-KKw@mail.gmail.com>
References: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>
 <CALHrtF=SBP-ODYhNckZsqfsv7fk52CYUUMSFhktpuBM4nGwh+w@mail.gmail.com>
 <CACUTo6zxRoLiOTS8614e8KTUp2omHWEojGLW0-2dAQn6kSRT9w@mail.gmail.com>
 <CALHrtFnrbMx4E4Do6zEU6uvC7LuGft-MasmTXwAvjQQDavzOSA@mail.gmail.com>
 <CACUTo6yCWyas7NwWTC=5KjTqyv+f4U6L7aX1HkOWekbfqvjE_Q@mail.gmail.com>
 <CALHrtF=vEz0ovF4678bcrcy=mp2KugWbzQMQ77ZmJMVjDW-KKw@mail.gmail.com>
Message-ID: <CACUTo6xmOQ2rJmRhj+prijf1ENHczO_TpydzMFjFRsyE5WZOMA@mail.gmail.com>

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 <cheng.shao at tweag.io> 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 <bryan at haskell.foundation>
> 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 <cheng.shao at tweag.io> 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 <bryan at haskell.foundation>
> 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 <cheng.shao at tweag.io>
> 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
> >> >> <ghc-devs at haskell.org> 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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220929/e6af9403/attachment.html>

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: <CACUTo6xmOQ2rJmRhj+prijf1ENHczO_TpydzMFjFRsyE5WZOMA@mail.gmail.com>
References: <CACUTo6z_QHrTwqy+4ihW1GSWq-G9YH9_nZ0s5S2kKXhiXe9O1g@mail.gmail.com>
 <CALHrtF=SBP-ODYhNckZsqfsv7fk52CYUUMSFhktpuBM4nGwh+w@mail.gmail.com>
 <CACUTo6zxRoLiOTS8614e8KTUp2omHWEojGLW0-2dAQn6kSRT9w@mail.gmail.com>
 <CALHrtFnrbMx4E4Do6zEU6uvC7LuGft-MasmTXwAvjQQDavzOSA@mail.gmail.com>
 <CACUTo6yCWyas7NwWTC=5KjTqyv+f4U6L7aX1HkOWekbfqvjE_Q@mail.gmail.com>
 <CALHrtF=vEz0ovF4678bcrcy=mp2KugWbzQMQ77ZmJMVjDW-KKw@mail.gmail.com>
 <CACUTo6xmOQ2rJmRhj+prijf1ENHczO_TpydzMFjFRsyE5WZOMA@mail.gmail.com>
Message-ID: <CALHrtFk9NNn-x4GOZ=4v2HJWd-_adU77Gz0jYyK3O5HaT_kwHg@mail.gmail.com>

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 <bryan at haskell.foundation> 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 <cheng.shao at tweag.io> 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 <bryan at haskell.foundation> 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 <cheng.shao at tweag.io> 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 <bryan at haskell.foundation> 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 <cheng.shao at tweag.io> 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
>> >> >> <ghc-devs at haskell.org> 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: <CAJKmMz9PWTrwDyD1XHxdbhB_om-XeLdGuePekB0MtXWRSpvfxw@mail.gmail.com>
References: <CAJKmMz9PWTrwDyD1XHxdbhB_om-XeLdGuePekB0MtXWRSpvfxw@mail.gmail.com>
Message-ID: <CACUTo6yymDoaSCeqsrpqVzYPgeQCY==HG-Yq8pA0RoYKosp4sA@mail.gmail.com>

(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: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20220930/a911b57c/attachment.html>