Opened 3 years ago

Closed 3 years ago

Last modified 3 years ago

#5486 closed bug (fixed)

LLVM can't compile HsOpenSSL

Reported by: dterei Owned by: dterei
Priority: normal Milestone: 7.6.1
Component: Compiler (LLVM) Version: 7.2.1
Keywords: Cc:
Operating System: Unknown/Multiple Architecture: Unknown/Multiple
Type of failure: Compile-time crash Test Case:
Blocked By: Blocking:
Related Tickets: #5681 Differential Revisions:

Description (last modified by dterei)

> ...
> [10 of 31] Compiling OpenSSL.BIO      ( dist/build/OpenSSL/IO.hs, dist/build/OpenSSL/BIO.o )
> [11 of 31] Compiling OpenSSL.Random   ( dist/build/OpenSSL/Random.hs, dist/build/OpenSSL/Random.o )
> [12 of 31] Compiling OpenSSL.BN       ( dist/build/OpenSSL/BN.hs, dist/build/OpenSSL/BN.o )
>
> OpenSSL/BN.hsc:46:1:
>    Warning: In the use of `unsafePerformIO'
>             (imported from Foreign):
>             Deprecated: "Use System.IO.Unsafe.unsafePerformIO instead; This function will be removed in the next release"
> [13 of 31] Compiling OpenSSL.DSA      ( dist/build/OpenSSL/DSA.hs, dist/build/OpenSSL/DSA.o )
>
> OpenSSL/DSA.hsc:37:1:
>    Warning: In the use of `unsafePerformIO'
>             (imported from Foreign):
>             Deprecated: "Use System.IO.Unsafe.unsafePerformIO instead; This function will be removed in the next release"
> opt: /tmp/ghc18807_0/ghc18807_0.ll:20051:1: error: instructions returning void cannot have a name
> %lnPRJ = call ccc void (i8*,i8*,i32)* @memcpy( i8* %lnPRF, i8* %lnPRH, i32 %lnPRI ) nounwind
> ^

Also seems to be some mangler problems.

Change History (8)

comment:1 Changed 3 years ago by dterei

  • Description modified (diff)

comment:2 Changed 3 years ago by dterei

Bug report from Peter Gammie <peteg42@…>, thanks!

comment:3 Changed 3 years ago by dterei

OK, no mangler issues so just the call issue.

comment:4 Changed 3 years ago by dterei

OK so its one of the annoying type mismatch issues where LLVM uses a different intrinsic type for functions then the standard C library ones.

memcpy for libc is:

void *memcpy(void *dst, const void *src, size_t n);

memcpy for llvm is:

void memcpy(i8 *dst, i8 *src, i64 n);

Actually. No this isn't the problem as the code in question isn't using the LLVM intrinsic. I should check how the LLVM intrinsic is handled as the above may be an issue.

The problem is the cmm code generated uses two different types for memcpy.

(_s3::I64, PtrHint) = foreign "ccall" memcpy(...)

and

foreign "ccall" memcpy(...)

So sometimes cmm treats it as (void) other times as (void *). Probably better to fix up the Cmm code gen to be consistent and leave LLVM as its really doing the right thing.

comment:5 Changed 3 years ago by igloo

  • Milestone set to 7.6.1

comment:6 Changed 3 years ago by dterei

Bug #5681 is a duplicate of this.

comment:7 Changed 3 years ago by dterei

  • Resolution set to fixed
  • Status changed from new to closed

comment:8 Changed 3 years ago by dterei

Note: See TracTickets for help on using tickets.