Re: HEAD bootstrap error macOS

[Gabor Greif]

This is now resolved. There were some incompatible

includes/ghcautoconf.h
includes/ghcplatform.h
includes/ghcversion.h

files hanging around (probably from a previous Hadrian build)
These never caused trouble, because all the right symbols were defined.
But recently with c2290596f10 some of the symbols changed.

Sorry for the noise.

Gabor

On 12/24/19, Gabor Greif  wrote:
> Comparing the above to the (successfully bootstrapping) Darwin CI
> job's configure output:
> ```
>Using (for bootstrapping) : gcc
>Using gcc : cc
>   which is version   : 11.0.0
> ```
>
>
> On 12/23/19, Gabor Greif  wrote:
>> I see some conflict potential from
>> ```
>> Configure completed successfully.
>>
>>Building GHC version  : 8.11.0.20191222
>>   Git commit id  : 1c302c6289a6eddc92b48815dd420bd58eb2f286
>>
>>Build platform: x86_64-apple-darwin
>>Host platform : x86_64-apple-darwin
>>Target platform   : x86_64-apple-darwin
>>
>>Bootstrapping using   :
>> /nix/store/m7nigmssmx89j5v22r1a83w6fb8cs6qb-ghc-8.6.5/bin/ghc
>>   which is version   : 8.6.5
>>
>>>>>   Using (for bootstrapping) :
>>>>> /nix/store/a76n8l1caynyyngdpnyihlrgyr9k9ilg-clang-wrapper-7.1.0/bin/cc
>>>>>   Using gcc :
>>>>> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
>>   which is version   : 9.0.0
>>Building a cross compiler : NO
>>Unregisterised: NO
>>TablesNextToCode  : YES
>>hs-cpp   :
>> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
>>hs-cpp-flags : -E -undef -traditional -Wno-invalid-pp-token
>> -Wno-unicode -Wno-trigraphs
>> ```
>>
>> It is strange that
>> `/nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc`
>> is identified as `gcc`. It is `clang`:
>> ```
>> [nix-shell:~/ghc]$
>> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
>> --version
>> clang version 9.0.0 (tags/RELEASE_900/final)
>> Target: x86_64-apple-darwin17.7.0
>> Thread model: posix
>> InstalledDir: /nix/store/mg8gzayayl9sbgdy5hq2km6lxgi9x6dp-clang-9.0.0/bin
>> ```
>>
>> Cheers,
>>
>> Gabor
>>
>>
>>
>> On 12/23/19, Gabor Greif  wrote:
>>> This is a clean tree. Modulo
>>> ```
>>> $ diff -u mk/build.mk.sample mk/build.mk
>>> --- mk/build.mk.sample  2019-12-07 20:44:48.850209944 +0100
>>> +++ mk/build.mk 2019-11-27 14:18:57.052582066 +0100
>>> @@ -20,7 +20,7 @@
>>>  #BuildFlavour = perf-cross-ncg
>>>
>>>  # Fast build with optimised libraries, no profiling (RECOMMENDED):
>>> -#BuildFlavour = quick
>>> +BuildFlavour = quick
>>> ```
>>>
>>> I see
>>> ```
>>> $ grep CC_LLVM_BACKEND config*
>>> config.log:| #define CC_LLVM_BACKEND 1
>>> ```
>>>
>>> Yes this is with clang-9, but it also happened with clang-7.
>>>
>>> I'll try to track this down. The TLS tip is good.
>>>
>>> Thanks,
>>>
>>>  Gabor
>>>
>>> On 12/23/19, Ben Gamari  wrote:
>>>> Gabor Greif  writes:
>>>>
>>>>> Recently I started getting following error:
>>>>> ```
>>>>> [nix-shell:~/ghc]$ "inplace/bin/ghc-stage1" -optc-Wall -optc-Wall
>>>>> -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes
>>>>> -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith
>>>>> -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls
>>>>> -optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist
>>>>> -optc-Iincludes/dist-derivedconstants/header
>>>>> -optc-Iincludes/dist-ghcconstants/header
>>>>> -optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build
>>>>> -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing
>>>>> -optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen
>>>>> -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit-frame-pointer -optc-g
>>>>> -optc-DRtsWay=\"rts_thr\" -static -optc-DTHREADED_RTS  -O0 -H64m -Wall
>>>>>   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
>>>>> -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
>>>>> -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESP

Re: HEAD bootstrap error macOS

[Gabor Greif]

Comparing the above to the (successfully bootstrapping) Darwin CI
job's configure output:
```
   Using (for bootstrapping) : gcc
   Using gcc : cc
  which is version   : 11.0.0
```


On 12/23/19, Gabor Greif  wrote:
> I see some conflict potential from
> ```
> Configure completed successfully.
>
>Building GHC version  : 8.11.0.20191222
>   Git commit id  : 1c302c6289a6eddc92b48815dd420bd58eb2f286
>
>Build platform: x86_64-apple-darwin
>Host platform : x86_64-apple-darwin
>Target platform   : x86_64-apple-darwin
>
>Bootstrapping using   :
> /nix/store/m7nigmssmx89j5v22r1a83w6fb8cs6qb-ghc-8.6.5/bin/ghc
>   which is version   : 8.6.5
>
>>>>   Using (for bootstrapping) :
>>>> /nix/store/a76n8l1caynyyngdpnyihlrgyr9k9ilg-clang-wrapper-7.1.0/bin/cc
>>>>   Using gcc :
>>>> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
>   which is version   : 9.0.0
>Building a cross compiler : NO
>Unregisterised: NO
>TablesNextToCode  : YES
>hs-cpp   :
> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
>hs-cpp-flags : -E -undef -traditional -Wno-invalid-pp-token
> -Wno-unicode -Wno-trigraphs
> ```
>
> It is strange that
> `/nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc`
> is identified as `gcc`. It is `clang`:
> ```
> [nix-shell:~/ghc]$
> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
> --version
> clang version 9.0.0 (tags/RELEASE_900/final)
> Target: x86_64-apple-darwin17.7.0
> Thread model: posix
> InstalledDir: /nix/store/mg8gzayayl9sbgdy5hq2km6lxgi9x6dp-clang-9.0.0/bin
> ```
>
> Cheers,
>
> Gabor
>
>
>
> On 12/23/19, Gabor Greif  wrote:
>> This is a clean tree. Modulo
>> ```
>> $ diff -u mk/build.mk.sample mk/build.mk
>> --- mk/build.mk.sample   2019-12-07 20:44:48.850209944 +0100
>> +++ mk/build.mk  2019-11-27 14:18:57.052582066 +0100
>> @@ -20,7 +20,7 @@
>>  #BuildFlavour = perf-cross-ncg
>>
>>  # Fast build with optimised libraries, no profiling (RECOMMENDED):
>> -#BuildFlavour = quick
>> +BuildFlavour = quick
>> ```
>>
>> I see
>> ```
>> $ grep CC_LLVM_BACKEND config*
>> config.log:| #define CC_LLVM_BACKEND 1
>> ```
>>
>> Yes this is with clang-9, but it also happened with clang-7.
>>
>> I'll try to track this down. The TLS tip is good.
>>
>> Thanks,
>>
>>  Gabor
>>
>> On 12/23/19, Ben Gamari  wrote:
>>> Gabor Greif  writes:
>>>
>>>> Recently I started getting following error:
>>>> ```
>>>> [nix-shell:~/ghc]$ "inplace/bin/ghc-stage1" -optc-Wall -optc-Wall
>>>> -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes
>>>> -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith
>>>> -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls
>>>> -optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist
>>>> -optc-Iincludes/dist-derivedconstants/header
>>>> -optc-Iincludes/dist-ghcconstants/header
>>>> -optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build
>>>> -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing
>>>> -optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen
>>>> -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit-frame-pointer -optc-g
>>>> -optc-DRtsWay=\"rts_thr\" -static -optc-DTHREADED_RTS  -O0 -H64m -Wall
>>>>   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
>>>> -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
>>>> -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts
>>>> -this-unit-id rts -dcmm-lint  -DDTRACE -i -irts -irts/dist/build
>>>> -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen
>>>>-O2 -Wcpp-undef-Wnoncanonical-monad-instances  -c
>>>> rts/sm/Scav_thr.c -o rts/dist/build/sm/Scav_thr.thr_o -v
>>>> Glasgow Haskell Compiler, Version 8.11.0.20191222, stage 1 booted by
>>>> GHC version 8.6.5
>>>> *** initializing package database:
>>>> Using binary package database:
>>>> /Users/ggreif/ghc/inplace/lib/package.conf.d/package.cache
>>>> package flags []
>>>> loading package database /Users/ggreif/ghc/inplace/lib/package.conf.d
>>>> wired-in package ghc-prim mapped t

Re: HEAD bootstrap error macOS

[Gabor Greif]

I see some conflict potential from
```
Configure completed successfully.

   Building GHC version  : 8.11.0.20191222
  Git commit id  : 1c302c6289a6eddc92b48815dd420bd58eb2f286

   Build platform: x86_64-apple-darwin
   Host platform : x86_64-apple-darwin
   Target platform   : x86_64-apple-darwin

   Bootstrapping using   :
/nix/store/m7nigmssmx89j5v22r1a83w6fb8cs6qb-ghc-8.6.5/bin/ghc
  which is version   : 8.6.5

>>>   Using (for bootstrapping) : 
>>> /nix/store/a76n8l1caynyyngdpnyihlrgyr9k9ilg-clang-wrapper-7.1.0/bin/cc
>>>   Using gcc : 
>>> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
  which is version   : 9.0.0
   Building a cross compiler : NO
   Unregisterised: NO
   TablesNextToCode  : YES
   hs-cpp   :
/nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
   hs-cpp-flags : -E -undef -traditional -Wno-invalid-pp-token
-Wno-unicode -Wno-trigraphs
```

It is strange that
`/nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc`
is identified as `gcc`. It is `clang`:
```
[nix-shell:~/ghc]$
/nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
--version
clang version 9.0.0 (tags/RELEASE_900/final)
Target: x86_64-apple-darwin17.7.0
Thread model: posix
InstalledDir: /nix/store/mg8gzayayl9sbgdy5hq2km6lxgi9x6dp-clang-9.0.0/bin
```

Cheers,

    Gabor



On 12/23/19, Gabor Greif  wrote:
> This is a clean tree. Modulo
> ```
> $ diff -u mk/build.mk.sample mk/build.mk
> --- mk/build.mk.sample2019-12-07 20:44:48.850209944 +0100
> +++ mk/build.mk   2019-11-27 14:18:57.052582066 +0100
> @@ -20,7 +20,7 @@
>  #BuildFlavour = perf-cross-ncg
>
>  # Fast build with optimised libraries, no profiling (RECOMMENDED):
> -#BuildFlavour = quick
> +BuildFlavour = quick
> ```
>
> I see
> ```
> $ grep CC_LLVM_BACKEND config*
> config.log:| #define CC_LLVM_BACKEND 1
> ```
>
> Yes this is with clang-9, but it also happened with clang-7.
>
> I'll try to track this down. The TLS tip is good.
>
> Thanks,
>
>  Gabor
>
> On 12/23/19, Ben Gamari  wrote:
>> Gabor Greif  writes:
>>
>>> Recently I started getting following error:
>>> ```
>>> [nix-shell:~/ghc]$ "inplace/bin/ghc-stage1" -optc-Wall -optc-Wall
>>> -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes
>>> -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith
>>> -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls
>>> -optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist
>>> -optc-Iincludes/dist-derivedconstants/header
>>> -optc-Iincludes/dist-ghcconstants/header
>>> -optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build
>>> -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing
>>> -optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen
>>> -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit-frame-pointer -optc-g
>>> -optc-DRtsWay=\"rts_thr\" -static -optc-DTHREADED_RTS  -O0 -H64m -Wall
>>>   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
>>> -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
>>> -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts
>>> -this-unit-id rts -dcmm-lint  -DDTRACE -i -irts -irts/dist/build
>>> -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen
>>>-O2 -Wcpp-undef-Wnoncanonical-monad-instances  -c
>>> rts/sm/Scav_thr.c -o rts/dist/build/sm/Scav_thr.thr_o -v
>>> Glasgow Haskell Compiler, Version 8.11.0.20191222, stage 1 booted by
>>> GHC version 8.6.5
>>> *** initializing package database:
>>> Using binary package database:
>>> /Users/ggreif/ghc/inplace/lib/package.conf.d/package.cache
>>> package flags []
>>> loading package database /Users/ggreif/ghc/inplace/lib/package.conf.d
>>> wired-in package ghc-prim mapped to ghc-prim-0.6.1
>>> wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0
>>> wired-in package base mapped to base-4.14.0.0
>>> wired-in package rts mapped to rts
>>> wired-in package template-haskell mapped to template-haskell-2.16.0.0
>>> wired-in package ghc mapped to ghc-8.11.0.20191222
>>> !!! initializing package database: finished in 8.51 milliseconds,
>>> allocated 8.770 megabytes
>>> Created temporary directory:
>>> /var/folders/39/lr50t0q96tx5qp0mzht34r24gn/T/ghc55616_0
>>> *** systool:cc:
>>> *** C Compiler:
>>> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/

Re: HEAD bootstrap error macOS

[Gabor Greif]

This is a clean tree. Modulo
```
$ diff -u mk/build.mk.sample mk/build.mk
--- mk/build.mk.sample  2019-12-07 20:44:48.850209944 +0100
+++ mk/build.mk 2019-11-27 14:18:57.052582066 +0100
@@ -20,7 +20,7 @@
 #BuildFlavour = perf-cross-ncg

 # Fast build with optimised libraries, no profiling (RECOMMENDED):
-#BuildFlavour = quick
+BuildFlavour = quick
```

I see
```
$ grep CC_LLVM_BACKEND config*
config.log:| #define CC_LLVM_BACKEND 1
```

Yes this is with clang-9, but it also happened with clang-7.

I'll try to track this down. The TLS tip is good.

Thanks,

 Gabor

On 12/23/19, Ben Gamari  wrote:
> Gabor Greif  writes:
>
>> Recently I started getting following error:
>> ```
>> [nix-shell:~/ghc]$ "inplace/bin/ghc-stage1" -optc-Wall -optc-Wall
>> -optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes
>> -optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith
>> -optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls
>> -optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist
>> -optc-Iincludes/dist-derivedconstants/header
>> -optc-Iincludes/dist-ghcconstants/header
>> -optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build
>> -optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing
>> -optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen
>> -optc-Wno-unknown-pragmas -optc-O2 -optc-fomit-frame-pointer -optc-g
>> -optc-DRtsWay=\"rts_thr\" -static -optc-DTHREADED_RTS  -O0 -H64m -Wall
>>   -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
>> -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
>> -Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts
>> -this-unit-id rts -dcmm-lint  -DDTRACE -i -irts -irts/dist/build
>> -Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen
>>-O2 -Wcpp-undef-Wnoncanonical-monad-instances  -c
>> rts/sm/Scav_thr.c -o rts/dist/build/sm/Scav_thr.thr_o -v
>> Glasgow Haskell Compiler, Version 8.11.0.20191222, stage 1 booted by
>> GHC version 8.6.5
>> *** initializing package database:
>> Using binary package database:
>> /Users/ggreif/ghc/inplace/lib/package.conf.d/package.cache
>> package flags []
>> loading package database /Users/ggreif/ghc/inplace/lib/package.conf.d
>> wired-in package ghc-prim mapped to ghc-prim-0.6.1
>> wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0
>> wired-in package base mapped to base-4.14.0.0
>> wired-in package rts mapped to rts
>> wired-in package template-haskell mapped to template-haskell-2.16.0.0
>> wired-in package ghc mapped to ghc-8.11.0.20191222
>> !!! initializing package database: finished in 8.51 milliseconds,
>> allocated 8.770 megabytes
>> Created temporary directory:
>> /var/folders/39/lr50t0q96tx5qp0mzht34r24gn/T/ghc55616_0
>> *** systool:cc:
>> *** C Compiler:
>> /nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
>> -x c rts/sm/Scav_thr.c -o
>> /var/folders/39/lr50t0q96tx5qp0mzht34r24gn/T/ghc55616_0/ghc_1.s
>> -fno-common -U__PIC__ -D__PIC__ -Wimplicit -S -O2 -include
>> /Users/ggreif/ghc/includes/ghcversion.h -Iincludes -Iincludes/dist
>> -Iincludes/dist-derivedconstants/header
>> -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
>> -Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen
>> -I/Users/ggreif/ghc/libraries/base/include
>> -I/Users/ggreif/ghc/libraries/base/dist-install/build/include
>> -I/Users/ggreif/ghc/libraries/base/dist-install/build/dist-install/build/include
>> -I/Users/ggreif/ghc/libraries/integer-gmp/include
>> -I/Users/ggreif/ghc/libraries/integer-gmp/dist-install/build/include
>> -I/Users/ggreif/ghc/libraries/integer-gmp/dist-install/build/dist-install/build/include
>> -I/Users/ggreif/ghc/rts/dist/build -I/Users/ggreif/ghc/includes
>> -I/Users/ggreif/ghc/includes/dist-derivedconstants/header
>> -I/Users/ggreif/ghc/includes/dist-install/build -Xpreprocessor
>> -DCOMPILING_RTS -Xpreprocessor '-DFS_NAMESPACE=rts' -Xpreprocessor
>> -DDTRACE -Wall -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes
>> -Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn
>> -Wnested-externs -Wredundant-decls -Wno-aggregate-return -Iincludes
>> -Iincludes/dist -Iincludes/dist-derivedconstants/header
>> -Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
>> -Irts -Irts/dist/build -DCOMPILING_RTS '-DFS_NAMESPACE=rts'
>> -fno-strict-aliasing -fno-common -DDTRACE -Irts/dist/build/./autogen
>> -Wno-unknown-pragmas -O2 -fomit-frame-pointer -g '-DRtsWay="

HEAD bootstrap error macOS

[Gabor Greif]

