Bug 995419 - [F20] [neon] ghc throws an illegal instruction error when compiling on nvidia tegra2
[F20] [neon] ghc throws an illegal instruction error when compiling on nvidia...
Status: CLOSED EOL
Product: Fedora
Classification: Fedora
Component: ghc (Show other bugs)
20
arm Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Jens Petersen
Fedora Extras Quality Assurance
:
Depends On:
Blocks: ARMTracker
  Show dependency treegraph
 
Reported: 2013-08-09 05:53 EDT by Hans de Goede
Modified: 2015-06-29 21:18 EDT (History)
5 users (show)

See Also:
Fixed In Version: ghc-7.6.3-25.fc21
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2015-06-29 21:18:38 EDT
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)

  None (edit)
Description Hans de Goede 2013-08-09 05:53:13 EDT
While doing a testbuild of hedgewars on my trimslice (arm system with nVidia Tegra2 soc), I got the following error:

/bin/sh: line 1:  1076 Illegal instruction     /usr/bin/ghc --make /root/rpmbuild/BUILD/hedgewars-src-0.9.18/gameServer/hedgewars-server.hs -i/root/rpmbuild/BUILD/hedgewars-src-0.9.18/gameServer -o /root/rpmbuild/BUILD/hedgewars-src-0.9.18/bin/hedgewars-server -odir /root/rpmbuild/BUILD/hedgewars-src-0.9.18/gameServer -hidir /root/rpmbuild/BUILD/hedgewars-src-0.9.18/gameServer -O2

This is with F-20 ghc, but F-19 glibc due to bug 985342, after fixing the build issue I was trying to debug "blind" (guessing the cause and firing of a build) the build did succeed on the buildsystem, so the likely cause for this is the ghc binaries containing (unconditionally executed) neon code.

A good place to start fixing this is to check the compile flags for ghc, end ensure they don't enable neon. If that is not the case it may be interesting to wait and see how bug 985342 plays out, as that is a similar issue.
Comment 1 Jens Petersen 2013-08-20 03:33:48 EDT
On ARM ghc uses the llvm backend (note not clang)
to generate machine code.  This might be an llvm bug perhaps.

Can you try running the above command with "ghc -v ..." or so?
That might give a better clue to where the exact problem happens.
Comment 2 Hans de Goede 2013-08-30 09:19:59 EDT
I tried adding the -v but all ghc says is: "Illegal instruction", actually even just doing "ghc --help" on the trimslice results in an Illegal instruction error. So it looks like ghc on arm is most likely build in such a way that it uses neon instructions which the nvidia tegra 2 in the trimslice does not have.
Comment 3 Jens Petersen 2013-09-01 04:42:01 EDT
I see, thanks for the info.

Is it not allowed to build packages with neon for Fedora ARM?
Comment 4 Hans de Goede 2013-09-02 02:46:35 EDT
(In reply to Jens Petersen from comment #3)
> I see, thanks for the info.
> 
> Is it not allowed to build packages with neon for Fedora ARM?

Not unconditionally, see ie this glibc bug: https://bugzilla.redhat.com/show_bug.cgi?id=985342 which was about a glibc bug causing it to use neon versions of memcpy, etc. on non neon machines. Fedora tries to support armv7 as baseline, and neon is optional on v7.

TL;DR: having the binaries use neon if they detect a neon capable cpu is fine, using neon unconditionally is not,
Comment 5 Fedora End Of Life 2013-09-16 12:28:24 EDT
This bug appears to have been reported against 'rawhide' during the Fedora 20 development cycle.
Changing version to '20'.

More information and reason for this action is here:
https://fedoraproject.org/wiki/BugZappers/HouseKeeping/Fedora20
Comment 6 Jens Petersen 2014-01-29 01:21:33 EST
Does llvm (or clang) work for you on your tegra2?
Comment 7 Hans de Goede 2014-01-29 05:27:37 EST
Unfortunately my trimslice is acting up. Once I get it to boot it seems fine, but the !@#% buggy uboot they ship wants to boot neither from mmc nor from the HD.

So I got it to boot once, and clang --version and llvm-as --version both worked fine. I wanted to also upgrade ghc to the latest and try ghc --version again, but my sdcard was too small and booting from hdd fails (as does booting the sdcard now too).

Adding Peter Robinson to the CC, hopefully he can help. Peter my trimslice is acting up, can you update / install ghc on yours and see if "ghc --version" in F-20 (or newer) still fails with an illegal instruction error ?
Comment 8 Peter Robinson 2014-01-29 06:03:34 EST
The trimslice (tegra2) doesn't support NEON, this indicates that the ghc build isn't using the distro CFLAGS which don't enable NEON by default. The means we usually support NEON is by run time detection with code fast paths for NEON
Comment 9 Jens Petersen 2014-01-29 20:16:26 EST
ghc is not written in C... :)

