[Bug 995419] New: ghc throws an illegal instruction error when compiling on nvidia tegra2
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Bug ID: 995419 Summary: ghc throws an illegal instruction error when compiling on nvidia tegra2 Product: Fedora Version: rawhide Component: ghc Assignee: petersen@redhat.com Reporter: hdegoede@redhat.com QA Contact: extras-qa@fedoraproject.org CC: bos@serpentine.com, haskell-devel@lists.fedoraproject.org, petersen@redhat.com
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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Hans de Goede hdegoede@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Blocks| |245418 (ARMTracker)
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #1 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |hdegoede@redhat.com Flags| |needinfo?(hdegoede@redhat.c | |om)
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Hans de Goede hdegoede@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Flags|needinfo?(hdegoede@redhat.c | |om) |
--- Comment #2 from Hans de Goede hdegoede@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #3 from Jens Petersen petersen@redhat.com --- I see, thanks for the info.
Is it not allowed to build packages with neon for Fedora ARM?
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #4 from Hans de Goede hdegoede@redhat.com --- (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,
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Hardware|Unspecified |arm Summary|ghc throws an illegal |[neon] ghc throws an |instruction error when |illegal instruction error |compiling on nvidia tegra2 |when compiling on nvidia | |tegra2
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #6 from Jens Petersen petersen@redhat.com --- Does llvm (or clang) work for you on your tegra2?
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Hans de Goede hdegoede@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- CC| |pbrobinson@gmail.com
--- Comment #7 from Hans de Goede hdegoede@redhat.com --- 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 ?
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #8 from Peter Robinson pbrobinson@gmail.com --- 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
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #9 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #10 from Peter Robinson pbrobinson@gmail.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #11 from Jens Petersen petersen@redhat.com --- (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. ;)
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #12 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #13 from Jens Petersen petersen@redhat.com --- (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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|NEW |ASSIGNED
--- Comment #14 from Jens Petersen petersen@redhat.com --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #15 from Peter Robinson pbrobinson@gmail.com ---
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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #16 from Jens Petersen petersen@redhat.com --- (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?
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #17 from Peter Robinson pbrobinson@gmail.com ---
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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #18 from Jens Petersen petersen@redhat.com --- Okay thanks.
What version of Fedora would you like me to build a test package for?
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #19 from Peter Robinson pbrobinson@gmail.com --- either F-20 or F-21 is fine
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #20 from Peter Robinson pbrobinson@gmail.com --- (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
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #21 from Jens Petersen petersen@redhat.com --- Okay I started this build in koji:
http://koji.fedoraproject.org/koji/taskinfo?taskID=7142529
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #22 from Jens Petersen petersen@redhat.com --- Okay that build failed due to a packaging issue...
Hopefully this one will finish: http://koji.fedoraproject.org/koji/taskinfo?taskID=7149663
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #23 from Jens Petersen petersen@redhat.com --- (In reply to Jens Petersen from comment #22)
Yes, it finished
I think it should be sufficient just to test:
https://kojipkgs.fedoraproject.org//work/tasks/9663/7149663/ghc-compiler-7.6... https://kojipkgs.fedoraproject.org//work/tasks/9663/7149663/ghc-base-4.6.0.1... https://kojipkgs.fedoraproject.org//work/tasks/9663/7149663/ghc-binary-devel...
and try running "ghc --help" or "ghc-pkg list".
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #24 from Jens Petersen petersen@redhat.com --- I think the scratch build might get gc'ed soon... but if so give me a shout - I have downloaded it. ;)
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #25 from Peter Robinson pbrobinson@gmail.com --- (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 :-/
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #26 from Peter Robinson pbrobinson@gmail.com --- [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
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #27 from Jens Petersen petersen@redhat.com --- May I suggest:
# yum remove ghc-* # rpm -ivh ghc-compiler-* ghc-base-* $ ghc --version
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #28 from Peter Robinson pbrobinson@gmail.com ---
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
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #29 from Peter Robinson pbrobinson@gmail.com --- [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 ~]#
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #30 from Jens Petersen petersen@redhat.com --- 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?
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #31 from Peter Robinson pbrobinson@gmail.com --- [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 ~]#
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #32 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #33 from Peter Robinson pbrobinson@gmail.com --- # 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)
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #34 from Jens Petersen petersen@redhat.com --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|ASSIGNED |MODIFIED
--- Comment #35 from Jens Petersen petersen@redhat.com --- Should get fixed in ghc-7.6.3-25.fc22.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|MODIFIED |POST
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #36 from Jens Petersen petersen@redhat.com --- Also built for f21
http://koji.fedoraproject.org/koji/buildinfo?buildID=549877
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #37 from Jens Petersen petersen@redhat.com --- There will be a backport later for f20.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Fixed In Version| |ghc-7.6.3-25.fc21
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[neon] ghc throws an |[neon] [F20] ghc throws an |illegal instruction error |illegal instruction error |when compiling on nvidia |when compiling on nvidia |tegra2 |tegra2
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Jens Petersen petersen@redhat.com changed:
What |Removed |Added ---------------------------------------------------------------------------- Summary|[neon] [F20] ghc throws an |[F20] [neon] ghc throws an |illegal instruction error |illegal instruction error |when compiling on nvidia |when compiling on nvidia |tegra2 |tegra2
https://bugzilla.redhat.com/show_bug.cgi?id=995419
--- Comment #38 from Fedora End Of Life endoflife@fedoraproject.org --- 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.
https://bugzilla.redhat.com/show_bug.cgi?id=995419
Fedora End Of Life endoflife@fedoraproject.org changed:
What |Removed |Added ---------------------------------------------------------------------------- Status|POST |CLOSED Resolution|--- |EOL Last Closed| |2015-06-29 21:18:38
--- Comment #39 from Fedora End Of Life endoflife@fedoraproject.org --- 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.
haskell-devel@lists.fedoraproject.org
-
Red Hat Bugzilla