Recently I started getting following error:
```
[nix-shell:~/ghc]$ "inplace/bin/ghc-stage1" -optc-Wall -optc-Wall
-optc-Wextra -optc-Wstrict-prototypes -optc-Wmissing-prototypes
-optc-Wmissing-declarations -optc-Winline -optc-Wpointer-arith
-optc-Wmissing-noreturn -optc-Wnested-externs -optc-Wredundant-decls
-optc-Wno-aggregate-return -optc-Iincludes -optc-Iincludes/dist
-optc-Iincludes/dist-derivedconstants/header
-optc-Iincludes/dist-ghcconstants/header
-optc-Iincludes/dist-install/build -optc-Irts -optc-Irts/dist/build
-optc-DCOMPILING_RTS -optc-DFS_NAMESPACE=rts -optc-fno-strict-aliasing
-optc-fno-common -optc-DDTRACE -optc-Irts/dist/build/./autogen
-optc-Wno-unknown-pragmas -optc-O2 -optc-fomit-frame-pointer -optc-g
-optc-DRtsWay=\"rts_thr\" -static -optc-DTHREADED_RTS  -O0 -H64m -Wall
  -Iincludes -Iincludes/dist -Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
-Irts -Irts/dist/build -DCOMPILING_RTS -DFS_NAMESPACE=rts
-this-unit-id rts -dcmm-lint  -DDTRACE -i -irts -irts/dist/build
-Irts/dist/build -irts/dist/build/./autogen -Irts/dist/build/./autogen
   -O2 -Wcpp-undef-Wnoncanonical-monad-instances  -c
rts/sm/Scav_thr.c -o rts/dist/build/sm/Scav_thr.thr_o -v
Glasgow Haskell Compiler, Version 8.11.0.20191222, stage 1 booted by
GHC version 8.6.5
*** initializing package database:
Using binary package database:
/Users/ggreif/ghc/inplace/lib/package.conf.d/package.cache
package flags []
loading package database /Users/ggreif/ghc/inplace/lib/package.conf.d
wired-in package ghc-prim mapped to ghc-prim-0.6.1
wired-in package integer-wired-in mapped to integer-gmp-1.0.2.0
wired-in package base mapped to base-4.14.0.0
wired-in package rts mapped to rts
wired-in package template-haskell mapped to template-haskell-2.16.0.0
wired-in package ghc mapped to ghc-8.11.0.20191222
!!! initializing package database: finished in 8.51 milliseconds,
allocated 8.770 megabytes
Created temporary directory:
/var/folders/39/lr50t0q96tx5qp0mzht34r24gn/T/ghc55616_0
*** systool:cc:
*** C Compiler:
/nix/store/mq8dqgqf2qqkp77pzf3jwc05px8rkbny-clang-wrapper-9.0.0/bin/cc
-x c rts/sm/Scav_thr.c -o
/var/folders/39/lr50t0q96tx5qp0mzht34r24gn/T/ghc55616_0/ghc_1.s
-fno-common -U__PIC__ -D__PIC__ -Wimplicit -S -O2 -include
/Users/ggreif/ghc/includes/ghcversion.h -Iincludes -Iincludes/dist
-Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
-Irts -Irts/dist/build -Irts/dist/build -Irts/dist/build/./autogen
-I/Users/ggreif/ghc/libraries/base/include
-I/Users/ggreif/ghc/libraries/base/dist-install/build/include
-I/Users/ggreif/ghc/libraries/base/dist-install/build/dist-install/build/include
-I/Users/ggreif/ghc/libraries/integer-gmp/include
-I/Users/ggreif/ghc/libraries/integer-gmp/dist-install/build/include
-I/Users/ggreif/ghc/libraries/integer-gmp/dist-install/build/dist-install/build/include
-I/Users/ggreif/ghc/rts/dist/build -I/Users/ggreif/ghc/includes
-I/Users/ggreif/ghc/includes/dist-derivedconstants/header
-I/Users/ggreif/ghc/includes/dist-install/build -Xpreprocessor
-DCOMPILING_RTS -Xpreprocessor '-DFS_NAMESPACE=rts' -Xpreprocessor
-DDTRACE -Wall -Wall -Wextra -Wstrict-prototypes -Wmissing-prototypes
-Wmissing-declarations -Winline -Wpointer-arith -Wmissing-noreturn
-Wnested-externs -Wredundant-decls -Wno-aggregate-return -Iincludes
-Iincludes/dist -Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -Iincludes/dist-install/build
-Irts -Irts/dist/build -DCOMPILING_RTS '-DFS_NAMESPACE=rts'
-fno-strict-aliasing -fno-common -DDTRACE -Irts/dist/build/./autogen
-Wno-unknown-pragmas -O2 -fomit-frame-pointer -g '-DRtsWay="rts_thr"'
-DTHREADED_RTS

In file included from rts/sm/Scav_thr.c:3:0: error:

In file included from rts/sm/Scav.c:51:0: error:

In file included from rts/sm/GCUtils.h:18:0: error:

rts/sm/GCTDecl.h:113:1: error:
 error: register '%r13' unsuitable for global register variables
on this target
|
113 | GCT_REG_DECL(gc_thread*, gct, REG_Base);
| ^
GCT_REG_DECL(gc_thread*, gct, REG_Base);
^

rts/sm/GCTDecl.h:37:56: error:
 note: expanded from macro 'GCT_REG_DECL'
   |
37 | #define GCT_REG_DECL(type,name,reg) register type name REG(reg);
   |^
#define GCT_REG_DECL(type,name,reg) register type name REG(reg);
   ^

includes/stg/MachRegs.h:160:24: error:
 note: expanded from macro 'REG'
|
160 | #define REG(x) __asm__("%" #x)
|^
#define REG(x) __asm__("%" #x)
   ^
1 error generated.
*** Deleting temp files:
Deleting: /var/folders/39/lr50t0q96tx5qp0mzht34r24gn/T/ghc55616_0/ghc_1.s
/var/folders/39/lr50t0q96tx5qp0mzht34r24gn/T/ghc55616_0/ghc_2.rsp
Warning: deleting non-existent
/var/folders/39/lr50t0q96tx5qp0mzht34r24gn/T/ghc55616_0/ghc_1.s
*** Deleting temp dirs:
Deleting: /var/folders/39/lr

Re: Typo in closure name in rts/Prelude.h

[Gabor Greif]

No, this is not a typo, it it "z-encoding".
(http://hackage.haskell.org/package/zenc-0.1.1/docs/Text-Encoding-Z.html)

Cheers,

Gabor

On 12/15/19, Csaba Hruska  wrote:
> Sorry, I messed up the first link. It meant to be
> *base_GHCziWeak_runFinalizzerBatch_closure*
> 
>
> On Sun, Dec 15, 2019 at 1:15 PM Csaba Hruska 
> wrote:
>
>> Hello,
>>
>> Could you confirm if *base_GHCziWeak_rrts/win32/libHSbase.def_closure*
>>  is a
>> typo in rts/Prelude.h?
>> I guess it is a typo because *base_GHCziWeak_runFinalizerBatch_closure*
>> does exists in base/GHC/Weak.hs.
>> 
>>
>> The following files have the wrong name:
>>
>>- rts/package.conf.in
>>- rts/rts.cabal.in
>>- rts/Prelude.h
>>- rts/win32/libHSbase.def
>>
>> Regards,
>> Csaba
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC 8.10.1 Release Plan

[Gabor Greif]

Please consider https://gitlab.haskell.org/ghc/ghc/merge_requests/1742.
I thought it would be a hassle to write tests for it, but I figured
out a nice way.

I set the milestone to 8.12.1, because I expected more problems, but
it seems like things are going smoothly and this is becoming a
candidate for 8.10.1.

Cheers,

Gabor

On 9/18/19, Ben Gamari  wrote:
> tl;dr. If you have unmerged work that you would like to be in GHC 8.10
> please
>reply to this email and submit it for review in the next couple
>of weeks.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Min closure payload size?

[Gabor Greif]

Just guessing here, maybe this thunk type lives in (read-only?) static
sections, and as such it will never be overwritten with forwarding
pointers?

Gabor

On 2/5/19, Ömer Sinan Ağacan  wrote:
> I just came across a closure that is according to this code is not valid:
>
> >>> print *get_itbl(0x7b2870)
> $8 = {
>   layout = {
> payload = {
>   ptrs = 0,
>   nptrs = 0
> },
> bitmap = 0,
> large_bitmap_offset = 0,
> __pad_large_bitmap_offset = 0,
> selector_offset = 0
>   },
>   type = 21,
>   srt = 3856568,
>   code = 0x404ef0 
> "H\215E\360L9\370rDH\203\354\bL\211\350H\211\336H\211\307\061\300\350|\034\062"
> }
>
> This is a THUNK_STATIC with 0 ptrs and nptrs in the payload.
>
> Ömer
>
> Ömer Sinan Ağacan , 4 Şub 2019 Pzt, 16:23
> tarihinde şunu yazdı:
>>
>> Hi,
>>
>> I was trying to understand why some info tables that have no ptrs and
>> nptrs like
>> GCD_CAF end up with 1 nptrs in the generated info table and found this
>> code in
>> Constants.h:
>>
>> /*
>> -
>>Minimum closure sizes
>>
>>This is the minimum number of words in the payload of a
>>heap-allocated closure, so that the closure has enough room to be
>>overwritten with a forwarding pointer during garbage collection.
>>
>> --
>> */
>>
>> #define MIN_PAYLOAD_SIZE 1
>>
>> We use this in a few places in the compiler and add at least one word
>> space in
>> the payload. However the comment is actually wrong, forwarding pointers
>> are made
>> by tagging the info ptr field so we don't need a word in the payload for
>> forwarding pointers. I tried updating this as 0 but that caused a lot of
>> test
>> failures (mostly in GHCi). I'm wondering if I'm missing anything or is it
>> just
>> some code assuming min payload size 1 without using this macro.
>>
>> Any ideas?
>>
>> Ömer
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Gitlab pain

[Gabor Greif]

I have just tried putting following URL into the discussion tab's URL bar

 javascript: $(".discussion-toggle-button:has(i.fa-chevron-down)").click()

and it seems to work.

Cheers,

Gabor

On 1/4/19, Artem Pelenitsyn  wrote:
> It seems you'd want the "Toggle All" button. There is an issue for that:
>
> https://gitlab.com/gitlab-org/gitlab-ce/issues/19149
>
> There is even a beautiful workaround given there with typing the following
> command in the JavaScript console in a browser:
> $(".discussion-toggle-button:has(i.fa-chevron-down)").click()
> After that, indeed, I could Ctrl+F the phrase referenced by Simon ("Another
> module should reference the symbol") while before I could not.
>
> --
> Best, Artem
>
> On Fri, 4 Jan 2019 at 21:48 Ben Gamari  wrote:
>
>> Quite right. I will bring this up with upstream.
>>
>> On January 4, 2019 1:04:43 PM EST, Brandon Allbery 
>> wrote:
>>>
>>> On Fri, Jan 4, 2019 at 1:02 PM Ben Gamari  wrote:
>>>
 As mentioned by others, discussions that have been marked as "resolved"
 are collapsed by default. If you search for the text "Toggle
 discussion"
 you will find that the collapsed discussions have link on their
 right-hand side which you can click on to expand the hidden comments.

>>>
>>> The problem there being there's a lot of such, and no way to tell which
>>> one is relevant unless you have both original links and enough context.
>>> Finding stuff like that absent context doesn't look at all easy. :/
>>>
>>> --
>>> brandon s allbery kf8nh
>>> allber...@gmail.com
>>>
>>
>> --
>> Sent from my Android device with K-9 Mail. Please excuse my brevity.
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab forks and submodules

[Gabor Greif]

You can specify `[skip ci]` in the commit message if you don't want to
run the pipeline. When you are done, just amend your commit with the
finalised note.

Gabor

On 1/8/19, Ömer Sinan Ağacan  wrote:
>> As I mention in the documentation, those with commits bits should feel
>> free to push branches to ghc/ghc.
>
> This is sometimes not ideal as it wastes GHC's CI resources. For example I
> make
> a lot of WIP commits to my work branches, and I don't want to keep CI
> machines
> busy for those.
>
> Ömer
>
> Ben Gamari , 8 Oca 2019 Sal, 04:53 tarihinde şunu yazdı:
>>
>> Moritz Angermann  writes:
>>
>> > Can’t we have absolute submodule paths? Wouldn’t that elevate the
>> > issue?
>> >
>> Perhaps; I mentioned this possibility in my earlier response. It's not
>> clear which trade-off is better overall, however.
>>
>> > When we all had branches on ghc/ghc this
>> > was not an issue.
>> >
>> As I mention in the documentation, those with commits bits should feel
>> free to push branches to ghc/ghc.
>>
>> Cheers,
>>
>> - Ben
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Q] Inlining done: evtRead

[Gabor Greif]

Thanks Mikolaj and Simon,

this explains it. I'll study the related ticket next. Still, the
floating-out related duplication aspect looks like a problem, or would
you disagree? I mean,

a) If the INLINE pragma is such a commandment, why don't we respect it with -O0?
b) Would it be sensible to only inline in scrutinee (`case  of
...`) context, to avoid duplication? After all it's the guts of the
value we are interested in, not the whole package.
c) Could a global CSE pass pick up the floated-out value and revert it
to the original imported identifier?
d) Or should be simply remove the INLINE pragmas from the library
(0-ary objects)? Possibly changing to INLINABLE?

Just thinking out loud, as this appears like a pessimisation to me.

Cheers,

Gabor

On 1/8/19, Mikolaj Konarski  wrote:
> On Tue, Jan 8, 2019 at 2:10 AM Gabor Greif  wrote:
>>
>> Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
>> inliner to respect the pragma?
>
> Yes:
> https://gitlab.haskell.org/ghc/ghc/commit/b9b1f99954e69f23e9647d00e048938d5509ec14
>
> But it's not on 8.6 branch (yet?).
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Q] Inlining done: evtRead

[Gabor Greif]

Hmm, yes. So why wasn't GHC 8.4 doing this? Did some commit fix the
inliner to respect the pragma?

Thanks and cheers,

Gabor

On 1/8/19, Simon Peyton Jones  wrote:
> Oh well, your INLINE pragma is saying "please inline evtRead at every call
> site". And so GHC does exactly that.
>
> That seems like obeying the pragma doesn't it?
>
> Simon
>
> | -Original Message-
> | From: Gabor Greif 
> | Sent: 08 January 2019 00:06
> | To: Simon Peyton Jones 
> | Cc: ghc-devs 
> | Subject: Re: [Q] Inlining done: evtRead
> |
> | I think you have to follow this:
> |
> | -- | Data is available to be read.
> | evtRead :: Event
> | evtRead = Event 1
> | {-# INLINE evtRead #-}
> |
> |
> | On 1/8/19, Simon Peyton Jones  wrote:
> | > Are you sure?   GHC.Event isn't used on Windows, so I did this:
> | >
> | > =
> | > module Bar where
> | >
> | > newtype Evt = Evt Int
> | >
> | > evtRead :: Evt
> | > evtRead = Evt 33
> | >
> | > instance Show Evt where
> | >   show = showEvt
> | >
> | > showEvt :: Evt -> String
> | > {-# NOINLINE showEvt #-}
> | > showEvt (Evt x) = show x
> | > 
> | >
> | > module Foo where
> | >
> | > import Bar
> | >
> | > main = print evtRead
> | > ===
> | >
> | > And indeed when I compile these with -O I get
> | >
> | > Foo.main1
> | >   = showEvt (Bar.evtRead1 `cast` (Sym (Bar.N:Evt[0]) :: Int ~R# Evt))
> | >
> | > where Bar.evtRead1 is the static (I# 33) box.
> | >
> | > No duplication.
> | >
> | > Can you give me a repro case that isn't OS-specific?  (I suppose I can
> | try
> | > on Linux tomorrow, but I'm sure that the OS is only accidentally
> involved
> | > here.)
> | >
> | > Simon
> | >
> | > | -Original Message-
> | > | From: Gabor Greif 
> | > | Sent: 07 January 2019 23:28
> | > | To: Simon Peyton Jones 
> | > | Cc: ghc-devs 
> | > | Subject: [Q] Inlining done: evtRead
> | > |
> | > | Hi Simon,
> | > |
> | > | a simplifier question...
> | > |
> | > | Roughly a year ago I started learning about imported Ids, their
> | > unfoldings
> | > | etc.
> | > |
> | > | I have very small example program that compiles on Linux.
> | > |
> | > | ```haskell
> | > | import GHC.Event
> | > |
> | > | main = print evtRead
> | > | ```
> | > |
> | > | `evtRead` is a newtype-wrapped Int. When you compile above program
> | > | with HEAD GHC without optimisation, you'll see that `evtRead` gets
> | > | passed directly to `show`.
> | > |
> | > | But with -O1 it's unfolding will be inlined, floated to toplevel, and
> | > | dumped as static global data into the using Main module. This was not
> | > | the case in GHC 8.4. Not sure about 8.6 (will check). Anyway here is
> | > | the inlining notice that the simplifier gave me (-ddump-inlinings
> | > | -dverbose-core2core)
> | > |
> | > | > Inlining done: GHC.Event.Internal.evtRead
> | > | > Inlined fn:  (GHC.Types.I# 1#)
> | > | >  `cast` (Sym (GHC.Event.Internal.N:Event[0])
> | > | >  :: GHC.Types.Coercible GHC.Types.Int
> | > | > GHC.Event.Internal.Event)
> | > | > Cont:   Stop[BoringCtxt] GHC.Event.Internal.Event
> | > | >
> | > |
> | > | I believe this is a regression, as copies of global data can pop up
> in
> | > | potentially many different modules.
> | > |
> | > | What do you think? Which change could have caused this?
> | > |
> | > | Cheers,
> | > |
> | > | Gabor
> | >
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [Q] Inlining done: evtRead

[Gabor Greif]

I think you have to follow this:

-- | Data is available to be read.
evtRead :: Event
evtRead = Event 1
{-# INLINE evtRead #-}


On 1/8/19, Simon Peyton Jones  wrote:
> Are you sure?   GHC.Event isn't used on Windows, so I did this:
>
> =
> module Bar where
>
> newtype Evt = Evt Int
>
> evtRead :: Evt
> evtRead = Evt 33
>
> instance Show Evt where
>   show = showEvt
>
> showEvt :: Evt -> String
> {-# NOINLINE showEvt #-}
> showEvt (Evt x) = show x
> 
>
> module Foo where
>
> import Bar
>
> main = print evtRead
> ===
>
> And indeed when I compile these with -O I get
>
> Foo.main1
>   = showEvt (Bar.evtRead1 `cast` (Sym (Bar.N:Evt[0]) :: Int ~R# Evt))
>
> where Bar.evtRead1 is the static (I# 33) box.
>
> No duplication.
>
> Can you give me a repro case that isn't OS-specific?  (I suppose I can try
> on Linux tomorrow, but I'm sure that the OS is only accidentally involved
> here.)
>
> Simon
>
> | -Original Message-
> | From: Gabor Greif 
> | Sent: 07 January 2019 23:28
> | To: Simon Peyton Jones 
> | Cc: ghc-devs 
> | Subject: [Q] Inlining done: evtRead
> |
> | Hi Simon,
> |
> | a simplifier question...
> |
> | Roughly a year ago I started learning about imported Ids, their
> unfoldings
> | etc.
> |
> | I have very small example program that compiles on Linux.
> |
> | ```haskell
> | import GHC.Event
> |
> | main = print evtRead
> | ```
> |
> | `evtRead` is a newtype-wrapped Int. When you compile above program
> | with HEAD GHC without optimisation, you'll see that `evtRead` gets
> | passed directly to `show`.
> |
> | But with -O1 it's unfolding will be inlined, floated to toplevel, and
> | dumped as static global data into the using Main module. This was not
> | the case in GHC 8.4. Not sure about 8.6 (will check). Anyway here is
> | the inlining notice that the simplifier gave me (-ddump-inlinings
> | -dverbose-core2core)
> |
> | > Inlining done: GHC.Event.Internal.evtRead
> | > Inlined fn:  (GHC.Types.I# 1#)
> | >  `cast` (Sym (GHC.Event.Internal.N:Event[0])
> | >  :: GHC.Types.Coercible GHC.Types.Int
> | > GHC.Event.Internal.Event)
> | > Cont:   Stop[BoringCtxt] GHC.Event.Internal.Event
> | >
> |
> | I believe this is a regression, as copies of global data can pop up in
> | potentially many different modules.
> |
> | What do you think? Which change could have caused this?
> |
> | Cheers,
> |
> | Gabor
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

[Q] Inlining done: evtRead

[Gabor Greif]

Hi Simon,

a simplifier question...

Roughly a year ago I started learning about imported Ids, their unfoldings etc.

I have very small example program that compiles on Linux.

```haskell
import GHC.Event

