llvm / llvm-project

The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.

The LLVM Compiler Infrastructure

Welcome to the LLVM project!

This repository contains the source code for LLVM, a toolkit for the construction of highly optimized compilers, optimizers, and run-time environments.

The LLVM project has multiple components. The core of the project is itself called "LLVM". This contains all of the tools, libraries, and header files needed to process intermediate representations and convert them into object files. Tools include an assembler, disassembler, bitcode analyzer, and bitcode optimizer.

C-like languages use the Clang frontend. This component compiles C, C++, Objective-C, and Objective-C++ code into LLVM bitcode -- and from there into object files, using LLVM.

Other components include: the libc++ C++ standard library, the LLD linker, and more.

Getting the Source Code and Building LLVM

Consult the Getting Started with LLVM page for information on building and running LLVM.

For information on how to contribute to the LLVM project, please take a look at the Contributing to LLVM guide.

Getting in touch

Join the LLVM Discourse forums, Discord chat, LLVM Office Hours or Regular sync-ups.

The LLVM project has adopted a code of conduct for participants to all modes of communication within the project.

llvm-project's Issues

[loopsimplify] The loopsimplify pass should guarantee that loops have a single backedge

Bugzilla Link	34
Resolution	FIXED
Resolved on	Feb 22, 2010 12:49
Version	trunk
OS	Linux

Extended Description

The summary says it all

C Backend cannot emit NAN's as global initializers

Bugzilla Link	33
Resolution	FIXED
Resolved on	Mar 06, 2010 14:00
Version	1.0
OS	All
CC	@lattner

Extended Description

The C backend cannot emit NAN's and other non-number values (such as infinity)
as global variable initializers.

This is tested by: test/Regression/CBackend/2003-10-12-NANGlobalInits.ll

Target release

Bugzilla Link	18
Resolution	FIXED
Resolved on	Feb 22, 2010 12:47
Version	unspecified
OS	Windows 2000

Extended Description

It would be nice to have a target release field for a bug. This way we could
mark bugs which need to be fixed by the next release, or if a bug won't be
fixed, we could mark it for a generic "future" release or something.

When working towards a release, we should then be able to query for all bugs
targetted to that release, and ship there are none.

BTW, what's up with the "Products" and "UI" components of the Bugzilla Admin
product?

Linking two .a files explicitly on the command line fails

Bugzilla Link	3
Resolution	WORKSFORME
Resolved on	Sep 19, 2018 06:24
Version	trunk
OS	Linux

Extended Description

"gccld foo.a foo.a" fails with multiple symbol definition bugs, whereas "gccld
-lfoo -lfoo" works properly.

Get notified of ANY new bug?

Bugzilla Link	20
Resolution	FIXED
Resolved on	Feb 22, 2010 12:51
Version	unspecified
OS	All
Depends On	llvm/llvm-bugzilla-archive#23

Extended Description

There should be a way for a user to choose to be notified if ANY new bug gets
submitted, not just module owners. Even if this is just hacked into bugzilla
with a certain set of people who are interested, it would be nice to have.

[bugpoint] "Non-instruction is using an external function"

Bugzilla Link	38
Resolution	FIXED
Resolved on	Feb 22, 2010 12:41
Version	1.0
OS	All
Depends On	llvm/llvm-bugzilla-archive#290
CC	@lattner

Extended Description

In code generator debugging mode, we should transform the program so that this
error cannot occur. This amounts to implementing a new feature in bugpoint, so
it's only an enhancement request, but it would make it actually useful on
programs like SPEC.

[instcombine] Should eliminate no-op casts in varargs calls

Bugzilla Link	7
Resolution	FIXED
Resolved on	Feb 22, 2010 12:55
Version	trunk
OS	Linux

Extended Description

The cast in this testcase should be eliminated:

declare void %test2(int, ...)

void %test(sbyte* %A) {
%B = cast sbyte* %A to int*
call void %test2(int 0, int* %B)
ret void
}

