ghc-cryptonite LTO failure on s390x

[Elliott Sales de Andrade]

Hi,

The build for ghc-cryptonite failed in the mass rebuild [1] and a
later rebuild by me [2], but only on s390x. The failure appears to be
LTO related. This doesn't appear to affect many other Haskell
packages. (I've found one seemingly-related failure in
ghc-haskell-src-exts [3].) Since it's Haskell, I'm using the standard
macros that should pass consistent flags, etc., so I'm not sure what
more information I can provide.

What happens is that ld.gold warns about mixed LTO/non-LTO:

[  1 of 131] Compiling Crypto.Cipher.DES.Primitive (
Crypto/Cipher/DES/Primitive.hs,
dist/build/Crypto/Cipher/DES/Primitive.p_o )
/usr/bin/ld.gold: warning: incremental linking of LTO and non-LTO
objects; using -flinker-output=nolto-rel which will bypass whole
program optimization

and then errors out because of many LTO mismatches like:

/tmp/ghc794663_0/ghc_19.c:11:19: error:
     warning: type of
‘cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc’
does not match original declaration [-Wlto-type-mismatch]
       11 | extern CostCentre
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[];
          |                   ^
   |
11 | extern CostCentre
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[];
   |                   ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
     note: type ‘StgWord’ should match type ‘struct CostCentre’
       44 | StgWord
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
          |         ^
   |
44 | StgWord
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
   |         ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
     note:
‘cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc’
was previously declared here
   |
44 | StgWord
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
   |         ^
/tmp/ghc794663_0/ghc_18.hc:44:9: error:
     note: code may be misoptimized unless ‘-fno-strict-aliasing’ is used
   |
44 | StgWord
cryptonitezm0zi26zmIKFu0XykBrR53imeIPM2Uw_CryptoziCipherziDESziPrimitive_CAFs_cc[]__attribute__((aligned(8)))=
{
   |         ^

followed by inlining failures:

/usr/include/bits/string_fortified.h: In function ‘fill_segment’:
/usr/include/bits/string_fortified.h:59:1: error:
     error: inlining failed in call to ‘always_inline’ ‘memset’:
function body can be overwritten at link time
       59 | __NTH (memset (void *__dest, int __ch, size_t __len))
          | ^
   |
59 | __NTH (memset (void *__dest, int __ch, size_t __len))
   | ^


[1] https://koji.fedoraproject.org/koji/taskinfo?taskID=47957210
[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=48408236
[3] https://koji.fedoraproject.org/koji/taskinfo?taskID=48322376

-- 
Elliott

[Jens-Ulrik Petersen]

Hi Elliot, thanks for the heads up:

On Mon, Aug 3, 2020 at 8:12 AM Elliott Sales de Andrade <
quantum.analyst(a)gmail.com&gt; wrote:

>  The build for ghc-cryptonite failed in the mass rebuild [1] and a
>  later rebuild by me [2], but only on s390x. The failure appears to be
>  LTO related. This doesn't appear to affect many other Haskell
>  packages. (I've found one seemingly-related failure in
>  ghc-haskell-src-exts [3].) Since it's Haskell, I'm using the standard
>  macros that should pass consistent flags, etc., so I'm not sure what
>  more information I can provide.
>
>  What happens is that ld.gold warns about mixed LTO/non-LTO:
>  
Yeah this seems to be affecting profiling libraries (ghc-*-prof.s390x).

[2] https://koji.fedoraproject.org/koji/taskinfo?taskID=48408236


I opened https://bugzilla.redhat.com/show_bug.cgi?id=1863601 using the
output from this build.

For now I am going to workaround this by disabling LTO for s390x Haskell
packages in ghc-rpm-macros.
I think when we move to ghc-8.10 for F34 we can hopefully switch s390x to
llvm10 which should make this problem go away.

Thanks, Jens