main = print evtRead
```

`evtRead` is a newtype-wrapped Int. When you compile above program
with HEAD GHC without optimisation, you'll see that `evtRead` gets
passed directly to `show`.

But with -O1 it's unfolding will be inlined, floated to toplevel, and
dumped as static global data into the using Main module. This was not
the case in GHC 8.4. Not sure about 8.6 (will check). Anyway here is
the inlining notice that the simplifier gave me (-ddump-inlinings
-dverbose-core2core)

> Inlining done: GHC.Event.Internal.evtRead
> Inlined fn:  (GHC.Types.I# 1#)
>  `cast` (Sym (GHC.Event.Internal.N:Event[0])
>  :: GHC.Types.Coercible GHC.Types.Int
> GHC.Event.Internal.Event)
> Cont:   Stop[BoringCtxt] GHC.Event.Internal.Event
>

I believe this is a regression, as copies of global data can pop up in
potentially many different modules.

What do you think? Which change could have caused this?

Cheers,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Failure to catch C++ exception in Haskell on OS X

[Gabor Greif]

Hi Bas,

maybe some DWARF unwind tables are not correctly installed in OS X?

Do intra-C++ exception catching work in your example?

Cheers,

Gabor

On 1/4/19, Bas van Dijk  wrote:
> Dear GHC Devs,
>
> I'm debugging an issue in our haskell-opencv library where a C++ exception
> that is thrown by the OpenCV C++ library isn't caught by the C++
> try...catch block we have inlined in our Haskell code using inline-c-cpp.
> This results in the process terminating by SIGABRT.
>
> Note that this only happens on OS X. In Linux the exception is caught
> correctly.
>
> I wrote a minimal isolated test case (which doesn't use OpenCV) at:
>
>   https://github.com/basvandijk/darwin-cxx-exception-bug
>
> I wrote some instructions in the README on how to reproduce this and
> included some debugging notes.
>
> I'm not sure the bug is caused by a mis-configuration in my code or if it's
> a bug in nixpkgs, Cabal or GHC. Any idea what could be causing this?
>
> Bas
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Welcome to GitLab!

[Gabor Greif]

Great work, Ben!

Thanks for all the hard work setting up this CI. My hopes are high
that our contributions' quality and ease will go up.

There seem to be a few loose ends that need to be wrapped up, like
redirect the mirroring of https://github.com/ghc/ghc/ towards GitLab
and possibly switch on mirroring for http://git.haskell.org/ghc.git .
Or should we just add a redirect? Should pull requests be blocked on the former?

Anyway some readmes need to be adapted for the new world order.

Cheers,

Gabor

On 12/27/18, Ara Adkins  wrote:
> Congrats to Ben and everybody involved! This has been a long time coming and
> I’m super excited to see what it means for GHC in the future!
>
> _ara
>
> On 27 Dec 2018, at 11:56, Matthew Pickering 
> wrote:
>
>>> To ensure that GHC's git history remains linear ghc/ghc will use GitLab's
>>> "fast-forward without a merge commit" merge strategy.
>>
>> Are merge requests squashed before they are merged?
>>
>> It seems that the answer by default is no..
>> https://gitlab.com/gitlab-org/gitlab-ce/issues/27956
>>
>> and the reason being that upsteam prefers "Convention over
>> Configuration"..
>> https://about.gitlab.com/handbook/product/#convention-over-configuration
>>
>> However it seems that there is a per-mr option which can be checked if
>> you are diligent to do it for each MR. Some comments indicate that
>> it's possible to implement a webhook to change this behaviour.
>>
>> Matt
>>
>>> On Thu, Dec 27, 2018 at 6:28 AM Ben Gamari  wrote:
>>>
>>> TL;DR. https://gitlab.haskell.org/ghc/ghc.git is now the official
>>>   upstream GHC repository. Various introductory notes are
>>>   discussed. Let me know if you have any trouble.
>>>
>>>   Also, please do verify the correctness of the email address
>>>   associated with your Trac account in the next few weeks. It will
>>>   be used to map users when we transition Trac tickets to GitLab.
>>>
>>>
>>>
>>> Hello everyone,
>>>
>>> I am happy to announce that CI on GHC's GitLab instance [1] is now
>>> stable. At this point https://gitlab.haskell.org/ghc/ghc.git is to be
>>> considered the official upstream repository of GHC.
>>>
>>> The rest of this email is meant to serve as a brief introduction and
>>> status update. It can also be viewed on the GitLab Wiki [2].
>>>
>>> [1] https://gitlab.haskell.org/
>>> [2] https://gitlab.haskell.org/ghc/ghc/wikis/welcome
>>>
>>>
>>> # Getting started
>>>
>>> To get started on GitLab you will first want to either create a new
>>> account
>>> [1] or login with your GitHub credentials [2].
>>>
>>> Once you have an account you should add an SSH key [3] so that you can
>>> push
>>> to your repositories. If you currently have commit rights to GHC notify
>>> me
>>> (Ben Gamari) of your user name so I can grant you similar rights in
>>> GitLab.
>>>
>>>
>>> [1] https://gitlab.haskell.org/users/sign_in
>>> [2] https://gitlab.haskell.org/users/auth/github
>>> [3] https://gitlab.haskell.org/profile/keys
>>>
>>>
>>> # Updating your development environment
>>>
>>> You can updated existing working directory (assuming the usual upstream
>>> remote name of `origin`) for the new upstream repository location by
>>> running the following:
>>>
>>>git remote set-url origin https://gitlab.haskell.org/ghc/ghc.git
>>>git remote set-url --push origin g...@gitlab.haskell.org:ghc/ghc
>>>
>>> This is all that should be necessary; a quick `git pull origin master`
>>> should verify that everything is working as expected.
>>>
>>>
>>> # Continuous integration
>>>
>>> Continuous integration is now provided by GitLab's native continuous
>>> integration infrastructure. We currently test a variety of
>>> configurations, including many that neither Phabricator nor
>>> CircleCI/Appveyor previously tested (see [1] for an example run):
>>>
>>> * With the make build system:
>>>* x86_64/Linux on Fedora 27, Debian 8, and Debian 9
>>>* i386/Linux on Debian 9
>>>* aarch64/Linux on Debian 9 (currently broken due to a variety of
>>>  issues)
>>>* x86_64/Windows
>>>* x86_64/Darwin
>>>* x86_64/Linux on Debian 9 in a few special configurations:
>>>* unregisterised (still a bit fragile due to #16085)
>>>* integer-simple
>>>* building GHC with -fllvm
>>> * With Hadrian:
>>>* x86_64/Linux on Debian 9
>>>* x86_64/Windows (currently broken due to #15950)
>>>
>>> We also run a slightly larger set of jobs on a nightly basis. Note that
>>> binary distributions are saved from most builds and are available for
>>> download for a few weeks (we may put in place a longer retention policy
>>> for some builds in the future).
>>>
>>> There are admittedly a few kinks that we are still working out,
>>> particularly in the case of Windows (specifically the long build times
>>> seen on Windows). If you suspect you are seeing spurious build failures
>>> do let us know.
>>>
>>> To make the best use of our limited computational resources our CI
>>> builds occur in three stages:
>

Re: GitLab Migration (CI heads-up)

[Gabor Greif]

Yeah, it starts now, thanks!

However it won't terminate due to a restrictive time limit of 60 mins.
Can we have 120?

Gabor

On 12/22/18, Ben Gamari  wrote:
> Gabor Greif  writes:
>
>> (following-up own mail)
>>
>> This seems resolved too. I have submitted my branch into the main
>> repo, and now the pipeline is executing :-)
>>
>> Still, do we want running pipelines for external contributors too?
>>
> Indeed we do. Small oversight on my part; now fixed.
>
> Thanks!
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab Migration (CI heads-up)

[Gabor Greif]

(following-up own mail)

This seems resolved too. I have submitted my branch into the main
repo, and now the pipeline is executing :-)

Still, do we want running pipelines for external contributors too?

Gabor

On 12/22/18, Gabor Greif  wrote:
> Hi Ben,
>
> thanks for the explanation, that indeed makes sense. I suspected some
> runaway optimisation, since the GHC seemed to crash on the same small
> set of sources.
>
> On a related note, even after rebasing to master, the linter of
> ghc/ghc!10 doesn't appear to kick in, blocking (and timing out) the
> test pipeline: https://gitlab.haskell.org/ggreif/ghc/pipelines/428
>
> It looks like there are no "lint" runners available.
>
> Cheers and thanks,
>
> Gabor
>
> On 12/22/18, Ben Gamari  wrote:
>> Gabor Greif  writes:
>>
>>> Hi Ben,
>>>
>> Hi Gabor,
>>
>>> I was wondering why my pull request (merely to trigger a bit more of
>>> CI than what I have at my local disposal) was suddenly failing (1),
>>> when it worked in a previous incarnation (2).
>>>
>>> It turns out that either CI or the entire tree is broken since (3)
>>> being the last sound one.
>>>
>> Indeed CircleCI recently revised their billing policies and consequently
>> we have lost the ability to use the large instance sizes which we were
>> previously using for our builds. Sadly GHC builds do not reliably finish
>> on the instances we still do have access to due to memory and build time
>> constraints. It appears that this may be the cause of the failures in
>> your build (1).
>>
>> This billing change was the reason why I have been moving our CI
>> infrastructure to GitLab. Unfortunately in the chaos it looks like I
>> neglected to forward the ghc-devops thread describing the situation [2]
>> to ghc-devs. Sorry for the confusion!
>>
>> I'm going to draft a summary email describing the state of the GitLab
>> transition right now.
>>
>> Cheers,
>>
>> - Ben
>>
>>
>> [2]
>> https://mail.haskell.org/pipermail/ghc-devops-group/2018-December/000273.html
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab Migration (CI heads-up)

[Gabor Greif]

Hi Ben,

thanks for the explanation, that indeed makes sense. I suspected some
runaway optimisation, since the GHC seemed to crash on the same small
set of sources.

On a related note, even after rebasing to master, the linter of
ghc/ghc!10 doesn't appear to kick in, blocking (and timing out) the
test pipeline: https://gitlab.haskell.org/ggreif/ghc/pipelines/428

It looks like there are no "lint" runners available.

Cheers and thanks,

Gabor

On 12/22/18, Ben Gamari  wrote:
> Gabor Greif  writes:
>
>> Hi Ben,
>>
> Hi Gabor,
>
>> I was wondering why my pull request (merely to trigger a bit more of
>> CI than what I have at my local disposal) was suddenly failing (1),
>> when it worked in a previous incarnation (2).
>>
>> It turns out that either CI or the entire tree is broken since (3)
>> being the last sound one.
>>
> Indeed CircleCI recently revised their billing policies and consequently
> we have lost the ability to use the large instance sizes which we were
> previously using for our builds. Sadly GHC builds do not reliably finish
> on the instances we still do have access to due to memory and build time
> constraints. It appears that this may be the cause of the failures in
> your build (1).
>
> This billing change was the reason why I have been moving our CI
> infrastructure to GitLab. Unfortunately in the chaos it looks like I
> neglected to forward the ghc-devops thread describing the situation [2]
> to ghc-devs. Sorry for the confusion!
>
> I'm going to draft a summary email describing the state of the GitLab
> transition right now.
>
> Cheers,
>
> - Ben
>
>
> [2]
> https://mail.haskell.org/pipermail/ghc-devops-group/2018-December/000273.html
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab Migration (CI heads-up)

[Gabor Greif]

Hi Ben,

I was wondering why my pull request (merely to trigger a bit more of
CI than what I have at my local disposal) was suddenly failing (1),
when it worked in a previous incarnation (2).

It turns out that either CI or the entire tree is broken since (3)
being the last sound one.

Looks like x86-64 is affected on the linux platform only. Darwin seems
to work, i386 too, and my PR (2) has been validated for PPC64le
recently.

So this is just a heads up that there is something fishy with
github->CircleCI (at least).

Cheers,

 Gabor

(1) https://circleci.com/gh/ghc/ghc/tree/pull/242
(2) https://circleci.com/gh/ghc/ghc/tree/pull/224
(3) https://circleci.com/gh/ghc/ghc/tree/pull/239

On 12/21/18, Ben Gamari  wrote:
> Ara Adkins  writes:
>
>> Hey All,
>>
>> Sorry for my confusion, but I'm a bit unclear as to when we're meant to
>> start working against the GHC repo on the gitlab.haskell.org instance. I
>> had in mind that the cutover was intended to be the 18th, but going on
>> there it still appears as if it's mirrored from git.haskell.org. Can
>> somebody clarify this for me?
>>
> Sorry for the confusion. I have been reluctant to formally announce the
> cut-over until CI is green but this has taken a fair bit longer than
> anticipated due to the long CI cycle time. Nevertheless people have
> started submitting MRs against the GitLab instance and you are more than
> welcome to do so.
>
> As far as the official upstream repository, indeed
> gitlab.haskell.org/ghc/ghc is still mirroring git.haskell.org/ghc. This
> will change when I formally announce the switchover.
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GitLab Migration

[Gabor Greif]

(To: Ben added directly)

Yes, https://gitlab.haskell.org/ghc/ghc still seems to mirror
https://:*@git.haskell.org/ghc, so the cutover is not complete
yet.

OTOH, the Gitlab instance allowed me to merge a request (which did not
work yesterday), so /something/ has changed. The interesting
consequence is now that
https://gitlab.haskell.org/ghc/ghc fails to sync with its master.

Another thing missing is to redirect the github mirror
(https://github.com/ghc/ghc), too.

Cheers,

Gabor

On 12/20/18, Ara Adkins  wrote:
> Hey All,
>
> Sorry for my confusion, but I'm a bit unclear as to when we're meant to
> start working against the GHC repo on the gitlab.haskell.org instance. I
> had in mind that the cutover was intended to be the 18th, but going on
> there it still appears as if it's mirrored from git.haskell.org. Can
> somebody clarify this for me?
>
> Best,
> _ara
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Post-spec optimisation, wen and where

[Gabor Greif]

Sure. It happens in
https://gitlab.staging.haskell.org/ghc/ghc/blob/master/compiler/simplCore/SimplCore.hs#L225

When full laziness is enabled, then after Specialising there is a
float-out pass.

The normal simplification passes are later, at line 254. This is the
reason why I see already optimised core with -ddump-simpl-iterations.
The issue disappears when I compile with -fno-full-laziness.

So I answered my own question. Now on to figuring out why some silly
float-outs are happening. (This is related to
https://ghc.haskell.org/trac/ghc/ticket/16039, btw.)

Cheers and thanks,

Gabor

On 12/13/18, Simon Peyton Jones  wrote:
> I’m afraid I don’t understand the question. Can you show a small test case
> and make your question concrete?
>
> Simon
>
> From: ghc-devs  On Behalf Of Gabor Greif
> Sent: 13 December 2018 06:10
> To: ghc-devs 
> Subject: Post-spec optimisation, wen and where
>
> Hi devs,
>
> I am wondering where the optimisation (e.g. simplified) of specialised
> dictionaries is taking place. In my case -ddump-spec shows unoptimised, but
> -ddump-simpl-iterations shows already optimised dictionaries (float-out
> already happened).
>
> I searched yesterday, but to no avail.
>
> Thanks,
>
>Gabor
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Post-spec optimisation, wen and where

[Gabor Greif]

Hi devs,

I am wondering where the optimisation (e.g. simplified) of specialised
dictionaries is taking place. In my case -ddump-spec shows unoptimised, but
-ddump-simpl-iterations shows already optimised dictionaries (float-out
already happened).

I searched yesterday, but to no avail.

Thanks,

   Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: llvm way only tests?

[Gabor Greif]

Hi Ben,

from my config.status:

S["OptCmd"]=""
S["ac_ct_OPT"]="opt"
S["OPT"]=""
S["LlcCmd"]=""
S["ac_ct_LLC"]="llc"
S["LLC"]=""
S["ClangCmd"]="clang"
S["CLANG"]="clang"

This is also what my config summary visualizes.
I have LLVM 5.0.2 installed. It *seems* to do the job.

Cheers,

Gabor



On 11/29/18, Ben Gamari  wrote:
> Gabor Greif  writes:
>
>> Hi all,
>>
>> what is the magic incantation for running tests only when the llvm
>> tools (e.g. `opt`) are around?
>>
>> I am currently declaring the test as
>>
>> test('T15155l',
>>   [ only_ways(llvm_ways),
>>   ], run_command, ['$MAKE -s --no-print-directory T15155l'])
>>
>> but it won't be included neither in the optasm builds (which is okay)
>> nor in the llvm builds (gets skipped unexpetedly) I looked at the
>> other test which are declared similarly, and they behave just like
>> mine.
>>
> Hmm, I suspect the logic in testsuite/mk/test.mk for determining whether
> LLVM is available is flawed. It concludes that LLVM is unavailable if
> LLC=llc. I can only assume that the reason for this is that configure
> will often find the system's on PATH (in which case LLC=llc) which
> likely isn't the LLVM release that we expect.
>
> However, we probably ought to be more careful here.
>
> Could you comment on what LLC is set to in your environment?
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

llvm way only tests?

[Gabor Greif]

Hi all,

what is the magic incantation for running tests only when the llvm
tools (e.g. `opt`) are around?

I am currently declaring the test as

test('T15155l',
  [ only_ways(llvm_ways),
  ], run_command, ['$MAKE -s --no-print-directory T15155l'])

but it won't be included neither in the optasm builds (which is okay)
nor in the llvm builds (gets skipped unexpetedly) I looked at the
other test which are declared similarly, and they behave just like
mine.

What I am doing wrong?

Thanks,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Introduce Int16# and Word16# (36fcf9e)

[Gabor Greif]

Hello Abhiroop!

LLVM backend seems to choke on this still:

ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 8.7.20181118 for x86_64-unknown-linux):
LlvmCodeGen.CodeGen.cmmPrimOpFunctions: MO_S_QuotRem W16 not supported 
here

Please report this as a GHC bug:  http://www.haskell.org/ghc/reportabug

Cheers,

Gabor

On 11/17/18, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/36fcf9edee31513db2ddbf716ee0aa79766cbe69/ghc
>
>>---
>
> commit 36fcf9edee31513db2ddbf716ee0aa79766cbe69
> Author: Abhiroop Sarkar 
> Date:   Mon Nov 5 12:06:58 2018 -0500
>
> Introduce Int16# and Word16#
>
> This builds off of D4475.
>
> Bumps binary submodule.
>
> Reviewers: carter, AndreasK, hvr, goldfire, bgamari, simonmar
>
> Subscribers: rwbarton, thomie
>
> Differential Revision: https://phabricator.haskell.org/D5006
>
>
>>---
>
> 36fcf9edee31513db2ddbf716ee0aa79766cbe69
>  compiler/cmm/CmmUtils.hs   |   4 +
>  compiler/codeGen/StgCmmArgRep.hs   |   2 +
>  compiler/codeGen/StgCmmPrim.hs |  45 +
>  compiler/prelude/PrelNames.hs  | 115 ++--
>  compiler/prelude/TysPrim.hs|  22 ++-
>  compiler/prelude/TysWiredIn.hs |  15 +-
>  compiler/prelude/TysWiredIn.hs-boot|   1 +
>  compiler/prelude/primops.txt.pp|  82 +
>  compiler/simplStg/RepType.hs   |   2 +
>  compiler/typecheck/TcGenDeriv.hs   |  42 -
>  compiler/types/TyCon.hs|   4 +
>  compiler/utils/Binary.hs   |   4 +
>  libraries/base/Data/Typeable/Internal.hs   |   2 +
>  libraries/binary   |   2 +-
>  libraries/ghc-prim/GHC/Types.hs|   6 +-
>  testsuite/tests/ffi/should_run/PrimFFIInt16.hs |  28 +++
>  .../{PrimFFIInt8.stdout => PrimFFIInt16.stdout}|   0
>  testsuite/tests/ffi/should_run/PrimFFIInt16_c.c|   7 +
>  testsuite/tests/ffi/should_run/PrimFFIWord16.hs|  28 +++
>  .../{PrimFFIInt8.stdout => PrimFFIWord16.stdout}   |   0
>  testsuite/tests/ffi/should_run/PrimFFIWord16_c.c   |   7 +
>  testsuite/tests/ffi/should_run/all.T   |   4 +
>  testsuite/tests/primops/should_run/ArithInt16.hs   | 197
> +
>  .../tests/primops/should_run/ArithInt16.stdout |   8 +
>  testsuite/tests/primops/should_run/ArithWord16.hs  | 194
> 
>  .../tests/primops/should_run/ArithWord16.stdout|   8 +
>  .../primops/should_run/{CmpInt8.hs => CmpInt16.hs} |  34 ++--
>  .../should_run/{CmpInt8.stdout => CmpInt16.stdout} |   0
>  .../should_run/{CmpWord8.hs => CmpWord16.hs}   |  34 ++--
>  .../{CmpInt8.stdout => CmpWord16.stdout}   |   0
>  testsuite/tests/primops/should_run/ShowPrim.hs |  16 +-
>  testsuite/tests/primops/should_run/ShowPrim.stdout |   3 +-
>  testsuite/tests/primops/should_run/all.T   |   5 +
>  utils/genprimopcode/Main.hs|   4 +-
>  34 files changed, 809 insertions(+), 116 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
> git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc 36fcf9edee31513db2ddbf716ee0aa79766cbe69
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: slow execution of built executables on a Mac

[Gabor Greif]

Maybe a symptom of an AFPS bug?
https://gregoryszorc.com/blog/2018/10/29/global-kernel-locks-in-apfs/

Just came across this, might be worth a look.

Cheers,

Gabor

On 10/26/18, Richard Eisenberg  wrote:
> Hi devs,
>
> I have a shiny, new iMac in my office. It's thus frustrating that it takes
> my iMac longer to build GHC than my trusty 28-month-old laptop. Building
> devel2 on a fresh checkout takes just about an hour. By contrast, my laptop
> is done after 30 minutes of work (same build settings). The laptop has a
> 2.8GHz Intel i7 running macOS 10.13.5; the desktop has a 3.5GHz Intel i5
> running macOS 10.13.6. Both bootstrapped from the binary distro of GHC
> 8.6.1.
>
> Watching GHC build, everything is snappy enough during the stage-1 build.
> But then, as soon as we start using GHC-produced executables, things slow
> down. It's most noticeable in the rts_dist_HC phase, which crawls. Stage 2
> is pretty slow, too.
>
> So: is there anything anyone knows about recent Macs not liking locally
> built executables? Or is there some local setting that I need to update? The
> prepackaged GHC seems to work well, so that gives me hope that someone knows
> what setting to tweak.
>
> Thanks!
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cmm learning tools

[Gabor Greif]

No worries! I searched for C--, which was its name back in the day. There
are a bunch of other conference papers in the "GHC commentary" too.

Cheers,

 Gabor


Em ter, 17 de jul de 2018 às 08:00, Daniel Cartwright 
escreveu:

> Thanks, I'll check it out.
>
> P.S.: Apologies if my request seemed low-effort w.r.t. searching, I did
> spend a good 15 minutes doing so before asking, and was unable to find the
> document you just produced.
>
> On Tue, Jul 17, 2018, 1:49 AM Gabor Greif  wrote:
>
>> Hello Daniel,
>>
>> a quick web search brought up this manual:
>>
>>
>> https://www.microsoft.com/en-us/research/wp-content/uploads/1998/01/pal-manual.pdf
>>
>> Please note that Cmm is slightly different, but it should get you started.
>>
>> Cheers,
>>
>>  Gabor
>>
>> Em ter, 17 de jul de 2018 às 05:20, Daniel Cartwright <
>> chessai1...@gmail.com> escreveu:
>>
>>> Hello all, I've recently become interested in learning Cmm, but cannot
>>> seem to find any concrete learning resources or extensive papers. It
>>> doesn't help that the web seems to contain a lot of useless information for
>>> a newcomer to Cmm. If anyone could provide some reading material about Cmm,
>>> I would be most grateful.
>>> ___
>>> ghc-devs mailing list
>>> ghc-devs@haskell.org
>>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>>
>>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Cmm learning tools

[Gabor Greif]

Hello Daniel,

a quick web search brought up this manual:

https://www.microsoft.com/en-us/research/wp-content/uploads/1998/01/pal-manual.pdf

Please note that Cmm is slightly different, but it should get you started.

Cheers,

 Gabor

Em ter, 17 de jul de 2018 às 05:20, Daniel Cartwright 
escreveu:

> Hello all, I've recently become interested in learning Cmm, but cannot
> seem to find any concrete learning resources or extensive papers. It
> doesn't help that the web seems to contain a lot of useless information for
> a newcomer to Cmm. If anyone could provide some reading material about Cmm,
> I would be most grateful.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Diagonally in Data.Bimap

[Gabor Greif]

Hi!

Just searched for a `bimap` variant that simultaneously transforms
both components with the same morphism:

``` haskell
diag :: Bifunctor p => (a -> b) -> p a a -> p b b
diag f = bimap f f
```

I did not find any. Would it make sense to add it?

Cheers,

Gabor

PS: same for profunctors:

``` haskell
xmap :: Profunctor p => (a -> b) -> p b a -> p a b
```
PPS: I would have sent this to librar...@haskell.org but it seem to be
closed group.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: UNREG: PprC: add support for of W16 literals (Ticket #15237) (01c9d95)

[Gabor Greif]

Hi Sergei,

thanks for your swift response!

I did:
```
$ mips64-wrsmllib64-linux-gcc -E -dM -  wrote:
> On Fri, 15 Jun 2018 10:49:41 +0200
> Gabor Greif  wrote:
>
>> Thanks for fixing this!
>>
>> I am in the process of building an unregisterised MIPS64
>> cross-compiler and just noticed this warning running by:
>>
>>   HC [stage 1] libraries/base/dist-install/build/GHC/Show.p_o
>> /tmp/ghc414_0/ghc_7.hc: In function '_c53i':
>>
>> /tmp/ghc414_0/ghc_7.hc:1483:17: error:
>>  warning: integer constant is so large that it is unsigned
>>  _s4Lo = (_s4Ld+-9223372036854775808) + (_s4Lg + _s4L9);
>>  ^
>>  |
>> 1483 | _s4Lo = (_s4Ld+-9223372036854775808) + (_s4Lg + _s4L9);
>>  | ^
>>
>> Not sure whether I should be worried (there seem to be others of this
>> kind) or a simple change in the datatype (int -> unsigned) could
>> silence this.
>
> The overflow looks fishy. -9223372036854775808 is 0x8000.
> What ABI your mips64 targets to? 64 or n32? I'd like to reproduce it
> locally.
>
> Simplest way to check for ABI (mine is N32):
>   $ mips64-unknown-linux-gnu-gcc -E -dM -#define _MIPS_SIM _ABIN32
>
> --
>
>   Sergei
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: UNREG: PprC: add support for of W16 literals (Ticket #15237) (01c9d95)

[Gabor Greif]

Thanks for fixing this!

I am in the process of building an unregisterised MIPS64
cross-compiler and just noticed this warning running by:

  HC [stage 1] libraries/base/dist-install/build/GHC/Show.p_o
/tmp/ghc414_0/ghc_7.hc: In function '_c53i':

/tmp/ghc414_0/ghc_7.hc:1483:17: error:
 warning: integer constant is so large that it is unsigned
 _s4Lo = (_s4Ld+-9223372036854775808) + (_s4Lg + _s4L9);
 ^
 |
1483 | _s4Lo = (_s4Ld+-9223372036854775808) + (_s4Lg + _s4L9);
 | ^

Not sure whether I should be worried (there seem to be others of this
kind) or a simple change in the datatype (int -> unsigned) could
silence this.

Cheers,

Gabor


On 6/15/18, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/01c9d95aca12caf5c954320a2a82335b32568554/ghc
>
>>---
>
> commit 01c9d95aca12caf5c954320a2a82335b32568554
> Author: Sergei Trofimovich 
> Date:   Thu Jun 14 23:13:16 2018 +0100
>
> UNREG: PprC: add support for of W16 literals (Ticket #15237)
>
> Fix UNREG build failure for 32-bit targets.
>
> This change is an equivalent of commit
> 0238a6c78102d43dae2f56192bd3486e4f9ecf1d
> ("UNREG: PprC: add support for of W32 literals")
>
> The change allows combining two subwords into one word
> on 32-bit targets. Tested on nios2-unknown-linux-gnu.
>
> GHC Trac Issues: #15237
>
> Signed-off-by: Sergei Trofimovich 
>
>
>>---
>
> 01c9d95aca12caf5c954320a2a82335b32568554
>  compiler/cmm/PprC.hs | 8 
>  1 file changed, 8 insertions(+)
>
> diff --git a/compiler/cmm/PprC.hs b/compiler/cmm/PprC.hs
> index e46fff1..8b30bbf 100644
> --- a/compiler/cmm/PprC.hs
> +++ b/compiler/cmm/PprC.hs
> @@ -546,6 +546,14 @@ pprStatics dflags (CmmStaticLit (CmmInt a W32) :
>  rest)
>  else pprStatics dflags (CmmStaticLit (CmmInt ((shiftL b 32) .|. a) W64)
> :
>  rest)
> +pprStatics dflags (CmmStaticLit (CmmInt a W16) :
> +   CmmStaticLit (CmmInt b W16) : rest)
> +  | wordWidth dflags == W32
> +  = if wORDS_BIGENDIAN dflags
> +then pprStatics dflags (CmmStaticLit (CmmInt ((shiftL a 16) .|. b) W32)
> :
> +rest)
> +else pprStatics dflags (CmmStaticLit (CmmInt ((shiftL b 16) .|. a) W32)
> :
> +rest)
>  pprStatics dflags (CmmStaticLit (CmmInt _ w) : _)
>| w /= wordWidth dflags
>= pprPanic "pprStatics: cannot emit a non-word-sized static literal" (ppr
> w)
>
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Embrace -XTypeInType, add -XStarIsType (d650729)

[Gabor Greif]

My `happy` chokes on the unicode sequence you added:

(if isUnicode $1 then "★" else "*")

Casn this be done with unicode escapes somehow?

Cheers,

Gabor

PS: Happy Version 1.19.9 Copyright (c) 1993-1996 Andy Gill, Simon
Marlow (c) 1997-2005 Simon Marlow

On 6/14/18, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60/ghc
>
>>---
>
> commit d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60
> Author: Vladislav Zavialov 
> Date:   Thu Jun 14 15:02:36 2018 -0400
>
> Embrace -XTypeInType, add -XStarIsType
>
> Summary:
> Implement the "Embrace Type :: Type" GHC proposal,
> .../ghc-proposals/blob/master/proposals/0020-no-type-in-type.rst
>
> GHC 8.0 included a major change to GHC's type system: the Type :: Type
> axiom. Though casual users were protected from this by hiding its
> features behind the -XTypeInType extension, all programs written in GHC
> 8+ have the axiom behind the scenes. In order to preserve backward
> compatibility, various legacy features were left unchanged. For example,
> with -XDataKinds but not -XTypeInType, GADTs could not be used in types.
> Now these restrictions are lifted and -XTypeInType becomes a redundant
> flag that will be eventually deprecated.
>
> * Incorporate the features currently in -XTypeInType into the
>   -XPolyKinds and -XDataKinds extensions.
> * Introduce a new extension -XStarIsType to control how to parse * in
>   code and whether to print it in error messages.
>
> Test Plan: Validate
>
> Reviewers: goldfire, hvr, bgamari, alanz, simonpj
>
> Reviewed By: goldfire, simonpj
>
> Subscribers: rwbarton, thomie, mpickering, carter
>
> GHC Trac Issues: #15195
>
> Differential Revision: https://phabricator.haskell.org/D4748
>
>
>>---
>
> d650729f9a0f3b6aa5e6ef2d5fba337f6f70fa60
>  .gitignore |   1 +
>  .gitmodules|   4 +-
>  compiler/basicTypes/DataCon.hs |  22 +-
>  compiler/basicTypes/Name.hs|  21 +-
>  compiler/basicTypes/RdrName.hs |  96 +++-
>  compiler/basicTypes/SrcLoc.hs  |   5 +-
>  compiler/deSugar/DsMeta.hs |   7 +-
>  compiler/hsSyn/Convert.hs  |  37 +-
>  compiler/hsSyn/HsDecls.hs  |   9 +-
>  compiler/hsSyn/HsExtension.hs  |  16 +-
>  compiler/hsSyn/HsInstances.hs  |   5 -
>  compiler/hsSyn/HsTypes.hs  | 117 +
>  compiler/iface/IfaceType.hs|   8 +-
>  compiler/main/DynFlags.hs  |  31 ++
>  compiler/main/DynFlags.hs-boot |   1 +
>  compiler/main/HscTypes.hs  |   3 +-
>  compiler/parser/Lexer.x| 104 +++--
>  compiler/parser/Parser.y   |  88 ++--
>  compiler/parser/RdrHsSyn.hs| 190 
>  compiler/prelude/PrelNames.hs  |   7 +-
>  compiler/prelude/PrelNames.hs-boot |   3 +-
>  compiler/prelude/TysWiredIn.hs |  24 +-
>  compiler/rename/RnEnv.hs   |  43 +-
>  compiler/rename/RnSource.hs|   4 +-
>  compiler/rename/RnTypes.hs | 186 ++--
>  compiler/typecheck/TcDeriv.hs  |  14 +-
>  compiler/typecheck/TcHsType.hs |  82 ++--
>  compiler/typecheck/TcInstDcls.hs   |   4 +-
>  compiler/typecheck/TcMType.hs  |   2 +-
>  compiler/typecheck/TcPatSyn.hs |   2 +-
>  compiler/typecheck/TcRnTypes.hs|   6 -
>  compiler/typecheck/TcSplice.hs |   4 +-
>  compiler/typecheck/TcTyClsDecls.hs |  43 +-
>  compiler/types/Kind.hs |  33 +-
>  compiler/types/TyCoRep.hs  |   1 +
>  compiler/types/TyCon.hs|   8 +-
>  compiler/types/Type.hs |  11 +-
>  compiler/types/Unify.hs|   2 +-
>  compiler/utils/Outputable.hs   |  11 +-
>  docs/users_guide/8.6.1-notes.rst   |  30 +-
>  docs/users_guide/glasgow_exts.rst  | 482
> +
>  libraries/base/Data/Data.hs|   4 +-
>  libraries/base/Data/Kind.hs|   2 +-
>  libraries/base/Data/Proxy.hs   |   2 +-
>  libraries/base/Data/Type/Equality.hs   |   4 +-
>  libraries/base/Data/Typeable.

Re: LclId -> GblId question

[Gabor Greif]

Never mind, I figured it out. It is the CoreTidy pass of the
compilation pipeline:
https://ghc.haskell.org/trac/ghc/wiki/Commentary/Compiler/HscMain

Cheers,

Gabor

On 5/29/18, Gabor Greif  wrote:
> Hi devs,
>
> I have a simple question, but could not find an answer yet. The same
> variable (I checked!) appears in two dumps with different names and
> different external visibilities.
> Which pass transforms this variable to a global id, and why? Shouldn't
> a LclId remain local along the entire optimisation chain?
>
> Any hint appreciated!
>
> Cheers and thanks,
>
>  Gabor
>
> Snippets from dumps below
>
> ##
>
> -rw-r--r-- 1 ggreif sw12  3281225 May 29 14:14 TcSMonad.dump-stranal
>
>
> -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
> lvl_sOra :: TcTyVarDetails
> [LclId,
>  Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False,
>  WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}]
> lvl_sOra
>   = ghc-prim-0.5.3:GHC.Magic.noinline
>   @ TcTyVarDetails vanillaSkolemTv
>
> ##
>
> -rw-r--r-- 1 ggreif sw12  1438015 May 29 14:14 TcSMonad.dump-simpl
>
>
> -- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
> TcSMonad.isFilledMetaTyVar_maybe2 :: TcTyVarDetails
> [GblId,
>  Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False,
>  WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}]
> TcSMonad.isFilledMetaTyVar_maybe2
>   = ghc-prim-0.5.3:GHC.Magic.noinline
>   @ TcTyVarDetails vanillaSkolemTv
>
> ##
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

LclId -> GblId question

[Gabor Greif]

Hi devs,

I have a simple question, but could not find an answer yet. The same
variable (I checked!) appears in two dumps with different names and
different external visibilities.
Which pass transforms this variable to a global id, and why? Shouldn't
a LclId remain local along the entire optimisation chain?

Any hint appreciated!

Cheers and thanks,

 Gabor

Snippets from dumps below

##

-rw-r--r-- 1 ggreif sw12  3281225 May 29 14:14 TcSMonad.dump-stranal


-- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
lvl_sOra :: TcTyVarDetails
[LclId,
 Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False,
 WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}]
lvl_sOra
  = ghc-prim-0.5.3:GHC.Magic.noinline
  @ TcTyVarDetails vanillaSkolemTv

##

-rw-r--r-- 1 ggreif sw12  1438015 May 29 14:14 TcSMonad.dump-simpl


-- RHS size: {terms: 2, types: 1, coercions: 0, joins: 0/0}
TcSMonad.isFilledMetaTyVar_maybe2 :: TcTyVarDetails
[GblId,
 Unf=Unf{Src=, TopLvl=True, Value=False, ConLike=False,
 WorkFree=False, Expandable=False, Guidance=IF_ARGS [] 20 0}]
TcSMonad.isFilledMetaTyVar_maybe2
  = ghc-prim-0.5.3:GHC.Magic.noinline
  @ TcTyVarDetails vanillaSkolemTv

##
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

-ddump-simpl-phases

[Gabor Greif]

Hi all,

the manual mentions `-ddump-simpl-phases`  but there is no such flag
[1]. How should we fix this?

Cheers,

Gabor

[1] $ git grep ddump-simpl-phases
docs/users_guide/debugging.rst:outputs even more information than
``-ddump-simpl-phases``.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Windows

[Gabor Greif]

Just an idea...

could this hint be part of the `configure` error message?

 Gabor

On 3/23/18, loneti...@gmail.com  wrote:
> Hi Simon,
>
> You need
>
> export MSYSTEM=MINGW64
>
> in your bash profile.
>
> Regards,
> Tamar
>
> From: Simon Peyton Jones via ghc-devs
> Sent: Friday, March 23, 2018 22:21
> To: ghc-devs@haskell.org
> Subject: Windows
>
> I’ve just got  a new laptop (the old one’s hard disk died) so I’m trying to
> get to the point of being able to build GHC again.
> I’m currently stuck here:
> ./configure
> configure: loading site script /usr/local/etc/config.site
> checking for gfind... no
> checking for find... /usr/bin/find
> checking for sort... /usr/bin/sort
> checking for GHC version date... inferred 8.5.20180323
> checking for GHC Git commit id... inferred
> affdea82bb70e5a912b679a169c6e9a230e4c93e
> checking for ghc... /c/fp/HP-8.2.2/bin/ghc
> checking version of ghc... 8.2.2
> GHC path canonicalised to: c:/fp/HP-8.2.2/bin/ghc
> checking build system type... x86_64-pc-msys
> checking host system type... x86_64-pc-msys
> checking target system type... x86_64-pc-msys
> Unknown OS msys
> Any ideas?
> Thanks
> Simon
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Adds -ghc-version flag to ghc. (12a7444)

[Gabor Greif]

Hmm, when seeing "-ghc-version" I first thought

  why a new flag for querying the version of GHC?

But the flag has a different purpose!

I'd suggest to rename it to "-ghcversion-file" or similar.

Just my two cents...

Cheers,

Gabor

