#define NULL ((void *)0)
typedef unsigned long size_t; // Customize by platform.
typedef long intptr_t;
typedef unsigned long uintptr_t;
typedef long scalar_t__; // Either arithmetic or pointer type.
/* By default, we understand bool (as a convenience). */
typedef int bool;
#define false 0
#define true 1

/* Forward declarations */

/* Type definitions */

/* Variables and functions */
char *BZ2_bzlibVersion();
int /*<<< orphan*/ exit(int);
int /*<<< orphan*/ fprintf(int /*<<< orphan*/, char *, ...);
int /*<<< orphan*/ stderr;
void BZ2_bz__AssertH__fail(int errcode) {
  fprintf(stderr,
          "\n\nbzip2/libbzip2: internal error number %d.\n"
          "This is a bug in bzip2/libbzip2, %s.\n"
          "Please report it to me at: jseward@acm.org.  If this happened\n"
          "when you were using some program which uses libbzip2 as a\n"
          "component, you should also report this bug to the author(s)\n"
          "of that program.  Please make an effort to report this bug;\n"
          "timely and accurate bug reports eventually lead to higher\n"
          "quality software.  Thanks.  Julian Seward, 30 December 2001.\n\n",
          errcode, BZ2_bzlibVersion());
  if (errcode == 1007) {
    fprintf(
        stderr,
        "\n*** A special note about internal error number 1007 ***\n"
        "\n"
        "Experience suggests that a common cause of i.e. 1007\n"
        "is unreliable memory or other hardware.  The 1007 assertion\n"
        "just happens to cross-check the results of huge numbers of\n"
        "memory reads/writes, and so acts (unintendedly) as a stress\n"
        "test of your memory system.\n"
        "\n"
        "I suggest the following: try compressing the file again,\n"
        "possibly monitoring progress in detail with the -vv flag.\n"
        "\n"
        "* If the error cannot be reproduced, and/or happens at different\n"
        "  points in compression, you may have a flaky memory system.\n"
        "  Try a memory-test program.  I have used Memtest86\n"
        "  (www.memtest86.com).  At the time of writing it is free (GPLd).\n"
        "  Memtest86 tests memory much more thorougly than your BIOSs\n"
        "  power-on test, and may find failures that the BIOS doesn't.\n"
        "\n"
        "* If the error can be repeatably reproduced, this is a bug in\n"
        "  bzip2, and I would very much like to hear about it.  Please\n"
        "  let me know, and, ideally, save a copy of the file causing the\n"
        "  problem -- without which I will be unable to investigate it.\n"
        "\n");
  }
  exit(3);
}


x86 assembly (clang, -O0):
<BZ2_bz__AssertH__fail>:
push   %rbp
mov    %rsp,%rbp
sub    $0x10,%rsp
mov    %edi,-0x4(%rbp)
mov    0x2e9e(%rip),%rax
mov    (%rax),%eax
mov    %eax,-0xc(%rbp)
mov    -0x4(%rbp),%eax
mov    %eax,-0x8(%rbp)
mov    $0x0,%al
call   1030 <BZ2_bzlibVersion@plt>
mov    -0xc(%rbp),%edi
mov    -0x8(%rbp),%edx
mov    %rax,%rcx
lea    0xe9c(%rip),%rsi
mov    $0x0,%al
call   1040 <fprintf@plt>
cmpl   $0x3ef,-0x4(%rbp)
jne    118f <BZ2_bz__AssertH__fail+0x5f>
mov    0x2e61(%rip),%rax
mov    (%rax),%edi
lea    0x1032(%rip),%rsi
mov    $0x0,%al
call   1040 <fprintf@plt>
mov    $0x3,%edi
call   1050 <exit@plt>

x86 assembly (clang, -O2):
<BZ2_bz__AssertH__fail>:
push   %rbp
push   %r14
push   %rbx
mov    %edi,%ebx
mov    0x2ea3(%rip),%r14
mov    (%r14),%ebp
xor    %eax,%eax
call   1030 <BZ2_bzlibVersion@plt>
lea    0xeb2(%rip),%rsi
mov    %ebp,%edi
mov    %ebx,%edx
mov    %rax,%rcx
xor    %eax,%eax
call   1040 <fprintf@plt>
cmp    $0x3ef,%ebx
jne    1175 <BZ2_bz__AssertH__fail+0x45>
mov    (%r14),%edi
lea    0x104c(%rip),%rsi
xor    %eax,%eax
call   1040 <fprintf@plt>
mov    $0x3,%edi
call   1050 <exit@plt>