email llvm-bugs when a bug changes state

Bugzilla Link	46
Resolution	FIXED
Resolved on	Feb 22, 2010 12:47
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

We will probably want to be able to email llvmbugs when a bug
changes state (RESOLVED or REOPENED), as opposed to just on bug
creation.

Other people are working on this - see the Bugzilla bug:
http://bugzilla.mozilla.org/show_bug.cgi?id=76794

We however are not constrained by artificial ideas of
code cleanliness (heh heh heh), and we want something
that basically works now, so we can probably
just hack something into process_bug.cgi.

Casted pointer arithmetic not incremented correctly

Bugzilla Link	39
Resolution	FIXED
Resolved on	Mar 06, 2010 13:58
Version	trunk
OS	Linux

Extended Description

This bug was painstakenly reduced from 176.gcc, manually. The C front-end
generates incorrect code for the increment here:

#include <stdio.h>

int main() {
int Array[10];
void *Pointer = &Array[0];
unsigned i;

    for (i = 0; i < 10; ++i) {
            *((int*)Pointer)++ = 1234;
            printf("0x%d\n", (int)Pointer-(int)&Array[0]);
    }

}

This has been checked in as
test/Programs/SingleSource/Regression/C/2003-10-13-PointerIncrementTest.c

PassManager enhancements

Bugzilla Link	36
Resolution	FIXED
Resolved on	Feb 22, 2010 12:52
Version	trunk
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#51
CC	@lattner

Extended Description

The following are my notes on PassManager V2. Note that the sum effect of these
improvements is basically a complete rewrite of the pass manager.

1. There should be an explicit ModulePass class. The "Pass" class should
   be abstract.

2. The pass manager should be extended to support callgraph SCC passes
   and Loop passes. The structural hierarchy of passes should be:

ModulePass
CallGraphSCCPass
FunctionPass
LoopPass
BasicBlockPass

3. Instead of the structural hierarchy being reflected directly in
   the C++ class hierarchy, the various Pass subclasses should be
   derived like this:

Pass
ModulePass
CallGraphSCCPass
FunctionPass
LoopPass
BasicBlockPass

4. The current implementation of the PassManager in PassManagerT.h is really
   ugly and should be rewritten.

5. There needs to be a way to indicate that a pass needs to extend the
   lifetime of a pass it uses. For example, the alias analyses all chain to
   simpler implementation of alias analysis. For this reason, the simpler
   alias analyses should not be destroyed until the more complex ones are.

6. Implement support for ModulePasses that require FunctionPasses.

Need to add product version numbers

Bugzilla Link	1
Resolution	FIXED
Resolved on	Feb 22, 2010 12:40
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

Add versions "1.0" and "trunk" to all our supported products.
Remove the "unspecified" version as it is of no use to us.

[x86] The X86 backend miscompiles 'local-alloc.c' from 176.gcc

Bugzilla Link	45
Resolution	FIXED
Resolved on	Feb 22, 2010 12:48
Version	trunk
OS	Linux

Extended Description

Subject says it all. The JIT and static backends both execute the 176.gcc
benchmark incorrectly when the local-alloc.c file is compiled with the LLVM x86
backend.

All other files are compiled correctly.

Error messages when I submit a bug comment

Bugzilla Link	10
Resolution	FIXED
Resolved on	Nov 07, 2018 00:17
Version	unspecified
OS	Linux
Blocks	llvm/llvm-bugzilla-archive#17
Reporter	LLVM Bugzilla Contributor

Extended Description

When I submit a comment for a bug, the page bugzilla sends back
includes the following error messages:

Changes submitted for bug 4
Who are you?: Inappropriate ioctl for device /no/such/directory/dead.letter...
cannot open /no/such/directory/dead.letter: No such file or directory Email sent
to: [email protected]
Excluding: [email protected]
If you wish to tweak the kinds of mail Bugzilla sends you, you can change your
preferences

[llvm-ar] Command line arguments have funny syntax