On 11/18/17, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/12a763184e9eddbe7b7251a0ee1e976f4d75/ghc
>
>>---
>
> commit 12a763184e9eddbe7b7251a0ee1e976f4d75
> Author: Moritz Angermann 
> Date:   Fri Nov 17 19:29:25 2017 +0800
>
> Adds -ghc-version flag to ghc.
>
> Summary:
> When building the rts with ghc (e.g. using ghc as a c compiler), ghc's
> "Value Add"[1] is, it includes adding `-include /path/to/ghcversion.h`.
> For
> this it looksup the rts package in the package database, which--if
> empty--fails.  Thus to allow compiling C files with GHC, we add the
> `-ghc-version` flag, which takes the path to the `ghcversion.h` file.
>
> A `-no-ghc-version` flag was omitted, as at that point it becomes
> questionable why one would use ghc to compile c if one doesn't
> any of the added value.
>
> --
>
> [1] from `compiler/main/DriverPipeline.hs`
> >-- add package include paths even if we're just compiling .c
> >-- files; this is the Value Add(TM) that using ghc instead of
> >-- gcc gives you :)
>
> Reviewers: bgamari, geekosaur, austin
>
> Reviewed By: bgamari
>
> Subscribers: rwbarton, thomie
>
> Differential Revision: https://phabricator.haskell.org/D4135
>
>
>>---
>
> 12a763184e9eddbe7b7251a0ee1e976f4d75
>  compiler/main/DriverPipeline.hs | 11 ---
>  compiler/main/DynFlags.hs   |  7 +++
>  docs/users_guide/using.rst  | 23 +++
>  3 files changed, 38 insertions(+), 3 deletions(-)
>
> diff --git a/compiler/main/DriverPipeline.hs
> b/compiler/main/DriverPipeline.hs
> index fab7fad..4f7bfbd 100644
> --- a/compiler/main/DriverPipeline.hs
> +++ b/compiler/main/DriverPipeline.hs
> @@ -2204,11 +2204,16 @@ touchObjectFile dflags path = do
>  -- | Find out path to @ghcversion.h@ file
>  getGhcVersionPathName :: DynFlags -> IO FilePath
>  getGhcVersionPathName dflags = do
> -  dirs <- getPackageIncludePath dflags [toInstalledUnitId rtsUnitId]
> +  candidates <- case ghcVersion dflags of
> +Just path -> return [path]
> +Nothing -> (map ( "ghcversion.h")) <$>
> +   (getPackageIncludePath dflags [toInstalledUnitId rtsUnitId])
>
> -  found <- filterM doesFileExist (map ( "ghcversion.h") dirs)
> +  found <- filterM doesFileExist candidates
>case found of
> -  []-> throwGhcExceptionIO (InstallationError ("ghcversion.h
> missing"))
> +  []-> throwGhcExceptionIO (InstallationError
> +("ghcversion.h missing; tried: "
> +  ++ intercalate ", " candidates))
>(x:_) -> return x
>
>  -- Note [-fPIC for assembler]
> diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs
> index 5888acc..04ac635 100644
> --- a/compiler/main/DynFlags.hs
> +++ b/compiler/main/DynFlags.hs
> @@ -534,6 +534,7 @@ data GeneralFlag
> | Opt_ExternalInterpreter
> | Opt_OptimalApplicativeDo
> | Opt_VersionMacros
> +   | Opt_GhcVersion
> | Opt_WholeArchiveHsLibs
>
> -- PreInlining is on by default. The option is there just to see how
> @@ -917,6 +918,7 @@ data DynFlags = DynFlags {
>flushOut  :: FlushOut,
>flushErr  :: FlushErr,
>
> +  ghcVersion:: Maybe FilePath,
>haddockOptions:: Maybe String,
>
>-- | GHCi scripts specified by -ghci-script, in reverse order
> @@ -1682,6 +1684,7 @@ defaultDynFlags mySettings myLlvmTargets =
>  filesToClean   = panic "defaultDynFlags: No filesToClean",
>  dirsToClean= panic "defaultDynFlags: No dirsToClean",
>  generatedDumps = panic "defaultDynFlags: No generatedDumps",
> +ghcVersion = Nothing,
>  haddockOptions = Nothing,
>  dumpFlags = EnumSet.empty,
>  generalFlags = EnumSet.fromList (defaultFlags mySettings),
> @@ -2339,6 +2342,9 @@ addDepSuffix s d = d { depSuffixes = s : depSuffixes d
> }
>
>  addCmdlineFramework f d = d { cmdlineFrameworks = f : cmdlineFrameworks d}
>
> +addGhcVersion :: FilePath -> DynFlags -> DynFlags
> +addGhcVersion f d = d { ghcVersion = Just f }
> +
>  addHaddockOpts f d = d { haddockOptions = Just f}
>
>  addGhciScript f d = d { ghciScripts = f : ghciScripts d}
> @@ -2866,6 +2872,7 @@ dynamic_flags_deps = [
>, make_ord_flag defGhcFlag "no-rtsopts-suggestions"
>(noArg (\d -> d {rtsOptsSuggestions = False}))
>
> +  , make_ord_flag defGhcFlag "ghc-version"  (hasArg addGhcVersion)
>, make_ord_flag 

Re: [commit: ghc] master: llvmGen: Pass vector arguments in vector registers by default (15f788f)

[Gabor Greif]

IIRC there are no more static flags around. So adding ":type: dynamic"
each time seems redundant. Could this be automated somehow? Or should
we remove ":type:" altogether?

Cheers,

Gabor

On 11/3/17, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/15f788f5e5096641245a4f060600a6db9cbc2c4e/ghc
>
>>---
>
> commit 15f788f5e5096641245a4f060600a6db9cbc2c4e
> Author: Ben Gamari 
> Date:   Thu Nov 2 17:28:40 2017 -0400
>
> llvmGen: Pass vector arguments in vector registers by default
>
> Earlier this year Edward Kmett requested [1] that we enable passing of
> vector values in vector registers by default. The GHC calling convention
> changes have been in LLVM for a number of years now so let's just flip
> the switch.
>
> [1] https://mail.haskell.org/pipermail/ghc-devs/2017-March/013905.html
>
> Reviewers: austin
>
> Subscribers: rwbarton, thomie
>
> Differential Revision: https://phabricator.haskell.org/D4142
>
>
>>---
>
> 15f788f5e5096641245a4f060600a6db9cbc2c4e
>  compiler/main/DynFlags.hs   |  5 +++--
>  docs/users_guide/using-optimisation.rst | 12 
>  2 files changed, 15 insertions(+), 2 deletions(-)
>
> diff --git a/compiler/main/DynFlags.hs b/compiler/main/DynFlags.hs
> index a421284..825497e 100644
> --- a/compiler/main/DynFlags.hs
> +++ b/compiler/main/DynFlags.hs
> @@ -3757,7 +3757,7 @@ fFlagsDeps = [
>flagSpec "kill-one-shot"Opt_KillOneShot,
>flagSpec "late-dmd-anal"Opt_LateDmdAnal,
>flagSpec "liberate-case"Opt_LiberateCase,
> -  flagHiddenSpec "llvm-pass-vectors-in-regs"
> Opt_LlvmPassVectorsInRegisters,
> +  flagSpec "llvm-pass-vectors-in-regs"
> Opt_LlvmPassVectorsInRegisters,
>flagHiddenSpec "llvm-tbaa"  Opt_LlvmTBAA,
>flagHiddenSpec "llvm-fill-undef-with-garbage"
> Opt_LlvmFillUndefWithGarbage,
>flagSpec "loopification"Opt_Loopification,
> @@ -4051,7 +4051,8 @@ defaultFlags settings
>Opt_RPath,
>Opt_SharedImplib,
>Opt_SimplPreInlining,
> -  Opt_VersionMacros
> +  Opt_VersionMacros,
> +  Opt_LlvmPassVectorsInRegisters
>  ]
>
>  ++ [f | (ns,f) <- optLevelFlags, 0 `elem` ns]
> diff --git a/docs/users_guide/using-optimisation.rst
> b/docs/users_guide/using-optimisation.rst
> index 4714de7..fc958e0 100644
> --- a/docs/users_guide/using-optimisation.rst
> +++ b/docs/users_guide/using-optimisation.rst
> @@ -493,6 +493,18 @@ by saying ``-fno-wombat``.
>  self-recursive saturated tail calls into local jumps rather than
>  function calls.
>
> +.. ghc-flag:: -fllvm-pass-vectors-in-regs
> +:shortdesc: Pass vector value in vector registers for function calls
> +:type: dynamic
> +:reverse: -fno-llvm-pass-vectors-in-regs
> +:category:
> +
> +:default: on
> +
> +Instructs GHC to use the platform's native vector registers to pass
> vector
> +arguments during function calls. As with all vector support, this
> requires
> +:ghc-flag:`-fllvm`.
> +
>  .. ghc-flag:: -fmax-inline-alloc-size=⟨n⟩
>  :shortdesc: *default: 128.* Set the maximum size of inline array
> allocations
>  to ⟨n⟩ bytes (default: 128).
>
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Q: Types in GADT pattern match

[Gabor Greif]

On 10/30/17, Csongor Kiss  wrote:
> Right, but I think Gabor's suggestion here is for type checking of the
> pattern to be done first, and then capturing the coercions
> that were brought into scope by the pattern match.
>
> data Foo a where
>   Bar :: Foo [a]
>
> foo :: Foo a -> ()
> foo Bar =  -- we know (a ~ [b]) here, for some b
>
> The pattern match on Bar in foo gives us the equality assumption on the
> right hand side, but
> we don't have an easy way of capturing 'b' - which we might want to do for,
> say, visible type application inside .


Yep. Visible type application on the RHS is what I am after. It is
just user-unfriendly that one has to doubly pattern match on the same
object in order to bring the GADT constructor's type equality into
play.

Thanks Csongor for the expanded reasoning!

Gabor


>
> foo' :: Foo a -> ()
> foo' (Bar :: Foo a) = 
>
> of course works, but it only gives us access to 'a' in .
>
> foo'' :: Foo a -> ()
> foo'' (Bar :: Foo [c]) = 
>
> This would mean that in addition to (a ~ [b]), for some b, we would get (a ~
> [c]), for our new c. This then gives (b ~ c),
> essentially giving us access to the existential b. Of course we would need
> to check that our scoped type signature
> doesn't introduce bogus coercions, like
>
> foo''' :: Foo a -> ()
> foo''' (Bar :: Foo [[c]]) = 
>
> is clearly invalid, because (a ~ [b]) and (a ~ [[c]]) would need (b ~ [c]),
> which we can't prove from the given assumptions.
>
>
> Cheers,
> Csongor
>
> On 30 Oct 2017, 12:13 +, Brandon Allbery , wrote:
>> > On Mon, Oct 30, 2017 at 5:14 AM, Gabor Greif  wrote:
>> > > My original question, though, is not answered yet, namely why not to
>> > > detect that we are about to pattern match on a GADT constructor and
>> > > allow the programmer to capture the *refined* type with her type
>> > > annotation. Sure this would necessitate a change to the type checker,
>> > > but would also increase the expressive power a bit.
>> > >
>> > > Is there some fundamental problem with this? Or simply nobody wanted
>> > > to do this yet? Would it be hard to implement type checking *after*
>> > > refinement on GADT(-like) patterns?
>>
>> I wouldn't be surprised if type checking is precisely what enables
>> refinement, making this a bit chicken-and-egg.
>>
>> --
>> brandon s allbery kf8nh   sine nomine
>> associates
>> allber...@gmail.com
>>  ballb...@sinenomine.net
>> unix, openafs, kerberos, infrastructure, xmonad
>>  http://sinenomine.net
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Types in GADT pattern match

[Gabor Greif]

On 10/30/17, Simon Peyton Jones  wrote:
> foo b@(Bar :: Foo [a]) = quux b
> The pattern (p :: ty) checks that the thing being matched has type ‘ty’ and
> THEN matches ‘p’.  You expected it to FIRST match ‘p’, and THEN check that
> the thing being matched has type ‘ty’.  But that’s not the way it works.

Yep. Understood. I was just hoping that one could annotate the
"insider view" of GADT pattern matches (considering the equality
constraints of the constructor) as well as the "outsider view", namely
'foo's external signature.

>
> e.g what about this
>
> rats ([Just (Bar, True)] :: [Maybe (Foo [a], Bool)]) = …
>
> Here the pattern to be matched is deep, with the Bar part deep inside.  Do
> you still expect it to work?

Well, it reflects a truth, so I'd expect it to work, yes :-)

>
> This would be hard to change.  And I’m not sure it’d be an improvement.

Hmmm, sure. There are probably better areas to invest effort into.

Thanks,

Gabor

>
> Simon
>
> From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor
> Greif
> Sent: 29 October 2017 17:43
> To: ghc-devs 
> Subject: Q: Types in GADT pattern match
>
> Hi Devs!
>
> I encountered a curious restriction with type signatures (tyvar bindings) in
> GADT pattern matches.
>
> GHC won't let me directly capture the refined type structure of GADT
> constructors like this:
>
>
> {-# Language GADTs, ScopedTypeVariables #-}
>
> data Foo a where
>   Bar :: Foo [a]
>
> foo :: Foo a -> ()
> foo b@(Bar :: Foo [a]) = quux b
>   where quux :: Foo [b] -> ()
> quux Bar = ()
>
>
> I get:
>
>
>
> test.hs:7:8: error:
>
> • Couldn't match type ‘a1’ with ‘[a]’
>
>   ‘a1’ is a rigid type variable bound by
>
> the type signature for:
>
>   foo :: forall a1. Foo a1 -> ()
>
> at test.hs:6:1-18
>
>   Expected type: Foo a1
>
> Actual type: Foo [a]
>
>
> To me it appears that the type refinement established by the GADT pattern
> match is not accounted for.
>
> Of course I can write:
>
> foo :: Foo a -> ()
> foo b@Bar | (c :: Foo [a]) <- b = quux c
>   where quux :: Foo [b] -> ()
> quux Bar = ()
>
> but it feels like a complicated way to do it...
>
> My question is whether this is generally seen as the way to go or whether
> ScopedTypeVariables coming from a GADT pattern match should be able to
> capture the refined type. To me the latter seems more useful.
>
> Just wanted to feel the waters before writing a ticket about this.
>
> Cheers and thanks,
>
> Gabor
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Q: Types in GADT pattern match

[Gabor Greif]

Hi Oleg, Richard,

thanks for your answers! Seems like my original diagnosis is correct and
GADT type refinement is done *after* the checking of the pattern type signature.

My workaround

  >  foo b@Bar | (c :: Foo [x]) <- b = ... @x ...

works perfectly well and is essentially the same what Richard
suggests, while being
a little less gross.

My original question, though, is not answered yet, namely why not to
detect that we are about to pattern match on a GADT constructor and
allow the programmer to capture the *refined* type with her type
annotation. Sure this would necessitate a change to the type checker,
but would also increase the expressive power a bit.

Is there some fundamental problem with this? Or simply nobody wanted
to do this yet? Would it be hard to implement type checking *after*
refinement on GADT(-like) patterns?

Cheers and thanks,

Gabor


On 10/30/17, Richard Eisenberg  wrote:
> Hi Gabor,
>
> Oleg is right that the re-use of type variables obscures the error, but it's
> not quite a scoping error under the hood. The problem is that GHC
> type-checks type signatures on patterns *before* type-checking the pattern
> itself. That means that when GHC checks your `Foo [a]` type signature, we
> haven't yet learned that `a1` (the type variable used in the type signature
> of foo) equals `[a]`. This makes it hard to bind a variable to `a`. Here's
> what I've done:
>
>> foo :: Foo a -> ()
>> foo b@Bar = case b of
>>   (_ :: Foo [c]) -> quux b
>> where
>>   quux :: Foo [c] -> ()
>>   quux Bar = ()
>
> It's gross, but it works, and I don't think there's a better way at the
> moment. A collaborator of mine is working on a proposal (and implementation)
> of binding existentials in patterns (using similar syntax to visible type
> application), but that's still a few months off, at best.
>
> Richard
>
>> On Oct 29, 2017, at 1:42 PM, Gabor Greif  wrote:
>>
>> Hi Devs!
>>
>> I encountered a curious restriction with type signatures (tyvar bindings)
>> in GADT pattern matches.
>>
>> GHC won't let me directly capture the refined type structure of GADT
>> constructors like this:
>>
>>
>> {-# Language GADTs, ScopedTypeVariables #-}
>>
>> data Foo a where
>>   Bar :: Foo [a]
>>
>> foo :: Foo a -> ()
>> foo b@(Bar :: Foo [a]) = quux b
>>   where quux :: Foo [b] -> ()
>> quux Bar = ()
>>
>>
>> I get:
>>
>>
>> test.hs:7:8: error:
>> • Couldn't match type ‘a1’ with ‘[a]’
>>   ‘a1’ is a rigid type variable bound by
>> the type signature for:
>>   foo :: forall a1. Foo a1 -> ()
>> at test.hs:6:1-18
>>   Expected type: Foo a1
>> Actual type: Foo [a]
>>
>>
>> To me it appears that the type refinement established by the GADT pattern
>> match is not accounted for.
>>
>> Of course I can write:
>>
>> foo :: Foo a -> ()
>> foo b@Bar | (c :: Foo [a]) <- b = quux c
>>   where quux :: Foo [b] -> ()
>> quux Bar = ()
>>
>> but it feels like a complicated way to do it...
>>
>> My question is whether this is generally seen as the way to go or whether
>> ScopedTypeVariables coming from a GADT pattern match should be able to
>> capture the refined type. To me the latter seems more useful.
>>
>> Just wanted to feel the waters before writing a ticket about this.
>>
>> Cheers and thanks,
>>
>> Gabor
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Q: Types in GADT pattern match

[Gabor Greif]

Hi Devs!

I encountered a curious restriction with type signatures (tyvar bindings)
in GADT pattern matches.

GHC won't let me directly capture the refined type structure of GADT
constructors like this:


{-# Language GADTs, ScopedTypeVariables #-}

data Foo a where
  Bar :: Foo [a]

foo :: Foo a -> ()
foo b@(Bar :: Foo [a]) = quux b
  where quux :: Foo [b] -> ()
quux Bar = ()


I get:


*test.hs:7:8: **error:*

*• Couldn't match type ‘a1’ with ‘[a]’*

*  ‘a1’ is a rigid type variable bound by*

*the type signature for:*

*  foo :: forall a1. Foo a1 -> ()*

*at test.hs:6:1-18*

*  Expected type: Foo a1*

*Actual type: Foo [a]*


To me it appears that the type refinement established by the GADT pattern
match is not accounted for.

Of course I can write:

foo :: Foo a -> ()
foo b@Bar | (c :: Foo [a]) <- b = quux c
  where quux :: Foo [b] -> ()
quux Bar = ()

but it feels like a complicated way to do it...

My question is whether this is generally seen as the way to go or whether
ScopedTypeVariables coming from a GADT pattern match should be able to
capture the refined type. To me the latter seems more useful.

Just wanted to feel the waters before writing a ticket about this.

Cheers and thanks,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC] #14294: IndexError: pop from empty list

[Gabor Greif]

Right.

On 9/27/17, GHC  wrote:
> #14294: IndexError: pop from empty list
> -+-
> Reporter:  heisenbug |Owner:  (none)
> Type:  bug   |   Status:  new
> Priority:  normal|Milestone:
>Component:  Compiler  |  Version:  8.2.1
>   Resolution:| Keywords:
> Operating System:  Unknown/Multiple  | Architecture:
>  |  Unknown/Multiple
>  Type of failure:  None/Unknown  |Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:|  Differential Rev(s):
>Wiki Page:|
> -+-
>
> Comment (by bgamari):
>
>  Was the URL you were requesting
>  https://ghc.haskell.org/trac/ghc/attachment/ticket/14293/ ?
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Stg-lint and bootstrapping (fails?)

[Gabor Greif]

Indeed, it does not happen on fresh HEAD, I'll have to dig deeper.
Maybe it is related to my changes, but I only changed Stg-related
stuff. Join-points are a Core thing, right?

Anyway, I'll keep you informed if I figure it out.

Cheers,

Gabor

On 8/22/17, Simon Peyton Jones  wrote:
> Is this with HEAD?  I have an up to date HEAD, and with your command line I
> don't get those warnings.  But I do get the OccAnal warnings, so it's not
> that the warnings are being suppressed.
>
> I'm not sure how to reproduce.
>
> Does this happen on anything smaller?  Eg. on a testsuite program (you'll
> need to switch off the -dno-debug-output)?
>
> Simon
>
> |  -Original Message-
> |  From: Gabor Greif [mailto:ggr...@gmail.com]
> |  Sent: 22 August 2017 09:57
> |  To: Simon Peyton Jones ; ghc-devs  |  d...@haskell.org>
> |  Subject: Re: Stg-lint and bootstrapping (fails?)
> |
> |  On 8/21/17, Gabor Greif  wrote:
> |  > Hi Simon,
> |  >
> |  > for me it happens on many files that are compiled with
> |  >
> |  >   $ make GhcStage2HcOpts="-O1 -g"
> |  >
> |  > while the stage1 compiler is active.
> |  >
> |  > Tomorrow I can add a concrete invocation.
> |
> |  Here is it:
> |
> |  "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m
> -Wall
> |  -fllvm-fill-undef-with-garbage -Werror -Iincludes -Iincludes/dist -
> |  Iincludes/dist-derivedconstants/header
> |  -Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3
> -hide-all-packages
> |  -i -icompiler/backpack -icompiler/basicTypes -icompiler/cmm -
> |  icompiler/codeGen -icompiler/coreSyn -icompiler/deSugar -icompiler/ghci
> -
> |  icompiler/hsSyn -icompiler/iface -icompiler/llvmGen -icompiler/main -
> |  icompiler/nativeGen -icompiler/parser -icompiler/prelude -
> |  icompiler/profiling -icompiler/rename -icompiler/simplCore -
> |  icompiler/simplStg -icompiler/specialise -icompiler/stgSyn -
> |  icompiler/stranal -icompiler/typecheck -icompiler/types -icompiler/utils
> -
> |  icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build -
> |  icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen -
> |  Icompiler/. -Icompiler/parser -Icompiler/utils
> -Icompiler/../rts/dist/build
> |  -Icompiler/stage2 -optP-DGHCI -optP-include -
> |  optPcompiler/stage2/build/./autogen/cabal_macros.h
> |  -package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id
> |  directory-1.3.0.2 -package-id process-1.6.1.0 -package-id
> |  bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id
> |  time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0 -
> |  package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0
> -package-
> |  id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id
> |  ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3
> -package-id
> |  unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall -fno-warn-name-shadowing
> -
> |  this-unit-id ghc -XHaskell2010 -optc-DTHREADED_RTS -
> |  DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing
> |  -O1 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir
> |  compiler/stage2/build -hidir compiler/stage2/build -stubdir
> |  compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs
> -o
> |  compiler/stage2/build/TcEvidence.o -dyno
> |  compiler/stage2/build/TcEvidence.dyn_o
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soeO]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soeN]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_sosq]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soxX]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soy2]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soy9]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_soyw]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_sowZ]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_sovR]
> |  WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |OccurAnal failed to rediscover join point(s): [$j_sovx]
> |  WARNING: file compiler/simplCore/SimplCore.hs, line 700
&g

Re: Stg-lint and bootstrapping (fails?)

[Gabor Greif]

On 8/21/17, Gabor Greif  wrote:
> Hi Simon,
>
> for me it happens on many files that are compiled with
>
>   $ make GhcStage2HcOpts="-O1 -g"
>
> while the stage1 compiler is active.
>
> Tomorrow I can add a concrete invocation.

Here is it:

"inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0 -H64m
-Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes
-Iincludes/dist -Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3
-hide-all-packages -i -icompiler/backpack -icompiler/basicTypes
-icompiler/cmm -icompiler/codeGen -icompiler/coreSyn
-icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface
-icompiler/llvmGen -icompiler/main -icompiler/nativeGen
-icompiler/parser -icompiler/prelude -icompiler/profiling
-icompiler/rename -icompiler/simplCore -icompiler/simplStg
-icompiler/specialise -icompiler/stgSyn -icompiler/stranal
-icompiler/typecheck -icompiler/types -icompiler/utils
-icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build
-icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen
-Icompiler/. -Icompiler/parser -Icompiler/utils
-Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI
-optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h
-package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id
directory-1.3.0.2 -package-id process-1.6.1.0 -package-id
bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id
time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0
-package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0
-package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id
ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3
-package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall
-fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010
-optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing
-O1 -no-user-package-db -rtsopts -Wnoncanonical-monad-instances -odir
compiler/stage2/build -hidir compiler/stage2/build -stubdir
compiler/stage2/build -dynamic-too -c compiler/typecheck/TcEvidence.hs
-o compiler/stage2/build/TcEvidence.o -dyno
compiler/stage2/build/TcEvidence.dyn_o
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_soeO]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_soeN]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_sosq]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_soxX]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_soy2]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_soy9]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_soyw]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_sowZ]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_sovR]
WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [$j_sovx]
WARNING: file compiler/simplCore/SimplCore.hs, line 700
  Simplifier bailing out after 4 iterations [721, 479, 80, 4]
Size = {terms: 8,035, types: 8,864, coercions: 1,129, joins: 0/96}
WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
WARNING: file compiler/simplCore/OccurAnal.hs, line 2163 Just 3 []
WARNING: file compiler/simplCore/SimplCore.hs, line 1024
  Not shorting out: ebv_uniq


And with `-g` I get even more:


$ "inplace/bin/ghc-stage1" -hisuf hi -osuf o -hcsuf hc -static -O0
-H64m -Wall -fllvm-fill-undef-with-garbage -Werror -Iincludes
-Iincludes/dist -Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header -this-unit-id ghc-8.3
-hide-all-packages -i -icompiler/backpack -icompiler/basicTypes
-icompiler/cmm -icompiler/codeGen -icompiler/coreSyn
-icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface
-icompiler/llvmGen -icompiler/main -icompiler/nativeGen
-icompiler/parser -icompiler/prelude -icompiler/profiling
-icompiler/rename -icompiler/simplCore -icompiler/simplStg
-icompiler/specialise -icompiler/stgSyn -icompiler/stranal
-icompiler/typecheck -icompiler/types -icompiler/utils
-icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build
-icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen
-Icompiler/. -Icompiler/parser -Icompiler/utils
-Icompiler/../rts/dist/build -Icompiler/stage2 -optP-DGHCI
-optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h
-package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-

Re: Stg-lint and bootstrapping (fails?)

[Gabor Greif]

Hi Simon,

for me it happens on many files that are compiled with

 $ make GhcStage2HcOpts="-O1 -g"

while the stage1 compiler is active.

Tomorrow I can add a concrete invocation.

Cheers,

 Gabor

Em seg, 21 de ago de 2017 às 17:49, Simon Peyton Jones <
simo...@microsoft.com> escreveu:

> |  Oh dear, then I've really misunderstood the intent of this warning. I've
> |  been noticing these during the GHC build for quite some time now.
>
> Really?
>
> After stumbling on #14142, I removed -dno-debug-output from mk/flavours/
> validate.mk and re-validated.  Not a single occurrence of
>
> |  > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |  > |   OccurAnal failed to rediscover join point(s): [go58_akKa]
>
> How can I reproduce what you are seeing?
>
> Simon
>
> |  -Original Message-
> |  From: Ben Gamari [mailto:b...@smart-cactus.org]
> |  Sent: 19 August 2017 16:54
> |  To: Simon Peyton Jones ; Gabor Greif
> |  
> |  Cc: ghc-devs 
> |  Subject: RE: Stg-lint and bootstrapping (fails?)
> |
> |  Simon Peyton Jones  writes:
> |
> |  > | WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
> |  > |   OccurAnal failed to rediscover join point(s): [go58_akKa]
> |  >
> |  > That shouldn't happen!  If you can make a repro case, please open a
> |  ticket.
> |  >
> |  Oh dear, then I've really misunderstood the intent of this warning. I've
> |  been noticing these during the GHC build for quite some time now.
> |
> |  Cheers,
> |
> |  - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Stg-lint and bootstrapping (fails?)

[Gabor Greif]

Hi Ben,

thanks for also looking into the issue! I am in the process of
debugging a miscompilation related to #13861 (self-inflicted,
hahahar), but without a working linter I am pretty much toast... I'll
wait a bit more until your fixed hit master.

Unrelated to linting, but seemingly related to "-g" I get a ton of
warnings like this:

WARNING: file compiler/simplCore/OccurAnal.hs, line 2695
  OccurAnal failed to rediscover join point(s): [go58_akKa]

Is this perhaps covered by your fixes?

Cheers,

Gabor

