moving from ghc-6.2 to 6.4

[Simon Marlow]

On 29 March 2005 17:56, Keean Schupke wrote:

> Thought I would run some benchmarks with different compiler options,
> so I pulled out some code (that compiled fine with 6.2). The code uses
> MArrays to calculate a tree difference between two different XML
> files. Anyway tying to compile with 6.4 I get:
> 
>  >ghc-6.3: panic! (the `impossible' happened, GHC version 6.3):
>  >        app_match: unbound tpl s{tv a2M9}
>  >
>  >Please report it as a compiler bug to
> glasgow-haskell-bugs at haskell.org, 
> 
> Any idea how to track down the cause of this?

The error message claims to be from GHC 6.3, perhaps you're using a
pre-6.4 snapshot?  Could you try with the released 6.4 and let us know
if it still happens?

Cheers,
	Simon

>     Keean.
> 
> Simon Marlow wrote:
> 
>> On 29 March 2005 08:59, Johannes Waldmann wrote:
>> 
>> 
>> 
>>> I am trying to bring a larger heap of code
>>> (http://141.57.11.163/auto/ ) into 6.4 land (because of wonder
>>> stories about faster compilation, faster execution, Data.Map, and
>>> so on ...) Here are a few observations and questions
>>> that may be useful to others as well.
>>> 
>>> * what is the situation with ghc-6.4 for sparc/solaris?
>>>   I don't see a binary package in the download area.
>>>   I started to build from source - can this be successful?
>>> 
>>>   (The rest of this report refers to i386/linux)
>>> 
>>> 
>> 
>> There are some outstanding issues on Sparc/Solaris that I didn't get
>> around to investigating before the release.  One of them is a random
>> crash, so you should probably consider 6.4 to be broken on
>> Sparc/Solaris for the time being (it might be related to gcc version
>> though: 6.2.x might be just as broken with recent gcc versions). 
>> I'm keen to get more data points, if you have the time & inclination
>> to test it. 
>> 
>> We could really do with a Sparc/GHC guru to take up the mantle of
>> maintaining the Sparc port - it's kind of hard for us to do it
>> without the hardware locally, and I'm no Sparc expert.
>> 
>> 
>> 
>>> * Cabal is very nice! - The only thing that was confusing me
>>>   is that I have to list all modules in the *.cabal file:
>>>   if I don't, it still happily builds and installs the package
>>>   but it cannot be used, giving linker errors. Couldn't this be
>>>   checked earlier? Or better, couldn't it infer the needed
>>>   hidden modules? Anyway I can generate the module list by a shell
>>>   script but that does not feel right. - How do I build and install
>>>   a profiling version of a package, how does Cabal support this?
>>> 
>>> 
>> 
>> The module list: yes, I think this is something the Cabal team would
>> like to automate in the future.  There's no way to build profiled
>> packages at the moment, as far as I'm aware.  I agree it's an
>> important feature, though. 
>> 
>> 
>> 
>>> * I don't see "dramatic" improvements in execution times -
>>>   are there some magic ghc options I missed? I used -O -fvia-C.
>>>   Still, executables are maybe 2 .. 5 % smaller and faster than they
>>>   were with 6.2 - and compilation without -O is really fast.
>>> 
>>> 
>> 
>> I don't know where this rumour of dramatic improvements in execution
>> time comes from :-)  Our testing shows modest improvements in most
>> programs, with some programs going slower.  The focus of 6.4 wasn't
>> really on performance, but we hope to merge performance improvements
>> back into future 6.4 releases.
>> 
>> Cheers,
>> 	Simon
>> _______________________________________________
>> Glasgow-haskell-users mailing list
>> Glasgow-haskell-users at haskell.org
>> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users
>> 
>> 
> 
> _______________________________________________
> Glasgow-haskell-users mailing list
> Glasgow-haskell-users at haskell.org
> http://www.haskell.org/mailman/listinfo/glasgow-haskell-users