Bugzilla Link	30
Resolution	FIXED
Resolved on	Mar 06, 2010 14:06
Version	1.0
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@tlattner

Extended Description

The syntax of llvm-ar's command line arguments is strange
to someone who is used to using plain old ar or GNU ar.

For instance, you don't get to specify which action it
will take; it always creates ('c') archives. See the ar(1)
man page for an example of what I am getting at.

It would be really nice if llvm-ar took either the same
kinds of command line options as other versions of ar,
or a subset thereof.

Sorry this is so vague; I don't have
time to explicitly specify all the things that real ar(1)
can do, and the documentation is widely available.

[mem2reg] Promote mem2reg pass crashes on this input.

Bugzilla Link	50
Resolution	FIXED
Resolved on	Feb 22, 2010 12:51
Version	trunk
OS	Linux
Attachments	testcase

Extended Description

This testcase, distilled from a 5MB HDF5 bytecode file causes mem2reg to crash.

[instcombine] setcc instructions should allow limited cast propagation

Bugzilla Link	8
Resolution	FIXED
Resolved on	Feb 22, 2010 12:49
Version	trunk
OS	Linux

Extended Description

The cast in this testcase should be eliminated:

bool %test(sbyte* %A) {
%B = cast sbyte* %A to int*
%C = seteq int* %B, null
ret bool %C
}

[x86] X86 static compiler does not work with 254.gap at all

Bugzilla Link	44
Resolution	FIXED
Resolved on	Feb 22, 2010 12:46
Version	trunk
OS	Linux

Extended Description

This looks like a bug in either the assembly emitter or in the 'gas' that we are
using, because it is very consistent, and the JIT works fine.

Either way, this should be fixed in lib/Target/X86/Printer.cpp

I'm not getting email from bugzilla

Bugzilla Link	17
Resolution	FIXED
Resolved on	Feb 22, 2010 12:47
Version	unspecified
OS	Windows 2000
Depends On	#382

Extended Description

Several of the bugs I submitted were resolved, but I never got any email about
it. I haven't modified my preferences to not send me email.

Any ideas?

Quip buggy

Bugzilla Link	22
Resolution	WONTFIX
Resolved on	Nov 07, 2018 00:17
Version	unspecified
OS	Linux

Extended Description

"When you have to solder the transistors to the motherboard, you keep the
assembly language pretty simple."

s/assembly language/machine code/

?

File fails to compile

Bugzilla Link	28
Resolution	FIXED
Resolved on	Feb 22, 2010 12:50
Version	trunk
OS	Windows 2000

Extended Description

struct Foo {
unsigned a;
unsigned b;
unsigned c;
};

struct Bar {
union {
void **a;
struct Foo b;
}u;
};

struct Bar test = {0};

LLVM needs explicit support for weak variables

Bugzilla Link	9
Resolution	FIXED
Resolved on	Feb 22, 2010 12:50
Version	trunk
OS	Linux

Extended Description

Compile this program with the C frontend:

---

int X;

X is removed from the translation unit. In C, the variable must be declared as
weak, and since LLVM has no notion of the difference between "linkonce" and
"weak", the optimizer things the variable is safe to delete.

test bug

Bugzilla Link	42
Resolution	INVALID
Resolved on	Feb 22, 2010 12:48
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

testing

LLC Produced executables randomly crash

Bugzilla Link	4
Resolution	FIXED
Resolved on	Feb 22, 2010 12:42
Version	trunk
OS	Linux
Depends On	llvm/llvm-bugzilla-archive#41

Extended Description

For an unknown reason, LLC produced executables randomly segfault. This does
not effect the JIT.

My contributions are still unacknowledged

Bugzilla Link	13
Resolution	INVALID
Resolved on	Nov 07, 2018 00:21
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@FlashSheridan

Extended Description

I authored more than 90% of the code in LLVM, but that
guy Chris Lattner gets his name on all the papers.
And furthermore, I am not getting enough sunlight,
which impedes my mental faculties.