On 8/16/17, Ben Gamari  wrote:
> Gabor Greif  writes:
>
>> Hi all,
>>
>> I tried an stg-lint build thus:
>>
> How timely; just yesterday I looked at a number of stg lint issues after
> having noticed a number of issues with it over the past few months.
> I pushed patches for a number of issues (#14116, #14117, #14118) to
> Phabricator, but the bigger problem is #14120, which I don't yet have a
> compelling solution for (other than the "give up on catching all but the
> most trivial type errors" approach).
>
> Cheers,
>
> - Ben
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Stg-lint and bootstrapping (fails?)

[Gabor Greif]

Hi all,

I tried an stg-lint build thus:

$ make V=1 GhcStage2HcOpts="-O1 -g -dstg-lint"

... and failed:

"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -O0
-H64m -Wall -fllvm-fill-undef-with-garbage-Werror
-this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/.
-ilibraries/base/dist-install/build
-Ilibraries/base/dist-install/build
-ilibraries/base/dist-install/build/./autogen
-Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include
  -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include
-optPlibraries/base/dist-install/build/./autogen/cabal_macros.h
-package-id rts -package-id ghc-prim-0.5.1.0 -package-id
integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint
-dno-debug-output  -no-user-package-db -rtsopts  -Wno-trustworthy-safe
-Wno-deprecated-flags -Wnoncanonical-monad-instances  -odir
libraries/base/dist-install/build -hidir
libraries/base/dist-install/build -stubdir
libraries/base/dist-install/build   -dynamic-too -c
libraries/base/./System/Mem/Weak.hs -o
libraries/base/dist-install/build/System/Mem/Weak.o -dyno
libraries/base/dist-install/build/System/Mem/Weak.dyn_o
"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -O0
-H64m -Wall -fllvm-fill-undef-with-garbage-Werror
-this-unit-id base-4.10.0.0 -hide-all-packages -i -ilibraries/base/.
-ilibraries/base/dist-install/build
-Ilibraries/base/dist-install/build
-ilibraries/base/dist-install/build/./autogen
-Ilibraries/base/dist-install/build/./autogen -Ilibraries/base/include
  -optP-DOPTIMISE_INTEGER_GCD_LCM -optP-include
-optPlibraries/base/dist-install/build/./autogen/cabal_macros.h
-package-id rts -package-id ghc-prim-0.5.1.0 -package-id
integer-gmp-1.0.1.0 -this-unit-id base -XHaskell2010 -O -dcore-lint
-dno-debug-output  -no-user-package-db -rtsopts  -Wno-trustworthy-safe
-Wno-deprecated-flags -Wnoncanonical-monad-instances  -odir
libraries/base/dist-install/build -hidir
libraries/base/dist-install/build -stubdir
libraries/base/dist-install/build   -dynamic-too -c
libraries/base/./Control/Monad/IO/Class.hs -o
libraries/base/dist-install/build/Control/Monad/IO/Class.o -dyno
libraries/base/dist-install/build/Control/Monad/IO/Class.dyn_o
"inplace/bin/ghc-stage1" -hisuf hi -osuf  o -hcsuf hc -static  -O0
-H64m -Wall -fllvm-fill-undef-with-garbage-Werror  -Iincludes
-Iincludes/dist -Iincludes/dist-derivedconstants/header
-Iincludes/dist-ghcconstants/header   -this-unit-id ghc-8.3
-hide-all-packages -i -icompiler/backpack -icompiler/basicTypes
-icompiler/cmm -icompiler/codeGen -icompiler/coreSyn
-icompiler/deSugar -icompiler/ghci -icompiler/hsSyn -icompiler/iface
-icompiler/llvmGen -icompiler/main -icompiler/nativeGen
-icompiler/parser -icompiler/prelude -icompiler/profiling
-icompiler/rename -icompiler/simplCore -icompiler/simplStg
-icompiler/specialise -icompiler/stgSyn -icompiler/stranal
-icompiler/typecheck -icompiler/types -icompiler/utils
-icompiler/vectorise -icompiler/stage2/build -Icompiler/stage2/build
-icompiler/stage2/build/./autogen -Icompiler/stage2/build/./autogen
-Icompiler/. -Icompiler/parser -Icompiler/utils
-Icompiler/../rts/dist/build -Icompiler/stage2   -optP-DGHCI
-optP-include -optPcompiler/stage2/build/./autogen/cabal_macros.h
-package-id base-4.10.0.0 -package-id deepseq-1.4.3.0 -package-id
directory-1.3.0.2 -package-id process-1.6.1.0 -package-id
bytestring-0.10.8.2 -package-id binary-0.8.5.1 -package-id
time-1.8.0.2 -package-id containers-0.5.10.2 -package-id array-0.5.2.0
-package-id filepath-1.4.1.2 -package-id template-haskell-2.12.0.0
-package-id hpc-0.6.0.3 -package-id transformers-0.5.2.0 -package-id
ghc-boot-8.3 -package-id ghc-boot-th-8.3 -package-id ghci-8.3
-package-id unix-2.7.2.2 -package-id terminfo-0.4.1.0 -Wall
-fno-warn-name-shadowing -this-unit-id ghc -XHaskell2010
-optc-DTHREADED_RTS -DGHCI_TABLES_NEXT_TO_CODE -DSTAGE=2 -Rghc-timing
-O1 -g -dstg-lint  -no-user-package-db -rtsopts
-Wnoncanonical-monad-instances  -odir compiler/stage2/build -hidir
compiler/stage2/build -stubdir compiler/stage2/build   -dynamic-too -c
compiler/utils/Exception.hs -o compiler/stage2/build/Exception.o -dyno
compiler/stage2/build/Exception.dyn_o
/home/ggreif/%NoBackup%/ghc-head/libraries/base/dist-install/build/GHC/IO/Exception.hi
Declaration for $fExceptionIOException4
Unfolding of $fExceptionIOException4:
  Failed to load interface for ?GHC.Fingerprint?
  There are files missing in the ?base-4.10.0.0? package,
  try running 'ghc-pkg check'.
  Use -v to see a list of the files searched for.
ghc-stage1: panic! (the 'impossible' happened)
  (GHC version 8.3.20170815 for x86_64-unknown-linux):
kindPrimRep
  * -> *
  typePrimRep (m_as6 :: * -> *)
  Call stack:
  CallStack (from HasCallStack):
callStackDoc, called at compiler/utils/Outputable.hs:1138:37
in ghc:Outputable
pprPanic, called at compiler/simplStg/RepType.hs:344:5 in ghc:RepType
kindPrimRep, called at compiler/simplStg/RepType.hs:305:18 in
ghc:RepType
t

Occurrence info on binders and STG

[Gabor Greif]

Hi devs!

I just had a short exchange with Joachim, he sent me to this place.

Can anybody explain how occurrence info is used in STG?

Cheers and thanks,

Gabor

-- Forwarded message --
From: Joachim Breitner 
Date: Tue, 01 Aug 2017 10:47:48 -0400
Subject: Re: [commit: ghc] master: Simplify OccurAnal.tagRecBinders (b311096)
To: Gabor Greif 

Hi,

feel free to CC the mailing list on such questions. I often don’t know
things perfectly either.

Am Dienstag, den 01.08.2017, 16:43 +0200 schrieb Gabor Greif:

>
> Loosely related question:

Very loosely :-)


>  - when doing STG Cse, the occurrence info is not updated when a
> wild(card)-binder is used. Is there a recommended way to re-run
> occ-analysis on STG? (I fear there is not.)

I fear that too. It the occ info used past that stage?

>  - I noticed that "wild"-binders sometimes do not appear at their
> binding site (after "of" and "{") in STG dumps. Dumping gets
> suppressed when they are deemed dead. Should STG consider occ-info at
> all?

Good questions. I remember that Simon commented on that before, but I
don’t remember where…


> oachim
-- 
Joachim “nomeata” Breitner
  m...@joachim-breitner.de • https://www.joachim-breitner.de/
  XMPP: nome...@joachim-breitner.de • OpenPGP-Key: 0xF0FBF51F
  Debian Developer: nome...@debian.org
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: validation failure on Mac

[Gabor Greif]

It is related, see

https://mail.haskell.org/pipermail/ghc-devs/2017-April/014055.html

I did not check whether `time` has been updated yet.

Cheers,

Gabor

Em seg, 1 de mai de 2017 às 03:01, Richard Eisenberg 
escreveu:

> Hi devs,
>
> Trying to validate with tonight's HEAD (+ my local changes) on a Mac yields
>
> *libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:22:7: **error:*
> * error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0
> [-Werror,-Wundef]*
> *   |*
> *22 |* #elif *H*AVE_CLOCK_GETTIME
> *   |**   ^*
> #elif HAVE_CLOCK_GETTIME
>   ^
>
> *libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:70:7: **error:*
> * error: 'HAVE_CLOCK_GETTIME' is not defined, evaluates to 0
> [-Werror,-Wundef]*
> *   |*
> *70 |* #elif *H*AVE_CLOCK_GETTIME
> *   |**   ^*
> #elif HAVE_CLOCK_GETTIME
>
> Is this related to the recent change from #ifdef to #if?
>
> Thanks,
> Richard
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: linux build broken

[Gabor Greif]

Ben,

I am compiling with a libraries/time fix now, looks good.

I have pushed it to https://github.com/ggreif/packages-time/tree/ghc

maybe you can review it and make it official somehow.

Cheers,

Gabor



On 4/5/17, Ben Gamari  wrote:
> Simon Peyton Jones via ghc-devs  writes:
>
>> My linux build is broken.  See below.  Help!
>
> All of this is due to the recent CPP cleanup, unfortunately. I think
> I will revert it for now and we can work out the issues elsewhere.
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: linux build broken

[Gabor Greif]

I see this too :-(

I have checked in a fix (please pull!), but libraries/time still needs
this tweak:

index 6027cdf..b87d302 100644
--- a/lib/Data/Time/Clock/Internal/SystemTime.hs
+++ b/lib/Data/Time/Clock/Internal/SystemTime.hs
@@ -19,7 +19,7 @@ import Data.Time.Clock.Internal.DiffTime

 #ifdef mingw32_HOST_OS
 import qualified System.Win32.Time as Win32
-#elif HAVE_CLOCK_GETTIME
+#elif defined(HAVE_CLOCK_GETTIME)
 import Data.Time.Clock.Internal.CTimespec
 import Foreign.C.Types (CTime(..), CLong(..))
 #else
@@ -67,7 +67,7 @@ getSystemTime = do
 getTime_resolution = 100E-9 -- 100ns
 getTAISystemTime = Nothing

-#elif HAVE_CLOCK_GETTIME
+#elif defined(HAVE_CLOCK_GETTIME)
 -- Use hi-res clock_gettime

 timespecToSystemTime :: CTimespec -> SystemTime




Cheers,

Gabor




On 4/5/17, Simon Peyton Jones via ghc-devs  wrote:
> My linux build is broken.  See below.  Help!
> Simon
>
> libraries/time/ghc.mk:4:
> libraries/time/dist-install/build/.depend-v-dyn.haskell: No such file or
> directory
> "rm" -f libraries/time/dist-install/build/.depend-v-dyn.haskell.tmp
> "inplace/bin/ghc-stage1" -M -static  -O0 -H64m -Wall
> -fllvm-fill-undef-with-garbage-Werror -Wcpp-undef-this-unit-id
> time-1.8.0.1 -hide-all-packages -i -ilibraries/time/lib
> -ilibraries/time/dist-install/build -Ilibraries/time/dist-install/build
> -ilibraries/time/dist-install/build/./autogen
> -Ilibraries/time/dist-install/build/./autogen -Ilibraries/time/lib/include
> -optP-DLANGUAGE_Rank2Types -optP-DLANGUAGE_DeriveDataTypeable
> -optP-DLANGUAGE_StandaloneDeriving -optP-include
> -optPlibraries/time/dist-install/build/./autogen/cabal_macros.h -package-id
> base-4.10.0.0 -package-id deepseq-1.4.3.0 -Wall -fwarn-tabs -XHaskell2010
> -XCPP -XRank2Types -XDeriveDataTypeable -XStandaloneDeriving -O -dcore-lint
> -dno-debug-output -ticky  -no-user-package-db -rtsopts -Wno-deprecated-flags
> -Wnoncanonical-monad-instances  -odir libraries/time/dist-install/build
> -hidir libraries/time/dist-install/build -stubdir
> libraries/time/dist-install/build -dep-makefile
> libraries/time/dist-install/build/.depend-v-dyn.haskell.tmp -dep-suffix ""
> -dep-suffix "dyn_" -include-pkg-deps
> libraries/time/lib/Data/Time/Calendar.hs
> libraries/time/lib/Data/Time/Calendar/MonthDay.hs
> libraries/time/lib/Data/Time/Calendar/OrdinalDate.hs
> libraries/time/lib/Data/Time/Calendar/WeekDate.hs
> libraries/time/lib/Data/Time/Calendar/Julian.hs
> libraries/time/lib/Data/Time/Calendar/Easter.hs
> libraries/time/lib/Data/Time/Clock.hs
> libraries/time/lib/Data/Time/Clock/System.hs
> libraries/time/lib/Data/Time/Clock/POSIX.hs
> libraries/time/lib/Data/Time/Clock/TAI.hs
> libraries/time/lib/Data/Time/LocalTime.hs
> libraries/time/lib/Data/Time/Format.hs  libraries/time/lib/Data/Time.hs
> libraries/time/lib/Data/Time/Calendar/Private.hs
> libraries/time/lib/Data/Time/Calendar/Days.hs
> libraries/time/lib/Data/Time/Calendar/Gregorian.hs
> libraries/time/lib/Data/Time/Calendar/JulianYearDay.hs
> libraries/time/lib/Data/Time/Clock/Internal/DiffTime.hs
> libraries/time/lib/Data/Time/Clock/Internal/AbsoluteTime.hs
> libraries/time/lib/Data/Time/Clock/Internal/NominalDiffTime.hs
> libraries/time/lib/Data/Time/Clock/Internal/POSIXTime.hs
> libraries/time/lib/Data/Time/Clock/Internal/UniversalTime.hs
> libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs
> libraries/time/lib/Data/Time/Clock/Internal/UTCTime.hs
> libraries/time/lib/Data/Time/Clock/Internal/CTimeval.hs
> libraries/time/dist-install/build/Data/Time/Clock/Internal/CTimespec.hs
> libraries/time/lib/Data/Time/Clock/Internal/UTCDiff.hs
> libraries/time/lib/Data/Time/LocalTime/Internal/TimeZone.hs
> libraries/time/lib/Data/Time/LocalTime/Internal/TimeOfDay.hs
> libraries/time/lib/Data/Time/LocalTime/Internal/LocalTime.hs
> libraries/time/lib/Data/Time/LocalTime/Internal/ZonedTime.hs
> libraries/time/lib/Data/Time/Format/Parse.hs
> libraries/time/lib/Data/Time/Format/Locale.hs
>
> libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:22:0: error:
>  error: "HAVE_CLOCK_GETTIME" is not defined [-Werror=undef]
>|
> 22 | #elif HAVE_CLOCK_GETTIME
>| ^
>
> libraries/time/lib/Data/Time/Clock/Internal/SystemTime.hs:70:0: error:
>  error: "HAVE_CLOCK_GETTIME" is not defined [-Werror=undef]
>|
> 70 | #elif HAVE_CLOCK_GETTIME
>| ^
> cc1: all warnings being treated as errors
> `gcc' failed in phase `C pre-processor'. (Exit code: 1)
> make[1]: *** [libraries/time/dist-install/build/.depend-v-dyn.haskell] Error
> 1
> make: *** [all] Error 2
> simonpj@cam-05-unx:~/5builds/HEAD-5$
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)

[Gabor Greif]

Hi Moritz,

I have just committed a6675a93efe7cae2f206508047a39e73ce4e92a5

There are two more spots to clean up, which I have left to you,
since I have no MachO machine to test on:

```
git grep "_.*FormatInfo" | grep -v LinkerInternals.h
linker/MachOTypes.h:typedef struct _ObjectCodeFormatInfo {
linker/MachOTypes.h:typedef struct _SectionFormatInfo {
```

I suggest that you apply the same transformation unless the LinkerInternals.h's
definition does not apply for this case.

Cheers,

Gabor


On 3/27/17, Gabor Greif  wrote:
> This commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29 introduced a
> compilation failure with gcc4.4 (my gcc). The typedef-name
> `SectionFormatInfo` is redefined.
>
> Here is the reason:
> http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-error-with-gcc-4-3-but-not-gcc-4-6
>
> I have a fix in testing, will commit shortly.
>
> Cheers,
>
> Gabor
>
> On 3/27/17, g...@git.haskell.org  wrote:
>> Repository : ssh://g...@git.haskell.org/ghc
>>
>> On branch  : master
>> Link   :
>> http://ghc.haskell.org/trac/ghc/changeset/8ed29b50376856018dfbbcbd6d728c69af0c9f29/ghc
>>
>>>---
>>
>> commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>> Author: Moritz Angermann 
>> Date:   Tue Mar 21 10:59:49 2017 -0400
>>
>> rts linker: Introduce MachOTypes
>>
>> This diff introduces MachOTypes, to reduce the need to typing
>> `struct`
>> all the time.  It also coaleces the 64 and non 64 structs. It also
>> adds
>> additional fiedls to the object code structure for macho, which makes
>> working with macho object code much simpler and requires less passing
>> around of variabls or address recomputation for the header, symbol
>> table, etc...
>>
>> Furthermore this diff introduces a type for a linked list of stubs.
>>
>> I had to move the #ifdef from the bottom of the file up, to be able
>> to
>> extend the object code structure conditional on the use of the macho
>> file format.
>>
>> This is just one of the pieces for the rts linker
>> support for ios (aarch64-macho)
>>
>> ---
>>
>> The following diagram and legend tries to explain the dependencies a
>> bit:
>> ```
>>   .- D3240
>>   v
>> D3255 <- D3252 <- D3251 <- This
>>   ^
>>   '- D3238
>> ```
>>
>> - In D3238 we started allowing preloading object code with mmap
>>   in iOS, where we can't have r+w+x.
>> - In D3239 we introduced a richer extension of the object code
>>   data type to make working with mach-o files easier.
>> - In D3240 we set the stage to allow loading archives (.a) on iOS
>> - In D3251 we added init and deinit functions to populate and
>>   depopulate the enriched object code data structure for mach-o
>>   files.
>> - In D3252 we refactored most of the MachO.c file to use the
>>   new types and data structure.
>> - in D3255 we finally introduce the aarch64-mach-o linker.
>>
>> Reviewers: austin, erikd, simonmar, rwbarton, bgamari
>>
>> Subscribers: rwbarton, thomie, ryantrinkle
>>
>> Differential Revision: https://phabricator.haskell.org/D3239
>>
>>
>>>---
>>
>> 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>>  rts/Linker.c|   6 +++
>>  rts/LinkerInternals.h   |  28 +-
>>  rts/linker/MachOTypes.h | 133
>> 
>>  3 files changed, 165 insertions(+), 2 deletions(-)
>>
>> Diff suppressed because of size. To see it, use:
>>
>> git diff-tree --root --patch-with-stat --no-color
>> --find-copies-harder
>> --ignore-space-at-eol --cc 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>> ___
>> ghc-commits mailing list
>> ghc-comm...@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: rts linker: Introduce MachOTypes (8ed29b5)

[Gabor Greif]

This commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29 introduced a
compilation failure with gcc4.4 (my gcc). The typedef-name
`SectionFormatInfo` is redefined.

Here is the reason:
http://stackoverflow.com/questions/6526322/why-redefinition-of-typedef-error-with-gcc-4-3-but-not-gcc-4-6

I have a fix in testing, will commit shortly.

Cheers,

Gabor

On 3/27/17, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/8ed29b50376856018dfbbcbd6d728c69af0c9f29/ghc
>
>>---
>
> commit 8ed29b50376856018dfbbcbd6d728c69af0c9f29
> Author: Moritz Angermann 
> Date:   Tue Mar 21 10:59:49 2017 -0400
>
> rts linker: Introduce MachOTypes
>
> This diff introduces MachOTypes, to reduce the need to typing `struct`
> all the time.  It also coaleces the 64 and non 64 structs. It also adds
> additional fiedls to the object code structure for macho, which makes
> working with macho object code much simpler and requires less passing
> around of variabls or address recomputation for the header, symbol
> table, etc...
>
> Furthermore this diff introduces a type for a linked list of stubs.
>
> I had to move the #ifdef from the bottom of the file up, to be able to
> extend the object code structure conditional on the use of the macho
> file format.
>
> This is just one of the pieces for the rts linker
> support for ios (aarch64-macho)
>
> ---
>
> The following diagram and legend tries to explain the dependencies a
> bit:
> ```
>   .- D3240
>   v
> D3255 <- D3252 <- D3251 <- This
>   ^
>   '- D3238
> ```
>
> - In D3238 we started allowing preloading object code with mmap
>   in iOS, where we can't have r+w+x.
> - In D3239 we introduced a richer extension of the object code
>   data type to make working with mach-o files easier.
> - In D3240 we set the stage to allow loading archives (.a) on iOS
> - In D3251 we added init and deinit functions to populate and
>   depopulate the enriched object code data structure for mach-o
>   files.
> - In D3252 we refactored most of the MachO.c file to use the
>   new types and data structure.
> - in D3255 we finally introduce the aarch64-mach-o linker.
>
> Reviewers: austin, erikd, simonmar, rwbarton, bgamari
>
> Subscribers: rwbarton, thomie, ryantrinkle
>
> Differential Revision: https://phabricator.haskell.org/D3239
>
>
>>---
>
> 8ed29b50376856018dfbbcbd6d728c69af0c9f29
>  rts/Linker.c|   6 +++
>  rts/LinkerInternals.h   |  28 +-
>  rts/linker/MachOTypes.h | 133
> 
>  3 files changed, 165 insertions(+), 2 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
> git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc 8ed29b50376856018dfbbcbd6d728c69af0c9f29
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Inlining Wiki Page

[Gabor Greif]

Hello Tim!

I had a pet inlining ticket, which exposes some frivolous blowup:

https://ghc.haskell.org/trac/ghc/ticket/8901

It has been closed because nobody really knows how to proceed.

Anyway, I have just got the latest stats (appending to the ticket too)

$ ls -l ./libraries/time/dist-install/build/Data/Time/Format.*o
-rw-r--r-- 1 ggreif lb40 482568 Jan 12 16:24
./libraries/time/dist-install/build/Data/Time/Format.dyn_o
-rw-r--r-- 1 ggreif lb40 514776 Jan 12 16:24
./libraries/time/dist-install/build/Data/Time/Format.o

$ wc -l ./libraries/time/lib/Data/Time/Format.hs
254 ./libraries/time/lib/Data/Time/Format.hs
$ strip ./libraries/time/dist-install/build/Data/Time/Format.*o
$ ls -l ./libraries/time/dist-install/build/Data/Time/Format.*o
-rw-r--r-- 1 ggreif lb40 201512 Jan 12 17:26
./libraries/time/dist-install/build/Data/Time/Format.dyn_o
-rw-r--r-- 1 ggreif lb40 187712 Jan 12 17:26
./libraries/time/dist-install/build/Data/Time/Format.o

$ ghc -e "187712/254"
739.0236220472441

As you can see a single line of Format.hs gets compiled to 739 stripped bytes.

Maybe you are inclined to put this ticket on the Wiki list too?

Cheers,

Gabor

On 1/11/17, Tim McGilchrist  wrote:
> Hi Matt,
>
> I noted this down last year as something I wanted to work on for this year.
> Just letting you know that I'm starting to look at some of the easier
> tickets in that page.
>
> Is there a good person or place to ask questions if I get stuck on
> anything?
>
> Cheers,
> Tim
>
> On Thursday, 4 August 2016, Matthew Pickering 
> wrote:
>
>> Dear Devs,
>>
>> I've spent the last day looking at the inliner. In doing so I updated
>> the wiki page about inlining to be a lot more useful to other people
>> wanting to understand the intricacies and problems.
>>
>> https://ghc.haskell.org/trac/ghc/wiki/Inlining
>>
>> This looks like the perfect place for a newcomer to start working on
>> GHC. The inliner is quite well contained, there are lots of open
>> tickets with well-specified aims and lots of investigatory work to be
>> done.
>>
>> So the purpose of this email is:
>>
>> 1. Please tag any tickets relevant to inlining/specialisation with
>> "Inlining"
>> 2. Any newcomers keen to get involved should read the wiki page and
>> see if they can tackle one of the tickets there.
>>
>> Matt
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org 
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Non-working "-no-pie" test?

[Gabor Greif]

Hi all,

The test for checking "-no-pie" support of GCC doesn't seem to work. See below:

$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

$ echo 'int main() { return 0; }' > conftest.c

$ if gcc -o conftest -no-pie conftest.c > /dev/null 2>&1 ; then echo
YEP ; else echo NOPE ; fi
YEP
$ if gcc -o conftest -no-pie conftest.c ; then echo YEP ; else echo NOPE ; fi
gcc: unrecognized option '-no-pie'
YEP
$ if gcc -o conftest -no-pie conftest.c > /dev/null ; then echo YEP ;
else echo NOPE ; fi
gcc: unrecognized option '-no-pie'
YEP


Is the test supposed to check that there is nothing output into stdout?

If so, it seems to fail. It leads to lots of failures when "make
test", because gcc gets chatty.

Cheers,

Gabor

PS: I have bash 4.1.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: building ghc-8.0 branch on Win10

[Gabor Greif]

http://git.haskell.org/ghc.git/blobdiff/db5a22627b3e6bcc9fa17fbc070daac0919b552a..1101045cbdbd6f240fa7e2438d9488822cd604fb:/utils/ghc-cabal/ghc.mk

This might help...

Cheers,

Gabor

Em segunda-feira, 19 de setembro de 2016, Josh Berman 
escreveu:

> Sorry to pester - now 'make' is failing:
>
> ===--- building phase 0
>> make --no-print-directory -f ghc.mk phase=0 phase_0_builds
>> "/mingw64/bin/ghc.exe" -O0 -H64m -Wall \
>>-optc-Wall -optc-Werror -optc-fno-stack-protector \
>> \
>>-hide-all-packages \
>>-package base -package array -package time -package containers
>> -package bytestring -package deepseq -package process -package pretty
>> -package directory -package Win32 \
>>--make utils/ghc-cabal/Main.hs -o 
>> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe
>> \
>>-no-user-package-db \
>>-Wall -fno-warn-unused-imports -fno-warn-warnings-deprecations \
>>-DCABAL_VERSION=  1,25,0,0 \
>>-DMIN_VERSION_binary_0_8_0 \
>>-DBOOTSTRAPPING \
>>-optP-include -optPutils/ghc-cabal/cabal_macros_boot.h \
>>-odir  bootstrapping \
>>-hidir bootstrapping \
>>-ilibraries/Cabal/Cabal \
>>-ilibraries/binary/src -DGENERICS \
>>-ilibraries/filepath \
>>-ilibraries/hpc \
>> target `1,25,0,0' is not a module name or a source file
>> ghc/ghc.mk:111: ghc/stage1/package-data.mk: No such file or directory
>> make[1]: *** [utils/ghc-cabal/ghc.mk:48: 
>> utils/ghc-cabal/dist/build/tmp/ghc-cabal.exe]
>> Error 1
>> make: *** [Makefile:130: all] Error 2
>
>
> I updated my cabal to be 1.25, thinking that might be the issue, but now I
> realize that was probably irrelevant.
>
> Any further ideas? (This time, I searched trac before emailing... but
> didn't find anything).
>
> Thanks,
> - Josh
>
>
> On Mon, Sep 19, 2016 at 2:38 PM, Josh Berman  > wrote:
>
>> Yeah, I just saw that bug report, too. Thanks.
>>
>> On Mon, Sep 19, 2016 at 2:37 PM, Phyx > > wrote:
>>
>>> Hi Josh,
>>>
>>> Yes you are hitting a bug in configure that was exposed due to changes
>>> in msys.
>>>
>>> Cherry-pick this commit to your branch https://ghc.haskell.org/trac/g
>>> hc/ticket/12487
>>>
>>> Tamar
>>>
>>> On Mon, Sep 19, 2016, 12:24 Josh Berman >> > wrote:
>>>
 Hi,

 I was able to build the "master" branch of ghc 8.0.1 using the
 instructions found here:
 https://ghc.haskell.org/trac/ghc/wiki/Building/Preparation/Windows

 When I switched to the "ghc-8.0" branch, though, I get the following
 error:

 configure: error:
> You've selected:
>   BUILD:  x86_64-w64-mingw32   (the architecture we're building on)
>   HOST:   x86_64-unknown-mingw32(the architecture the compiler
> we're building will execute on)
>   TARGET: x86_64-unknown-mingw32  (the architecture the compiler we're
> building will produce code for)
> BUILD must equal HOST; that is, we do not support building GHC itself
> with a cross-compiler.  To cross-compile GHC itself, set TARGET: stage
> 1 will be a cross-compiler, and stage 2 will be the cross-compiled
> GHC.



 Anyone know off the top of their heads what the issue is?

 Thanks,
 - Josh Berman
 ___
 ghc-devs mailing list
 ghc-devs@haskell.org
 
 http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

>>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: GHC HEAD (built with itself) blows allocation stats :-(

[Gabor Greif]

Thanks for the tip, Ben! I have just tried with ./validate and those
horrific stats are gone.

`$(MAKE) test` now also works. Apparently the thorough cleaning was
overdue. I'm fine with this.

Cheers,

Gabor

PS: Out of sheer curiosity, what could have caused the hiccups?

On 5/30/16, Ben Gamari  wrote:
> Gabor Greif  writes:
>
>> Hi devs,
>>
>> I get some pretty bad allocation statistics when testing GHC HEAD. Not
>> sure why,
>> but this is with a stage-0 compiler that is also GHC HEAD. (I doubt
>> that that is the reason, though.)
>>
> I presume this wasn't with ./validate. Have you tried ./validate?
>
> Cheers,
>
> - Ben
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

GHC HEAD (built with itself) blows allocation stats :-(

[Gabor Greif]

Hi devs,

I get some pretty bad allocation statistics when testing GHC HEAD. Not sure why,
but this is with a stage-0 compiler that is also GHC HEAD. (I doubt
that that is the reason, though.)

I see on a linux x64 system (RHEL6) :

Unexpected stat failures:
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10370  T10370 [stat
not good enough] (optasm)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T10547  T10547 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T1969   T1969 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3064   T3064 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T3294   T3294 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T4801   T4801 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5030   T5030 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321FD T5321FD [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5321FunT5321Fun
[stat not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5631   T5631 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5642   T5642 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T5837   T5837 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T6048   T6048 [stat
not good enough] (optasm)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T783T783 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9020   T9020 [stat
not good enough] (optasm)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9233   T9233 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9675   T9675 [stat
not good enough] (optasm)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a  T9872a [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872b  T9872b [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872c  T9872c [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872d  T9872d [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9961   T9961 [stat
not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/parsing001  parsing001
[stat not good enough] (normal)
   /tmp/ghctest/ayiNBP/1/2/3/./perf/space_leaks/T4029T4029 [stat
not good enough] (ghci)


Some of the tests look like this:

cd /tmp/ghctest/ayiNBP/1/2/3/./perf/compiler/T9872a &&
"ghc-head-x86_64/inplace/test   spaces/ghc-stage2" -c T9872a.hs
-fforce-recomp -dno-debug-output -no-user-package-db -rtsopts
-fno-warn-tabs -fno-warn-missed-specialisations -fshow-warning-groups
-fno-ghci-history   +RTS -V0 -tT9872a.comp.stats --machine-readable
-RTS > T9872a.comp.stderr 2>&1
bytes allocated value is too high:
ExpectedT9872a(normal) bytes allocated:  3352882080 +/-5%
Lower bound T9872a(normal) bytes allocated:  3185237976
Upper bound T9872a(normal) bytes allocated:  3520526184
Actual  T9872a(normal) bytes allocated: 13260131240
Deviation   T9872a(normal) bytes allocated:   295.5 %
*** unexpected stat test failure for T9872a(normal)

Around 300% looks really bad. Can anybody reproduce this? For
reference, this is the test command I run:

$ make test TEST="T9961 T10547 T10370 T3064 T4029 T5642 parsing001
T783 T3294 T9872d T9872b T9872c T9872a T1969 T5321Fun T5837 T5631
T5321FD T5030 T4801 T6048 T9675 T9233 T9020"

The testsuite works nicely otherwise.

Cheers and thanks,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Rank2Types example not typechecking w/ GHC8. Bug or feature?

[Gabor Greif]

The same bug has bitten git-annex too. IIRC.

Cheers,

Gabor

Em domingo, 29 de maio de 2016, Michael Karg 
escreveu:

> Hi devs,
>
> could you please have a look at the following code snippet (modeled after
> a real-world app of mine)? There's a rank2type involved, and it doesn't
> type-check anymore when the type is e.g. part of a tuple, whereas
> everything's fine when it's the "outermost" type.
>
> With GHC7.10 both variants type-check. Could anyone shed some light on
> what's behind this? Is the way the types are used in the snippet considered
> dispreferred or wrong under GHC8?
>
> Thanks for having a look and hopefully pointing me to a page/ticket/...
> providing insight,
> Michael
>
> 
>
> {-# LANGUAGE Rank2Types #-}
>
> module TestTypes where
>
> data State a= State a
>
> data Dummy  = Dummy
>
> type Handler result = forall state . State state -> IO result
>
> type Resolver   = String -> Handler String
>
>
> eventRouter :: Resolver -> String -> IO ()
> eventRouter resolver event =
> resolver event state >> return ()
>   where
> state :: State ()
> state = undefined
>
> {-
> -- does type check
> createResolver :: Resolver
> createResolver = \event state -> return "result"
>
> processor :: IO ()
> processor =
> getLine >>= eventRouter resolver >> processor
>   where
> resolver = createResolver
> -}
>
>
> -- does not type check when the rank 2 type isn't the "outermost" one?
> createResolver :: (Resolver, Dummy)
> createResolver = (\event state -> return "result", Dummy)
>
> processor :: IO ()
> processor =
> getLine >>= eventConsumer resolver >> processor
>   where
> (resolver, _) = createResolver
>
> {-
> • Couldn't match type ‘t’ with ‘Resolver’
>   ‘t’ is a rigid type variable bound by
> the inferred type of resolver :: t at TestTypes.hs:41:5
>   Expected type: (t, Dummy)
> Actual type: (Resolver, Dummy)
> -}
>
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [GHC] #11239: GHC HEAD: cannot bootstrap HEAD with HEAD

[Gabor Greif]

Sounds very much like it :-) Will try the workaround tomorrow.

Em segunda-feira, 28 de dezembro de 2015, GHC 
escreveu:

> #11239: GHC HEAD: cannot bootstrap HEAD with HEAD
> -+-
> Reporter:  heisenbug |Owner:
> Type:  bug   |   Status:  new
> Priority:  high  |Milestone:  8.0.1
>Component:  Compiler  |  Version:  7.11
>   Resolution:| Keywords:
> Operating System:  Unknown/Multiple  | Architecture:
>  Type of failure:  Building GHC  |  Unknown/Multiple
>   failed |Test Case:
>   Blocked By:| Blocking:
>  Related Tickets:|  Differential Rev(s):
>Wiki Page:|
> -+-
>
> Comment (by hvr):
>
>  Replying to [comment:4 heisenbug]:
>  > It would be interesting to see if it is just me or if somebody can
>  reproduce the problem.
>
>  Re `genprimopcode` see #11302 and #11303
>
> --
> Ticket URL: 
> GHC 
> The Glasgow Haskell Compiler
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Check: More Clang/CPP wibbles (befc4e4)

[Gabor Greif]

Hi Ben,

there are still a bunch left:

git grep "ASSERT ("

Cheers,

Gabor

On 12/4/15, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/befc4e4c4c76fd89a092240935d9f508de2ee664/ghc
>
>>---
>
> commit befc4e4c4c76fd89a092240935d9f508de2ee664
> Author: Ben Gamari 
> Date:   Fri Dec 4 13:07:16 2015 +0100
>
> Check: More Clang/CPP wibbles
>
>
>>---
>
> befc4e4c4c76fd89a092240935d9f508de2ee664
>  compiler/deSugar/Check.hs | 10 +-
>  1 file changed, 5 insertions(+), 5 deletions(-)
>
> diff --git a/compiler/deSugar/Check.hs b/compiler/deSugar/Check.hs
> index 55dcfc2..dcf3b23 100644
> --- a/compiler/deSugar/Check.hs
> +++ b/compiler/deSugar/Check.hs
> @@ -370,12 +370,12 @@ translateConPatVec  univ_tys  ex_tvs c (RecCon
> (HsRecFields fs _))
>  -- The data constructor was not defined using record syntax. For the
>  -- pattern to be in record syntax it should be empty (e.g. Just {}).
>  -- So just like the previous case.
> -  | null orig_lbls = ASSERT (null matched_lbls) mkPatternVarsSM arg_tys
> +  | null orig_lbls = ASSERT(null matched_lbls) mkPatternVarsSM arg_tys
>  -- Some of the fields appear, in the original order (there may be
> holes).
>  -- Generate a simple constructor pattern and make up fresh variables
> for
>  -- the rest of the fields
>| matched_lbls `subsetOf` orig_lbls
> -  = ASSERT (length orig_lbls == length arg_tys)
> +  = ASSERT(length orig_lbls == length arg_tys)
>let translateOne (lbl, ty) = case lookup lbl matched_pats of
>  Just p  -> translatePat p
>  Nothing -> mkPatternVarsSM [ty]
> @@ -616,7 +616,7 @@ process_guards us  gs
>  -- * Basic utilities
>
>  patternType :: Pattern -> Type
> -patternType (PmGuard pv _) = ASSERT (patVecArity pv == 1) (patternType p)
> +patternType (PmGuard pv _) = ASSERT(patVecArity pv == 1) (patternType p)
>where Just p = find ((==1) . patternArity) pv
>  patternType (NonGuard pat) = pmPatType pat
>
> @@ -826,8 +826,8 @@ splitConstraints (c : rest)
>= case c of
>TyConstraint cs-> (cs ++ ty_cs, tm_cs, bot_cs)
>TmConstraint e1 e2 -> (ty_cs, (e1,e2):tm_cs, bot_cs)
> -  BtConstraint cs-> ASSERT (isNothing bot_cs) -- NB: Only one x ~
> _|_
> -   (ty_cs, tm_cs, Just cs)
> +  BtConstraint cs-> ASSERT(isNothing bot_cs) -- NB: Only one x ~
> _|_
> +  (ty_cs, tm_cs, Just cs)
>where
>  (ty_cs, tm_cs, bot_cs) = splitConstraints rest
>
>
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Implied GHC extensions (in HEAD)

[Gabor Greif]

Hi devs,

when compiling a snippet of code (which I have written using GHC HEAD)
with GHC 7.10.2 (from the platform) I got errors about missing
extension pragmas. I had to add two:

> {-# LANGUAGE ViewPatterns, KindSignatures, GADTs, PolyKinds, 
> StandaloneDeriving, FlexibleContexts, FlexibleInstances, ScopedTypeVariables, 
> TypeFamilies, PatternSynonyms, FunctionalDependencies, RankNTypes, 
> UndecidableInstances #-}
> {-# LANGUAGE DataKinds, TypeOperators #-} -- 7.10??

Looks like the implications have been extended in 7.11.

I guess PolyKinds now implies DataKinds, but cannot think of what
implies TypeOperators.

Was this change by design or by accident?

Any ideas?

Cheers,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Duplicated typedef trips my gcc over

[Gabor Greif]

I have just committed a tentative fix I am using for a while, and keep
watching the buildbots.

Cheers,

Gabor

On 10/26/15, Christiaan Baaij  wrote:
> I cannot build HEAD for the same reason. Same GCC version.
>
> On 21 October 2015 at 13:08, Gabor Greif  wrote:
>
>> Hi all,
>>
>> look:
>>
>> $ git grep "typedef struct LibDwSession_ "
>> rts/Libdw.c:typedef struct LibDwSession_ LibDwSession;
>> rts/Libdw.h:typedef struct LibDwSession_ LibDwSession;
>>
>> $ which gcc
>> /usr/bin/gcc
>>
>> $ gcc --version
>> gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
>> Copyright (C) 2010 Free Software Foundation, Inc.
>> This is free software; see the source for copying conditions.  There is
>> NO
>> warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR
>> PURPOSE.
>>
>> Any reason why we need the typedef in rts/Libdw.c ?? My gcc complains
>> about it...
>>
>> Cheers,
>>
>> Gabor
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Building HEAD with HEAD fails

[Gabor Greif]

Hi Edward,

I commented in the phab.

Btw., this looks like a copy-paste error:

 git show 6338a1cc
commit 6338a1cc6df2c7fd8a62eeb4c5240dd90ee74a6c
Author: Edward Z. Yang 
Date:   Sun Oct 11 13:41:20 2015 -0700

Rename PACKAGE_KEY and LIB_NAME in build system.

Signed-off-by: Edward Z. Yang 

diff --git a/compiler/ghc.mk b/compiler/ghc.mk
index 8172ca6..fc9e891 100644
--- a/compiler/ghc.mk
+++ b/compiler/ghc.mk
@@ -441,11 +441,11 @@ ifeq "$(compiler_stage1_VERSION_MUNGED)" "YES"
 compiler_stage1_MUNGED_VERSION = $(subst
.$(ProjectPatchLevel),,$(ProjectVersion))
 define compiler_PACKAGE_MAGIC
 compiler_stage1_VERSION = $(compiler_stage1_MUNGED_VERSION)
-compiler_stage1_PACKAGE_KEY = $(subst
.$(ProjectPatchLevel),,$(compiler_stage1_PACKAGE_KEY))
-compiler_stage1_LIB_NAME = $(subst
.$(ProjectPatchLevel),,$(compiler_stage1_LIB_NAME))
+compiler_stage1_COMPONENT_ID = $(subst
.$(ProjectPatchLevel),,$(compiler_stage1_COMPONENT_ID))
+compiler_stage1_COMPONENT_ID = $(subst
.$(ProjectPatchLevel),,$(compiler_stage1_COMPONENT_ID))
 endef

Cheers,

Gabor

On 10/22/15, Edward Z. Yang  wrote:
> Phab here: https://phabricator.haskell.org/D1355
>
> Excerpts from Edward Z. Yang's message of 2015-10-22 13:09:25 -0700:
>> Scratch that, I managed to reproduced. (As you said, it occurs only when
>> you do the bindist.)  I'll debug.
>>
>> Edward
>>
>> Excerpts from Gabor Greif's message of 2015-10-21 23:47:37 -0700:
>> > I did not use an inplace-stage2 but had a 'make install' before and
>> > did a boot/reconfigure.
>> >
>> > Not sure whether this detail is relevant.
>> >
>> > How can I debug this problem? What does the error message say
>> > precisely?
>> >
>> > Cheers,
>> >
>> > Gabor
>> >
>> > On 10/22/15, Edward Z. Yang  wrote:
>> > > So... I can't reproduce this.  I validated a copy of GHC HEAD,
>> > > and then used the inplace ghc-stage2 to build another using
>> > > ./configure --with-ghc=... and it built fine.
>> > >
>> > > Maybe, do you have some more details?
>> > >
>> > > Edward
>> > >
>> > > Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700:
>> > >> This is likely my fault, w.r.t. to the recent Cabal submodule
>> > >> update.
>> > >> I'm a bit confused why there are things in the DB that don't have
>> > >> ABI
>> > >> hashes though...
>> > >>
>> > >> Edward
>> > >>
>> > >> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700:
>> > >> > Hi devs,
>> > >> >
>> > >> > just a heads-up (pun intended...)
>> > >> >
>> > >> > (After updating to TOT, boot and configure with a freshly
>> > >> > installed
>> > >> > TOT ghc as bootstrap compiler. Then 'make clean'.)
>> > >> >
>> > >> > Running 'make' gives:
>> > >> >
>> > >> > ...
>> > >> > Creating includes/ghcplatform.h...
>> > >> > Done.
>> > >> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp
>> > >> > "/home/ggreif/bin/ghc" -M -static  -H64m -O0 -fasm   -package-db
>> > >> > libraries/bootstrapping.conf  -hide-all-packages -i
>> > >> > -iutils/hsc2hs/.
>> > >> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen
>> > >> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen
>> > >> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h
>> > >> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2
>> > >> > -package-id
>> > >> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id
>> > >> > process-1.2.3.0 -XHaskell2010  -no-user-package-db -rtsopts
>> > >> > -odir
>> > >> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
>> > >> > utils/hsc2hs/dist/build -dep-makefile
>> > >> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix ""
>> > >> > -include-pkg-deps  utils/hsc2hs/./Main.hs  utils/hsc2hs/./C.hs
>> > >> > utils/hsc2hs/./Common.hs  utils/hsc2hs/./CrossCodegen.hs
>> > >> > utils/hsc2hs/./DirectCodegen.hs  utils/hsc2hs/./Flags.hs
>> > >> > utils/hsc2hs/./HSCParser.hs  utils/hsc2hs/./UtilsCodegen.hs
>> > >> > : package db: duplicate packages with incompatible
>> > >> > ABIs:
>> > >> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac
>> > >> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779
>> > >> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4
>> > >> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e
>> > >> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2
>> > >> > transformers-0.4.3.0 has ABIs: ,
>> > >> > 812457c97c58693d7f8a813b1ba19a33
>> > >> > template-haskell-2.11.0.0 has ABIs: ,
>> > >> > 0ef51476100e9bdf96d1bf59696b98a1
>> > >> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467
>> > >> >
>> > >> >
>> > >> > The only solution I could come up for now is
>> > >> >
>> > >> > cd libraries
>> > >> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d
>> > >> > bootstrapping.conf
>> > >> >
>> > >> > then resuming 'make' leads to success.
>> > >> >
>> > >> > What could this be? Has somebody seen such an error?
>> > >> >
>> > >> > Cheers and thanks,
>> >

Re: Building HEAD with HEAD fails

[Gabor Greif]

I did not use an inplace-stage2 but had a 'make install' before and
did a boot/reconfigure.

Not sure whether this detail is relevant.

How can I debug this problem? What does the error message say precisely?

Cheers,

Gabor

On 10/22/15, Edward Z. Yang  wrote:
> So... I can't reproduce this.  I validated a copy of GHC HEAD,
> and then used the inplace ghc-stage2 to build another using
> ./configure --with-ghc=... and it built fine.
>
> Maybe, do you have some more details?
>
> Edward
>
> Excerpts from Edward Z. Yang's message of 2015-10-21 11:44:26 -0700:
>> This is likely my fault, w.r.t. to the recent Cabal submodule update.
>> I'm a bit confused why there are things in the DB that don't have ABI
>> hashes though...
>>
>> Edward
>>
>> Excerpts from Gabor Greif's message of 2015-10-21 03:51:02 -0700:
>> > Hi devs,
>> >
>> > just a heads-up (pun intended...)
>> >
>> > (After updating to TOT, boot and configure with a freshly installed
>> > TOT ghc as bootstrap compiler. Then 'make clean'.)
>> >
>> > Running 'make' gives:
>> >
>> > ...
>> > Creating includes/ghcplatform.h...
>> > Done.
>> > "rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp
>> > "/home/ggreif/bin/ghc" -M -static  -H64m -O0 -fasm   -package-db
>> > libraries/bootstrapping.conf  -hide-all-packages -i -iutils/hsc2hs/.
>> > -iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen
>> > -Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen
>> > -optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h
>> > -package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id
>> > directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id
>> > process-1.2.3.0 -XHaskell2010  -no-user-package-db -rtsopts  -odir
>> > utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
>> > utils/hsc2hs/dist/build -dep-makefile
>> > utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix ""
>> > -include-pkg-deps  utils/hsc2hs/./Main.hs  utils/hsc2hs/./C.hs
>> > utils/hsc2hs/./Common.hs  utils/hsc2hs/./CrossCodegen.hs
>> > utils/hsc2hs/./DirectCodegen.hs  utils/hsc2hs/./Flags.hs
>> > utils/hsc2hs/./HSCParser.hs  utils/hsc2hs/./UtilsCodegen.hs
>> > : package db: duplicate packages with incompatible ABIs:
>> > binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac
>> > Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779
>> > hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4
>> > ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e
>> > hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2
>> > transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33
>> > template-haskell-2.11.0.0 has ABIs: ,
>> > 0ef51476100e9bdf96d1bf59696b98a1
>> > terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467
>> >
>> >
>> > The only solution I could come up for now is
>> >
>> > cd libraries
>> > ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d
>> > bootstrapping.conf
>> >
>> > then resuming 'make' leads to success.
>> >
>> > What could this be? Has somebody seen such an error?
>> >
>> > Cheers and thanks,
>> >
>> > Gabor
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Duplicated typedef trips my gcc over

[Gabor Greif]

Hi all,

look:

$ git grep "typedef struct LibDwSession_ "
rts/Libdw.c:typedef struct LibDwSession_ LibDwSession;
rts/Libdw.h:typedef struct LibDwSession_ LibDwSession;

$ which gcc
/usr/bin/gcc

$ gcc --version
gcc (GCC) 4.4.7 20120313 (Red Hat 4.4.7-4)
Copyright (C) 2010 Free Software Foundation, Inc.
This is free software; see the source for copying conditions.  There is NO
warranty; not even for MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.

Any reason why we need the typedef in rts/Libdw.c ?? My gcc complains
about it...

Cheers,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Building HEAD with HEAD fails

[Gabor Greif]

Hi devs,

just a heads-up (pun intended...)

(After updating to TOT, boot and configure with a freshly installed
TOT ghc as bootstrap compiler. Then 'make clean'.)

Running 'make' gives:

...
Creating includes/ghcplatform.h...
Done.
"rm" -f utils/hsc2hs/dist/build/.depend.haskell.tmp
"/home/ggreif/bin/ghc" -M -static  -H64m -O0 -fasm   -package-db
libraries/bootstrapping.conf  -hide-all-packages -i -iutils/hsc2hs/.
-iutils/hsc2hs/dist/build -iutils/hsc2hs/dist/build/autogen
-Iutils/hsc2hs/dist/build -Iutils/hsc2hs/dist/build/autogen
-optP-include -optPutils/hsc2hs/dist/build/autogen/cabal_macros.h
-package-id base-4.8.2.0 -package-id containers-0.5.6.2 -package-id
directory-1.2.2.0 -package-id filepath-1.4.0.0 -package-id
process-1.2.3.0 -XHaskell2010  -no-user-package-db -rtsopts  -odir
utils/hsc2hs/dist/build -hidir utils/hsc2hs/dist/build -stubdir
utils/hsc2hs/dist/build -dep-makefile
utils/hsc2hs/dist/build/.depend.haskell.tmp -dep-suffix ""
-include-pkg-deps  utils/hsc2hs/./Main.hs  utils/hsc2hs/./C.hs
utils/hsc2hs/./Common.hs  utils/hsc2hs/./CrossCodegen.hs
utils/hsc2hs/./DirectCodegen.hs  utils/hsc2hs/./Flags.hs
utils/hsc2hs/./HSCParser.hs  utils/hsc2hs/./UtilsCodegen.hs
: package db: duplicate packages with incompatible ABIs:
binary-0.7.5.0 has ABIs: , c28f822c21e75eb270eca0870e42aaac
Cabal-1.23.0.0 has ABIs: , a0a6af8f1dd909f2ee719ddb2cd65779
hpc-0.6.0.2 has ABIs: , 3434375974d4bc6d14952a90ec97d0c4
ghc-boot-0.0.0.0 has ABIs: , f422fc19421064f81c42815f25a11e6e
hoopl-3.10.0.2 has ABIs: , 8968e2731ff8d529c37c048d65e94bf2
transformers-0.4.3.0 has ABIs: , 812457c97c58693d7f8a813b1ba19a33
template-haskell-2.11.0.0 has ABIs: , 0ef51476100e9bdf96d1bf59696b98a1
terminfo-0.4.0.1 has ABIs: , aa24f544c0e3614d419e63fa170ac467


The only solution I could come up for now is

cd libraries
ln -s /home/ggreif/lib/ghc-7.11.20151020/package.conf.d bootstrapping.conf

then resuming 'make' leads to success.

What could this be? Has somebody seen such an error?

Cheers and thanks,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: problem running on arm

[Gabor Greif]

This is bug https://ghc.haskell.org/trac/ghc/ticket/7695 and I've been
bitten by it on an iconv-starved embedded system (PowerPC) for which I
cross-compiled "Hello World" years ago.

Cheers,

   Gabor

Em sábado, 15 de agosto de 2015, Luka Rahne  escreveu:

> It turns out that issue is due to some locale settings and having
> impropper/not having locale setting just freeze runtime. Temporary
> solution is using ascii marshaling functions
>
> myPrintStrLn  str  = withCAString str c_myprint
>
> Basic stuff now works. I will have to figure out how to fix this
> locale issue. Binding for library will be ready soon.
>
> On 14 August 2015 at 19:20, Luka Rahne  > wrote:
> > Hello everyone I am new here and I have build crosscompiler for
> > RedPitaya (http://redpitaya.com), but now i am unable to run hello
> > world. (main = putStrLn "hello world")
> >
> > Running with +RTS -Gg -RTS prints out bunch of data.
> > What I think is going on is that GC consumes all memory.
> >
> > Here is one output on device. (using larger heap just takes more time
> > and produces longer output)
> >
> > https://gist.github.com/ra1u/ab7ab0c23b86436a09ae
> >
> > In qemu everything is working fine.
> >
> > here is ghc verbose output for compilation
> > https://gist.github.com/ra1u/ed376dc81ea21cd5a66b
> >
> > If somebody has some pointers to share i would be very happy.
> >
> > best regards, Luka Rahne
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org 
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: can't validate on Mac

[Gabor Greif]

what about this loittle patch?

diff --git a/rts/posix/OSMem.c b/rts/posix/OSMem.c
index 125ae10..edb240a 100644
--- a/rts/posix/OSMem.c
+++ b/rts/posix/OSMem.c
@@ -145,6 +145,7 @@ my_mmap (void *addr, W_ size, int operation)

 kern_return_t err = 0;
 ret = addr;
+(void)prot;

 if(operation & MEM_RESERVE)
 {


On 8/3/15, Richard Eisenberg  wrote:
> Hi devs,
>
> In a (almost) clean validate on my MacOS 10.8 machine, I see this:
>
> {{{
> rts/posix/OSMem.c: In function 'my_mmap':
>
> rts/posix/OSMem.c:109:15: error:
>  error: variable 'flags' set but not used
> [-Werror=unused-but-set-variable]
>  int prot, flags;
>^
>
> rts/posix/OSMem.c:109:9: error:
>  error: variable 'prot' set but not used
> [-Werror=unused-but-set-variable]
>  int prot, flags;
>  ^
> cc1: all warnings being treated as errors
> }}}
>
> Help?
>
> Thanks,
> Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fundep question

[Gabor Greif]

With *UndecidableInstances* switchd on it seems to work :-)

Thanks for the help!

Gabor

Em sexta-feira, 31 de julho de 2015, Gabor Greif 
escreveu:

> No. I'll switch that on and report back.
>
> Thanks,
>
> Gabor
>
> Em sexta-feira, 31 de julho de 2015, Simon Peyton Jones <
> simo...@microsoft.com
> > escreveu:
>
>> you need "liberal coverage checking", so UndecidableInstances. Are you
>> doing that?
>>
>> |  -Original Message-
>> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
>> |  Richard Eisenberg
>> |  Sent: 31 July 2015 16:10
>> |  To: Gabor Greif
>> |  Cc: ghc-devs
>> |  Subject: Re: Fundep question
>> |
>> |  Let's rewrite with explicit kind variables, noting that b is also
>> |  poly-kinded:
>> |
>> |  class Dep k k2 (a :: k) (b :: k2) | a -> b k2
>> |  -- if a determines b, it surely determines k2
>> |
>> |  instance Dep k * x y => Dep (Maybe k) * (Just x) (Maybe y)
>> |
>> |  Actually, even with the kinds explicit, it still looks valid to me.
>> |  Post a bug report?
>> |
>> |  Richard
>> |
>> |  On Jul 31, 2015, at 9:54 AM, Gabor Greif  wrote:
>> |
>> |  > Hi all,
>> |  >
>> |  > say I want to instantiate
>> |  >
>> |  >class Dep (a :: k) b | a -> b
>> |  >
>> |  > as
>> |  >
>> |  >instance Dep x y => Dep (Just x) (Maybe y)
>> |  >
>> |  > Is this supposed to work? I get "The coverage condition fails"
>> |  errors.
>> |  >
>> |  > For simple cases like
>> |  >
>> |  >instance Dep True Bool
>> |  >
>> |  > etc. it seems to work fine.
>> |  >
>> |  > Thanks and cheers,
>> |  >
>> |  >Gabor
>> |  > ___
>> |  > ghc-devs mailing list
>> |  > ghc-devs@haskell.org
>> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>> |
>> |  ___
>> |  ghc-devs mailing list
>> |  ghc-devs@haskell.org
>> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Fundep question

[Gabor Greif]

No. I'll switch that on and report back.

Thanks,

Gabor

Em sexta-feira, 31 de julho de 2015, Simon Peyton Jones <
simo...@microsoft.com> escreveu:

> you need "liberal coverage checking", so UndecidableInstances. Are you
> doing that?
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org ] On
> Behalf Of
> |  Richard Eisenberg
> |  Sent: 31 July 2015 16:10
> |  To: Gabor Greif
> |  Cc: ghc-devs
> |  Subject: Re: Fundep question
> |
> |  Let's rewrite with explicit kind variables, noting that b is also
> |  poly-kinded:
> |
> |  class Dep k k2 (a :: k) (b :: k2) | a -> b k2
> |  -- if a determines b, it surely determines k2
> |
> |  instance Dep k * x y => Dep (Maybe k) * (Just x) (Maybe y)
> |
> |  Actually, even with the kinds explicit, it still looks valid to me.
> |  Post a bug report?
> |
> |  Richard
> |
> |  On Jul 31, 2015, at 9:54 AM, Gabor Greif  > wrote:
> |
> |  > Hi all,
> |  >
> |  > say I want to instantiate
> |  >
> |  >class Dep (a :: k) b | a -> b
> |  >
> |  > as
> |  >
> |  >instance Dep x y => Dep (Just x) (Maybe y)
> |  >
> |  > Is this supposed to work? I get "The coverage condition fails"
> |  errors.
> |  >
> |  > For simple cases like
> |  >
> |  >instance Dep True Bool
> |  >
> |  > etc. it seems to work fine.
> |  >
> |  > Thanks and cheers,
> |  >
> |  >Gabor
> |  > ___
> |  > ghc-devs mailing list
> |  > ghc-devs@haskell.org 
> |  > http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
> |
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org 
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Fundep question

[Gabor Greif]

Hi all,

say I want to instantiate

class Dep (a :: k) b | a -> b

as

instance Dep x y => Dep (Just x) (Maybe y)

Is this supposed to work? I get "The coverage condition fails" errors.

For simple cases like

instance Dep True Bool

etc. it seems to work fine.

Thanks and cheers,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TypeLits and type families wrt. equality

[Gabor Greif]

On 7/27/15, Richard Eisenberg  wrote:
> This works for me (with ScopedTypeVariables):
>
>> gabor :: forall a b lhs rhs.
>>  (KnownSymbol a, KnownSymbol b)
>>   => Proxy a -> Proxy b -> Proxy (lhs :~: rhs)
>>   -> Either (lhs :~: rhs) (a :~: b)
>> gabor a b _ = case sameSymbol a b of
>>   Just refl -> Right refl
>>   Nothing   -> Left (unsafeCoerce Refl)
>>
>

This is basically what I am doing now. Namely using unsafeCoerce.

But this is not what I am after. Namely a safe way to exploit negative
evidence coming from sameSymbol. I want a (weak form of) decidable
type-level equality, where I either get a witness that a and b are equal
(just like sameSymbol works now) or alternatively a different witness
that a type function evaluates to some type under the assumption that
a is not b. This is the interesting part, as the type family could get stuck
without this knowledge as my original example illustrates (and also Simon's).

The goal is not only to obtain *some* witness, but to never obtain a bad
witness this way (i.e. never get something like 'True :~: 'False).

Cheers,

Gabor


>
> Does this do what you want?
>
> Richard
>
> On Jul 27, 2015, at 11:22 AM, Gabor Greif  wrote:
>
>> On 7/27/15, Richard Eisenberg  wrote:
>>>
>>> On Jul 27, 2015, at 10:56 AM, Gabor Greif  wrote:
>>>>>>
>>>>>> decideRefl :: Proxy (a :: Symbol) -> Proxy b
>>>>>> -> Proxy (Equal a b :~: 'False)
>>>>>> -> Either (Equal a b :~: 'False) (a :~: b)
>>>
>>> What's the point of the third Proxy argument? I don't think it adds
>>> anything. Perhaps without that the way forward (albeit still with
>>> unsafeCoerce) will become clear.
>>
>> Proxy (Equal a b :~: 'False) is just the specialised version to the
>> general issue I'd like to crack:
>>
>> Proxy a -> Proxy b
>>  -> Proxy (
>>:~: )
>>  -> Either (
>>:~: )
>>(a :~: b)
>>
>> Somehow one has to communicate the equation to the compiler that
>> should be proved under the assumption that a is not unifiable with b.
>>
>> Is this clearer? Sorry for the sloppy definition!
>>
>> Cheers,
>>
>>Gabor
>>
>>
>>>
>>> Richard
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TypeLits and type families wrt. equality

[Gabor Greif]

On 7/27/15, Richard Eisenberg  wrote:
>
> On Jul 27, 2015, at 10:56 AM, Gabor Greif  wrote:
>>>>
>>>> decideRefl :: Proxy (a :: Symbol) -> Proxy b
>>>>  -> Proxy (Equal a b :~: 'False)
>>>>  -> Either (Equal a b :~: 'False) (a :~: b)
>
> What's the point of the third Proxy argument? I don't think it adds
> anything. Perhaps without that the way forward (albeit still with
> unsafeCoerce) will become clear.

Proxy (Equal a b :~: 'False) is just the specialised version to the
general issue I'd like to crack:

Proxy a -> Proxy b
  -> Proxy (
:~: )
  -> Either (
:~: )
(a :~: b)

Somehow one has to communicate the equation to the compiler that
should be proved under the assumption that a is not unifiable with b.

Is this clearer? Sorry for the sloppy definition!

Cheers,

Gabor


>
> Richard
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TypeLits and type families wrt. equality

[Gabor Greif]

On 7/27/15, Richard Eisenberg  wrote:
>
> On Jul 27, 2015, at 10:36 AM, Gabor Greif  wrote:
>
>> When saying "Big Deal" did you mean
>>  - highly desirable and somebody should go for it
>>  - or a terrible amount of work, and who tackles it is probably a
>> fool on a hubris trip?
>>
>> (I still have my problems deciphering British irony.)
>
> My use of Big Deal here is more your second option, but without so much
> negativity. :) I'm sure the person who tackled this problem would learn a
> ton and contribute to programming language research. It's just that we
> haven't yet found a great motivation for doing so.
>

Okay, agreed.

>>
>> I guess a full-blown solution is too much work for now (also considering
>> previous comments from Richard). But what about a simpler construct
>>
>> decideRefl :: Proxy (a :: Symbol) -> Proxy b
>>   -> Proxy (Equal a b :~: 'False)
>>   -> Either (Equal a b :~: 'False) (a :~: b)
>
> I believe that this function could be written only with the help of
> unsafeCoerce. Indeed, the `singletons` package provides an `SDecide`
> instance for the type-lits (which accomplishes a similar, though not
> identical, goal) via unsafeCoerce.

I doubt it could even be written with unsafeCoerce. It would need some
magic sauce from the compiler,
tapping into the type family normalizer. Consider:

> decideRefl (Proxy :: Proxy "a") (Proxy :: Proxy "b") (Proxy :: Proxy (Equal a 
> b :~: 'True)

This should give a type error (we shouldn't fabricate false evidence!), while

> decideRefl (Proxy :: Proxy "a") (Proxy :: Proxy "b") (Proxy :: Proxy (Equal a 
> b :~: 'False)

should pass the type checker and give Left Refl.

Cheers,

Gabor

>
> Richard
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: TypeLits and type families wrt. equality

[Gabor Greif]

Simon,

yes, this is the the same problem. You probably meant:

=
type family Equal a b where
  Equal a a = 'True
  Equal a b = 'False

foo :: Proxy 'False -> Bool
foo x = False

f :: forall a b. Maybe (a :~: b) -> Bool
f x = case x of
Just Refl -> True
Nothing   -> foo (undefined :: Proxy (Equal a b))
=

When saying "Big Deal" did you mean
  - highly desirable and somebody should go for it
  - or a terrible amount of work, and who tackles it is probably a
fool on a hubris trip?

(I still have my problems deciphering British irony.)

I guess a full-blown solution is too much work for now (also considering
previous comments from Richard). But what about a simpler construct

decideRefl :: Proxy (a :: Symbol) -> Proxy b
   -> Proxy (Equal a b :~: 'False)
   -> Either (Equal a b :~: 'False) (a :~: b)

The Right case is just rewrapping the Refl from a `sameSymbol`, while
the Left injection
would suppress the clause "Equal a a = 'True" from the type family,
knowing that it cannot contribute to an outcome, arriving at the 'False result.

(I have no idea how this could be represented in Core, though.)

What do you think?

Cheers,

Gabor

On 7/27/15, Simon Peyton Jones  wrote:
> Yes. Here's a simpler example:
>
> =
> type family Equal a b where
>   Equal a a = 'True
>   Equal a b = 'False
>
> foo :: Proxy 'True -> Bool
> foo x = True
>
> f :: forall a b. Maybe (a :~: b) -> Bool
> f x = case x of
> Just Refl -> True
> Nothing   -> foo (undefined :: Proxy (Equal a b))
> =
>
> In the 'Nothing' branch of the case, we know that a is not equal to b; but
> we don't exploit that negative information when trying to reduce (Equal a
> b).
>
> Making type inference (and system FC) exploit negative info would be a Big
> Deal, I think.
>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of
> |  Gabor Greif
> |  Sent: 24 July 2015 16:02
> |  To: ghc-devs; Richard Eisenberg
> |  Subject: TypeLits and type families wrt. equality
> |
> |  Hi all!
> |
> |  I have a problem with following disconnect: equalities for types as
> |  detectable by type families, while I am missing a convincing technique
> |  to do the same at the value level. (convincing means here: without
> |  resorting to unsafeCoerce)
> |
> |  Here is a demo snippet illustrating the issue. Try to get the
> |  commented line to compile without using unsafeCoerce.
> |
> |  ##
> |  {-# LANGUAGE DataKinds, GADTs, TypeOperators
> | , KindSignatures, ScopedTypeVariables, TypeFamilies #-}
> |
> |  import Data.Type.Equality
> |  import GHC.TypeLits
> |  import Data.Proxy
> |
> |  data Path (names :: [Symbol]) where
> |Empty :: Path '[]
> |Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name
> |  ': names)
> |
> |  type family StripOut (name :: Symbol) (path :: [Symbol]) where
> |StripOut name '[] = '[]
> |StripOut name (name ': ns) = StripOut name ns
> |StripOut n (name ': ns) = n ': StripOut name ns
> |
> |  stripOut :: KnownSymbol name => Proxy name -> Path names -> Path
> |  (StripOut name names)
> |  stripOut _ Empty = Empty
> |  stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' =
> |  stripOut n path
> |  --stripOut n (Longer n' path) = Longer n' (stripOut n path)
> |  ##
> |
> |  I get the error reproduced at the end of this message.
> |
> |  My suspicion is that we need to model type inequality (with a new
> |  built-in eliminator, perhaps?) that helps us to skip the equation
> |  "StripOut name (name ': ns) = StripOut name ns" in the case when
> |  sameSymbol would return Nothing.
> |
> |  Any ideas?
> |
> |  Cheers and thanks
> |
> |  Gabor
> |
> |
> |  -
> |
> |
> |  Lits.hs:20:31: error:
> |  Could not deduce: StripOut name (name1 : names1)
> |~ (name1 : StripOut name names1)
> |  from the context: (names ~ (name1 : names1), KnownSymbol name1)
> |bound by a pattern with constructor:
> |   Longer :: forall (name :: Symbol) (names ::
> |  [Symbol]).
> | KnownSymbol name =>
> | P

Re: TypeLits and type families wrt. equality

[Gabor Greif]

Hi Anthony,

while I suspected that one would need to go the "value inference"
route (i.e. type classes), I had no idea how to get started. So thanks
for your snippet, it is very helpful.

Otoh, it only strips one segment

``` haskell
*GaborTEq> showPath $ stripOut (Proxy :: Proxy "Hey") (Longer (Proxy
:: Proxy "Du") $ Longer (Proxy :: Proxy "Hey") $ Longer (Proxy ::
Proxy "Bee") $ Longer (Proxy :: Proxy "Hey") $ Longer (Proxy :: Proxy
"Hey") $ Empty)
"Du -> Bee -> Hey -> Hey"
```
I'll play around a bit with FDs and see what I can figure out to make this work.

Cheers,

Gabor


On 7/24/15, Anthony Cowley  wrote:
>
> I think you are already very familiar with what I'll show here, but I
> figured I'd offer this alternative approach just in case. It does not
> directly address your type error, but does show one way of loosely steering
> values from the type level.
>
> https://gist.github.com/acowley/57724b6facd6a39a196f
>
> Anthony
>
> Gabor Greif writes:
>
>> Hi all!
>>
>> I have a problem with following disconnect: equalities for types as
>> detectable by type families, while I am missing a convincing technique
>> to do the same at the value level. (convincing means here: without
>> resorting to unsafeCoerce)
>>
>> Here is a demo snippet illustrating the issue. Try to get the
>> commented line to compile without using unsafeCoerce.
>>
>> ##
>> {-# LANGUAGE DataKinds, GADTs, TypeOperators
>>, KindSignatures, ScopedTypeVariables, TypeFamilies #-}
>>
>> import Data.Type.Equality
>> import GHC.TypeLits
>> import Data.Proxy
>>
>> data Path (names :: [Symbol]) where
>>   Empty :: Path '[]
>>   Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name ':
>> names)
>>
>> type family StripOut (name :: Symbol) (path :: [Symbol]) where
>>   StripOut name '[] = '[]
>>   StripOut name (name ': ns) = StripOut name ns
>>   StripOut n (name ': ns) = n ': StripOut name ns
>>
>> stripOut :: KnownSymbol name => Proxy name -> Path names -> Path
>> (StripOut name names)
>> stripOut _ Empty = Empty
>> stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' = stripOut n
>> path
>> --stripOut n (Longer n' path) = Longer n' (stripOut n path)
>> ##
>>
>> I get the error reproduced at the end of this message.
>>
>> My suspicion is that we need to model type inequality (with a new
>> built-in eliminator, perhaps?) that helps us to skip the equation
>> "StripOut name (name ': ns) = StripOut name ns" in the case when
>> sameSymbol would return Nothing.
>>
>> Any ideas?
>>
>> Cheers and thanks
>>
>> Gabor
>>
>>
>> -
>>
>>
>> Lits.hs:20:31: error:
>> Could not deduce: StripOut name (name1 : names1)
>>   ~ (name1 : StripOut name names1)
>> from the context: (names ~ (name1 : names1), KnownSymbol name1)
>>   bound by a pattern with constructor:
>>  Longer :: forall (name :: Symbol) (names :: [Symbol]).
>>KnownSymbol name =>
>>Proxy name -> Path names -> Path (name :
>> names),
>>in an equation for  stripOut
>>   at Lits.hs:20:13-26
>> Expected type: Path (StripOut name names)
>>   Actual type: Path (name1 : StripOut name names1)
>> Relevant bindings include
>>   path :: Path names1
>> (bound at Lits.hs:20:23)
>>   n' :: Proxy name1
>> (bound at Lits.hs:20:20)
>>   n :: Proxy name
>> (bound at Lits.hs:20:10)
>>   stripOut :: Proxy name -> Path names -> Path (StripOut name names)
>> (bound at Lits.hs:18:1)
>> In the expression: Longer n' (stripOut n path)
>> In an equation for  stripOut :
>> stripOut n (Longer n' path) = Longer n' (stripOut n path)
>> Failed, modules loaded: none.
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

TypeLits and type families wrt. equality

[Gabor Greif]

Hi all!

I have a problem with following disconnect: equalities for types as
detectable by type families, while I am missing a convincing technique
to do the same at the value level. (convincing means here: without
resorting to unsafeCoerce)

Here is a demo snippet illustrating the issue. Try to get the
commented line to compile without using unsafeCoerce.

##
{-# LANGUAGE DataKinds, GADTs, TypeOperators
   , KindSignatures, ScopedTypeVariables, TypeFamilies #-}

import Data.Type.Equality
import GHC.TypeLits
import Data.Proxy

data Path (names :: [Symbol]) where
  Empty :: Path '[]
  Longer :: KnownSymbol name => Proxy name -> Path names -> Path (name ': names)

type family StripOut (name :: Symbol) (path :: [Symbol]) where
  StripOut name '[] = '[]
  StripOut name (name ': ns) = StripOut name ns
  StripOut n (name ': ns) = n ': StripOut name ns

stripOut :: KnownSymbol name => Proxy name -> Path names -> Path
(StripOut name names)
stripOut _ Empty = Empty
stripOut n (Longer n' path) | Just Refl <- n `sameSymbol` n' = stripOut n path
--stripOut n (Longer n' path) = Longer n' (stripOut n path)
##

I get the error reproduced at the end of this message.

My suspicion is that we need to model type inequality (with a new
built-in eliminator, perhaps?) that helps us to skip the equation
"StripOut name (name ': ns) = StripOut name ns" in the case when
sameSymbol would return Nothing.

Any ideas?

Cheers and thanks

Gabor


-


Lits.hs:20:31: error:
Could not deduce: StripOut name (name1 : names1)
  ~ (name1 : StripOut name names1)
from the context: (names ~ (name1 : names1), KnownSymbol name1)
  bound by a pattern with constructor:
 Longer :: forall (name :: Symbol) (names :: [Symbol]).
   KnownSymbol name =>
   Proxy name -> Path names -> Path (name : names),
   in an equation for  stripOut
  at Lits.hs:20:13-26
Expected type: Path (StripOut name names)
  Actual type: Path (name1 : StripOut name names1)
Relevant bindings include
  path :: Path names1
(bound at Lits.hs:20:23)
  n' :: Proxy name1
(bound at Lits.hs:20:20)
  n :: Proxy name
(bound at Lits.hs:20:10)
  stripOut :: Proxy name -> Path names -> Path (StripOut name names)
(bound at Lits.hs:18:1)
In the expression: Longer n' (stripOut n path)
In an equation for  stripOut :
stripOut n (Longer n' path) = Longer n' (stripOut n path)
Failed, modules loaded: none.
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: expanding type synonyms in error messages

[Gabor Greif]

Clang (and recent GCC versions) do something like this in error
messages. They say

   MyString (aka std::string<...lots of junk...>) is uncool

maybe a similar system would help you?

Cheers,

Gabor

On 6/16/15, Ömer Sinan Ağacan  wrote:
> Hi all,
>
> While working with complex types with lots of arguments etc. errors are
> becoming annoying very fast. For example, GHC prints errors in this way:
>
> Expected type: 
>   Actual type: 
>
> Now I have to expand that synonym in my head to understand the error.
>
> I was wondering if implementing something like this is possible:
>
> In type error messages, GHC also prints types that are cleaned from type
> synonyms. Maybe something like this:
>
>  Expected type: 
> (without synonyms): 
>Actual type: 
> (without synonyms): 
>
> If this is not always desirable for some reason, we can hide this behavior
> behind a flag.
>
> What do GHC devs think about this? Is this, in theory, possible to do? How
> hard
> would it be to implement this?
>
> Thanks.
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Can we fix our Trac that doesn't lose new ticket text

[Gabor Greif]

On 4/24/15, Eric Crockett  wrote:
> On the contrary, I did precisely that just a few days ago (
> https://ghc.haskell.org/trac/ghc/ticket/10338), and to my surprise, trac
> *did* save my new ticket text. Perhaps this is a browser-specific issue?
> I'm using 64-bit Chrome 42.0.2311.90.

With a recent Firefox, I lost the text by clicking into "Formatting
Hints" and surfing back. I was not amused.

Cheers,

Gabor

>
> On Fri, Apr 24, 2015 at 9:54 AM, Edward Z. Yang  wrote:
>
>> Steps to reproduce:
>>
>> 1. Click "New Ticket"
>> 2. Type some text into the box
>> 3. Press "Back" in your browser
>> 4. Press "Forward" in your browser
>>
>> If you try this with an official Trac this doesn't happen, so either
>> this was fixed in a new version, or we have a plugin installed which
>> is causing this to happen.
>>
>> Current version of Trac is 1.0.5, we're currently running 1.0.1
>>
>> Thanks,
>> Edward
>> ___
>> ghc-devs mailing list
>> ghc-devs@haskell.org
>> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: deriving Typeable and Nat kinds

[Gabor Greif]

Here you go: https://ghc.haskell.org/trac/ghc/ticket/10348

Thanks for looking into this!

Cheers,

Gabor

On 4/23/15, Iavor Diatchki  wrote:
> Could you please make a ticket for this, so that we have a reference and it
> does not get lost?
>
> On Thu, Apr 23, 2015 at 9:59 AM, Iavor Diatchki 
> wrote:
>
>> Aha, I see what happened.  What I said before was wrong---indeed the
>> `Typeable` instance for type-nats (and symbols) used to be implemented in
>> terms of `KnownNat` and `KnownSymbol`:
>>
>> instance KnownNat n => Typeable (n :: Nat) where ...
>>
>> When I updated the `Typeable` solver, I forgot about that special
>> case---I'll have a go at a fix.
>>
>> -Iavor
>>
>>
>>
>>
>> On Thu, Apr 23, 2015 at 8:37 AM, Gabor Greif  wrote:
>>
>>> On 4/23/15, Iavor Diatchki  wrote:
>>> > Hello,
>>> >
>>>
>>> Hi Iavor,
>>>
>>> > Apologies if my changes caused difficulties with your work---we made
>>> > the
>>> > changes to `Typable` to preserve the soundness of the type system,
>>> > hopefully the new behavior is exactly equivalent to the old in the
>>> > safe
>>> > cases.
>>>
>>> No need to apologize, I chose this way to be able to intervene fast
>>> when something breaks :-) The old behaviour might have been unsafe,
>>> though I cannot see why.
>>>
>>> >
>>> > Could you post an example of the code where the unwanted `Typeable p`
>>> > constraint appears?  It seems entirely reasonable that if you want to
>>> solve
>>> > `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not
>>> > seeing the whole picture.
>>>
>>> Here is a small example where an additional constraint surfaces:
>>>
>>>
>>> --
>>> {-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures,
>>> StandaloneDeriving #-}
>>>
>>> import GHC.TypeLits
>>> import Data.Typeable
>>>
>>> data Foo (n :: Nat) where
>>>   Hey :: KnownNat n => Foo n
>>>
>>> deriving instance Show (Foo n)
>>>
>>> data T t where
>>>   T :: (Show t, Typeable t) => t -> T t
>>>
>>> deriving instance Show (T n)
>>>
>>> {-
>>>
>>> ---  WITH ghci-7.11.20150407 (and newer)
>>> *Main> :t T Hey
>>> T Hey :: (Typeable n, KnownNat n) => T (Foo n)
>>>
>>> ---  WITH ghci-7.11.20150215 (old)
>>> *Main> :t T Hey
>>> T Hey :: KnownNat n => T (Foo n)
>>>
>>> -}
>>>
>>> --
>>>
>>>
>>> >
>>> > To answer your question about `KnownNat p`---there is no relation
>>> between
>>> > it and `Typeable`.   You may think if a `KnownNat x` constraint as
>>> > just
>>> the
>>> > integer `x`.  As it happens, the integer is closely related to the
>>> > `Typeable` instance for the number, so I think we *could* make it work
>>> so
>>>
>>> Yes, this relation I was alluding to.
>>>
>>> > that if you have `KnownNat p`, then you can get `Typeable p`, but this
>>> has
>>> > never worked previosly, so perhaps there is another issue.
>>>
>>> Maybe with my example from above it might be easier to debug it.
>>>
>>> >
>>> > -Iavor
>>>
>>> Thanks,
>>>
>>> Gabor
>>>
>>> >
>>> >
>>> >
>>> > On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif  wrote:
>>> >
>>> >> Hi devs,
>>> >>
>>> >> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
>>> >> strange regression with deriving Typeable for data with Nat-kinded
>>> >> indices.
>>> >>
>>> >> Something like this used to work (I cannot post the whole thing,
>>> >> unfortunately)
>>> >>
>>> >> {{{
>>> >> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show,
>>> >> Typeable)
>>> >> }}}
>>> >>
>>> >> With my ghc-7.11.20150407 (and later) strange obligations of the form
>>> >> `Typeable p` appear, rendering my code uncompilable. But there is no
>>> >> way I can see how I can convince the type checker that the Nat index
>>> >> is indeed Typeable. I *do* have a `KnownNat p` constraint around,
>>> >> though.
>>> >>
>>> >> The relevant changes to mainline appear to be
>>> >>
>>> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
>>> >>
>>> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2
>>> >>
>>> >> both by Iavor.
>>> >>
>>> >> So now my questions:
>>> >>
>>> >> 1) Is this a regression on mainline? (I surely hope so!) How did this
>>> >> work before?
>>> >> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my
>>> >> `Typeable (OTU p o)`
>>> >> 3) if 2) is answered with "NO", how am I supposed to satisfy those
>>> >> constraints?
>>> >>
>>> >> Thanks and cheers,
>>> >>
>>> >> Gabor
>>> >>
>>> >>
>>> >> PS: Sometimes I feel like a canary doing my research-like programming
>>> >> with GHC-HEAD, and it is a mostly positive experience, but events
>>> >> like
>>> >> this make me shiver...
>>> >>
>>> >
>>>
>>
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: deriving Typeable and Nat kinds