LLVM IR (-O0):
@stderr = global i32 0
@.str = [442 x i8] c"\0A\0Abzip2/libbzip2: internal error number %d.\0AThis is a bug in bzip2/libbzip2, %s.\0APlease report it to me at: jseward@acm.org. If this happened\0Awhen you were using some program which uses libbzip2 as a\0Acomponent, you should also report this bug to the author(s)\0Aof that program. Please make an effort to report this bug;\0Atimely and accurate bug reports eventually lead to higher\0Aquality software. Thanks. Julian Seward, 30 December 2001.\0A\0A\00"
@.str.1 = [1057 x i8] c"\0A*** A special note about internal error number 1007 ***\0A\0AExperience suggests that a common cause of i.e. 1007\0Ais unreliable memory or other hardware. The 1007 assertion\0Ajust happens to cross-check the results of huge numbers of\0Amemory reads/writes, and so acts (unintendedly) as a stress\0Atest of your memory system.\0A\0AI suggest the following: try compressing the file again,\0Apossibly monitoring progress in detail with the -vv flag.\0A\0A* If the error cannot be reproduced, and/or happens at different\0A points in compression, you may have a flaky memory system.\0A Try a memory-test program. I have used Memtest86\0A (www.memtest86.com). At the time of writing it is free (GPLd).\0A Memtest86 tests memory much more thorougly than your BIOSs\0A power-on test, and may find failures that the BIOS doesn't.\0A\0A* If the error can be repeatably reproduced, this is a bug in\0A bzip2, and I would very much like to hear about it. Please\0A let me know, and, ideally, save a copy of the file causing the\0A problem -- without which I will be unable to investigate it.\0A\0A\00"
define void @BZ2_bz__AssertH__fail(i32 %0) {
%2 = alloca i32
store i32 %0, i32* %2
%3 = load i32, i32* @stderr
%4 = load i32, i32* %2
%5 = call i8* (...) @BZ2_bzlibVersion()
%6 = call i32 (i32, i8*, ...) @fprintf(i32 %3, i8* getelementptr inbounds ([442 x i8], [442 x i8]* @.str, i64 0, i64 0), i32 %4, i8* %5)
%7 = load i32, i32* %2
%8 = icmp eq i32 %7, 1007
br i1 %8, label %9, label %12
9: ; preds = %1
%10 = load i32, i32* @stderr
%11 = call i32 (i32, i8*, ...) @fprintf(i32 %10, i8* getelementptr inbounds ([1057 x i8], [1057 x i8]* @.str.1, i64 0, i64 0))
br label %12
12: ; preds = %9, %1
%13 = call i32 @exit(i32 3)
unreachable
}

LLVM IR (-O2):
@stderr = global i32 0
@.str = [442 x i8] c"\0A\0Abzip2/libbzip2: internal error number %d.\0AThis is a bug in bzip2/libbzip2, %s.\0APlease report it to me at: jseward@acm.org. If this happened\0Awhen you were using some program which uses libbzip2 as a\0Acomponent, you should also report this bug to the author(s)\0Aof that program. Please make an effort to report this bug;\0Atimely and accurate bug reports eventually lead to higher\0Aquality software. Thanks. Julian Seward, 30 December 2001.\0A\0A\00"
@.str.1 = [1057 x i8] c"\0A*** A special note about internal error number 1007 ***\0A\0AExperience suggests that a common cause of i.e. 1007\0Ais unreliable memory or other hardware. The 1007 assertion\0Ajust happens to cross-check the results of huge numbers of\0Amemory reads/writes, and so acts (unintendedly) as a stress\0Atest of your memory system.\0A\0AI suggest the following: try compressing the file again,\0Apossibly monitoring progress in detail with the -vv flag.\0A\0A* If the error cannot be reproduced, and/or happens at different\0A points in compression, you may have a flaky memory system.\0A Try a memory-test program. I have used Memtest86\0A (www.memtest86.com). At the time of writing it is free (GPLd).\0A Memtest86 tests memory much more thorougly than your BIOSs\0A power-on test, and may find failures that the BIOS doesn't.\0A\0A* If the error can be repeatably reproduced, this is a bug in\0A bzip2, and I would very much like to hear about it. Please\0A let me know, and, ideally, save a copy of the file causing the\0A problem -- without which I will be unable to investigate it.\0A\0A\00"
define void @BZ2_bz__AssertH__fail(i32 %0) {
%2 = load i32, i32* @stderr
%3 = tail call i8* (...) @BZ2_bzlibVersion()
%4 = tail call i32 (i32, i8*, ...) @fprintf(i32 %2, i8* getelementptr inbounds ([442 x i8], [442 x i8]* @.str, i64 0, i64 0), i32 %0, i8* %3)
%5 = icmp eq i32 %0, 1007
br i1 %5, label %6, label %9
6: ; preds = %1
%7 = load i32, i32* @stderr
%8 = tail call i32 (i32, i8*, ...) @fprintf(i32 %7, i8* getelementptr inbounds ([1057 x i8], [1057 x i8]* @.str.1, i64 0, i64 0))
br label %9
9: ; preds = %6, %1
%10 = tail call i32 @exit(i32 3)
unreachable
}