[GHC] #13624: loadObj() does not respect alignment

[GHC]

#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]:
 > Replying to [comment:13 George]:
 > > Trying to find out if MacOS on 8.6.1 is one of the platforms where
 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