[Gabor Greif]

On 4/23/15, Iavor Diatchki  wrote:
> Hello,
>

Hi Iavor,

> Apologies if my changes caused difficulties with your work---we made the
> changes to `Typable` to preserve the soundness of the type system,
> hopefully the new behavior is exactly equivalent to the old in the safe
> cases.

No need to apologize, I chose this way to be able to intervene fast
when something breaks :-) The old behaviour might have been unsafe,
though I cannot see why.

>
> Could you post an example of the code where the unwanted `Typeable p`
> constraint appears?  It seems entirely reasonable that if you want to solve
> `Typeable (OUT p o)`, you'll have to provide `Typealbe p`, so I am not
> seeing the whole picture.

Here is a small example where an additional constraint surfaces:

--
{-# LANGUAGE AutoDeriveTypeable, GADTs, DataKinds, KindSignatures,
StandaloneDeriving #-}

import GHC.TypeLits
import Data.Typeable

data Foo (n :: Nat) where
  Hey :: KnownNat n => Foo n

deriving instance Show (Foo n)

data T t where
  T :: (Show t, Typeable t) => t -> T t

deriving instance Show (T n)

{-

---  WITH ghci-7.11.20150407 (and newer)
*Main> :t T Hey
T Hey :: (Typeable n, KnownNat n) => T (Foo n)

---  WITH ghci-7.11.20150215 (old)
*Main> :t T Hey
T Hey :: KnownNat n => T (Foo n)

-}
--


>
> To answer your question about `KnownNat p`---there is no relation between
> it and `Typeable`.   You may think if a `KnownNat x` constraint as just the
> integer `x`.  As it happens, the integer is closely related to the
> `Typeable` instance for the number, so I think we *could* make it work so

Yes, this relation I was alluding to.

> that if you have `KnownNat p`, then you can get `Typeable p`, but this has
> never worked previosly, so perhaps there is another issue.

Maybe with my example from above it might be easier to debug it.

>
> -Iavor

Thanks,

Gabor

>
>
>
> On Thu, Apr 23, 2015 at 7:04 AM, Gabor Greif  wrote:
>
>> Hi devs,
>>
>> between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
>> strange regression with deriving Typeable for data with Nat-kinded
>> indices.
>>
>> Something like this used to work (I cannot post the whole thing,
>> unfortunately)
>>
>> {{{
>> data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show,
>> Typeable)
>> }}}
>>
>> With my ghc-7.11.20150407 (and later) strange obligations of the form
>> `Typeable p` appear, rendering my code uncompilable. But there is no
>> way I can see how I can convince the type checker that the Nat index
>> is indeed Typeable. I *do* have a `KnownNat p` constraint around,
>> though.
>>
>> The relevant changes to mainline appear to be
>> https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
>> https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2
>>
>> both by Iavor.
>>
>> So now my questions:
>>
>> 1) Is this a regression on mainline? (I surely hope so!) How did this
>> work before?
>> 2) Should `KnownNat p` imply `Typeable p` for the ability to have my
>> `Typeable (OTU p o)`
>> 3) if 2) is answered with "NO", how am I supposed to satisfy those
>> constraints?
>>
>> Thanks and cheers,
>>
>> Gabor
>>
>>
>> PS: Sometimes I feel like a canary doing my research-like programming
>> with GHC-HEAD, and it is a mostly positive experience, but events like
>> this make me shiver...
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

