llvm / llvm-project Goto Github PK
View Code? Open in Web Editor NEWThe LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
Home Page: http://llvm.org
License: Other
The LLVM Project is a collection of modular and reusable compiler and toolchain technologies.
Home Page: http://llvm.org
License: Other
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 |
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
Bugzilla Link | 42 |
Resolution | INVALID |
Resolved on | Feb 22, 2010 12:48 |
Version | unspecified |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
testing
Bugzilla Link | 49 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:53 |
Version | trunk |
OS | FreeBSD |
Reporter | LLVM Bugzilla Contributor |
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.)
Bugzilla Link | 21 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:46 |
Version | unspecified |
OS | Linux |
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.
Bugzilla Link | 14 |
Resolution | FIXED |
Resolved on | Nov 07, 2018 00:17 |
Version | unspecified |
OS | Linux |
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.
Bugzilla Link | 26 |
Resolution | FIXED |
Resolved on | Mar 06, 2010 14:00 |
Version | trunk |
OS | Linux |
$ 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.
Bugzilla Link | 28 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:50 |
Version | trunk |
OS | Windows 2000 |
struct Foo {
unsigned a;
unsigned b;
unsigned c;
};
struct Bar {
union {
void **a;
struct Foo b;
}u;
};
struct Bar test = {0};
Bugzilla Link | 33 |
Resolution | FIXED |
Resolved on | Mar 06, 2010 14:00 |
Version | 1.0 |
OS | All |
CC | @lattner |
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
Bugzilla Link | 44 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:46 |
Version | trunk |
OS | Linux |
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
Bugzilla Link | 46 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:47 |
Version | unspecified |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
CC | @lattner |
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.
Bugzilla Link | 37 |
Resolution | FIXED |
Resolved on | Mar 06, 2010 13:51 |
Version | trunk |
OS | Linux |
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;
}
}
Bugzilla Link | 41 |
Resolution | FIXED |
Resolved on | Mar 06, 2010 13:59 |
Version | 1.0 |
OS | Linux |
Blocks | #376 |
Reporter | LLVM Bugzilla Contributor |
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
}
Bugzilla Link | 19 |
Resolution | FIXED |
Resolved on | Mar 06, 2010 14:05 |
Version | trunk |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
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.
Bugzilla Link | 39 |
Resolution | FIXED |
Resolved on | Mar 06, 2010 13:58 |
Version | trunk |
OS | Linux |
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
Bugzilla Link | 2 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:43 |
Version | unspecified |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
Change the header on every page to say "LLVM bugs" instead of "Bugzilla".
Bugzilla Link | 32 |
Resolution | FIXED |
Resolved on | Mar 06, 2010 13:51 |
Version | trunk |
OS | Linux |
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.
Bugzilla Link | 27 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:51 |
Version | trunk |
OS | Linux |
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
Bugzilla Link | 8 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:49 |
Version | trunk |
OS | Linux |
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
}
Bugzilla Link | 36 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:52 |
Version | trunk |
OS | Linux |
Blocks | llvm/llvm-bugzilla-archive#51 |
CC | @lattner |
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.
There should be an explicit ModulePass class. The "Pass" class should
be abstract.
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
Pass
ModulePass
CallGraphSCCPass
FunctionPass
LoopPass
BasicBlockPass
The current implementation of the PassManager in PassManagerT.h is really
ugly and should be rewritten.
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.
Implement support for ModulePasses that require FunctionPasses.
Bugzilla Link | 1 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:40 |
Version | unspecified |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
Add versions "1.0" and "trunk" to all our supported products.
Remove the "unspecified" version as it is of no use to us.
Bugzilla Link | 31 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:47 |
Version | 1.0 |
OS | Linux |
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.
Bugzilla Link | 22 |
Resolution | WONTFIX |
Resolved on | Nov 07, 2018 00:17 |
Version | unspecified |
OS | Linux |
"When you have to solder the transistors to the motherboard, you keep the
assembly language pretty simple."
s/assembly language/machine code/
?
Bugzilla Link | 29 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:53 |
Version | trunk |
OS | Linux |
Depends On | llvm/llvm-bugzilla-archive#58 |
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.
Bugzilla Link | 9 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:50 |
Version | trunk |
OS | Linux |
Compile this program with the C frontend:
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.
Bugzilla Link | 48 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:53 |
Version | trunk |
OS | FreeBSD |
Reporter | LLVM Bugzilla Contributor |
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).
Bugzilla Link | 18 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:47 |
Version | unspecified |
OS | Windows 2000 |
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?
Bugzilla Link | 20 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:51 |
Version | unspecified |
OS | All |
Depends On | llvm/llvm-bugzilla-archive#23 |
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.
Bugzilla Link | 3 |
Resolution | WORKSFORME |
Resolved on | Sep 19, 2018 06:24 |
Version | trunk |
OS | Linux |
"gccld foo.a foo.a" fails with multiple symbol definition bugs, whereas "gccld
-lfoo -lfoo" works properly.
Bugzilla Link | 4 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:42 |
Version | trunk |
OS | Linux |
Depends On | llvm/llvm-bugzilla-archive#41 |
For an unknown reason, LLC produced executables randomly segfault. This does
not effect the JIT.
Bugzilla Link | 15 |
Resolution | DUPLICATE |
Resolved on | Feb 22, 2010 12:54 |
Version | trunk |
OS | Linux |
Summary says it all.
Bugzilla Link | 5 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:43 |
Version | trunk |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
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
Bugzilla Link | 13 |
Resolution | INVALID |
Resolved on | Nov 07, 2018 00:21 |
Version | unspecified |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
CC | @FlashSheridan |
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.
Bugzilla Link | 24 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:41 |
Version | trunk |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
CC | @lattner |
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.
Bugzilla Link | 30 |
Resolution | FIXED |
Resolved on | Mar 06, 2010 14:06 |
Version | 1.0 |
OS | All |
Reporter | LLVM Bugzilla Contributor |
CC | @tlattner |
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.
Bugzilla Link | 11 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:46 |
Version | 1.0 |
OS | All |
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();
}
Bugzilla Link | 23 |
Resolution | WONTFIX |
Resolved on | Feb 22, 2010 12:43 |
Version | unspecified |
OS | Linux |
Blocks | #392 |
Reporter | LLVM Bugzilla Contributor |
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.
Bugzilla Link | 12 |
Resolution | INVALID |
Resolved on | Feb 22, 2010 12:50 |
Version | unspecified |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
CC | @lattner |
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.
Bugzilla Link | 34 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:49 |
Version | trunk |
OS | Linux |
The summary says it all
Bugzilla Link | 43 |
Resolution | INVALID |
Resolved on | Feb 22, 2010 12:51 |
Version | unspecified |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
I promise this will be the last test bug I file.
Today, anyways. :-) (Sorry for the spam.)
Bugzilla Link | 45 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:48 |
Version | trunk |
OS | Linux |
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.
Bugzilla Link | 35 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:52 |
Version | 1.0 |
OS | All |
CC | @lattner |
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.
Bugzilla Link | 16 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:43 |
Version | 1.0 |
OS | All |
Summary says it all.
Bugzilla Link | 25 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:41 |
Version | trunk |
OS | Linux |
This testcase is eliminated:
$ llvmg++ -O3 ehtest.cc -c -o - | & llvm-dis
Bugzilla Link | 47 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:42 |
Version | trunk |
OS | Linux |
Reporter | LLVM Bugzilla Contributor |
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.
Bugzilla Link | 7 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:55 |
Version | trunk |
OS | Linux |
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
}
Bugzilla Link | 6 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:53 |
Version | 1.0 |
OS | All |
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
Bugzilla Link | 40 |
Resolution | FIXED |
Resolved on | Feb 22, 2010 12:55 |
Version | 1.0 |
OS | All |
Reporter | LLVM Bugzilla Contributor |
CC | @lattner |
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"
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 |
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.
A declarative, efficient, and flexible JavaScript library for building user interfaces.
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
An Open Source Machine Learning Framework for Everyone
The Web framework for perfectionists with deadlines.
A PHP framework for web artisans
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
Some thing interesting about web. New door for the world.
A server is a program made to process requests and deliver data to clients.
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
Some thing interesting about visualization, use data art
Some thing interesting about game, make everyone happy.
We are working to build community through open source technology. NB: members must have two-factor auth.
Open source projects and samples from Microsoft.
Google ❤️ Open Source for everyone.
Alibaba Open Source for everyone
Data-Driven Documents codes.
China tencent open source team.