Jeroen Bransen | 4 Mar 13:35 2013
Picon

GHC 7.6.2 introduces <<loop>> in UUAGC

Hi all,

The uuagc package [1] works fine with GHC versions 7.4.* and 7.6.1. However, with GHC 7.6.2 the binary still
compiles but runs into an infinite loop at runtime. To reproduce, do:

cabal install uuagc && touch tmp.ag && uuagc tmp.ag

With GHC versions < 7.6.2 this succeeds and creates a (rather boring) file tmp.hs, while with GHC 7.6.2 this displays:

uuagc: <<loop>>

I suspect that this is related to strictness annotations, which exist in many places in the UUAGC source
code (which itself is also preprocessed by the UUAGC system). In the release notes I cannot find anything
related to strictness which could introduce this, so would anyone have a clue on where to look? Has there
been a longstanding bug in the UUAGC source code which only now surfaces? Or is it a bug introduced in GHC
7.6.2 where something is a bit too strict?

Regards,
Jeroen Bransen

[1] http://hackage.haskell.org/package/uuagc
Jeroen Bransen | 7 Mar 11:36 2013
Picon

Re: GHC 7.6.2 introduces <<loop>> in UUAGC

> The uuagc package [1] works fine with GHC versions 7.4.* and 7.6.1. However, with GHC 7.6.2 the binary
still compiles but runs into an infinite loop at runtime. To reproduce, do:
> 
> cabal install uuagc && touch tmp.ag && uuagc tmp.ag
> 
> With GHC versions < 7.6.2 this succeeds and creates a (rather boring) file tmp.hs, while with GHC 7.6.2
this displays:
> 
> uuagc: <<loop>>
> 
> I suspect that this is related to strictness annotations, which exist in many places in the UUAGC source
code (which itself is also preprocessed by the UUAGC system). In the release notes I cannot find anything
related to strictness which could introduce this, so would anyone have a clue on where to look? Has there
been a longstanding bug in the UUAGC source code which only now surfaces? Or is it a bug introduced in GHC
7.6.2 where something is a bit too strict?

FYI, I have been able to trace this down to a bug in the GHC type checker, resulting in an incorrect (invalid)
type being inferred for a function in uulib, which UUAGC relies on. A new version of uulib has been uploaded
to Hackage which solves this issue, and the bug report for GHC can be found at http://hackage.haskell.org/trac/ghc/ticket/7748

Regards,
Jeroen Bransen

Gmane