deriving Typeable and Nat kinds

[Gabor Greif]

Hi devs,

between ghc-7.11.20150215 and ghc-7.11.20150407 I experienced a
strange regression with deriving Typeable for data with Nat-kinded
indices.

Something like this used to work (I cannot post the whole thing, unfortunately)

{{{
data OTU (p :: Nat) (o :: Nat) = OTU { ...fields... } deriving (Show, Typeable)
}}}

With my ghc-7.11.20150407 (and later) strange obligations of the form
`Typeable p` appear, rendering my code uncompilable. But there is no
way I can see how I can convince the type checker that the Nat index
is indeed Typeable. I *do* have a `KnownNat p` constraint around,
though.

The relevant changes to mainline appear to be
https://github.com/ghc/ghc/commit/b359c886cd7578ed083bcedcea05d315ecaeeb54
https://github.com/ghc/ghc/commit/3a0019e3672097761e7ce09c811018f774febfd2

both by Iavor.

So now my questions:

1) Is this a regression on mainline? (I surely hope so!) How did this
work before?
2) Should `KnownNat p` imply `Typeable p` for the ability to have my
`Typeable (OTU p o)`
3) if 2) is answered with "NO", how am I supposed to satisfy those constraints?

Thanks and cheers,

Gabor


PS: Sometimes I feel like a canary doing my research-like programming
with GHC-HEAD, and it is a mostly positive experience, but events like
this make me shiver...
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Branchless implementation for literal case – is it worth it?

[Gabor Greif]

Em domingo, 19 de abril de 2015, Joachim Breitner 
escreveu:

> Dear devs,
>
> in  https://ghc.haskell.org/trac/ghc/ticket/10124 bgamari suggested that
> code like
>
> f :: Int -> Bool
> f a = case a of
> 1  -> True
> 5  -> True
> 8  -> True
> 9  -> True
> 11 -> True
> 19 -> True
> _  -> False
> {-# NOINLINE f #-}
>
> should not compile to a series of conditional jumps, but rather a
> branchless code akin to
>
> let !p = a ==# 1 `orI#` a ==# 5 `orI#` a ==# 8 `orI#` a ==# 9
>  `orI#` a ==# 11 `orI#` a ==# 19
> case p of
>   1 -> do_something
>   0 -> do_something_else


I'd suggest to compile this particular case as a bittest in a 32-bit word.

Gabor


>
> Subsequently, I refactored the way we produce Cmm code from STG, opening
> the possibility to implement this optimization at that stage¹.
>
> But when I then added this implementation, I could not measure any
> runtime improvement, see
> https://ghc.haskell.org/trac/ghc/ticket/10124#comment:15
>
> So my question to the general audience: Is such branchless code really
> better than the current, branching code? Can someone provide us with an
> example that shows that it is better? Do I need to produce different
> branchless assembly?
>
> If it is not better, I can again refactor the switch generation and
> simplify it a bit again.
>
> Hmm, only now I see that rwbarton has replied there. Not sure why I
> missed that. Anyways, more voices are welcome :-)
>
> Greetings,
> Joachim
>
> ¹ This should not preclude an implementation on the Core level, which
> SPJ preferred. But I improved other aspects of the code generation as
> well, so this is worthwhile on its own.
>
> --
> Joachim “nomeata” Breitner
>   m...@joachim-breitner.de  •
> http://www.joachim-breitner.de/
>   Jabber: nome...@joachim-breitner.de   • GPG-Key:
> 0xF0FBF51F
>   Debian Developer: nome...@debian.org 
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Overlapping instances for poly-kinded data

[Gabor Greif]

Hi all,

I observe a strange "deriving Show" behaviour for my data type Foo
that has proxies:

data Foo :: k -> * where
  Foo :: Proxy t -> Foo t

deriving instance Show (Foo t)

This works as expected. But now I add

