995419 – [F20] [neon] ghc throws an illegal instruction error when compiling on nvidia tegra2

Note: This is a public test instance of Red Hat Bugzilla. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback at bugzilla.redhat.com.

Bug 995419 - [F20] [neon] ghc throws an illegal instruction error when compiling on nvidia tegra2

Summary: [F20] [neon] ghc throws an illegal instruction error when compiling on nvidia...

Keywords:
Status:	CLOSED EOL
Alias:	None
Product:	Fedora
Classification:	Fedora
Component:	ghc
Sub Component:
Version:	20
Hardware:	arm
OS:	Unspecified
Priority:	unspecified
Severity:	unspecified
Target Milestone:	---
Assignee:	Jens Petersen
QA Contact:	Fedora Extras Quality Assurance
Docs Contact:
URL:
Whiteboard:
Depends On:
Blocks:	ARMTracker
TreeView+	depends on / blocked

Reported:	2013-08-09 09:53 UTC by Hans de Goede
Modified:	2015-06-30 01:18 UTC (History)
CC List:	5 users (show)
Fixed In Version:	ghc-7.6.3-25.fc21
Doc Type:	Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed:	2015-06-30 01:18:38 UTC
Type:	Bug
Embargoed:
Dependent Products:

Attachments	(Terms of Use)

Description Hans de Goede 2013-08-09 09:53:13 UTC

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 07:33:48 UTC

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 13:19:59 UTC

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 08:42:01 UTC

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 06:46:35 UTC

(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 16:28:24 UTC

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 06:21:33 UTC

Does llvm (or clang) work for you on your tegra2?

Comment 7 Hans de Goede 2014-01-29 10:27:37 UTC

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 11:03:34 UTC

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-30 01:16:26 UTC

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 05:06:48 UTC

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 09:52:59 UTC

(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 10:06:31 UTC

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 07:30:10 UTC

(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 07:54:56 UTC

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 08:31:20 UTC

>                                        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-15 02:52:07 UTC

(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 07:01:04 UTC

> 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 07:23:35 UTC

Okay thanks.

What version of Fedora would you like me to build a test package for?

Comment 19 Peter Robinson 2014-07-15 09:10:45 UTC

either F-20 or F-21 is fine

Comment 20 Peter Robinson 2014-07-15 09:11:18 UTC

(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 10:19:11 UTC

Okay I started this build in koji:

http://koji.fedoraproject.org/koji/taskinfo?taskID=7142529

Comment 22 Jens Petersen 2014-07-16 08:11:58 UTC

Okay that build failed due to a packaging issue...

Hopefully this one will finish:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7149663

Comment 23 Jens Petersen 2014-07-17 00:47:33 UTC

(In reply to Jens Petersen from comment #22)
> http://koji.fedoraproject.org/koji/taskinfo?taskID=7149663

Yes, it finished

I think it should be sufficient just to test:

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

and try running "ghc --help" or "ghc-pkg list".

Comment 24 Jens Petersen 2014-07-24 06:52:08 UTC

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 10:33:45 UTC

(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 07:23:47 UTC

[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 09:24:57 UTC

May I suggest:

# yum remove ghc-*
# rpm -ivh ghc-compiler-* ghc-base-*
$ ghc --version

Comment 28 Peter Robinson 2014-07-25 09:42:01 UTC

> 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 09:49:09 UTC

[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 10:02:49 UTC

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 10:12:23 UTC

[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 10:16:25 UTC

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 10:17:25 UTC

# 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 11:12:58 UTC

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 11:25:21 UTC

Should get fixed in ghc-7.6.3-25.fc22.

Comment 36 Jens Petersen 2014-08-02 12:36:32 UTC

Also built for f21

http://koji.fedoraproject.org/koji/buildinfo?buildID=549877

Comment 37 Jens Petersen 2014-08-02 12:37:05 UTC

There will be a backport later for f20.

Comment 38 Fedora End Of Life 2015-05-29 09:18:17 UTC

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-30 01:18:38 UTC

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.