Customize Bugzilla to have some LLVM flavah

Bugzilla Link	2
Resolution	FIXED
Resolved on	Feb 22, 2010 12:43
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

Change the header on every page to say "LLVM bugs" instead of "Bugzilla".

Current documentation should live primarily in LLVM CVS

Bugzilla Link	21
Resolution	FIXED
Resolved on	Feb 22, 2010 12:46
Version	unspecified
OS	Linux

Extended Description

We used to have llvm/www/docs/*, now we don't.

What we really want is to have a llvm/docs directory in LLVM CVS, with the
up-to-date versions of the CommandGuide, Getting Started Guide, etc. Whenever a
new version of the file gets committed to LLVM CVS, it should be auto-uploaded
to the "current" section of the web page.

Whenever a new LLVM release is made, these files are cloned into
llvm-www/releases/(version)/* files, so the state of the documentation as of a
particular release is always stable going into the future.

[loopsimplify] -loopsimplify should reconstruct nested loops

Bugzilla Link	35
Resolution	FIXED
Resolved on	Feb 22, 2010 12:52
Version	1.0
OS	All
CC	@lattner

Extended Description

The CFG simplification pass has a habit of merging the header nodes of loops
together into a single node. To counteract this, the -loopsimplify pass should
break them back up.

For example, consider this simple matrix multiplication testcase:

for( int i=0; i<L; i++ )
    for( int j=0; j<L; j++ ) {
        double sum = 0;
        for( int k=0; k<L; k++ )
            sum += C[L*i+k]*D[L*k+j];
        E[L*i+j] = sum;

This is currently compiled into:

no_exit.2:
...
br bool %tmp.5, label %no_exit.2, label %loopexit.2

loopexit.2:
...
br bool %tmp.3, label %no_exit.2, label %loopexit.1

loopexit.1:
...
br bool %tmp.1, label %no_exit.2, label %return

Which is a single natural loop.

To fix this, the LoopSimplify pass should detect that a backedge dominates
another backedge, and turn the dominating backedge into an inner loop.

When compiling with -O3, global functions are being marked link-once and deleted by optimizer!

Bugzilla Link	25
Resolution	FIXED
Resolved on	Feb 22, 2010 12:41
Version	trunk
OS	Linux

Extended Description

This testcase is eliminated:

---- foo.c ----
int main() {
return 10;
}

$ llvmg++ -O3 ehtest.cc -c -o - | & llvm-dis

testing bug 2

Bugzilla Link	43
Resolution	INVALID
Resolved on	Feb 22, 2010 12:51
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

I promise this will be the last test bug I file.

Today, anyways. :-) (Sorry for the spam.)

[inline] Opt freezes when used with -inline pass

Bugzilla Link	5
Resolution	FIXED
Resolved on	Feb 22, 2010 12:43
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

The opt program appears to freeze when it uses the -inline option on bytecode
assembled from the assembly code below. In reality, it is either an infinite
loop or just a gigantic running time:

implementation

declare int "atoi"(sbyte *)

ulong "fib"(ulong %n)
begin
setlt ulong %n, 2 ; {bool}:0
br bool %0, label %BaseCase, label %RecurseCase

BaseCase:
ret ulong 1

RecurseCase:
%n2 = sub ulong %n, 2
%n1 = sub ulong %n, 1
%f2 = call ulong(ulong) * %fib(ulong %n2)
%f1 = call ulong(ulong) * %fib(ulong %n1)
%result = add ulong %f2, %f1
ret ulong %result
end

ulong "realmain"(int %argc, sbyte ** %argv)
begin
seteq int %argc, 2 ; {bool}:0
br bool %0, label %HasArg, label %Continue
HasArg:
; %n1 = atoi(argv[1])
%n1 = add int 1, 1
br label %Continue

Continue:
%n = phi int [%n1, %HasArg], [1, %0]
%N = cast int %n to ulong
%F = call ulong(ulong) *%fib(ulong %N)
ret ulong %F
end

ulong "trampoline"(ulong %n, ulong(ulong)* %fibfunc)
begin
%F = call ulong(ulong) *%fibfunc(ulong %n)
ret ulong %F
end

int "main"()
begin
%Result = call ulong %trampoline(ulong 10, ulong(ulong) *%fib)
%Result = cast ulong %Result to int
ret int %Result
end

[lowerinvoke] The -lowerinvoke pass does not insert calls to setjmp/longjmp

Bugzilla Link	16
Resolution	FIXED
Resolved on	Feb 22, 2010 12:43
Version	1.0
OS	All

Extended Description

Summary says it all.

Need a "helper" script

Bugzilla Link	14
Resolution	FIXED
Resolved on	Nov 07, 2018 00:17
Version	unspecified
OS	Linux

Extended Description

It would be really nice to have a little helper CGI script to put in the
top-level LLVM directory which would allow us to forward to Bugzilla bugs. GCC
has something like this, for example.

LLVM should have this too: it would make preparing the release notes easier.
For now, it should forward to zion, but eventually it should forward to
llvm.cs.uiuc.edu.

C front-end miscompiles FP -> int initializers

Bugzilla Link	32
Resolution	FIXED
Resolved on	Mar 06, 2010 13:51
Version	trunk
OS	Linux

Extended Description

In this testcase:

#include <stdio.h>
int main() {
union { unsigned __l; float __d; } U = { 0x7fc00000U };
printf("%f\n", U.__d);
}

The C front-end emits this:
...
store float cast (uint 2143289344 to float), float* %tmp.1
...

which is obviously very broken.

email prefs pane changes don't stick

Bugzilla Link	23
Resolution	WONTFIX
Resolved on	Feb 22, 2010 12:43
Version	unspecified
OS	Linux
Blocks	#392
Reporter	LLVM Bugzilla Contributor

Extended Description

If you make a change to an email preference, and submit the
form, the change goes away. Everyone gets defaults, whether
they like them or not.

[llvmg++] Code for executing destructors is not shared

Bugzilla Link	11
Resolution	FIXED
Resolved on	Feb 22, 2010 12:46
Version	1.0
OS	All

Extended Description

Code for execution destructors of objects on stack is being duplicated for each
throw point, where it could be largely shared. For example:

struct F {
~F();
};

void couldThrow();

void test() {
F A;
couldThrow();
F B;
couldThrow();
F C;
couldThrow();
}

CWriter generated code performs poorly

Bugzilla Link	31
Resolution	FIXED
Resolved on	Feb 22, 2010 12:47
Version	1.0
OS	Linux

Extended Description

Especially on FP intensive codes, it looks like the C Writer is bad. For
example, in the oopack test (with options: Max=300000 Matrix=4000 Complex=200000
Iterator=600000), we get this native:

                     Seconds       Mflops         

Test Iterations C OOP C OOP Ratio

---

Max 300000 1.4 1.4 209.8 209.8 1.0
Matrix 4000 1.3 1.3 781.2 751.9 1.0
Complex 200000 1.3 10.5 1250.0 152.8 8.2
Iterator 600000 1.4 1.4 863.3 857.1 1.0

And the CWriter produces this:

                     Seconds       Mflops         

Test Iterations C OOP C OOP Ratio

---

Max 300000 1.5 1.5 202.7 205.5 1.0
Matrix 4000 2.5 2.5 408.2 393.7 1.0
Complex 200000 5.2 7.2 310.7 223.5 1.4
Iterator 600000 1.4 1.4 863.3 857.1 1.0

Note that especially the Matrix & Complex timings are horrible.

Both are compiled with GCC 3.3, -O3 -fomit-frame-pointer. Note that the LLVM
optimizer is being fairly aggressive with C++ code, so it's not directly
comperable, but C codes are.

llvmg++ crash on invalid code

Bugzilla Link	26
Resolution	FIXED
Resolved on	Mar 06, 2010 14:00
Version	trunk
OS	Linux

Extended Description

$ cat ehtest.cc
//#include <stdio.h>

int main() {
try {
throw 1;
}
catch (...) {
printf(" in catch\n");
return 1;
}
printf(" back in main\n");
return 10;
}

$ llvmg++ -O2 ehtest.cc -c
ehtest.cc: In function int main()': ehtest.cc:8: error: printf' undeclared (first use this function)
ehtest.cc:8: error: (Each undeclared identifier is reported only once for each
function it appears in.)
<var_decl 0x401b84d0 _ZTIi
type <record_type 0x401b4150 __fundamental_type_info_pseudo readonly type_5 DI
size <integer_cst 0x40021618 constant 64>
unit size <integer_cst 0x4002199c constant 8>
align 32 symtab 0 alias set -1
fields <field_decl 0x401b3ee0 type <record_type 0x401b3c40
__type_info_pseudo>
DI file line 0 size <integer_cst 0x40021618 64> unit size
<integer_cst 0x4002199c 8>
align 32 offset_align 32
offset <integer_cst 0x40021a64 constant 0>
bit offset <integer_cst 0x40021b04 constant 0> context <record_type
0x401b3f50 __fundamental_type_info_pseudo> arguments <integer_cst 0x40021a64 0>>
n_parents 0 use_template=0 interface-unknown>
readonly public static common external DI file ehtest.cc line 5 size
<integer_cst 0x40021618 64> unit size <integer_cst 0x4002199c 8>
align 32
chain <function_decl 0x401b8310 __llvm_cxxeh_allocate_exception>>
ehtest.cc:5: internal compiler error: in llvm_expand_lvalue_expr, at
llvm-expand.c:4258
Please submit a full bug report,
with preprocessed source if appropriate.
See URL:http://llvm.cs.uiuc.edu for instructions.

[cbackend] Fall through branches in switch instructions are miscompiled

Bugzilla Link	37
Resolution	FIXED
Resolved on	Mar 06, 2010 13:51
Version	trunk
OS	Linux

Extended Description

The following testcase is horribly mangled by the c backend.
This is distilled from a gigantic switch statement in 253.perlbmk.

#include <stdio.h>

int main(int argc) {
switch (argc) {
default:
printf("GOOD\n");
return 0;
case 100:
case 101:
case 1023:
printf("BAD\n");
return 1;
}
}

Constructors and destructors are not interacting with exceptions quite right

Bugzilla Link	27
Resolution	FIXED
Resolved on	Feb 22, 2010 12:51
Version	trunk
OS	Linux

Extended Description

The following testcase is being miscompiled. This was extracted from the GCC EH
newbies guide.

// Testcase for proper handling of
// c++ type, constructors and destructors.

#include <stdio.h>

int c, d;

struct A
{
int i;
A () { i = ++c; printf ("A() %d\n", i); }
A (const A&) { i = ++c; printf ("A(const A&) %d\n", i); }
~A() { printf ("~A() %d\n", i); ++d; }
};

void
f()
{
printf ("Throwing 1...\n");
throw A();
}

int main() {
try
{
f();
}
catch (A)
{
printf ("Caught.\n");
}
printf ("c == %d, d == %d\n", c, d);
return c != d;
}

You should get the following output:

Throwing 1...
A() 1
A(const A&) 2
~A() 1
A(const A&) 3
Caught.
~A() 3
~A() 2
c == 3, d == 3

bugpoint only allows user to debug default mode of llc

Bugzilla Link	40
Resolution	FIXED
Resolved on	Feb 22, 2010 12:55
Version	1.0
OS	All
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

I would like to be able to debug "llc -disable-fp-elim "
with bugpoint, but bugpoint does not let me pass in the "-disable-fp-elim"
option.

Perhaps bugpoint (specifically the AbstractInterpreters/ToolRunners) needs,
a general mechanism for passing in additional tool-specific arguments, as
opposed to arguments to the program. I thought of the following UI:
bugpoint -run-llc -tool-args="-disable-fp-elim"

what happened to UNCONFIRMED

Bugzilla Link	12
Resolution	INVALID
Resolved on	Feb 22, 2010 12:50
Version	unspecified
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

I thought when we enter bugs into the database, they were supposed
to show up as "UNCONFIRMED" until someone went to the trouble of
confirming them. It seems to be true, at least, if you believe
http://zion/bugs/bug_status.html . Instead they seem to be
showing up as NEW or ASSIGNED, I'm not sure which.

llc -disable-fp-elim miscompiles functions with allocas

Bugzilla Link	41
Resolution	FIXED
Resolved on	Mar 06, 2010 13:59
Version	1.0
OS	Linux
Blocks	#376
Reporter	LLVM Bugzilla Contributor

Extended Description

When I compile this LLVM code with "llc -disable-fp-elim" then assemble the
result with "gcc", and run it, it crashes almost every time. When I
remove "-disable-fp-elim", the result works fine every time.

target endian = little
target pointersize = 32
implementation
int %main() {
entry:
%Array = alloca [36 x [36 x int]]
ret int 0
}

crash on input from C++ frontend

Bugzilla Link	48
Resolution	FIXED
Resolved on	Feb 22, 2010 12:53
Version	trunk
OS	FreeBSD
Reporter	LLVM Bugzilla Contributor

Extended Description

void %_ZNSt12strstreambufC2Ei() {
%tmp.20 = or bool %tmp.19, and (bool shl (bool false, ubyte 1), bool true)
}

The above input crashes llvm-as in the parser, with the message:
Assertion failed: (V1.getType()->isInteger() && V2.getType() == Type::UByteTy),
function operator<<, file
/usr/home/brg/work/llvm/include/llvm/ConstantHandling.h, line 179.
Abort (core dumped)

I got this input from compiling libstdc++-v3/src/strstream.cc, in the middle
of trying to build libstdc++ on FreeBSD. I reduced the test case to the above
instruction in the above-named method. I am unsure whether the statement is
valid llvm assembly.

The stack trace is as follows:
(gdb) where
#​0 0x2834d763 in kill () from /usr/lib/libc.so.5
#​1 0x283b8e8c in abort () from /usr/lib/libc.so.5
#​2 0x28391f8f in __assert () from /usr/lib/libc.so.5
#​3 0x08188872 in operator<< (V1=@0x866e180, V2=@0x866e540)
at ConstantHandling.h:179
#​4 0x08164608 in ConstantFoldShiftInstruction(unsigned, Constant const*, Consta
nt const*) (Opcode=29, V1=0x866e180, V2=0x866e540) at ConstantHandling.cpp:139
#​5 0x08168813 in ConstantExpr::getShiftTy(Type const*, unsigned, Constant*, Con
stant*) (ReqTy=0x866a680, Opcode=29, C1=0x866e180, C2=0x866e540)
at Constants.cpp:939
#​6 0x0814cec4 in ConstantExpr::getShift(unsigned, Constant*, Constant*) (
Opcode=29, C1=0x866e180, C2=0x866e540) at Constants.h:527
#​7 0x0813a4ac in llvmAsmparse() () at llvmAsmParser.y:1098
#​8 0x08135fdd in RunVMAsmParser(std::string const&, __sFILE*) (
Filename=@0x826a138, F=0x283c71e0) at llvmAsmParser.y:601
#​9 0x08133ab7 in ParseAssemblyFile(std::string const&) (Filename=@0x826a138)
at Parser.cpp:27
#​10 0x0812faeb in main (argc=1, argv=0xbfbff528) at llvm-as.cpp:44
#​11 0x0812f9f5 in _start ()
(gdb) up 4
#​4 0x08164608 in ConstantFoldShiftInstruction(unsigned, Constant const*, Consta
nt const*) (Opcode=29, V1=0x866e180, V2=0x866e540) at ConstantHandling.cpp:139
139 case Instruction::Shl: return *V1 << *V2;
(gdb) p V1->dump()
bool false

(at this point gdb invariably crashes; who knows what else is going on.)
Apparently it doesn't like the bool shl (bool false, ubyte 1).

C++ front-end is not generating linkonce linkage type when it can

Bugzilla Link	29
Resolution	FIXED
Resolved on	Feb 22, 2010 12:53
Version	trunk
OS	Linux
Depends On	llvm/llvm-bugzilla-archive#58

Extended Description

In this testcase:

inline int foo() {
static int X = 0;
return ++X;
}
int bar() {
return foo();
}

The LLVM global variable declaration for the X variable should have "linkonce",
not "weak" linkage.

It is not clear how to get this information from the GCC front-end.

Oversized integer bitfields

Bugzilla Link	6
Resolution	FIXED
Resolved on	Feb 22, 2010 12:53
Version	1.0
OS	All

Extended Description

Bug: llvm/test/Regression/CFrontend/2003-08-30-LargeIntegerBitfieldMember.c

Causes crash:
$ llvmgcc -c 2003-08-30-LargeIntegerBitfieldMember.c
UNKNOWN INTEGRAL TYPE SIZE: 984
2003-08-30-LargeIntegerBitfieldMember.c:9: internal compiler error: in
llvm_type_get_integer, at llvm-types.c:489

gccld .... -lgcc -lc is breaking McCat/15-trie on BSD

Bugzilla Link	49
Resolution	FIXED
Resolved on	Feb 22, 2010 12:53
Version	trunk
OS	FreeBSD
Reporter	LLVM Bugzilla Contributor

Extended Description

I have slightly narrowed down the problem with "trie" on BSD. It turns out that
bugpoint was not lying when it said that none of the gccld passes were causing a
problem; in fact, the bug is triggered
when you say
gccld -o=trie Output/trie.linked.bc -lgcc -lc
and not when you say
gccld -o=trie Output/trie.linked.bc

(in both cases, I was testing with the JIT.)

gccld assumes first file is a bytecode file

Bugzilla Link	19
Resolution	FIXED
Resolved on	Mar 06, 2010 14:05
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

The gccld program assumes that the first file is a bytecode file. However, it
could be an archive file. If it is an archive file, it complains that the
bytecode file is corrupt (which it isn't) and exits.

The gccld program should be able to link files regardless of whether they are
all archive files, object files, or some combination thereof, given in any order.

Sparc backend does not support the 'unwind' instruction

Bugzilla Link	15
Resolution	DUPLICATE
Resolved on	Feb 22, 2010 12:54
Version	trunk
OS	Linux

Extended Description

Summary says it all.

Lots of spelling/grammar problems abound

Bugzilla Link	24
Resolution	FIXED
Resolved on	Feb 22, 2010 12:41
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor
CC	@lattner

Extended Description

Must fix as many spelling and grammar problems within our code and documentation
before the public release, lest people think we are some unedumacated fools off
the street.

bugpoint --debug --run-llc --args doesn't print args

Bugzilla Link	47
Resolution	FIXED
Resolved on	Feb 22, 2010 12:42
Version	trunk
OS	Linux
Reporter	LLVM Bugzilla Contributor

Extended Description

When you run bugpoint with --debug, it is supposed to print out the arguments to
the programs that it compiles and runs using the AbstractInterpreter interface
to GCC. This seems to work the first time GCC::ExecuteProgram() is called, but
not on subsequent occasions.

What seems to be happening is that std::cerr loses any output that gets written
to it, after GCC::ExecuteProgram() calls RunProgramWithTimeout() at
ToolRunner.cpp:315. It's not clear how this invocation of
RunProgramWithTimeout() is different from the earlier ones.

I produced this error today by trying to run bugpoint on the SPECint "GAP"
benchmark.