instance {-# OVERLAPPING #-} KnownSymbol s => Show (Proxy (s :: Symbol)) where
  show = ('#' :) . symbolVal
instance {-# OVERLAPPING #-} KnownNat n => Show (Proxy (n :: Nat)) where
  show = ('#' :) . show . natVal

these orphan instances, and "deriving Show" won't pick them up. When I
go and specialise
deriving instance {-# OVERLAPPING #-} KnownNat t => Show (Foo (t :: Nat))
deriving instance {-# OVERLAPPING #-} KnownSymbol s => Show (Foo (s :: Symbol))

then it seems to work allright. Is polykinded derivation so different
from the monokinded one? Or is this simply a bug?

(a more elaborate WIP example can be found here:
https://code.google.com/p/omega/source/browse/mosaic/CloudAtlas.hs?spec=svn2465&r=2465)

Cheers,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pattern matching and GADTs

[Gabor Greif]

On 3/3/15, Simon Peyton Jones  wrote:
>
> |  data Bar a where
> |Listy :: Bar [Int]
> |
> |  {-
> |  foo :: a -> Bar a -> Int
> |  foo [0] Listy = 1
>
> Well you'd get a seg-fault from the call (foo True (undefined :: Bar
> [Int])).  So we really MUST match the (Bar a) arg before the 'a' arg.  And

Oh, okay, I see! But you surely mean
  (foo True (undefined :: Bar Bool))


> Haskell only offers one way to do that, which is to put it first.
>
> You don't have to change the argument order.  Write
>
>   foo xs Listy | [0] <- xs = 1

Yeah, this is what I gave as foo'' in my examples. What about making
an irrefutable pattern match?

{{{
foo :: a -> Bar a -> Int
foo ~[a] Listy = a
}}}

While I guess this won't SEGV, it may error with a pattern match
failure. Besides, the type-checker won't let us:

Couldn't match expected type `a' with actual type `[a0]'
  `a' is a rigid type variable bound by
  the type signature for: foo :: a -> Bar a -> Int

So the pattern guard solution looks like our best option to fix the
ordering issue.

Thanks,

Gabor

>
> Simon
>
> |  -Original Message-
> |  From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor
> |  Greif
> |  Sent: 03 March 2015 14:13
> |  To: ghc-devs@haskell.org
> |  Subject: Re: Pattern matching and GADTs
> |
> |  This might be off-topic for your paper, but possibly relevant for GADT-
> |  based programming:
> |
> |  In the below snippet
> |  -
> |  {-# LANGUAGE GADTs, PatternGuards #-}
> |
> |  data Bar a where
> |Listy :: Bar [Int]
> |
> |  {-
> |  foo :: a -> Bar a -> Int
> |  foo [0] Listy = 1
> |
> |  gadtTest.hs:8:5:
> |  Couldn't match expected type `a' with actual type `[a0]'
> |`a' is a rigid type variable bound by
> |the type signature for: foo :: a -> Bar a -> Int
> |at /home/ggreif/gadtTest.hs:7:8
> |  Relevant bindings include
> |foo :: a -> Bar a -> Int (bound at /home/ggreif/gadtTest.hs:8:1)
> |  In the pattern: [0]
> |  In an equation for `foo': foo [0] Listy = 1 -}
> |
> |  foo' :: Bar a -> a -> Int
> |  foo' Listy [a] = a
> |
> |  foo'' :: a -> Bar a -> Int
> |  foo'' l Listy | [a] <- l = a
> |  -
> |
> |  the "wrong" order of pattern matches (i.e. foo) causes an error, the
> |  flipped order works (i.e. foo') and pattern guards remedy the situation
> |  (e.g. foo'').
> |
> |  Since the type signatures are isomorphic this is a bit disturbing. Why
> |  is it like this?
> |  My guess is that patterns are matched left-to-right and refinements
> |  become available "too late". Or is the reason buried in the OutsideIn
> |  algorithm (and function arrow associativity: a -> (Bar a -> Int)) ?
> |
> |  Would it be a big deal to forward-propagate type information in from
> |  GADT pattern matches?
> |
> |  Thanks and cheers,
> |
> |  Gabor
> |
> |  On 3/2/15, Simon Peyton Jones  wrote:
> |  > GHC developers
> |  > You may be interested in this paper, submitted to ICFP GADTs meet
> |  > their match: pattern-matching warnings that account for GADTs,
> |  guards,
> |  > and
> |  > laziness<http://research.microsoft.com/%7Esimonpj/papers/pattern-
> |  match
> |  > ing>, with Georgios Karachalias, Tom Schrijvers, and Dimitrios
> |  > Vytiniotis.
> |  > It describes a GADT-aware algorithm for detecting missing and
> |  > redundant patterns.
> |  > The implementation is not yet up to production quality, but it will
> |  be!
> |  > If you feel able to give us any feedback about the paper itself, that
> |  > would be incredibly useful. Thanks Simon
> |  >
> |  >
> |  ___
> |  ghc-devs mailing list
> |  ghc-devs@haskell.org
> |  http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Pattern matching and GADTs

[Gabor Greif]

This might be off-topic for your paper, but possibly relevant for
GADT-based programming:

In the below snippet
-
{-# LANGUAGE GADTs, PatternGuards #-}

data Bar a where
  Listy :: Bar [Int]

{-
foo :: a -> Bar a -> Int
foo [0] Listy = 1

gadtTest.hs:8:5:
Couldn't match expected type `a' with actual type `[a0]'
  `a' is a rigid type variable bound by
  the type signature for: foo :: a -> Bar a -> Int
  at /home/ggreif/gadtTest.hs:7:8
Relevant bindings include
  foo :: a -> Bar a -> Int (bound at /home/ggreif/gadtTest.hs:8:1)
In the pattern: [0]
In an equation for `foo': foo [0] Listy = 1
-}

foo' :: Bar a -> a -> Int
foo' Listy [a] = a

foo'' :: a -> Bar a -> Int
foo'' l Listy | [a] <- l = a
-

the "wrong" order of pattern matches (i.e. foo) causes an error,
the flipped order works (i.e. foo') and pattern guards remedy the
situation (e.g. foo'').

Since the type signatures are isomorphic this is a bit disturbing. Why
is it like this?
My guess is that patterns are matched left-to-right and refinements
become available "too late". Or is the reason buried in the OutsideIn
algorithm (and function arrow associativity: a -> (Bar a -> Int)) ?

Would it be a big deal to forward-propagate type information in from
GADT pattern matches?

Thanks and cheers,

Gabor

On 3/2/15, Simon Peyton Jones  wrote:
> GHC developers
> You may be interested in this paper, submitted to ICFP
> GADTs meet their match: pattern-matching warnings that account for GADTs,
> guards, and
> laziness,
> with Georgios Karachalias, Tom Schrijvers, and Dimitrios Vytiniotis.
> It describes a GADT-aware algorithm for detecting missing and redundant
> patterns.
> The implementation is not yet up to production quality, but it will be!
> If you feel able to give us any feedback about the paper itself, that would
> be incredibly useful. Thanks
> Simon
>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: Desugaring introduces

[Gabor Greif]

Yes, I am using 7.8.

I'll also try HEAD now...

... and it works! :-)

Thanks, I am happy now.

Cheers,

Gabor

PS: Would it be worth adding this as a regression test?




On 2/23/15, Simon Peyton Jones  wrote:
> Gabor
>
> You don't say which version of GHC you are using.  I assume 7.8.
>
> Yes, you should really get the same behaviour with the surgared and
> desugared versions.
>
> Happily, with HEAD (and 7.6) it compiles fine without ImpredicativeTypes.
>
> Simon
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org] On Behalf Of Gabor
> | Greif
> | Sent: 21 February 2015 11:42
> | To: ghc-devs
> | Subject: Desugaring introduces
> |
> | Hi devs,
> |
> | before I file a bug, I'd like to double check on a strange desugaring
> | behaviour with RankNTypes and RebindableSyntax.
> |
> | Here is the snippet
> | {{{
> | {-# LANGUAGE RankNTypes, RebindableSyntax #-}
> | {-# LANGUAGE ImpredicativeTypes #-}
> |
> | import qualified Prelude as P
> |
> | (>>=) :: a -> ((forall b . b) -> c) -> c
> | a >>= f = f P.undefined
> | return a = a
> | fail s = P.undefined
> |
> | t1 = 'd' >>= (\_ -> 'k')
> |
> | t2 = do _ <- 'd'
> | 'k'
> |
> | main = P.putStrLn [t1, t2]
> | }}}
> |
> | Without ImpredicativeTypes I get this error:
> | {{{
> | rebindtest.hs:13:9:
> | Cannot instantiate unification variable ‘t0’
> | with a type involving foralls: forall b. b
> |   Perhaps you want ImpredicativeTypes
> | In a stmt of a 'do' block: _ <- 'd'
> | In the expression:
> |   do { _ <- 'd';
> |'k' }
> | In an equation for ‘t2’:
> | t2
> |   = do { _ <- 'd';
> |  'k' }
> | }}}
> |
> | t1 is supposed to be the desugaring of t2. Strangely t2 only compiles
> | with ImpredicativeTypes. Why? Isn't desugaring a purely syntactic
> | transformation (esp. with RebindableSyntax)?
> |
> | Any hints welcome!
> |
> | Cheers,
> |
> | Gabor
> | ___
> | ghc-devs mailing list
> | ghc-devs@haskell.org
> | http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Desugaring introduces

[Gabor Greif]

Hi devs,

before I file a bug, I'd like to double check on a strange desugaring
behaviour with RankNTypes and RebindableSyntax.

Here is the snippet
{{{
{-# LANGUAGE RankNTypes, RebindableSyntax #-}
{-# LANGUAGE ImpredicativeTypes #-}

import qualified Prelude as P

(>>=) :: a -> ((forall b . b) -> c) -> c
a >>= f = f P.undefined
return a = a
fail s = P.undefined

t1 = 'd' >>= (\_ -> 'k')

t2 = do _ <- 'd'
'k'

main = P.putStrLn [t1, t2]
}}}

Without ImpredicativeTypes I get this error:
{{{
rebindtest.hs:13:9:
Cannot instantiate unification variable ‘t0’
with a type involving foralls: forall b. b
  Perhaps you want ImpredicativeTypes
In a stmt of a 'do' block: _ <- 'd'
In the expression:
  do { _ <- 'd';
   'k' }
In an equation for ‘t2’:
t2
  = do { _ <- 'd';
 'k' }
}}}

t1 is supposed to be the desugaring of t2. Strangely t2 only compiles
with ImpredicativeTypes. Why? Isn't desugaring a purely syntactic
transformation (esp. with RebindableSyntax)?

Any hints welcome!

Cheers,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: comments only (9894f6a)

[Gabor Greif]

On 1/20/15, Simon Marlow  wrote:
> No, it checks for and skips over complete zero words, not just trailing
> zeroes.

Sure, I mean the for-loops after your if-condition, in lines 291 and 304
https://git.haskell.org/ghc.git/blob/9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b:/rts/sm/Scav.c#l291

Cheers,

Gabor

>
> The bitmaps are really that sparse sometimes.  Like hundreds of zero
> words with a few non-zero bits at either end.  The change I made
> improved perf enough that this isn't a blocking issue for me any more,
> and I suspect that any further optimisation won't result in significant
> wins.  The real problem is that the code generator generates huge SRT
> bitmaps, and I bet there are bigger wins to be had there.
>
> Cheers,
> Simon
>
> On 20/01/2015 13:45, Gabor Greif wrote:
>> Hi Simon,
>>
>> JFTR, you seem to be after the trailing zeros in the code you commented.
>>
>> If the bitmap is *really* that sparse then it might be profitable to
>> rewrite it in terms of
>> __builtin_ctz (when present). Some CPUs even have instructions for this.
>>
>> http://hardwarebug.org/2010/01/14/beware-the-builtins/
>>
>> Possibly one could even switch to checking *leading* zeros by
>> reformulating the algorithm and eliminate a few more instructions.
>>
>> http://www.hackersdelight.org/ might be another source for inspiration.
>>
>> Cheers,
>>
>>  Gabor
>>
>> On 1/20/15, g...@git.haskell.org  wrote:
>>> Repository : ssh://g...@git.haskell.org/ghc
>>>
>>> On branch  : master
>>> Link   :
>>> http://ghc.haskell.org/trac/ghc/changeset/9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b/ghc
>>>
>>>> ---
>>>
>>> commit 9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b
>>> Author: Simon Marlow 
>>> Date:   Wed Jan 14 08:45:07 2015 +
>>>
>>>  comments only
>>>
>>>
>>>> ---
>>>
>>> 9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b
>>>   rts/sm/Scav.c | 2 ++
>>>   1 file changed, 2 insertions(+)
>>>
>>> diff --git a/rts/sm/Scav.c b/rts/sm/Scav.c
>>> index 2ecb23b..781840c 100644
>>> --- a/rts/sm/Scav.c
>>> +++ b/rts/sm/Scav.c
>>> @@ -285,6 +285,8 @@ scavenge_large_srt_bitmap( StgLargeSRT *large_srt )
>>>
>>>   for (i = 0; i < size / BITS_IN(W_); i++) {
>>>   bitmap = large_srt->l.bitmap[i];
>>> +// skip zero words: bitmaps can be very sparse, and this helps
>>> +// performance a lot in some cases.
>>>   if (bitmap != 0) {
>>>   for (j = 0; j < BITS_IN(W_); j++) {
>>>   if ((bitmap & 1) != 0) {
>>>
>>> ___
>>> ghc-commits mailing list
>>> ghc-comm...@haskell.org
>>> http://www.haskell.org/mailman/listinfo/ghc-commits
>>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: comments only (9894f6a)

[Gabor Greif]

Hi Simon,

JFTR, you seem to be after the trailing zeros in the code you commented.

If the bitmap is *really* that sparse then it might be profitable to
rewrite it in terms of
__builtin_ctz (when present). Some CPUs even have instructions for this.

http://hardwarebug.org/2010/01/14/beware-the-builtins/

Possibly one could even switch to checking *leading* zeros by
reformulating the algorithm and eliminate a few more instructions.

http://www.hackersdelight.org/ might be another source for inspiration.

Cheers,

Gabor

On 1/20/15, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b/ghc
>
>>---
>
> commit 9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b
> Author: Simon Marlow 
> Date:   Wed Jan 14 08:45:07 2015 +
>
> comments only
>
>
>>---
>
> 9894f6a5b4883ea87fd5f280a2eb4a8abfbd2a6b
>  rts/sm/Scav.c | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/rts/sm/Scav.c b/rts/sm/Scav.c
> index 2ecb23b..781840c 100644
> --- a/rts/sm/Scav.c
> +++ b/rts/sm/Scav.c
> @@ -285,6 +285,8 @@ scavenge_large_srt_bitmap( StgLargeSRT *large_srt )
>
>  for (i = 0; i < size / BITS_IN(W_); i++) {
>  bitmap = large_srt->l.bitmap[i];
> +// skip zero words: bitmaps can be very sparse, and this helps
> +// performance a lot in some cases.
>  if (bitmap != 0) {
>  for (j = 0; j < BITS_IN(W_); j++) {
>  if ((bitmap & 1) != 0) {
>
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Improve documentation of syntax for promoted lists (a972bdd)

[Gabor Greif]

Hmm, shouldn't that be -XDataKinds (instead of -XTypeOperators)?


also:
  umambiguous ---> unambiguous
  becuase ---> because

Cheers,

Gabor

On 12/15/14, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/a972bddfc8115d80d774383a55202a293dc68595/ghc
>
>>---
>
> commit a972bddfc8115d80d774383a55202a293dc68595
> Author: Simon Peyton Jones 
> Date:   Mon Dec 15 17:08:29 2014 +
>
> Improve documentation of syntax for promoted lists
>
> THe documentation in 7.9.4 of promoted list and tuple types was
> misleading, which led to Trac #9882.  This patch makes explicit
> that only type-level with two or more elements can have the
> quote omitted.
>
>
>>---
>
> a972bddfc8115d80d774383a55202a293dc68595
>  compiler/parser/Parser.y  |  8 ++--
>  docs/users_guide/glasgow_exts.xml | 19 ---
>  2 files changed, 22 insertions(+), 5 deletions(-)
>
> diff --git a/compiler/parser/Parser.y b/compiler/parser/Parser.y
> index bffe6e1..235d34a 100644
> --- a/compiler/parser/Parser.y
> +++ b/compiler/parser/Parser.y
> @@ -1483,6 +1483,10 @@ atype :: { LHsType RdrName }
> [mo $2,mc $4] }
>  | SIMPLEQUOTE var   { sLL $1 $> $ HsTyVar $
> unLoc $2 }
>
> +-- Two or more [ty, ty, ty] must be a promoted list type, just as
> +-- if you had written '[ty, ty, ty]
> +-- (One means a list type, zero means the list type constructor,
> +-- so you have to quote those.)
>  | '[' ctype ',' comma_types1 ']'  {% ams (sLL $1 $> $
> HsExplicitListTy
>   placeHolderKind ($2 :
> $4))
>   [mo $1, mj AnnComma $3,mc
> $5] }
> @@ -1503,11 +1507,11 @@ inst_types1 :: { [LHsType RdrName] }
>  | inst_type ',' inst_types1{% addAnnotation (gl $1) AnnComma
> (gl $2)
>>> return ($1 : $3) }
>
> -comma_types0  :: { [LHsType RdrName] }
> +comma_types0  :: { [LHsType RdrName] }  -- Zero or more:  ty,ty,ty
>  : comma_types1  { $1 }
>  | {- empty -}   { [] }
>
> -comma_types1:: { [LHsType RdrName] }
> +comma_types1:: { [LHsType RdrName] }  -- One or more:  ty,ty,ty
>  : ctype{ [$1] }
>  | ctype  ',' comma_types1  {% addAnnotation (gl $1) AnnComma
> (gl $2)
>>> return ($1 : $3) }
> diff --git a/docs/users_guide/glasgow_exts.xml
> b/docs/users_guide/glasgow_exts.xml
> index e12703f..7edca07 100644
> --- a/docs/users_guide/glasgow_exts.xml
> +++ b/docs/users_guide/glasgow_exts.xml
> @@ -6882,9 +6882,9 @@ is a single quote.
>  
>
>  
> -Promoted lists and tuples types
> +Promoted list and tuple types
>  
> -Haskell's list and tuple types are natively promoted to kinds, and enjoy
> the
> +With -XTypeOperators, Haskell's list and tuple types are
> natively promoted to kinds, and enjoy the
>  same convenient syntax at the type level, albeit prefixed with a quote:
>  
>  data HList :: [*] -> * where
> @@ -6893,8 +6893,21 @@ data HList :: [*] -> * where
>
>  data Tuple :: (*,*) -> * where
>Tuple :: a -> b -> Tuple '(a,b)
> +
> +foo0 :: HList '[]
> +foo0 = HNil
> +
> +foo1 :: HList '[Int]
> +foo1 = HCons (3::Int) HNil
> +
> +foo2 :: HList [Int, Bool]
> +foo2 = ...
>  
> -Note that this requires -XTypeOperators.
> +For type-level lists of two or more elements,
> +such as the signature of foo2 above, the quote may be
> omitted because the meaning is
> +umambiguous. But for lists of one or zero elements (as in
> foo0
> +and foo1), the quote is required, becuase the types
> []
> +and [Int] have existing meanings in Haskell.
>  
>  
>
>
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

[Gabor Greif]

So it could be regarded as a bugfix?

Em terça-feira, 2 de dezembro de 2014, Dr. ÉRDI Gergő 
escreveu:

> It is clear to everyone that all it would change is the *output* of GHCi's
> :info and Haddock-generated docs, right? There's no change whatsoever to
> what programs are accepted by GHC, or what they mean.
> On Dec 2, 2014 5:44 AM, "Simon Peyton Jones"  > wrote:
>
>> The issue is not so much timing for 7.8.4 (it's a modes change to
>> pretty-printing only) but rather that it would make 7.8.4 behave
>> differently to 7.8.3 (although similarly to 7.10). We typically do not do
>> that.  And the same would be true of 7.8.5.
>>
>> Simon
>>
>> | -Original Message-
>> | From: Gabor Greif [mailto:ggr...@gmail.com
>> ]
>> | Sent: 01 December 2014 15:53
>> | To: Dr. ERDI Gergo
>> | Cc: Simon Peyton Jones; ghc-devs@haskell.org
>> 
>> | Subject: Re: Back-porting pattern synonym type signature syntax for GHC
>> | 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]
>> |
>> | Gergö,
>> |
>> | even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-)
>> |
>> |  Gabor
>> |
>> |
>> | On 11/29/14, Dr. ERDI Gergo > > wrote:
>> | > On Wed, 26 Nov 2014, Simon Peyton Jones wrote:
>> | >
>> | >> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs
>> lie.
>> | >> But what do others think?
>> | >
>> | > Just to give an idea of how limited the scope of this change would be,
>> | > I've went and implemented it, on the
>> 'wip/pattern-synonym-sig-backport'
>> | > branch (of both GHC and Haddock).
>> | > ___
>> | > ghc-devs mailing list
>> | > ghc-devs@haskell.org
>> 
>> | > http://www.haskell.org/mailman/listinfo/ghc-devs
>> | >
>>
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050)

[Gabor Greif]

I tried to build HEAD to verify this, but got a linker error. IIRC when I
filed this bug I provided a test case which did compile, but you had to
uncomment signatures to see an error. I did not see those sigs uncommented
in your repro checkin.

So it might be too early for a party...

   Gabor

Em segunda-feira, 1 de dezembro de 2014, Simon Peyton Jones <
simo...@microsoft.com> escreveu:

> Good point, thank you!
>
> | -Original Message-
> | From: ghc-devs [mailto:ghc-devs-boun...@haskell.org ] On
> Behalf Of Gabor
> | Greif
> | Sent: 01 December 2014 16:01
> | To: ghc-devs@haskell.org 
> | Subject: Re: [commit: ghc] master: Fix the handling of instance
> | signatures (Trac #9582, #9833) (e6a2050)
> |
> | Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too?
> |
> | Cheers,
> |
> | Gabor
> |
> | On 12/1/14, g...@git.haskell.org   > wrote:
> | > Repository : ssh://g...@git.haskell.org/ghc
> | >
> | > On branch  : master
> | > Link   :
> | >
> |
> http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715
> | fbab355ca/ghc
> | >
> | >>---
> | >
> | > commit e6a2050ebb6da316aecec66a6795715fbab355ca
> | > Author: Simon Peyton Jones >
> | > Date:   Mon Dec 1 11:43:20 2014 +
> | >
> | > Fix the handling of instance signatures (Trac #9582, #9833)
> | >
> | > This finally solves the issue of instance-method signatures that
> | are
> | > more polymorphic than the instanted class method.
> | >
> | > See Note [Instance method signatures] in TcInstDcls.
> | >
> | > A very nice fix for the two Trac tickets above.
> | >
> | >
> | >>---
> | >
> | > e6a2050ebb6da316aecec66a6795715fbab355ca
> | >  compiler/typecheck/TcBinds.lhs |  18 ++-
> | >  compiler/typecheck/TcClassDcl.lhs  |  16 +--
> | >  compiler/typecheck/TcInstDcls.lhs  | 121
> | > -
> | >  docs/users_guide/glasgow_exts.xml  |  29 -
> | >  .../tests/indexed-types/should_compile/T9582.hs|  14 +++
> | >  testsuite/tests/indexed-types/should_compile/all.T |   1 +
> | >  testsuite/tests/polykinds/T9833.hs |  18 +++
> | >  testsuite/tests/polykinds/all.T|   2 +
> | >  testsuite/tests/typecheck/should_fail/T6001.stderr |   9 +-
> | >  testsuite/tests/typecheck/should_fail/T7545.hs |   1 +
> | >  testsuite/tests/typecheck/should_fail/T7545.stderr |   5 -
> | >  testsuite/tests/typecheck/should_fail/all.T|   2 +-
> | >  12 files changed, 157 insertions(+), 79 deletions(-)
> | >
> | > Diff suppressed because of size. To see it, use:
> | >
> | > git diff-tree --root --patch-with-stat --no-color --find-copies-
> | harder
> | > --ignore-space-at-eol --cc e6a2050ebb6da316aecec66a6795715fbab355ca
> | > ___
> | > ghc-commits mailing list
> | > ghc-comm...@haskell.org 
> | > http://www.haskell.org/mailman/listinfo/ghc-commits
> | >
> | ___
> | ghc-devs mailing list
> | ghc-devs@haskell.org 
> | http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: [commit: ghc] master: Fix the handling of instance signatures (Trac #9582, #9833) (e6a2050)

[Gabor Greif]

Maybe this (https://ghc.haskell.org/trac/ghc/ticket/7908) is fixed too?

Cheers,

Gabor

On 12/1/14, g...@git.haskell.org  wrote:
> Repository : ssh://g...@git.haskell.org/ghc
>
> On branch  : master
> Link   :
> http://ghc.haskell.org/trac/ghc/changeset/e6a2050ebb6da316aecec66a6795715fbab355ca/ghc
>
>>---
>
> commit e6a2050ebb6da316aecec66a6795715fbab355ca
> Author: Simon Peyton Jones 
> Date:   Mon Dec 1 11:43:20 2014 +
>
> Fix the handling of instance signatures (Trac #9582, #9833)
>
> This finally solves the issue of instance-method signatures that are
> more polymorphic than the instanted class method.
>
> See Note [Instance method signatures] in TcInstDcls.
>
> A very nice fix for the two Trac tickets above.
>
>
>>---
>
> e6a2050ebb6da316aecec66a6795715fbab355ca
>  compiler/typecheck/TcBinds.lhs |  18 ++-
>  compiler/typecheck/TcClassDcl.lhs  |  16 +--
>  compiler/typecheck/TcInstDcls.lhs  | 121
> -
>  docs/users_guide/glasgow_exts.xml  |  29 -
>  .../tests/indexed-types/should_compile/T9582.hs|  14 +++
>  testsuite/tests/indexed-types/should_compile/all.T |   1 +
>  testsuite/tests/polykinds/T9833.hs |  18 +++
>  testsuite/tests/polykinds/all.T|   2 +
>  testsuite/tests/typecheck/should_fail/T6001.stderr |   9 +-
>  testsuite/tests/typecheck/should_fail/T7545.hs |   1 +
>  testsuite/tests/typecheck/should_fail/T7545.stderr |   5 -
>  testsuite/tests/typecheck/should_fail/all.T|   2 +-
>  12 files changed, 157 insertions(+), 79 deletions(-)
>
> Diff suppressed because of size. To see it, use:
>
> git diff-tree --root --patch-with-stat --no-color --find-copies-harder
> --ignore-space-at-eol --cc e6a2050ebb6da316aecec66a6795715fbab355ca
> ___
> ghc-commits mailing list
> ghc-comm...@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-commits
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: Back-porting pattern synonym type signature syntax for GHC 7.8.4 [Re: ANNOUNCE: GHC 7.8.4 Release Candidate 1]

[Gabor Greif]

Gergö,

even if it might be too late for 7.8.4, don't give up hope for 7.8.5 :-)

 Gabor


On 11/29/14, Dr. ERDI Gergo  wrote:
> On Wed, 26 Nov 2014, Simon Peyton Jones wrote:
>
>> My instinct is that (a)-(c) overwhelm (d); i.e. let sleeping dogs lie.
>> But what do others think?
>
> Just to give an idea of how limited the scope of this change would be,
> I've went and implemented it, on the 'wip/pattern-synonym-sig-backport'
> branch (of both GHC and Haddock).
> ___
> ghc-devs mailing list
> ghc-devs@haskell.org
> http://www.haskell.org/mailman/listinfo/ghc-devs
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

package 'categories' fails with HEAD

[Gabor Greif]

Hi all,

some time ago I filed:

https://github.com/ekmett/categories/issues/4

against the 'categories' library. But I cannot see what is wrong with
the code. It also builds with older GHCs (though I should re-check
with 7.8.3).

So I conjecture this is a HEAD problem in GHC HEAD. It seems weird.

Any ideas what this could be?

Cheers,

Gabor
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs

Re: GHC Trac

[Gabor Greif]

Hopping from one ticket to the next takes about 5 seconds for me. I
call that very slow.

Cheers,

Gabor

On 11/3/14, Simon Peyton Jones  wrote:
> Is it just me, or is the GHC Trac soul-destroyingly slow at the moment?  IT
> takes minutes to load one page!
>
> Simon
>
___
ghc-devs mailing list
ghc-devs@haskell.org
http://www.haskell.org/mailman/listinfo/ghc-devs