Replying to [comment:13 George]:
Trying to find out if MacOS on 8.6.1 is one of the platforms where
#13624: loadObj() does not respect alignment -------------------------------------+------------------------------------- Reporter: tmcdonell | Owner: (none) Type: bug | Status: new Priority: high | Milestone: 8.8.1 Component: Runtime System | Version: 8.0.1 (Linker) | Keywords: linker, Resolution: | newcomer Operating System: Unknown/Multiple | Architecture: | Unknown/Multiple Type of failure: Runtime crash | Test Case: Blocked By: | Blocking: 8949 Related Tickets: | Differential Rev(s): Wiki Page: | -------------------------------------+------------------------------------- Comment (by George): Sorry, when I first read the bug I realized that I wouldn't be able to reproduce it on my machine but was interested in seeing it fixed as I plan on getting a new machine in the near future. When I saw comment 11 I forgot all that and tried to reproduce. Sorry for wasting your time but thanks for taking the time to answer. Replying to [comment:14 tmcdonell]: this needs to be fixed but I can't reproduce:
The problem still exists. I verified this just now; macOS 10.13.6
{{{ $ ghc --version The Glorious Glasgow Haskell Compilation System, version 8.6.1 $ ghc --print-project-git-commit-id 0d2cdec78471728a0f2c487581d36acda68bb941 }}}
I don't understand why lldb is needed to reproduce this in any case.
Obviously, `lldb` is not required. Just run the executable and watch it
segfault. The point of using a debugger (any would suffice) is to demonstrate which instruction is causing the problem, which for this issue is important to understand.
In particular how it changes the array size to 32, could you explain?
In the description it says "The #define N on line 7 will change the size of the array...For 32 elements or larger (i.e. entering the core loop) the program will (almost certainly) segfault. " I trying changing N to 32 but then running build.sh a.out just worked, no segfault.
If you read the description, you will see that the core loop is a 8-way
vectorised and 4-way unrolled; i.e. 32-elements per trip. For any remainder it backs out to a single element per loop. Thus, to activate the code path which exhibits the problem, you require at least 32 elements.
The description also says "For a CPU with AVX instructions (sandy bridge
or later) you should get the following". Since you are running an original corei7 (nephalem) and don't have AVX instructions, this exact example obviously won't trigger for you. If you checked the objdump output as suggested, you would also have seen this. -- Ticket URL: http://ghc.haskell.org/trac/ghc/ticket/13624#comment:15 GHC http://www.haskell.org/ghc/ The Glasgow Haskell Compiler