I asking if programs compiled with llvm/clang work on tegra2,
since ghc using llvm as its code generator backend on ARM.
Comment 10 Peter Robinson 2014-01-30 00:06:48 EST
I don't see what llvm has got to do with it. The fact is that for ARMv7 (any arm 32 bit) that NEON is optional so there should be options to disable it at compile time or at least make it run time detectable no matter what the compiler or language.
Comment 11 Jens Petersen 2014-01-30 04:52:59 EST
(In reply to Peter Robinson from comment #10)
> I don't see what llvm has got to do with it.

So I am asking if llvm does the right thing...
if it doesn't it is probably not ghc's fault. ;)
Comment 12 Jens Petersen 2014-01-30 05:06:31 EST
Anyway I will try to check the ghc llvm codegen code later to see
if there are any clues to this there and maybe ask upstream,
but my impression is that tegra2 is already getting a bit old
so I would not be surprised if there is not so much interest
or motivation to fix this if it is a ghc issue.

If someone could check the llvm side that would be helpful.
Comment 13 Jens Petersen 2014-07-14 03:30:10 EDT
(In reply to Hans de Goede from comment #7)
> Unfortunately my trimslice is acting up.
:
> So I got it to boot once, and clang --version and llvm-as --version both
> worked fine.

I guess we need to see how ghc is running llc...

I tried to build ghc-entropy on arm with verbose ghc output


=====
--- a/ghc-entropy.spec
+++ b/ghc-entropy.spec
@@ -44,6 +44,7 @@ This package provides the Haskell %{pkg_name} library development files.
 %patch1 -p1 -b .orig
 
 %build
+cabal_configure_extra_options="--ghc-option=-v"
 %ghc_lib_build
 
 
=====

and see (http://koji.fedoraproject.org/koji/taskinfo?taskID=7135691):

:
*** CodeGen:
*** LlVM CodeGen:
You are using a new version of LLVM that hasn't been tested yet!
We will try though...
*** LLVM Optimiser:
'/usr/bin/opt' '/tmp/ghc408_0/ghc408_0.ll' '-o' '/tmp/ghc408_0/ghc408_0.bc' '-O2' '--enable-tbaa=true'
*** LLVM Compiler:
'/usr/bin/llc' '-O3' '-relocation-model=static' '/tmp/ghc408_0/ghc408_0.bc' '-o' '/tmp/ghc408_0/ghc408_0.lm_s' '--enable-tbaa=true' '-mattr=+v7,+vfp3' '-float-abi=hard'
:

The "+vfp3" looks like the place where neon should be disabled perhaps.
Comment 14 Jens Petersen 2014-07-14 03:54:56 EDT
I suspect a change to ghc like this:

--- a/compiler/main/DriverPipeline.hs
+++ b/compiler/main/DriverPipeline.hs
@@ -1420,7 +1420,7 @@ runPhase (RealPhase LlvmLlc) input_fn dflags
         -- does not enable VFP by default. Let's do this manually here
         fpOpts = case platformArch (targetPlatform dflags) of 
                    ArchARM ARMv7 ext _ -> if (elem VFPv3 ext)
-                                      then ["-mattr=+v7,+vfp3"]
+                                      then ["-mattr=+v7,+vfp3,-neon"]
                                       else if (elem VFPv3D16 ext)
                                            then ["-mattr=+v7,+vfp3,+d16"]
                                            else []

would disable neon for all builds. I don't know if llvm
is able to generate runtime detection+code for neon.

How relevant is tegra2 and other SoC's without neon these days?

If I do a scratch build of ghc without neon is someone able
and willing to test it on a system with neon support?
Comment 15 Peter Robinson 2014-07-14 04:31:20 EDT
>                                        else if (elem VFPv3D16 ext)
>                                             then ["-mattr=+v7,+vfp3,+d16"]

Actually those options there are the ones we build Fedora for. 

> would disable neon for all builds. I don't know if llvm
> is able to generate runtime detection+code for neon.

Nor do I but it would be nice!

> How relevant is tegra2 and other SoC's without neon these days?

It's still the target we build for, there's a number of chips from Marvell that don't have NEON either. There's a number of projects that do run time detection of NEON.

> If I do a scratch build of ghc without neon is someone able
> and willing to test it on a system with neon support?

Yes. Just need the process to do so.
Comment 16 Jens Petersen 2014-07-14 22:52:07 EDT
(In reply to Peter Robinson from comment #15)
> >                                        else if (elem VFPv3D16 ext)
> >                                             then ["-mattr=+v7,+vfp3,+d16"]
> 
> Actually those options there are the ones we build Fedora for. 

Okay, I think Debian does too IIRC.

Does VFPv3D16 imply no Neon?
Comment 17 Peter Robinson 2014-07-15 03:01:04 EDT
> Does VFPv3D16 imply no Neon?

Not necessarily, it's just the lowest common denominator for a unit with VFPv3 unit and hence lowest common denominator of ARMv7 that we support. It indicates the VFPv3 unit has 16 double-precision registers, the other option is 32.
Comment 18 Jens Petersen 2014-07-15 03:23:35 EDT
Okay thanks.

What version of Fedora would you like me to build a test package for?
Comment 19 Peter Robinson 2014-07-15 05:10:45 EDT
either F-20 or F-21 is fine
Comment 20 Peter Robinson 2014-07-15 05:11:18 EDT
(In reply to Peter Robinson from comment #19)
> either F-20 or F-21 is fine

Actually make that F-20, the trimslice is still on F-20
Comment 21 Jens Petersen 2014-07-15 06:19:11 EDT
Okay I started this build in koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=7142529
Comment 22 Jens Petersen 2014-07-16 04:11:58 EDT
Okay that build failed due to a packaging issue...

Hopefully this one will finish:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7149663
Comment 24 Jens Petersen 2014-07-24 02:52:08 EDT
I think the scratch build might get gc'ed soon...
but if so give me a shout - I have downloaded it. ;)
Comment 25 Peter Robinson 2014-07-24 06:33:45 EDT
(In reply to Jens Petersen from comment #24)
> I think the scratch build might get gc'ed soon...
> but if so give me a shout - I have downloaded it. ;)

I have pulled them, I'll test tonight as the device has decided it doesn't wish to be accessed remotely for some reason ATM :-/
Comment 26 Peter Robinson 2014-07-25 03:23:47 EDT
[root@trimslice ~]# yum localinstall ghc*rpm
Loaded plugins: langpacks
Examining ghc-base-4.6.0.1-24.1.fc20.armv7hl.rpm: ghc-base-4.6.0.1-24.1.fc20.armv7hl
Marking ghc-base-4.6.0.1-24.1.fc20.armv7hl.rpm to be installed
Examining ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl.rpm: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
Marking ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl.rpm to be installed
Examining ghc-compiler-7.6.3-24.1.fc20.armv7hl.rpm: ghc-compiler-7.6.3-24.1.fc20.armv7hl
Marking ghc-compiler-7.6.3-24.1.fc20.armv7hl.rpm to be installed
Resolving Dependencies
--> Running transaction check
---> Package ghc-base.armv7hl 0:4.6.0.1-24.1.fc20 will be installed
---> Package ghc-binary-devel.armv7hl 0:0.5.1.1-24.1.fc20 will be installed
--> Processing Dependency: ghc-binary(armv7hl-32) = 0.5.1.1-24.1.fc20 for package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
updates/20/armhfp/metalink                                  |  25 kB  00:00
updates                                                     | 4.9 kB  00:00
updates-testing/20/armhfp/metalink                          |  22 kB  00:00
updates-testing                                             | 4.9 kB  00:00
(1/2): updates-testing/20/armhfp/primary_db                 | 1.6 MB  00:06
(2/2): updates/20/armhfp/primary_db                         | 9.0 MB  00:09
(1/4): updates-testing/20/armhfp/updateinfo                 | 210 kB  00:01
(2/4): updates-testing/20/armhfp/pkgtags                    | 880 kB  00:01
(3/4): updates/20/armhfp/updateinfo                         | 1.3 MB  00:03
(4/4): updates/20/armhfp/pkgtags                            | 880 kB  00:03
--> Processing Dependency: ghc-devel(array-0.4.0.1-72eb1caf42d7f1e9e960760f41ef98d0) for package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
--> Processing Dependency: ghc-devel(base-4.6.0.1-96bf6b6729ca53a5ac2cf45bb8b3cc3e) for package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
--> Processing Dependency: ghc-devel(bytestring-0.10.0.2-ea1d6622fb7aad447c7746744ecded40) for package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
--> Processing Dependency: ghc-devel(containers-0.5.0.0-3b8b869ec10d44736414ab5bea776319) for package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
---> Package ghc-compiler.armv7hl 0:7.6.3-24.1.fc20 will be installed
--> Processing Dependency: llvm >= 3.0 for package: ghc-compiler-7.6.3-24.1.fc20.armv7hl
--> Running transaction check
---> Package ghc-array-devel.armv7hl 0:0.4.0.1-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-array-devel-0.4.0.1-18.3.fc20.armv7hl
--> Processing Dependency: ghc-array(armv7hl-32) = 0.4.0.1-18.3.fc20 for package: ghc-array-devel-0.4.0.1-18.3.fc20.armv7hl
---> Package ghc-base-devel.armv7hl 0:4.6.0.1-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl
--> Processing Dependency: ghc-base(armv7hl-32) = 4.6.0.1-18.3.fc20 for package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl
--> Processing Dependency: libffi-devel(armv7hl-32) for package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl
--> Processing Dependency: gmp-devel(armv7hl-32) for package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl
---> Package ghc-binary-devel.armv7hl 0:0.5.1.1-24.1.fc20 will be installed
--> Processing Dependency: ghc-binary(armv7hl-32) = 0.5.1.1-24.1.fc20 for package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
---> Package ghc-bytestring-devel.armv7hl 0:0.10.0.2-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-bytestring-devel-0.10.0.2-18.3.fc20.armv7hl
--> Processing Dependency: ghc-bytestring(armv7hl-32) = 0.10.0.2-18.3.fc20 for package: ghc-bytestring-devel-0.10.0.2-18.3.fc20.armv7hl
--> Processing Dependency: ghc-devel(deepseq-1.3.0.1-aa1be128186a233c7290faf88620ffe5) for package: ghc-bytestring-devel-0.10.0.2-18.3.fc20.armv7hl
---> Package ghc-containers-devel.armv7hl 0:0.5.0.0-18.3.fc20 will be installed
--> Processing Dependency: ghc-containers(armv7hl-32) = 0.5.0.0-18.3.fc20 for package: ghc-containers-devel-0.5.0.0-18.3.fc20.armv7hl
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-containers-devel-0.5.0.0-18.3.fc20.armv7hl
---> Package llvm.armv7hl 0:3.4-6.fc20 will be installed
--> Running transaction check
---> Package ghc-array.armv7hl 0:0.4.0.1-18.3.fc20 will be installed
---> Package ghc-array-devel.armv7hl 0:0.4.0.1-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-array-devel-0.4.0.1-18.3.fc20.armv7hl
---> Package ghc-base-devel.armv7hl 0:4.6.0.1-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl
--> Processing Dependency: ghc-base(armv7hl-32) = 4.6.0.1-18.3.fc20 for package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl
---> Package ghc-binary-devel.armv7hl 0:0.5.1.1-24.1.fc20 will be installed
--> Processing Dependency: ghc-binary(armv7hl-32) = 0.5.1.1-24.1.fc20 for package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
---> Package ghc-bytestring.armv7hl 0:0.10.0.2-18.3.fc20 will be installed
---> Package ghc-bytestring-devel.armv7hl 0:0.10.0.2-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-bytestring-devel-0.10.0.2-18.3.fc20.armv7hl
---> Package ghc-containers.armv7hl 0:0.5.0.0-18.3.fc20 will be installed
---> Package ghc-containers-devel.armv7hl 0:0.5.0.0-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-containers-devel-0.5.0.0-18.3.fc20.armv7hl
---> Package ghc-deepseq-devel.armv7hl 0:1.3.0.1-18.3.fc20 will be installed
--> Processing Dependency: ghc-deepseq(armv7hl-32) = 1.3.0.1-18.3.fc20 for package: ghc-deepseq-devel-1.3.0.1-18.3.fc20.armv7hl
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-deepseq-devel-1.3.0.1-18.3.fc20.armv7hl
---> Package gmp-devel.armv7hl 1:5.1.2-2.fc20 will be installed
---> Package libffi-devel.armv7hl 0:3.0.13-5.fc20 will be installed
--> Running transaction check
---> Package ghc-array-devel.armv7hl 0:0.4.0.1-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-array-devel-0.4.0.1-18.3.fc20.armv7hl
---> Package ghc-base-devel.armv7hl 0:4.6.0.1-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl
--> Processing Dependency: ghc-base(armv7hl-32) = 4.6.0.1-18.3.fc20 for package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl
---> Package ghc-binary-devel.armv7hl 0:0.5.1.1-24.1.fc20 will be installed
--> Processing Dependency: ghc-binary(armv7hl-32) = 0.5.1.1-24.1.fc20 for package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl
---> Package ghc-bytestring-devel.armv7hl 0:0.10.0.2-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-bytestring-devel-0.10.0.2-18.3.fc20.armv7hl
---> Package ghc-containers-devel.armv7hl 0:0.5.0.0-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-containers-devel-0.5.0.0-18.3.fc20.armv7hl
---> Package ghc-deepseq.armv7hl 0:1.3.0.1-18.3.fc20 will be installed
---> Package ghc-deepseq-devel.armv7hl 0:1.3.0.1-18.3.fc20 will be installed
--> Processing Dependency: ghc-compiler = 7.6.3-18.3.fc20 for package: ghc-deepseq-devel-1.3.0.1-18.3.fc20.armv7hl
--> Finished Dependency Resolution
Error: Package: ghc-bytestring-devel-0.10.0.2-18.3.fc20.armv7hl (updates)
           Requires: ghc-compiler = 7.6.3-18.3.fc20
           Available: ghc-compiler-7.6.3-18.2.fc20.armv7hl (fedora)
               ghc-compiler = 7.6.3-18.2.fc20
           Available: ghc-compiler-7.6.3-18.3.fc20.armv7hl (updates)
               ghc-compiler = 7.6.3-18.3.fc20
Error: Package: ghc-array-devel-0.4.0.1-18.3.fc20.armv7hl (updates)
           Requires: ghc-compiler = 7.6.3-18.3.fc20
           Available: ghc-compiler-7.6.3-18.2.fc20.armv7hl (fedora)
               ghc-compiler = 7.6.3-18.2.fc20
           Available: ghc-compiler-7.6.3-18.3.fc20.armv7hl (updates)
               ghc-compiler = 7.6.3-18.3.fc20
Error: Package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl (updates)
           Requires: ghc-compiler = 7.6.3-18.3.fc20
           Available: ghc-compiler-7.6.3-18.2.fc20.armv7hl (fedora)
               ghc-compiler = 7.6.3-18.2.fc20
           Available: ghc-compiler-7.6.3-18.3.fc20.armv7hl (updates)
               ghc-compiler = 7.6.3-18.3.fc20
Error: Package: ghc-base-devel-4.6.0.1-18.3.fc20.armv7hl (updates)
           Requires: ghc-base(armv7hl-32) = 4.6.0.1-18.3.fc20
           Available: ghc-base-4.6.0.1-18.2.fc20.armv7hl (fedora)
               ghc-base(armv7hl-32) = 4.6.0.1-18.2.fc20
           Available: ghc-base-4.6.0.1-18.3.fc20.armv7hl (updates)
               ghc-base(armv7hl-32) = 4.6.0.1-18.3.fc20
Error: Package: ghc-containers-devel-0.5.0.0-18.3.fc20.armv7hl (updates)
           Requires: ghc-compiler = 7.6.3-18.3.fc20
           Available: ghc-compiler-7.6.3-18.2.fc20.armv7hl (fedora)
               ghc-compiler = 7.6.3-18.2.fc20
           Available: ghc-compiler-7.6.3-18.3.fc20.armv7hl (updates)
               ghc-compiler = 7.6.3-18.3.fc20
Error: Package: ghc-deepseq-devel-1.3.0.1-18.3.fc20.armv7hl (updates)
           Requires: ghc-compiler = 7.6.3-18.3.fc20
           Available: ghc-compiler-7.6.3-18.2.fc20.armv7hl (fedora)
               ghc-compiler = 7.6.3-18.2.fc20
           Available: ghc-compiler-7.6.3-18.3.fc20.armv7hl (updates)
               ghc-compiler = 7.6.3-18.3.fc20
Error: Package: ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl (/ghc-binary-devel-0.5.1.1-24.1.fc20.armv7hl)
           Requires: ghc-binary(armv7hl-32) = 0.5.1.1-24.1.fc20
           Available: ghc-binary-0.5.1.1-18.2.fc20.armv7hl (fedora)
               ghc-binary(armv7hl-32) = 0.5.1.1-18.2.fc20
           Available: ghc-binary-0.5.1.1-18.3.fc20.armv7hl (updates)
               ghc-binary(armv7hl-32) = 0.5.1.1-18.3.fc20
 You could try using --skip-broken to work around the problem
 You could try running: rpm -Va --nofiles --nodigest
Comment 27 Jens Petersen 2014-07-25 05:24:57 EDT
May I suggest:

# yum remove ghc-*
# rpm -ivh ghc-compiler-* ghc-base-*
$ ghc --version
Comment 28 Peter Robinson 2014-07-25 05:42:01 EDT
> https://kojipkgs.fedoraproject.org//work/tasks/9663/7149663/ghc-compiler-7.6.
> 3-24.1.fc20.armv7hl.rpm
> https://kojipkgs.fedoraproject.org//work/tasks/9663/7149663/ghc-base-4.6.0.1-
> 24.1.fc20.armv7hl.rpm
> https://kojipkgs.fedoraproject.org//work/tasks/9663/7149663/ghc-binary-devel-
> 0.5.1.1-24.1.fc20.armv7hl.rpm

Needed a few more of the packages from the build
Comment 29 Peter Robinson 2014-07-25 05:49:09 EDT
[root@trimslice ~]# ghc --version
The Glorious Glasgow Haskell Compilation System, version 7.6.3
[root@trimslice ~]# ghc --help
Usage:

    ghc [command-line-options-and-input-files]

To compile and link a complete Haskell program, run the compiler like
so:

    ghc --make Main

where the module Main is in a file named Main.hs (or Main.lhs) in the
current directory.  The other modules in the program will be located
and compiled automatically, and the linked program will be placed in
the file `a.out' (or `Main.exe' on Windows).

Alternatively, ghc can be used to compile files individually.  Each
input file is guided through (some of the) possible phases of a
compilation:

    - unlit:    extract code from a "literate program"
    - hscpp:    run code through the C pre-processor (if -cpp flag given)
    - hsc:      run the Haskell compiler proper
    - gcc:      run the C compiler (if compiling via C)
    - as:       run the assembler
    - ld:       run the linker

For each input file, the phase to START with is determined by the
file's suffix:

    - .lhs      literate Haskell                 unlit
    - .hs       plain Haskell                    ghc
    - .hc       C from the Haskell compiler      gcc
    - .c        C not from the Haskell compiler  gcc
    - .s        assembly language                as
    - other     passed directly to the linker    ld

The phase at which to STOP processing is determined by a command-line
option:

    -E          stop after generating preprocessed, de-litted Haskell
                     (used in conjunction with -cpp)
    -C          stop after generating C (.hc output)
    -S          stop after generating assembler (.s output)
    -c          stop after generating object files (.o output)

Other commonly-used options are:

    -v[n]           Control verbosity (n is 0--5, normal verbosity level is 1,
                      -v alone is equivalent to -v3)

    -fglasgow-exts  Allow Glasgow extensions (unboxed types, etc.)

    -O              An `optimising' package of compiler flags, for faster code

    -prof           Compile for cost-centre profiling
                     (add -auto-all for automagic cost-centres on all
                      top-level functions)

    -H14m           Increase compiler's heap size (might make compilation
                    faster, especially on large source files).

    -M              Output Makefile rules recording the
                    dependencies of a list of Haskell files.

Given the above, here are some TYPICAL invocations of ghc:

    # compile a Haskell module to a .o file, optimising:
    % ghc -c -O Foo.hs
    # link three .o files into an executable called "test":
    % ghc -o test Foo.o Bar.o Baz.o
    # compile a Haskell module to C (a .hc file), using a bigger heap:
    % ghc -C -H16m Foo.hs
    # compile Haskell-produced C (.hc) to assembly language:
    % ghc -S Foo.hc 

The User's Guide has more information about GHC's *many* options.  An
online copy can be found here:

   http://haskell.org/haskellwiki/GHC

------------------------------------------------------------------------
[root@trimslice ~]# ghc-pkg list
/usr/lib/ghc-7.6.3/package.conf.d
   array-0.4.0.1
   base-4.6.0.1
   binary-0.5.1.1   
   bytestring-0.10.0.2
   containers-0.5.0.0
   deepseq-1.3.0.1  
   ghc-prim-0.3.0.0 
   integer-gmp-0.5.0.0
   rts-1.0
[root@trimslice ~]#
Comment 30 Jens Petersen 2014-07-25 06:02:49 EDT
Great seems like it is working better.

You could try a simple helloworld:

$ cat > hello.hs
main = putStrLn "hi!"
$ ghc hello.hs
$ ./hello

If it is looks good and doesn't change the library ABI hashes
then I guess this could be made a Fedora Update.

But I am wondering on the impact of this bug to rest of
the Haskell packages. Maybe everything needs to be rebuilt
to work without Neon, which sounds like for rawhide?
Comment 31 Peter Robinson 2014-07-25 06:12:23 EDT
[root@trimslice ~]# ghc hello.hs
[1 of 1] Compiling Main             ( hello.hs, hello.o )
You are using a new version of LLVM that hasn't been tested yet!
We will try though...
Linking hello ...
[root@trimslice ~]# ./hello 
hi!
[root@trimslice ~]#
Comment 32 Jens Petersen 2014-07-25 06:16:25 EDT
Cool

Also could you attach the output of:

$ rpm -qa --provides ghc\*devel | grep ^ghc-devel\( | sort

That would save time when comparing the ABI hashes.
Comment 33 Peter Robinson 2014-07-25 06:17:25 EDT
# rpm -qa --provides ghc\*devel | grep ^ghc-devel\( | sort
ghc-devel(array-0.4.0.1-72eb1caf42d7f1e9e960760f41ef98d0)
ghc-devel(base-4.6.0.1-96bf6b6729ca53a5ac2cf45bb8b3cc3e)
ghc-devel(binary-0.5.1.1-070d1a748b38a86cefd3ecfe250c286a)
ghc-devel(bytestring-0.10.0.2-ea1d6622fb7aad447c7746744ecded40)
ghc-devel(containers-0.5.0.0-3b8b869ec10d44736414ab5bea776319)
ghc-devel(deepseq-1.3.0.1-aa1be128186a233c7290faf88620ffe5)
ghc-devel(ghc-prim-0.3.0.0-00db43fcd2f6e2a73243bdb496b765e0)
ghc-devel(integer-gmp-0.5.0.0-4093e6ff1e8ebdba04ec892df9ac108f)
Comment 34 Jens Petersen 2014-07-25 07:12:58 EDT
Okay thanks - I also verified locally that the provided hashes are unchanged so this changes looks safe for Fedora Updates.

Peter tested the fedora happy and cabal-install packages
and later gives "Illegal instruction", so would need
a rebuild to work on non-neon.
Comment 35 Jens Petersen 2014-07-25 07:25:21 EDT
Should get fixed in ghc-7.6.3-25.fc22.
Comment 36 Jens Petersen 2014-08-02 08:36:32 EDT
Also built for f21

http://koji.fedoraproject.org/koji/buildinfo?buildID=549877
Comment 37 Jens Petersen 2014-08-02 08:37:05 EDT
There will be a backport later for f20.
Comment 38 Fedora End Of Life 2015-05-29 05:18:17 EDT
This message is a reminder that Fedora 20 is nearing its end of life.
Approximately 4 (four) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 20. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '20'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 20 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.
Comment 39 Fedora End Of Life 2015-06-29 21:18:38 EDT
Fedora 20 changed to end-of-life (EOL) status on 2015-06-23. Fedora 20 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

Note You need to log in before you can comment on or make changes to this bug.