From akyrtzi at gmail.com  Tue Apr  1 16:47:44 2008
From: akyrtzi at gmail.com (Argiris Kirtzidis)
Date: Tue, 01 Apr 2008 14:47:44 -0700
Subject: [LLVMbugs] Fix for msvc compile errors
Message-ID: <47F2AD80.9070300@gmail.com>

Hi,

The attached patch fixes a couple of compiler errors of 
"lib/Support/MemoryBuffer.cpp", for MSVC.
-------------- next part --------------
An embedded and charset-unspecified text was scrubbed...
Name: memorybuffer-fix.patch
Url: http://lists.cs.uiuc.edu/pipermail/llvmbugs/attachments/20080401/f7fe08ca/attachment.pl 

From isanbard at gmail.com  Tue Apr  1 17:09:33 2008
From: isanbard at gmail.com (Bill Wendling)
Date: Tue, 1 Apr 2008 15:09:33 -0700
Subject: [LLVMbugs] Fix for msvc compile errors
In-Reply-To: <47F2AD80.9070300@gmail.com>
References: <47F2AD80.9070300@gmail.com>
Message-ID: <16e5fdf90804011509q95cd9b7g8b8344052087c0dc@mail.gmail.com>

Applied. Thanks!

-bw

On Tue, Apr 1, 2008 at 2:47 PM, Argiris Kirtzidis <akyrtzi at gmail.com> wrote:
> Hi,
>
>  The attached patch fixes a couple of compiler errors of
>  "lib/Support/MemoryBuffer.cpp", for MSVC.
>
> _______________________________________________
>  LLVMbugs mailing list
>  LLVMbugs at cs.uiuc.edu
>  http://lists.cs.uiuc.edu/mailman/listinfo/llvmbugs
>
>

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  1 20:05:42 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 1 Apr 2008 20:05:42 -0500
Subject: [LLVMbugs] [Bug 2017] clang crashes on array with void size
In-Reply-To: <bug-2017-206@http.llvm.org/bugs/>
Message-ID: <200804020105.m3215gg4029351@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2017


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-01 20:05:42 ---
Fixed, thanks!
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080331/004893.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  1 23:21:19 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 1 Apr 2008 23:21:19 -0500
Subject: [LLVMbugs] [Bug 2185] New: lli crash on valid bitcode file
Message-ID: <bug-2185-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2185

           Summary: lli crash on valid bitcode file
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: lli
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: viridia at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1563)
 --> (http://llvm.org/bugs/attachment.cgi?id=1563)
LLVM bitcode file that causes lli to crash

I've included a bitcode file which causes lli to crash. The file verifies fine,
and in fact you can run it through opt with -std-compile-opts and it will come
out fine but still cause lli to crash.

Here's the stack trace:

#0  0x92b64a03 in __dynamic_cast ()
#1  0x003eee7b in llvm::Pass::getAnalysisToUpdate<llvm::AliasAnalysis>
(this=0x1010de0) at PassAnalysisSupport.h:169
#2  0x003ee8a1 in (anonymous namespace)::LoopSimplify::runOnFunction
(this=0x1010de0, F=@0x1007e50) at LoopSimplify.cpp:115
#3  0x004d1123 in llvm::FPPassManager::runOnFunction (this=0x1010a10,
F=@0x1007e50) at PassManager.cpp:1178
#4  0x004d137c in llvm::FunctionPassManagerImpl::run (this=0x1010910,
F=@0x1007e50) at PassManager.cpp:1133
#5  0x004d14fa in llvm::FunctionPassManager::run (this=0x10108c4, F=@0x1007e50)
at PassManager.cpp:1078
#6  0x001911b9 in llvm::JIT::runJITOnFunction (this=0x1010850, F=0x1007e50) at
JIT.cpp:283
#7  0x0019159b in llvm::JIT::getPointerToFunction (this=0x1010850, F=0x1007e50)
at JIT.cpp:332
#8  0x00196069 in (anonymous namespace)::JITResolver::JITCompilerFn
(Stub=0x2080082) at JITEmitter.cpp:282
#9  0x0005cf41 in X86CompilationCallback2 (StackPtr=0xbffff4b8,
RetAddr=34078850) at X86JITInfo.cpp:340
#10 0x0005ce31 in X86CompilationCallback_SSE () at X86JITInfo.cpp:30
#11 0x02080086 in ?? ()
#12 0x00187aef in llvm::ExecutionEngine::runFunctionAsMain (this=0x1010850,
Fn=0x1008010, argv=@0x5a4f60, envp=0xbffff8c8) at ExecutionEngine.cpp:308
#13 0x00001e44 in main (argc=2, argv=0xbffff8bc, envp=0xbffff8c8) at
lli.cpp:141


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  2 00:19:52 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 2 Apr 2008 00:19:52 -0500
Subject: [LLVMbugs] [Bug 2039] clang doesn't propagate qualifiers for arrays
	correctly
In-Reply-To: <bug-2039-206@http.llvm.org/bugs/>
Message-ID: <200804020519.m325Jqk8004957@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2039


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2008-04-02 00:19:52 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080331/004901.html

Clang doesn't diagnose this:

int d() {
  int *A;  const int *B;
  return A == B;
}

so one of your testcases isn't triggering.  The AST looks correct though.

Thanks!

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  2 05:40:16 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 2 Apr 2008 05:40:16 -0500
Subject: [LLVMbugs] [Bug 2186] New: too many params when passing big struct
	by value
Message-ID: <bug-2186-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2186

           Summary: too many params when passing big struct by value
           Product: tools
           Version: 2.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jay.foad at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


I configured llvm-gcc with --target=arm-elf. Then:

$ cat big.c
struct big { int x[0x20000]; };
extern void f(struct big x);
void g() {
        struct big x;
        f(x);
}
$ cc1 big.c -quiet -emit-llvm-bc -o big.bc
$ opt big.bc
Attribute nounwind only applies to return values!
        call void @f( i64 %tmp3, i64 %tmp5, i64 %tmp7, i64 %tmp9, i64 %tmp11,
i64 %tmp13, i64 %tmp15, ..........................., i64 %tmp131067, i64
%tmp131069, i64 %tmp131071, i64
nounwind  %tmp131073 ) nounwind
Broken module found, compilation aborted!
/home/foad/llvm/objdir-llvm/Release/bin/opt((anonymous
namespace)::PrintStackTrace()+0x1a)[0x83d981a]
/lib/tls/i686/cmov/libc.so.6(abort+0x109)[0xb7d67fb9]
/home/foad/llvm/objdir-llvm/Release/bin/opt[0x8399c3a]
Aborted


I think the problem is that the big struct argument gets split into about 2^16
i64 arguments. But the ParamAttrsWithIndex class only uses a 16-bit field to
store the index, so it gets confused into thinking that a return value
attribute also applies to the 2^16th parameter.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  2 11:11:06 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 2 Apr 2008 11:11:06 -0500
Subject: [LLVMbugs] [Bug 2187] New: Crash with recursive? struct definition
Message-ID: <bug-2187-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2187

           Summary: Crash with recursive? struct definition
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sanxiyn at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Following short program crashes in CodeGen.

struct a { struct b *b; };
struct b { struct a a; };
struct a x;

While searching for previous reports, I realized I(!) reported this bug last
December. I guess that's why I should use the bug tracker for bug reporting,
not the mailing list...

http://lists.cs.uiuc.edu/pipermail/cfe-dev/2007-December/000703.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  2 11:18:44 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 2 Apr 2008 11:18:44 -0500
Subject: [LLVMbugs] [Bug 2187] Crash with recursive? struct definition
In-Reply-To: <bug-2187-206@http.llvm.org/bugs/>
Message-ID: <200804021618.m32GIi5i004251@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2187


Seo Sanghyeon <sanxiyn at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #1 from Seo Sanghyeon <sanxiyn at gmail.com>  2008-04-02 11:18:43 ---
Apparently I didn't search enough.

*** This bug has been marked as a duplicate of bug 2081 ***


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  2 12:01:29 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 2 Apr 2008 12:01:29 -0500
Subject: [LLVMbugs] [Bug 2186] too many params when passing big struct by
	value
In-Reply-To: <bug-2186-206@http.llvm.org/bugs/>
Message-ID: <200804021701.m32H1Tor005821@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2186


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #7 from Chris Lattner <sabre at nondot.org>  2008-04-02 12:01:29 ---
This bug is fixed in two ways on mainline:

1) as targets adopt byval more, this becomes a non-issue.
2) even if they don't, on mainline the argument # for the param attr is a int32
now instead of int16.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  2 14:02:25 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 2 Apr 2008 14:02:25 -0500
Subject: [LLVMbugs] [Bug 2188] New: Don't produce unneeded dwarf info
Message-ID: <bug-2188-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2188

           Summary: Don't produce unneeded dwarf info
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


If a function is marked nounwind then it should not
need any per-function frame moves.  So emitting an
empty set of moves into the eh moves frame should be
ok.  This would reduce the size.  Maybe it would even
be possible to get rid of the frame altogether.  These
kinds of optimizations would reduce the size of dwarf
info for functions which are marked nothrow (eg: throws())
and contain try-catch blocks.
It would be nice to reduce dwarf info to the absolute
minimum in general (it can take up quite some space in
the final executable).


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr  3 00:22:37 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 3 Apr 2008 00:22:37 -0500
Subject: [LLVMbugs] [Bug 2189] New: Inconsistencies with array typedefs
Message-ID: <bug-2189-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2189

           Summary: Inconsistencies with array typedefs
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


>From Eli:

The testcases in
question are the following:
int x() {const int s[5]; int t[5]; return &s == &t;}
typedef int a[5]; int x() {const a s; a t; return &s == &t;}

Per C99 6.7.3.8, these are equivalent, and clang currently warns for the first,
but not the second.

Another similar case:
typedef int a[5]; typedef const int c[5];  int x() {a s; c* t; t = &s;}
vs.
typedef int a[5]; int x() {a s; const a* t; t = &s;}

Again equivalent, clang should warn either for both or for neither.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr  3 00:51:12 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 3 Apr 2008 00:51:12 -0500
Subject: [LLVMbugs] [Bug 2081] clang assert: circular type definition
In-Reply-To: <bug-2081-206@http.llvm.org/bugs/>
Message-ID: <200804030551.m335pCUH028421@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2081


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #7 from Chris Lattner <sabre at nondot.org>  2008-04-03 00:51:11 ---
The patch looked great: updated and applied:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080331/004953.html

Thanks Lauro and Seo!

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr  3 02:34:37 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 3 Apr 2008 02:34:37 -0500
Subject: [LLVMbugs] [Bug 2190] New: llc crashes on
 SingleSource/Benchmarks/Misc-C++/ stepanov_container.cpp
Message-ID: <bug-2190-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2190

           Summary: llc crashes on SingleSource/Benchmarks/Misc-
                    C++/stepanov_container.cpp
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: resistor at mac.com
                CC: llvmbugs at cs.uiuc.edu


LLC is crashing on this testcase.  I tried putting it through bugpoint
-run-llc, but it couldn't reduce it any.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr  4 04:12:34 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 4 Apr 2008 04:12:34 -0500
Subject: [LLVMbugs] [Bug 2185] lli crash on valid bitcode file
In-Reply-To: <bug-2185-206@http.llvm.org/bugs/>
Message-ID: <200804040912.m349CYq7007861@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2185


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Duncan Sands <baldrick at free.fr>  2008-04-04 04:12:28 ---
The problem is in the bitcode, which is scribbling over memory
(buffer overflow).  When run normally by luck this doesn't do
anything fatal and you don't notice, but when run under lli it
scribbles over lli's internal data structures causing strange
crashes.  The corruption occurs in the memcpy call in
@"tart.core.Array::int..constructor.  It looks to me like you
should have used tart.core.Array::int and not tart.core.Array::char
when calculating the length in @"tart.core.Array::int.alloc(i32)->Array".


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr  4 04:47:38 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 4 Apr 2008 04:47:38 -0500
Subject: [LLVMbugs] [Bug 1963] Addr of functions not considered a constant
	expr
In-Reply-To: <bug-1963-206@http.llvm.org/bugs/>
Message-ID: <200804040947.m349lcNZ008907@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1963


Seo Sanghyeon <sanxiyn at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |sanxiyn at gmail.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Seo Sanghyeon <sanxiyn at gmail.com>  2008-04-04 04:47:37 ---
Fixed in r49212. Thanks!
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080331/004991.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr  4 09:53:55 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 4 Apr 2008 09:53:55 -0500
Subject: [LLVMbugs] [Bug 2191] New: missed optimization: b &= ~a
Message-ID: <bug-2191-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2191

           Summary: missed optimization: b &= ~a
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Using llvm-gcc SVN r49213 on the simple testcase below generates code with
extra mov instructions.

unsigned sum(unsigned a, unsigned b)
{
        do {
                a ^= b;
                b &= ~a;
        } while (b <<= 1);
        return a;
}

This is the assembly generated, note the extra movl, and testl after the and:

sum:
        .align  16
.LBB1_1:        # bb
        xorl    %esi, %edi
        movl    %edi, %eax
        xorl    $2147483647, %eax
        andl    %esi, %eax
        addl    %eax, %eax
        testl   %eax, %eax
        movl    %eax, %esi
        jne     .LBB1_1 # bb
.LBB1_2:        # bb12
        movl    %edi, %eax
        ret
        .size   sum, .-sum

This should be a more optimized version (maybe xor could be changed to a not,
not sure):
sum:
    .align    16
.LBB1_1:    # bb
    xorl    %esi, %edi
    movl    %edi, %eax
    xorl    $2147483647, %eax
    andl    %eax, %esi
    addl    %esi, %esi
    jne    .LBB1_1    # bb
.LBB1_2:    # bb12
    movl    %edi, %eax
    ret
    .size    sum, .-sum

FWIW, gcc doesn't generate the optimized version either, here is what I get
with gcc-4.3 -O3:
sum:
        .align  16
.LBB1_1:        # bb
        xorl    %esi, %edi
        movl    %edi, %eax
        xorl    $2147483647, %eax
        andl    %esi, %eax
        addl    %eax, %eax
        testl   %eax, %eax
        movl    %eax, %esi
        jne     .LBB1_1 # bb
.LBB1_2:        # bb12
        movl    %edi, %


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr  4 11:55:09 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 4 Apr 2008 11:55:09 -0500
Subject: [LLVMbugs] [Bug 1960] Complex integer codegen broken
In-Reply-To: <bug-1960-206@http.llvm.org/bugs/>
Message-ID: <200804041655.m34Gt9tA021816@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1960


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|enhancement                 |normal
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-04 11:55:09 ---
Fixed:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080331/004998.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr  4 13:43:11 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 4 Apr 2008 13:43:11 -0500
Subject: [LLVMbugs] [Bug 2049] clang: CGExprScalar.cpp:1060: llvm::Value*
 clang::CodeGen:: CodeGenFunction::EmitScalarExpr(const clang::Expr*):
 Assertion `E && !hasAggregateLLVMType(E->getType()) && " Invalid scalar
 expression to emit"' failed.
In-Reply-To: <bug-2049-206@http.llvm.org/bugs/>
Message-ID: <200804041843.m34IhBLA025024@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2049


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2008-04-04 13:43:11 ---
I updated Eli's patch and applied it here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080331/005001.html

Thanks Eli, sorry for the delay.  Note that this is now miscompiled due to
sema, I will file a new bugzilla.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr  4 13:45:12 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 4 Apr 2008 13:45:12 -0500
Subject: [LLVMbugs] [Bug 2192] New: Struct initializer initlistexpr wrong
	from sema
Message-ID: <bug-2192-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2192

           Summary: Struct initializer initlistexpr wrong from sema
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu, snaroff at apple.com


Consider:
typedef struct mark_header_tag {
 unsigned char mark[7];
} mark_header_t;
int is_rar_archive(int fd) {
        mark_header_t rar_hdr = {0x52, 0x61, 0x72, 0x21, 0x1a, 0x07, 0x00};
        foo(rar_hdr);

        return 0;
}

Sema currently only creates one initlistexpr:

 (DeclStmt 0x906a90 <line:5:23, :0:0>
    0x9068d0 "mark_header_t rar_hdr =
      (InitListExpr 0x9069e0 <t.c:5:33, col:74> 'mark_header_t':'struct
mark_header_tag'
        (ImplicitCastExpr 0x906a20 <col:34> 'unsigned char'
          (IntegerLiteral 0x906900 <col:34> 'int' 82))
        (ImplicitCastExpr 0x906a30 <col:40> 'unsigned char'
          (IntegerLiteral 0x906920 <col:40> 'int' 97))
        (ImplicitCastExpr 0x906a40 <col:46> 'unsigned char'
          (IntegerLiteral 0x906940 <col:46> 'int' 114))
        (ImplicitCastExpr 0x906a50 <col:52> 'unsigned char'
          (IntegerLiteral 0x906960 <col:52> 'int' 33))
        (ImplicitCastExpr 0x906a60 <col:58> 'unsigned char'
          (IntegerLiteral 0x906980 <col:58> 'int' 26))
        (ImplicitCastExpr 0x906a70 <col:64> 'unsigned char'
          (IntegerLiteral 0x9069a0 <col:64> 'int' 7))
        (ImplicitCastExpr 0x906a80 <col:70> 'unsigned char'
          (IntegerLiteral 0x9069c0 <col:70> 'int' 0)))"

This causes codegen to miscompile the example.  We need to start making
"implicit" initlistexprs as we've previously discussed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr  4 15:58:07 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 4 Apr 2008 15:58:07 -0500
Subject: [LLVMbugs] [Bug 2193] New: compiling X86ISelDAGToDAG. cpp with
 llvm-g++ -O3 exhausts memory
Message-ID: <bug-2193-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2193

           Summary: compiling X86ISelDAGToDAG.cpp with llvm-g++ -O3 exhausts
                    memory
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1566)
 --> (http://llvm.org/bugs/attachment.cgi?id=1566)
bzip2 packed preprocessed file

I tried to compile llvm with llvm-g++ itself.

I got a message that cc1plus was killed while building X86ISelDAGToDAG.cpp.
It looks like it used up all the memory+swap and the OOM killer killed it.

>From dmesg:
Out of memory: kill process 19266 (llvm-g++) score 225056 or a child
Killed process 19271 (cc1plus)

g++-4.3 can compile this at -O3 although it takes several minutes to do so:
$ g++-4.3 -O3 prep.i
$ llvm-g++ -O3 prep.i
.... it gets killed


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr  4 17:04:34 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 4 Apr 2008 17:04:34 -0500
Subject: [LLVMbugs] [Bug 2194] New: Wrong NoAlias from Andersens alias
 analysis in combination with loop-reduce
Message-ID: <bug-2194-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2194

           Summary: Wrong NoAlias from Andersens alias analysis in
                    combination with loop-reduce
           Product: libraries
           Version: 2.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: miscompilation
          Severity: major
          Priority: P2
         Component: Interprocedural Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: giuma.cordes at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Andersens returns NoAlias for pointers subject to integer pointer arithmetics:

/* anders-bug.c */
f3(int *p, int *q, int N) {
  int i, ret = 0;
  for (i = 0; i < N; i++) {
    *p++ = i;
    ret += *q++;
  }
  return ret;
}

> llvm-gcc -c -O2 -emit-llvm anders-bug.c -o anders-bug.bc
> opt -loop-reduce  -anders-aa -debug-only=anders-aa -o anders-bug.obc -f anders-bug.bc 


llvm instructions after opt:

bb:             ; preds = %bb, %bb.preheader
        %iv. = phi i32 [ 0, %bb.preheader ], [ %iv..inc, %bb ]          ; <i32>
[#uses=3]
        %ret.0.reg2mem.0 = phi i32 [ 0, %bb.preheader ], [ %tmp8, %bb ]        
; <i32> [#uses=1]
        %tmp4 = mul i32 %iv., 4         ; <i32> [#uses=2]
        %tmp5 = add i32 %p2, %tmp4              ; <i32> [#uses=1]
        %tmp56 = inttoptr i32 %tmp5 to i32*             ; <i32*> [#uses=1]
        %tmp7 = add i32 %q1, %tmp4              ; <i32> [#uses=1]
        %tmp78 = inttoptr i32 %tmp7 to i32*             ; <i32*> [#uses=1]
        store i32 %iv., i32* %tmp56, align 4
        %tmp6 = load i32* %tmp78, align 4               ; <i32> [#uses=1]
        %tmp8 = add i32 %tmp6, %ret.0.reg2mem.0         ; <i32> [#uses=2]
        %iv..inc = add i32 %iv., 1              ; <i32> [#uses=2]
        %exitcond = icmp eq i32 %iv..inc, %tmp30                ; <i1>
[#uses=1]
        br i1 %exitcond, label %bb18.loopexit, label %bb


debug output of opt, due to -debug-only=anders-aa:

Beginning constraint optimization
Beginning HVN
Finished HVN
Beginning HU
Finished HU
Finished constraint optimization
Uniting remaining pointer equivalences
Finished remaining pointer equivalences
Starting iteration #1
Starting iteration #2
Points-to graph:
[1] <universal> --> <universal>
[1] <nullptr>   --> <null>
[0] <null>      --> 
[0] artificial142534524 --> 
[1] f3:p        --> <universal>
[1] f3:q        --> <universal>
[0] f3:tmp56    --> 
[0] f3:tmp78    --> 


tmp56 and tmp78 are p and q inside the loop.  The debug output is from
-debug-only=anders-aa, and it shows that the PointsTo set of the nodes
associated to tmp56 and tmp78 are empty.  When asking to the alias analysis if
they alias, I get a NoAlias back, because indeed the intersection between two
empty sets is empty, that in this context means that they don't alias (while of
course in this case they could).

If I understand correctly, their PointTo set should rather be <universal>.

It seems to me that the problem may come from the fact that the Andersens
implementation considers only instructions of PointerType, while in this case,
the loop-reduce generates integer arithmetics for computing tmp56 and tmp78. 
So in effect tmp56 and tmp78 are disconnected in the points-to graph, and
therefore the constraint propagation phase never propagates <universal> to
them.

At a minimum the Andersens::alias method should not return NoAlias for nodes
whose PointsTo set is empty.

Ideally it would be much nicer if Andersens could be extended to make a deeper
analysis of instructions leading to pointers, i.e. not restricting it to
PointerType.  Or otherwise loop-reduce and other similar transformations should
keep the type of pointer-manipulating instructions as pointers, instead of
converting them to integers (I don't know if this would be semantically correct
though).

Thanks.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr  5 01:34:11 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 5 Apr 2008 01:34:11 -0500
Subject: [LLVMbugs] [Bug 2012] implicit int rules still not right
In-Reply-To: <bug-2012-206@http.llvm.org/bugs/>
Message-ID: <200804050634.m356YBp2012662@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2012


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from Chris Lattner <sabre at nondot.org>  2008-04-05 01:34:11 ---
Well I hope that's right.  I implemented this understanding here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080331/005008.html

This handles all the cases listed in this bugzilla as well as the cases in
PR1999.

Please let me know if I missed any thing or misunderstood the issue.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr  5 04:24:32 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 5 Apr 2008 04:24:32 -0500
Subject: [LLVMbugs] [Bug 2195] New: Prototype scope lookup broken
Message-ID: <bug-2195-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2195

           Summary: Prototype scope lookup broken
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: neil at daikokuya.co.uk
                CC: llvmbugs at cs.uiuc.edu


void f1(int z, int[sizeof z]);

is perfectly legal C90 and C99; clang complains z is not defined.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr  5 13:54:01 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 5 Apr 2008 13:54:01 -0500
Subject: [LLVMbugs] [Bug 2195] Prototype scope lookup broken
In-Reply-To: <bug-2195-206@http.llvm.org/bugs/>
Message-ID: <200804051854.m35Is1lg009110@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2195


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-05 13:54:00 ---
I'll take a look at this one next, thanks!

*** This bug has been marked as a duplicate of bug 2046 ***


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 04:41:20 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 04:41:20 -0500
Subject: [LLVMbugs] [Bug 2196] New: test/CodeGen/X86/vec_shuffle-16.ll fails
	on x86
Message-ID: <bug-2196-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2196

           Summary: test/CodeGen/X86/vec_shuffle-16.ll fails on x86
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Using SVN r49248 on x86 Linux, I get this make check failure:

FAIL: /home/edwin/llvm/llvm-svn/trunk/test/CodeGen/X86/vec_shuffle-16.ll
Failed with exit(1) at line 1
while running: llvm-as <
/home/edwin/llvm/llvm-svn/trunk/test/CodeGen/X86/vec_shuffle-16.ll | llc
-march=x86 -mattr=+sse  | grep shufps | count 4
count: expected 4 lines and got 0.
child process exited abnormally

This is the output from llc:
$ llvm-as < /home/edwin/llvm/llvm-svn/trunk/test/CodeGen/X86/vec_shuffle-16.ll
| llc -march=x86 -mattr=+sse


        .text
        .align  16
        .globl  t1
        .type   t1, at function
t1:
        pshufd  $0, %xmm1, %xmm0
        ret
        .size   t1, .-t1


        .align  16
        .globl  t2
        .type   t2, at function
t2:
        pshufd  $255, %xmm0, %xmm0
        ret
        .size   t2, .-t2


        .align  16
        .globl  t3
        .type   t3, at function
t3:
        pshufd  $0, %xmm1, %xmm0
        ret
        .size   t3, .-t3


        .align  16
        .globl  t4
        .type   t4, at function
t4:
        pshufd  $45, %xmm0, %xmm0
        ret
        .size   t4, .-t4


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 05:15:11 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 05:15:11 -0500
Subject: [LLVMbugs] [Bug 2197] New: llvm-test/MultiSource/Benchmarks/Olden/
 health fails on x86-64
Message-ID: <bug-2197-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2197

           Summary: llvm-test/MultiSource/Benchmarks/Olden/health fails on
                    x86-64
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1569)
 --> (http://llvm.org/bugs/attachment.cgi?id=1569)
report file

On SVN r49248, x86-64 Linux:

---------------------------------------------------------------
>>> ========= '/MultiSource/Benchmarks/Olden/health/health' Program
---------------------------------------------------------------

TEST-PASS: compile /MultiSource/Benchmarks/Olden/health/health
TEST-RESULT-compile:   Total Execution Time: 0.0299 seconds (0.0732 wall clock)

TEST-RESULT-compile: 14924 Output/health.llvm.bc


TEST-RESULT-nat-time: program 0.710000

TEST-FAIL: llc /MultiSource/Benchmarks/Olden/health/health

TEST-FAIL: jit /MultiSource/Benchmarks/Olden/health/health

TEST-FAIL: cbe /MultiSource/Benchmarks/Olden/health/health

I used gcc/g++ 4.2, because 4.3 won't build many programs from llvm-test
(strlen/strcpy undeclared, etc.).

Since CBE failed, I run this:
$ make bugpoint run-cbe
....


I get these bugpoint files, I am attaching them:
 bugpoint-reduced-simplified.bc  bugpoint.safe.bc  bugpoint.test.bc


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 05:48:09 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 05:48:09 -0500
Subject: [LLVMbugs] [Bug 2198] New: bugpoint: ERROR: Loop extraction broke
	the program.
Message-ID: <bug-2198-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2198

           Summary: bugpoint: ERROR: Loop extraction broke the program.
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1572)
 --> (http://llvm.org/bugs/attachment.cgi?id=1572)
bugpoint-loop-extract-fail-tno.bc

While reducing a miscompilation, something broke in bugpoint:

Checking to see if the program is misoptimized when this function is run
through the passes: hypre_SMGRelaxSetupASol
<cbe><gcc><llc><gcc><program>: still failing!

*** The following function is being miscompiled:  hypre_SMGRelaxSetupASol
Extracted a loop from the breaking portion of the program.
<cbe><gcc><program>  *** ERROR: Loop extraction broke the program. :( Please
report a bug!
      Continuing on with un-loop-extracted version.
Please submit the bugpoint-loop-extract-fail-*.bc files.

This is on x86-64 Linux.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 06:03:49 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 06:03:49 -0500
Subject: [LLVMbugs] [Bug 2199] New:
 llvm-test/MultiSource/Benchmarks/MiBench/ security-rijndael fails on x86-64
Message-ID: <bug-2199-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2199

           Summary: llvm-test/MultiSource/Benchmarks/MiBench/security-
                    rijndael fails on x86-64
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


On SVN r49248, x86-64 Linux, security-rijndael test fails:

*** The following function is being miscompiled:  main_UnifiedReturnBlock
<cbe><gcc>You can reproduce the problem with the command line:
  llc -f bugpoint.test.bc-RXS0Ug -o bugpoint.test.bc-RXS0Ug.s
  gcc ./bugpoint.safe.bc-OW8XQP.cbe.c.so bugpoint.test.bc-RXS0Ug.s -o
bugpoint.test.bc-RXS0Ug.exe -Wl,-R.
  bugpoint.test.bc-RXS0Ug.exe
/home/edwin/llvm-svn/llvm/projects/llvm-test/MultiSource/Benchmarks/MiBench/security-rijndael/output_large.enc
Output/output_large.dec d
1234567890abcdeffedcba09876543211234567890abcdeffedcba0987654321
The shared object was created with:
  llc -march=c bugpoint.safe.bc-OW8XQP -o temporary.c
  gcc -xc temporary.c -O2 -o ./bugpoint.safe.bc-OW8XQP.cbe.c.so -fPIC -shared
-fno-strict-aliasing

---------------------------------------------------------------
>>> ========= '/MultiSource/Benchmarks/MiBench/security-rijndael/security-rijndael' Program
---------------------------------------------------------------

TEST-PASS: compile
/MultiSource/Benchmarks/MiBench/security-rijndael/security-rijndael
TEST-RESULT-compile:   Total Execution Time: 1.0132 seconds (2.1249 wall clock)

TEST-RESULT-compile: 74852 Output/security-rijndael.llvm.bc


TEST-RESULT-nat-time: program 0.070000

TEST-FAIL: llc
/MultiSource/Benchmarks/MiBench/security-rijndael/security-rijndael

TEST-FAIL: jit
/MultiSource/Benchmarks/MiBench/security-rijndael/security-rijndael

TEST-FAIL: cbe
/MultiSource/Benchmarks/MiBench/security-rijndael/security-rijndael


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 07:05:21 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 07:05:21 -0500
Subject: [LLVMbugs] [Bug 2200] New: Wrong generation of multi-stage
 Instruction Itineraries
Message-ID: <bug-2200-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2200

           Summary: Wrong generation of multi-stage Instruction Itineraries
           Product: tools
           Version: 2.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: miscompilation
          Severity: blocker
          Priority: P2
         Component: TableGen
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: giuma.cordes at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1578)
 --> (http://llvm.org/bugs/attachment.cgi?id=1578)
SubtargetEmitter.cpp

Using the following description of InstrItineraries:

/////////////////////////////////////////////////////
include "Target.td"

def IALUS1  : FuncUnit;  // Integer ALU stage 1 
def IALUS2  : FuncUnit;  // Integer ALU stage 2

def LSUS1   : FuncUnit;  // Load/Store stage 1
def LSUS2   : FuncUnit;  // Load/Store stage 2
def LSUS3   : FuncUnit;  // Load/Store stage 3

def IntAlu2     : InstrItinClass;
def LdSt        : InstrItinClass;

def ShSItinerariesV0 : ProcessorItineraries<[
  InstrItinData<IntAlu2,[InstrStage<1, [IALUS1]>,
                         InstrStage<1, [IALUS2]>
  ]>,
  InstrItinData<LdSt,   [InstrStage<1, [LSUS1]>,
                         InstrStage<1, [LSUS2]>,
                         InstrStage<1, [LSUS3]>
  ]>
]>;

def T : Target {
}
/////////////////////////////////////////////////////

tblgen generates wrong itineraries

command:  $(LLVM_BIN)/tblgen  -gen-subtarget -I$(LLVM_SRC)/lib/Target/
-I$(LLVM_SRC)/include bug.td

output:

/////////////////////////////////////////////////////
static llvm::InstrStage Stages[] = {
  { 0, 0 }, // No itinerary
  { 1, IALUS1 },   { 1, IALUS2 }, // 1
  { 1, LSUS1 },   { 1, LSUS2 },   { 1, LSUS3 }, // 2
  { 0, 0 } // End itinerary
};

enum {
  StagesSize = sizeof(Stages)/sizeof(llvm::InstrStage)
};

static llvm::InstrItinerary TItinerariesV0[] = {
  { 1, 3 }, // 0
  { 2, 5 }, // 1
  { 0, 0 } // 2
};
/////////////////////////////////////////////////////

the range { 2, 5 } in TItinerariesV0[] for itinerary #1 clearly refers to the
wrong interval in the Stages array.
The correct range should be { 3, 6 }.


The problem is in in utils/TableGen/SubtargetEmitter.cpp, in function
SubtargetEmitter::EmitStageData, line 349:

      if (Find == 0) {
        // Emit as { cycles, u1 | u2 | ... | un }, // index
        OS << ItinString << ", // " << ItinEnum << "\n";
        // Record Itin class number
HERE!!  ItinMap[ItinString] = Find = ItinEnum++;  <--- bug HERE!!
      }

Indeed, this doesn't work for multi-stage itineraries, as ItinEnum gets
incremented by one, independently on the number of stages.

In attachment I propose a simple fix which takes indeed into account the
correct number of stages.

Thanks.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 12:39:01 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 12:39:01 -0500
Subject: [LLVMbugs] [Bug 2200] Wrong generation of multi-stage Instruction
	Itineraries
In-Reply-To: <bug-2200-206@http.llvm.org/bugs/>
Message-ID: <200804061739.m36Hd1UT014805@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2200


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-06 12:38:59 ---
Thanks, patch applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080331/060717.html

In the future, please send in a diff, not the whole file.  Also, please send in
patches against mainline, not llvm 2.2, thanks!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 14:49:23 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 14:49:23 -0500
Subject: [LLVMbugs] [Bug 2201] New: bugpoint: dump current status to .bc on
	user signal
Message-ID: <bug-2201-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2201

           Summary: bugpoint: dump current status to .bc on user signal
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: bugpoint
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When trying to get a reduced testcase from a large bitcode file, it can take a
very long time till there is a final result.

Being able to stop it and resume later would be a useful feature.

For example, trap SIGUSR1, and dump current status/bitcode file, with
instructions on how to resume.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 15:40:11 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 15:40:11 -0500
Subject: [LLVMbugs] [Bug 2201] bugpoint: dump current status to .bc on user
	signal
In-Reply-To: <bug-2201-206@http.llvm.org/bugs/>
Message-ID: <200804062040.m36KeBxY019654@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2201


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-06 15:40:10 ---
Bugpoint stops gracefully if you ctrl-c it (once, not twice).  I don't think
this is needed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr  6 19:14:02 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 6 Apr 2008 19:14:02 -0500
Subject: [LLVMbugs] [Bug 2202] New: LLVMCreateInterpreter creates a JIT
Message-ID: <bug-2202-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2202

           Summary: LLVMCreateInterpreter creates a JIT
           Product: libraries
           Version: 2.2
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Generic Execution Engine Support
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fvbommel at wxs.nl
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1580)
 --> (http://llvm.org/bugs/attachment.cgi?id=1580)
Patch that changes LLVMCreateInterpreter to actually create an interpreter even
if a JIT can be created.

When using the C bindings, llvm-c/ExecutionEngine.h:LLVMCreateInterpreter()[1]
passes 'false' as the ForceInterpreter parameter to ExecutionEngine::create,
resulting in it returning a JIT instead of an interpreter when the execution
engine is able to create a JIT.
This isn't what the name of the function suggests; especially since there are
also functions named LLVMCreateExecutionEngine and LLVMCreateJITCompiler.


[1]: Implemented in lib/ExecutionEngine/ExecutionEngineBindings.cpp


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr  7 09:21:08 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 7 Apr 2008 09:21:08 -0500
Subject: [LLVMbugs] [Bug 2169] anders-aa wrong result with memcpy
In-Reply-To: <bug-2169-206@http.llvm.org/bugs/>
Message-ID: <200804071421.m37EL8tH026925@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2169


Daniel Berlin <dberlin at dberlin.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Daniel Berlin <dberlin at dberlin.org>  2008-04-07 09:21:07 ---
Fixed


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr  7 11:49:42 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 7 Apr 2008 11:49:42 -0500
Subject: [LLVMbugs] [Bug 2203] New: bit-field access and alignment
Message-ID: <bug-2203-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2203

           Summary: bit-field access and alignment
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dpatel at apple.com
                CC: llvmbugs at cs.uiuc.edu


llvm-gcc-4.2 is not able to handle following test case from gcc dejagnu test
suite.

        struct S1075 {
                unsigned short int a;
                unsigned long long int b:29;
                unsigned long long int c:35;
                unsigned long long int d:31;
        } ;
        struct S1075 s1075;

        void foo() {
                s1075.d = 4;
        }


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr  7 12:02:35 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 7 Apr 2008 12:02:35 -0500
Subject: [LLVMbugs] [Bug 2196] test/CodeGen/X86/vec_shuffle-16.ll fails on
	x86
In-Reply-To: <bug-2196-206@http.llvm.org/bugs/>
Message-ID: <200804071702.m37H2ZTl031947@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2196


Evan Cheng <evan.cheng at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #6 from Evan Cheng <evan.cheng at apple.com>  2008-04-07 12:02:34 ---
Hrm.  I had thought -mattr=+sse also implicitly set -sse2. I've fixed the test
case.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr  7 12:07:14 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 7 Apr 2008 12:07:14 -0500
Subject: [LLVMbugs] [Bug 2204] New: clang: sizeof(int16_t) != 2
Message-ID: <bug-2204-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2204

           Summary: clang: sizeof(int16_t) != 2
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Compile the below testcase with clang, it aborts on Linux x86-64:

#include <stdlib.h>
#include <stdint.h>
int main()
{
        if(sizeof(int16_t) != 2)
                abort();
}


$ /home/edwin/llvm-svn/llvm/tools/clang/utils/ccc foo.c
foo.c
clang -emit-llvm-bc -o foo.o foo.c
llvm-ld -native -disable-internalize -o a.out foo.o
$ ./a.out
Aborted

Look at the declarations of int16_t from the headers, I think that attribute is
not handled.

/home/edwin/llvm-svn/llvm/tools/clang/utils/ccc foo.c -E|grep int16_t
typedef signed short int __int16_t;
typedef unsigned short int __uint16_t;
typedef int int16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned int u_int16_t __attribute__ ((__mode__ (__HI__)));
typedef unsigned short int uint16_t;
 if(sizeof(int16_t) != 2)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr  7 14:02:01 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 7 Apr 2008 14:02:01 -0500
Subject: [LLVMbugs] [Bug 2205] New: linker should handle parameter
	attributes better
Message-ID: <bug-2205-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2205

           Summary: linker should handle parameter attributes better
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Case 1: two declarations.  Consider module a:

declare void @f() nounwind

and module b:

declare void @f()

If you do
  llvm-link a.bc b.bc
then @f is nounwind, while with
  llvm-link b.bc a.bc
it is not nounwind.  It would be safer to
have it not nounwind in both cases.  More
generally, attributes should probably be
"and"'d together when the linker joins two
declarations.

Case 2: declaration and definition.  Consider module a:

declare void @f() nounwind

and module b:

define void @f() {
  ret void
}

Once again whether @f is nounwind in the linked
module depends on the order.  What should happen
is that the attributes from the definition should
win.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr  7 19:40:24 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 7 Apr 2008 19:40:24 -0500
Subject: [LLVMbugs] [Bug 2206] New: The bitwise-instruction optimizer doesn'
 t know about alignment of globals.
Message-ID: <bug-2206-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2206

           Summary: The bitwise-instruction optimizer doesn't know about
                    alignment of globals.
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fvbommel at wxs.nl
                CC: llvmbugs at cs.uiuc.edu


Consider "i64 and (i64 ptrtoint (i64 (i64)* @cons to i64), i64 -8)"[1].
(Where @cons is a global function with an alignment >= 8 specified)
Such expressions aren't simplified by "opt -std-compile-opts", even though the
relevant bits of the ptrtoint result are guaranteed to be zero because of
above-mentioned alignment and similar optimizations are performed if the
pointer is replaced by an integer.


[1]: That expression was shortened for readability, and not actually tested in
this form. The actual expression was "i64 inttoptr (i64 and (i64 or (i64
ptrtoint (i64 (i64)* @cons to i64), i64 1), i64 -8) to i64 (i64)*)".


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr  7 23:41:14 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 7 Apr 2008 23:41:14 -0500
Subject: [LLVMbugs] [Bug 2046] clang incorrectly rejects references to
 earlier parameters in a prototype
In-Reply-To: <bug-2046-206@http.llvm.org/bugs/>
Message-ID: <200804080441.m384fEJF019849@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2046


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
            Summary|clang incorrectly rejects   |clang incorrectly rejects
                   |references to earlier       |references to earlier
                   |paramters in a prototype    |parameters in a prototype




--- Comment #4 from Chris Lattner <sabre at nondot.org>  2008-04-07 23:41:13 ---
Doug fixed this, patch here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080407/005079.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 01:08:18 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 01:08:18 -0500
Subject: [LLVMbugs] [Bug 2207] New: pred_iterator out of range
Message-ID: <bug-2207-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2207

           Summary: pred_iterator out of range
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: critical
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: scottm at aero.org
                CC: llvmbugs at cs.uiuc.edu


This bug occurs when building a bootstrap (i.e., "I'm a n00bie that just
checked llvm out of the svn repo") version of llvm. I was able to narrow the
bug down to two before/after versions:

47988: No assert
47989: Assert gets triggered during 'make check'

To reproduce:
a) Install XCode 2.5 on a x86 Darwin machine (Mac Powerbook with Tiger)
b) check out version 47989 out of the svn repo
c) ./configure --enable-optimized
d) make
e) make check

During make check, the following assert gets triggered in many test cases, not
just one:

Support/CFG.h:64: failed assertion `!It.atEnd() && "pred_iterator out of
range!"


PS: If I had the time to track this down right now, I would.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 01:37:04 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 01:37:04 -0500
Subject: [LLVMbugs] [Bug 2208] New: Compiler warning: control reaches end of
 non-void function
Message-ID: <bug-2208-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2208

           Summary: Compiler warning: control reaches end of non-void
                    function
           Product: libraries
           Version: 2.2
          Platform: Other
        OS/Version: AIX
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Interprocedural Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: andrew at ishiboo.com
                CC: llvmbugs at cs.uiuc.edu


llvm[3]: Compiling Andersens.cpp for Release build
/llvm-2.2/include/llvm/ADT/SparseBitVector.h: In member function `int
llvm::SparseBitVectorElement<ElementSize>::find_first() const [with unsigned
int ElementSize = 128u]':
/llvm-2.2/include/llvm/ADT/SparseBitVector.h:168: warning: control reaches end
of non-void function

A function with an integer return ends in an assert() with no return value.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 01:41:35 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 01:41:35 -0500
Subject: [LLVMbugs] [Bug 2209] New: Compile error due to existing definition
 of FLT_ROUNDS
Message-ID: <bug-2209-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2209

           Summary: Compile error due to existing definition of FLT_ROUNDS
           Product: libraries
           Version: 2.2
          Platform: Other
        OS/Version: AIX
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Transformation Utilities
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: andrew at ishiboo.com
                CC: llvmbugs at cs.uiuc.edu


llvm[3]: Compiling LowerInvoke.cpp for Release build
In file included from /llvm-2.2/include/llvm/Target/TargetLowering.h:25,
                 from LowerInvoke.cpp:49:
/llvm-2.2/include/llvm/CodeGen/SelectionDAGNodes.h:403: error: expected
identifier before numeric constant
/llvm-2.2/include/llvm/CodeGen/SelectionDAGNodes.h:403: error: expected `}'
before numeric constant

Adding the following after the #include statements fixes the error:

#ifdef FLT_ROUNDS
#undef FLT_ROUNDS
#endif

I'm not sure if that is the best way to resolve this, though.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 02:47:40 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 02:47:40 -0500
Subject: [LLVMbugs] [Bug 2208] Compiler warning: control reaches end of
 non-void function
In-Reply-To: <bug-2208-206@http.llvm.org/bugs/>
Message-ID: <200804080747.m387leBu002861@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2208


Bill Wendling <isanbard at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |isanbard at gmail.com
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #3 from Bill Wendling <isanbard at gmail.com>  2008-04-08 02:47:40 ---
These are fixed in the current top of tree.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 02:48:46 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 02:48:46 -0500
Subject: [LLVMbugs] [Bug 2209] Compile error due to existing definition of
	FLT_ROUNDS
In-Reply-To: <bug-2209-206@http.llvm.org/bugs/>
Message-ID: <200804080748.m387mkVp002919@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2209


Bill Wendling <isanbard at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |isanbard at gmail.com
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #1 from Bill Wendling <isanbard at gmail.com>  2008-04-08 02:48:46 ---
This is fixed in the current TOT. We added a "_" on the end of FLT_ROUNDS.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 03:07:50 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 03:07:50 -0500
Subject: [LLVMbugs] [Bug 2210] New: PPCJITInfo.cpp fails to compile on
	Power5 / AIX 5.3
Message-ID: <bug-2210-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2210

           Summary: PPCJITInfo.cpp fails to compile on Power5 / AIX 5.3
           Product: libraries
           Version: 2.2
          Platform: Other
        OS/Version: AIX
            Status: NEW
          Severity: major
          Priority: P2
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: andrew at ishiboo.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1582)
 --> (http://llvm.org/bugs/attachment.cgi?id=1582)
PATCH to fix assembler errors

llvm[3]: Compiling PPCJITInfo.cpp for Release build
Assembler:
/tmp/ccLdO0ra.s: line 4: 1252-016 The specified opcode or pseudo-op is not
valid.
        Use supported instructions or pseudo-ops only.
make[3]: *** [/llvm-2.2/lib/Target/PowerPC/Release/PPCJITInfo.o] Error 1

I investigated and it is complaining about the .text lines. Also, once those
are fixed, it can't resolve the registers by name. Adding .set lines mapping
the registers to register numbers eliminates that problem as well. Generated
assembler  from gcc outputs .csect text[PR], so I switched the .text lines to
those.

I don't have any way of verifying this doesn't break anyone else, but the file
builds clean for me now with this patch.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 03:27:24 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 03:27:24 -0500
Subject: [LLVMbugs] [Bug 2211] New: Regenerating LibDeps.txt.tmp fails on
	AIX 5.3
Message-ID: <bug-2211-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2211

           Summary: Regenerating LibDeps.txt.tmp fails on AIX 5.3
           Product: tools
           Version: 2.2
          Platform: Other
        OS/Version: AIX
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-config
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: andrew at ishiboo.com
                CC: llvmbugs at cs.uiuc.edu


/llvm-2.2/tools/llvm-config $ make
llvm[0]: Regenerating LibDeps.txt.tmp
Usage: nm [-ACfhlprTv] [-B|-P] [-e|-g|-u] [-d|-o|-x|{-t [d|x|o]}]
                [-X{32|64|32_64|d64|any}] [--] File ...
Usage: nm [-ACfhlprTv] [-B|-P] [-e|-g|-u] [-d|-o|-x|{-t [d|x|o]}]
                [-X{32|64|32_64|d64|any}] [--] File ...
Usage: nm [-ACfhlprTv] [-B|-P] [-e|-g|-u] [-d|-o|-x|{-t [d|x|o]}]
                [-X{32|64|32_64|d64|any}] [--] File ...
Usage: nm [-ACfhlprTv] [-B|-P] [-e|-g|-u] [-d|-o|-x|{-t [d|x|o]}]
                [-X{32|64|32_64|d64|any}] [--] File ...
Usage: nm [-ACfhlprTv] [-B|-P] [-e|-g|-u] [-d|-o|-x|{-t [d|x|o]}]
                [-X{32|64|32_64|d64|any}] [--] File ...
...

$(NM_PATH) is set to "/usr/bin/nm -B"

File is just left with:

/llvm-2.2/tools/llvm-config $ cat LibDeps.txt.tmp
libLLVMAnalysis.a:
libLLVMArchive.a:
libLLVMAsmParser.a:
libLLVMBitReader.a:
libLLVMBitWriter.a:
libLLVMCodeGen.a:
libLLVMCore.a:
...


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 11:34:45 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 11:34:45 -0500
Subject: [LLVMbugs] [Bug 1555] Upgrade all llvm assembly files
In-Reply-To: <bug-1555-206@http.llvm.org/bugs/>
Message-ID: <200804081634.m38GYjWk006695@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1555


Tanya Lattner <tonic at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr  8 18:01:50 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 8 Apr 2008 18:01:50 -0500
Subject: [LLVMbugs] [Bug 2212] New: Call result #1 has unhandled type i16
Message-ID: <bug-2212-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2212

           Summary: Call result #1 has unhandled type i16
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: Mac System 9.x
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dpatel at apple.com
                CC: llvmbugs at cs.uiuc.edu


----

target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128"
target triple = "x86_64-apple-darwin9.1.0"
       %struct.S_6 = type { i8, i16 }

define %struct.S_6 @bar() {
       ret i8 1, i16 2
}

define i8 @foo() {
       %c = call %struct.S_6 @bar()
       %mrv_gr = getresult %struct.S_6 %c, 0 
       ret i8 %mrv_gr
}

----

 $ llvm-as < /tmp/a.ll | llc -o /tmp/a.s
Call result #1 has unhandled type i16
0   llc                                 0x00770753
_ZN40_GLOBAL__N_Signals.cpp_00000000_8351965815PrintStackTraceEv + 45
1   llc                                 0x0077094f
_ZN40_GLOBAL__N_Signals.cpp_00000000_8351965813SignalHandlerEi + 323
2   libSystem.B.dylib                   0x930bd97b _sigtramp + 43
3   ???                                 0xffffffff 0x0 + 4294967295
4   libSystem.B.dylib                   0x93136782 raise + 26
5   libSystem.B.dylib                   0x93145d3f abort + 73
6   llc                                 0x003d5f71
_ZN4llvm7CCState17AnalyzeCallResultEPNS_6SDNodeEPFbjjjNS_11CCValAssign7LocInfoENS_3ISD10ArgFlagsTyERS0_E
+ 271
7   llc                                 0x00292492
_ZN4llvm17X86TargetLowering15LowerCallResultENS_9SDOperandES1_PNS_6SDNodeEjRNS_12SelectionDAGE
+ 164
8   llc                                 0x002a7947
_ZN4llvm17X86TargetLowering9LowerCALLENS_9SDOperandERNS_12SelectionDAGE + 12413
9   llc                                 0x002ae25a
_ZN4llvm17X86TargetLowering14LowerOperationENS_9SDOperandERNS_12SelectionDAGE +
2968
10  llc                                 0x0041b80b
_ZNSt6vectorIN4llvm9SDOperandESaIS1_EEC1EmRKS1_RKS2_ + 67669
11  llc                                 0x0046385b
_ZNSt6vectorIN4llvm9SDOperandESaIS1_EEC1EmRKS1_RKS2_ + 362661
12  llc                                 0x00463d5b
_ZNSt6vectorIN4llvm9SDOperandESaIS1_EEC1EmRKS1_RKS2_ + 363941
13  llc                                 0x00463ef8
_ZN4llvm12SelectionDAG8LegalizeEv + 80
14  llc                                 0x004acf31
_ZN4llvm16SelectionDAGISel17CodeGenAndEmitDAGERNS_12SelectionDAGE + 257
15  llc                                 0x004ce412
_ZN4llvm16SelectionDAGISel16SelectBasicBlockEPNS_10BasicBlockERNS_15MachineFunctionERNS_20FunctionLoweringInfoE
+ 196
16  llc                                 0x004cff7b
_ZN4llvm16SelectionDAGISel13runOnFunctionERNS_8FunctionE + 537
17  llc                                 0x002cb44f
_ZN4llvm17X86TargetLoweringD1Ev + 103
18  llc                                 0x006fc771
_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE + 331
19  llc                                 0x006fc9ca
_ZN4llvm23FunctionPassManagerImpl3runERNS_8FunctionE + 110
20  llc                                 0x006fcb48
_ZN4llvm19FunctionPassManager3runERNS_8FunctionE + 156
21  llc                                 0x000031da main + 2586
22  llc                                 0x00002036 start + 54
Abort trap


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  9 04:41:55 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 9 Apr 2008 04:41:55 -0500
Subject: [LLVMbugs] [Bug 1971] EQUIVALENCE not supported in llvm-gfortran
In-Reply-To: <bug-1971-206@http.llvm.org/bugs/>
Message-ID: <200804090941.m399ftDg017039@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1971


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Duncan Sands <baldrick at free.fr>  2008-04-09 04:41:52 ---
Fixed with a suboptimal hack here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080407/060859.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  9 09:40:22 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 9 Apr 2008 09:40:22 -0500
Subject: [LLVMbugs] [Bug 2213] New: gvn fails to detect duplicate bitcast
Message-ID: <bug-2213-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2213

           Summary: gvn fails to detect duplicate bitcast
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Testcase:

define void @f(i8* %x) {
entry:
        %tmp = call i8* @m( i32 12 )            ; <i8*> [#uses=2]
        %tmp1 = bitcast i8* %tmp to i32*                ; <i32*> [#uses=0]
        %tmp2 = bitcast i8* %tmp to i32*                ; <i32*> [#uses=0]
        ret void
}

declare i8* @m(i32)

"opt -gvn" fails to eliminate the second bitcast.  However if you use
%x rather than %tmp in the bitcasts, then the second one is removed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  9 11:42:24 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 9 Apr 2008 11:42:24 -0500
Subject: [LLVMbugs] [Bug 2214] New: Varargs Code Triggers Assertion
Message-ID: <bug-2214-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2214

           Summary: Varargs Code Triggers Assertion
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-g++
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: criswell at uiuc.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1583)
 --> (http://llvm.org/bugs/attachment.cgi?id=1583)
Preprocessed source code that triggers assertion

I get the following assertion when compiling the attached code with llvm-g++ on
Darwin 9.2.0 on PowerPC:

/Users/criswell/box/ppc/llvm-gcc4/bin/llvm-g++ -emit-llvm -S test.i

/Users/criswell/src/llvm22/lib/VMCore/Instructions.cpp:290: failed assertion
`(FTy->getNumParams() == 1 || (FTy->isVarArg() && FTy->getNumParams() == 0)) &&
"Calling a function with bad signature"'
test.cpp: In function 'void funccheck(unsigned int, void*, void*, ...)':
test.cpp:17: internal compiler error: Abort trap
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs> for instructions.

The test case is attached.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  9 13:10:19 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 9 Apr 2008 13:10:19 -0500
Subject: [LLVMbugs] [Bug 2214] Varargs Code Triggers Assertion
In-Reply-To: <bug-2214-206@http.llvm.org/bugs/>
Message-ID: <200804091810.m39IAJkd000426@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2214


Dale Johannesen <dalej at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #3 from Dale Johannesen <dalej at apple.com>  2008-04-09 13:10:19 ---
Nope, still works for me.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr  9 17:58:06 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 9 Apr 2008 17:58:06 -0500
Subject: [LLVMbugs] [Bug 2215] New: ClamAV test reads files from .svn
	directory
Message-ID: <bug-2215-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2215

           Summary: ClamAV test reads files from .svn directory
           Product: Test Suite
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Programs Tests
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


The clamscan program apparently has the behavior of recursively
scanning directories to find input files. Since this test's input files
are currently in a directory in the source tree, this unfortunately
means that the .svn files that are part of the source tree are
found and are read in as part of the test. 

For example, I see this output:

Scanning
...../llvm-test/MultiSource/Applications/ClamAV/inputs/rtf-test/.svn/all-wcprops
...../llvm-test/MultiSource/Applications/ClamAV/inputs/rtf-test/.svn/all-wcprops:
OK

The main problem with this that I've hit is that stuff in the .svn
directory can change between runs, and since the llvm-test
makefiles don't re-run the native version if nothing they know
about has changed, this can cause failures because the new runs
will have different numbers of files to scan.

Theoretically there would also be a problem if something in the .svn
directory looked like a virus to clamscan.

One way to fix this would be to copy the input files into the
Output directory, excluding the .svn directories.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr 10 00:38:34 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 10 Apr 2008 00:38:34 -0500
Subject: [LLVMbugs] [Bug 2108] Horrible x86 codegen for _mm_loadl_epi64
In-Reply-To: <bug-2108-206@http.llvm.org/bugs/>
Message-ID: <200804100538.m3A5cYAM021787@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2108


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from Chris Lattner <sabre at nondot.org>  2008-04-10 00:38:34 ---
Here is a reduced testcase:

define fastcc double @doload64(i64 %x) nounwind  {
entry:
        %tmp717 = bitcast i64 %x to double              ; <double> [#uses=1]
        ret double %tmp717
}

compiles to:

_doload64:
        subl    $12, %esp
        movl    20(%esp), %eax
        movl    %eax, 4(%esp)
        movl    16(%esp), %eax
        movl    %eax, (%esp)
        movsd   (%esp), %xmm0
        addl    $12, %esp
        ret

I moved this to the X86 readme for the x86-32 piece.  The x86-64 piece is
fixed:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080407/060905.html

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr 10 04:20:00 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 10 Apr 2008 04:20:00 -0500
Subject: [LLVMbugs] [Bug 2216] New: llvm-ld triggers bug in llc when used
 with -disable-opt
Message-ID: <bug-2216-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2216

           Summary: llvm-ld triggers bug in llc when used with -disable-opt
           Product: tools
           Version: 2.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P2
         Component: llvm-ld
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: weigert.stefan at gmail.com
                CC: llvmbugs at cs.uiuc.edu


i want to compile mplayer with llvm. when i execute the following command:
llvm-ld -native -O0 --disable-opt --disable-internalize --disable-inlining -o
mplayer mplayer.o m_property.omp_fifo.o mp_msg.o mixer.o parser-mpcmd.o
subopt-helper.o command.o asxparser.o codec-cfg.o cpudetect.o edl.o find_sub.o
get_path.o m_config.o m_option.o m_struct.o mpcommon.o parser-cfg.o playtree.o
playtreeparser.o spudec.o sub_cc.o subreader.o vobsub.o unrarlib.o
libvo/libvo.a libao2/libao2.a input/libinput.a vidix/libvidix.a
libmpcodecs/libmpcodecs.a libaf/libaf.a libmpdemux/libmpdemux.a stream/stream.a
libswscale/libswscale.a libvo/libosd.a libavformat/libavformat.a
libavcodec/libavcodec.a libavutil/libavutil.a libpostproc/libpostproc.a
mp3lib/libmp3.a liba52/liba52.a libmpeg2/libmpeg2.a libfaad2/libfaad2.a
tremor/libvorbisidec.a dvdread/libdvdread.a libdvdcss/libdvdcss.a
libass/libass.a osdep/libosdep.a -lXext -lX11 -lXv -lXinerama -lXxf86vm
-lXxf86dga -lGL -lggi -laa -lcaca -lcucul -lvga -lSDL -ldl -lartsc -lpthread
-lgmodule-2.0 -ldl -lgthread-2.0 -lrt -lglib-2.0 -lesd -laudiofile -laudiofile
-ljack -lopenal -lfaac -lx264 -lmp3lame -L/usr/lib -L/usr/lib -L/usr/lib
-L/usr/lib -Xlinker=-z,noexecstack  -lposix -lposix4  -lncurses -lsmbclient
-lpng -lz -ljpeg -lungif -lasound   -lcdda_interface -lcdda_paranoia -lfreetype
-lz -lfontconfig  -L/usr/lib -lfribidi -lenca -lz -llzo2 -lmad -lspeex 
-ltheora -logg   -ldts -lmpcdec -ldv -lxvidcore -lm   -Xlinker=-export-dynamic
-llirc_client  -lm

i get the following output

llc: SelectionDAG.cpp:476: void llvm::SelectionDAG::DeleteNode(llvm::SDNode*):
Assertion `N->use_empty() && "Cannot delete a node that is not dead!"' failed.
/home/stefan/workspace/ParExC/code/usr/bin/llc[0x855210c]
/lib/tls/i686/cmov/libc.so.6(abort+0x101)[0xb7d30a01]
/lib/tls/i686/cmov/libc.so.6(__assert_fail+0xee)[0xb7d2810e]
/home/stefan/workspace/ParExC/code/usr/bin/llc[0x824bdb3]
llvm-ld:

if you want to test that yourself, get mplayer-1.0 rc2.
run "export CFLAGS="-emit-llvm -c"
run "./configure --cc=llvm-gcc --as=as --ar=llvm-ar --ranlib=llvm-ranlib
--disable-ssse3 --disable-sse --disable-sse2 --disable-mmx --disable-mmxext
--disable-fastmemcpy --disable-shm --disable-3dnow --disable-3dnowext
--disable-pthreads --disable-network --prefix=$HOME/workspace/ParExC/code/usr"
run "make"
it stops when trying to link mplayer

ignore that and execute the llvm-ld command from above


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr 10 17:19:41 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 10 Apr 2008 17:19:41 -0500
Subject: [LLVMbugs] [Bug 2190] llc crashes on
 SingleSource/Benchmarks/Misc-C++/ stepanov_container.cpp
In-Reply-To: <bug-2190-206@http.llvm.org/bugs/>
Message-ID: <200804102219.m3AMJfAF027190@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2190


Owen Anderson <resistor at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #6 from Owen Anderson <resistor at mac.com>  2008-04-10 17:19:40 ---
Fixed in r49499.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 11 00:13:51 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 11 Apr 2008 00:13:51 -0500
Subject: [LLVMbugs] [Bug 2213] gvn fails to detect duplicate bitcast
In-Reply-To: <bug-2213-206@http.llvm.org/bugs/>
Message-ID: <200804110513.m3B5DpsK007420@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2213


Owen Anderson <resistor at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Owen Anderson <resistor at mac.com>  2008-04-11 00:13:51 ---
Fixed in r49516.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 11 03:05:44 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 11 Apr 2008 03:05:44 -0500
Subject: [LLVMbugs] [Bug 2216] llvm-ld triggers bug in llc when used with
	-disable-opt
In-Reply-To: <bug-2216-206@http.llvm.org/bugs/>
Message-ID: <200804110805.m3B85iO2020077@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2216


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #11 from Duncan Sands <baldrick at free.fr>  2008-04-11 03:05:43 ---
I can't reproduce this, so presumably it is fixed in svn.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 11 07:29:45 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 11 Apr 2008 07:29:45 -0500
Subject: [LLVMbugs] [Bug 2217] New: problem with copying empty base classes
Message-ID: <bug-2217-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2217

           Summary: problem with copying empty base classes
           Product: tools
           Version: 2.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jay.foad at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1589)
 --> (http://llvm.org/bugs/attachment.cgi?id=1589)
source file from gcc testsuite

The attached source file is g++.dg/abi/empty4.C from the GCC 4.2.1 testsuite. I
get:

$ ~/llvm/llvm-gcc4.2-2.2-x86-linux-RHEL4/bin/llvm-gcc -g -o empty4 empty4.C
$ ./empty4 ; echo $?
1

The test is failing here:

  if (was != now)
    return 1;   // we copied the empty base which clobbered a.m.m's
                // original value.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 11 10:24:11 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 11 Apr 2008 10:24:11 -0500
Subject: [LLVMbugs] [Bug 2218] New: memcpyopt fails to eliminate pointless
	memcpy's
Message-ID: <bug-2218-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2218

           Summary: memcpyopt fails to eliminate pointless memcpy's
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: resistor at mac.com, llvmbugs at cs.uiuc.edu


Created an attachment (id=1590)
 --> (http://llvm.org/bugs/attachment.cgi?id=1590)
testcase .ll

Here's the testcase (also attached).  %pointless could be
eliminated since no use is ever made of it except as a
memcpy target.  %temporary could also be eliminated in
favour of passing %result directly to the @initialize call.

define void @f(i8* noalias sret  %result) {
entry:
        %temporary = alloca i8          ; <i8*> [#uses=3]
        %pointless = alloca i8          ; <i8*> [#uses=1]
        call void @initialize( i8* noalias sret  %temporary )
        call void @llvm.memcpy.i32( i8* %pointless, i8* %temporary, i32 1, i32
4 )
        call void @llvm.memcpy.i32( i8* %result, i8* %temporary, i32 1, i32 4 )
        ret void
}

declare void @initialize(i8* noalias sret )
declare void @llvm.memcpy.i32(i8*, i8*, i32, i32) nounwind


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 13 04:26:29 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 13 Apr 2008 04:26:29 -0500
Subject: [LLVMbugs] [Bug 2219] New: make test failures on SVN r49608
Message-ID: <bug-2219-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2219

           Summary: make test failures on SVN r49608
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


On Linux lightspeed2 2.6.25-rc8 #5 Tue Apr 8 21:16:47 EEST 2008 x86_64
GNU/Linux:

FAIL: /home/edwin/llvm-svn/llvm/test/Analysis/BasicAA/pure-const-dce.ll
Failed with exit(1) at line 2
while running: llvm-as <
/home/edwin/llvm-svn/llvm/test/Analysis/BasicAA/pure-const-dce.ll | opt
-basicaa -gvn | llvm-dis | grep TestPure  | count 3
count: expected 3 lines and got 4.
child process exited abnormally

FAIL: /home/edwin/llvm-svn/llvm/test/CFrontend/2007-05-07-NestedStructReturn.c
Failed with exit(1) at line 1
while running: /usr/local/bin/llvm-gcc -emit-llvm
/home/edwin/llvm-svn/llvm/test/CFrontend/2007-05-07-NestedStructReturn.c -S
-fnested-functions -o - | grep {sret *%agg.result}
child process exited abnormally

FAIL: /home/edwin/llvm-svn/llvm/test/CFrontend/2008-01-25-ByValReadNone.c
Failed with exit(1) at line 1
while running: /usr/local/bin/llvm-gcc -emit-llvm -O3 -S -o - -emit-llvm
/home/edwin/llvm-svn/llvm/test/CFrontend/2008-01-25-ByValReadNone.c | not grep
readonly
        %tmp3001 = call i32 @g( i32 %x.0.0, i32 %x.0.1, i32 %x.0.2, i32 %x.0.3,
i32 %x.0.4, i32 %x.0.5, i32 %x.0.6, i32 %x.0.7, i32 %x.0.8, i32 %x.0.9, i32
%x.0.10, i32 %x.0.11, i32 %x.0.12, i32 %x.0.13, i32 %x.0.14, i32 %x.0.15, i32
%x.0.16, i32 %x.0.17, i32 %x.0.18, i32 %x.0.19, i32 %x.0.20, i32 %x.0.21, i32
%x.0.22, i32 %x.0.23, i32 %x.0.24, i32 %x.0.25, i32 %x.0.26, i32 %x.0.27, i32
%x.0.28, i32 %x.0.29, i32 %x.0.30, 
...
^This one is known (PR2132)

FAIL: /home/edwin/llvm-svn/llvm/test/CFrontend/2008-04-08-NoExceptions.c
Failed with exit(1) at line 1
while running: /usr/local/bin/llvm-gcc -emit-llvm -S -o -
/home/edwin/llvm-svn/llvm/test/CFrontend/2008-04-08-NoExceptions.c | grep
nounwind | count 2
count: expected 2 lines and got 1.
child process exited abnormally

FAIL: /home/edwin/llvm-svn/llvm/test/CFrontend/sret.c
Failed with exit(1) at line 1
while running: /usr/local/bin/llvm-gcc -emit-llvm
/home/edwin/llvm-svn/llvm/test/CFrontend/sret.c -S -emit-llvm -O0 -o - | grep
sret | count 5
count: expected 5 lines and got 1.
child process exited abnormally

FAIL: /home/edwin/llvm-svn/llvm/test/CFrontend/sret2.c
Failed with exit(1) at line 1
while running: /usr/local/bin/llvm-gcc -emit-llvm
/home/edwin/llvm-svn/llvm/test/CFrontend/sret2.c -S -emit-llvm -O0 -o - | grep
sret | count 2
count: expected 2 lines and got 1.
child process exited abnormally

                ===  Summary ===

# of expected passes            2514
# of unexpected failures        6
# of expected failures          4


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 13 09:39:12 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 13 Apr 2008 09:39:12 -0500
Subject: [LLVMbugs] [Bug 2220] New: Poor diagnostic
Message-ID: <bug-2220-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2220

           Summary: Poor diagnostic
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: minor
          Priority: P2
         Component: preprocessor
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: neil at daikokuya.co.uk
                CC: llvmbugs at cs.uiuc.edu


Clang claims that * is not a valid token in preprocessor expressions, but  it
is of course.  Clang accepted the first one!

$ clang /tmp/expr.c
/tmp/expr.c:1:9: error: token is not valid in preprocessor expressions
#if 1 * * 2
        ^
1 diagnostic generated.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 13 12:27:08 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 13 Apr 2008 12:27:08 -0500
Subject: [LLVMbugs] [Bug 2221] New: Assertion failure when inlining function.
Message-ID: <bug-2221-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2221

           Summary: Assertion failure when inlining function.
           Product: libraries
           Version: 2.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Transformation Utilities
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fvbommel at wxs.nl
                CC: llvmbugs at cs.uiuc.edu


I have some code that generates an assertion failure when I try to run "opt
-inline" on it:
-----
; ModuleID = 'out.bc'

define i64 (i64)* @getFn(i64) {
entry:
        %ptr = inttoptr i64 %0 to i64 (i64)*            ; <i64 (i64)*>
[#uses=1]
        ret i64 (i64)* %ptr
}

define i64 @fn() {
entry:
        %func = call i64 (i64)* (i64)* @getFn( i64 ptrtoint (i64 (i64)* @fn1 to
i64) )          ; <i64 (i64)*> [#uses=1]
        %call = call i64 %func( i64 0 )         ; <i64> [#uses=1]
        ret i64 %call
}

define i64 @fn1(i64) align 4 {
entry:
        ret i64 0
}
-----
$ opt out.bc -o opt.bc -f -inline
opt: CallGraph.cpp:288: void
llvm::CallGraphNode::removeCallEdgeTo(llvm::CallGraphNode*): Assertion `i &&
"Cannot find callee to remove!"' failed.
opt((anonymous namespace)::PrintStackTrace()+0x15)[0x769f75]
opt((anonymous namespace)::SignalHandler(int)+0x216)[0x76a306]
/lib/libc.so.6[0x2ad5f8b017d0]
/lib/libc.so.6(gsignal+0x35)[0x2ad5f8b01765]
/lib/libc.so.6(abort+0x110)[0x2ad5f8b031c0]
/lib/libc.so.6(__assert_fail+0xef)[0x2ad5f8afac2f]
opt(llvm::CallGraph::destroy()+0x0)[0x627ca0]
opt(llvm::InlineFunction(llvm::CallSite, llvm::CallGraph*, llvm::TargetData
const*)+0xc17)[0x5df9f7]
opt(llvm::Inliner::runOnSCC(std::vector<llvm::CallGraphNode*,
std::allocator<llvm::CallGraphNode*> > const&)+0x8c7)[0x4bafd7]
opt(CGPassManager::runOnModule(llvm::Module&)+0x5b8)[0x62a0c8]
opt(llvm::MPPassManager::runOnModule(llvm::Module&)+0x1c5)[0x70cd75]
opt(llvm::PassManagerImpl::run(llvm::Module&)+0x72)[0x70d062]
opt(llvm::PassManager::run(llvm::Module&)+0xc)[0x70d0bc]
opt(main+0x608)[0x493ac8]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2ad5f8aedb44]
opt(sinh+0x41)[0x48cc49]
Aborted (core dumped)

$ opt --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.2
  Optimized build with assertions.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 13 14:40:09 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 13 Apr 2008 14:40:09 -0500
Subject: [LLVMbugs] [Bug 2222] New: llvm-gcc-4.2 fails to pass the unittest
 c++ test suite.
Message-ID: <bug-2222-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2222

           Summary: llvm-gcc-4.2 fails to pass the unittest c++ test suite.
           Product: new-bugs
           Version: unspecified
          Platform: Macintosh
               URL: http://unittest-cpp.sourceforge.net/
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: devchan1 at bellsouth.net
                CC: llvmbugs at cs.uiuc.edu


src/tests/TestTest.cpp:78: error: Failure in
CrashingTestsAreReportedAsFailures: Expected 1 but was 0
FAILURE: 1 out of 169 tests failed (1 failures).
Test time: 0.19 seconds.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 13 15:39:39 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 13 Apr 2008 15:39:39 -0500
Subject: [LLVMbugs] [Bug 2220] Poor diagnostic
In-Reply-To: <bug-2220-206@http.llvm.org/bugs/>
Message-ID: <200804132039.m3DKdd4S002766@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2220


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-13 15:39:38 ---
Fixed, nice catch:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080407/005167.html

We now produce:

t.c:2:9: error: invalid token at start of a preprocessor subexpression
#if 1 * * 2
        ^
t.c:5:7: error: token is not a valid binary operator in a preprocessor
subexpression
#if 4 [ 2
      ^


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 14 04:31:07 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 14 Apr 2008 04:31:07 -0500
Subject: [LLVMbugs] [Bug 2223] New: llc fails on tailcall to function pointer
Message-ID: <bug-2223-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2223

           Summary: llc fails on tailcall to function pointer
           Product: tools
           Version: 2.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fvbommel at wxs.nl
                CC: llvmbugs at cs.uiuc.edu


On my x86_64 linux box, running "llc -tailcallopt" on the following code
generates an assertion failure:
=====
$ llvm-dis -o - llc-tailcallopt-bug.bc
; ModuleID = 'llc-tailcallopt-bug.bc'

define fastcc i64 @call(i64 ()*) {
entry:
        %ptrcall = tail call fastcc i64 %0( )           ; <i64> [#uses=1]
        ret i64 %ptrcall
}
=====
$ llc llc-tailcallopt-bug.bc -f -o llc-tailcallopt-bug.s -tailcallopt
llc: X86ISelLowering.cpp:1487: llvm::SDOperand
llvm::X86TargetLowering::LowerCALL(llvm::SDOperand, llvm::SelectionDAG&):
Assertion `Callee.getOpcode() == ISD::LOAD && "Function destination must be
loaded into virtual register"' failed.
llc((anonymous namespace)::PrintStackTrace()+0x15)[0xae24b5]
llc((anonymous namespace)::SignalHandler(int)+0x216)[0xae2846]
/lib/libc.so.6[0x2ad3bea167d0]
/lib/libc.so.6(gsignal+0x35)[0x2ad3bea16765]
/lib/libc.so.6(abort+0x110)[0x2ad3bea181c0]
/lib/libc.so.6(__assert_fail+0xef)[0x2ad3bea0fc2f]
llc(llvm::X86TargetLowering::LowerCALL(llvm::SDOperand,
llvm::SelectionDAG&)+0x30f0)[0x6ef410]
llc(llvm::X86TargetLowering::LowerOperation(llvm::SDOperand,
llvm::SelectionDAG&)+0x1a1)[0x6fa951]
llc[0x894903]
llc[0x88e75c]
llc[0x8cabed]
llc(llvm::SelectionDAG::Legalize()+0x33)[0x8cb523]
llc(llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)+0x74)[0x83a294]
llc(llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)+0x39f)[0x863b7f]
llc(llvm::SelectionDAGISel::runOnFunction(llvm::Function&)+0x292)[0x8669d2]
llc[0x71c8f3]
llc(llvm::FPPassManager::runOnFunction(llvm::Function&)+0x1ef)[0xa8404f]
llc(llvm::FunctionPassManagerImpl::run(llvm::Function&)+0x72)[0xa84522]
llc(llvm::FunctionPassManager::run(llvm::Function&)+0x3e)[0xa8466e]
llc(main+0xc46)[0x4fc066]
/lib/libc.so.6(__libc_start_main+0xf4)[0x2ad3bea02b44]
llc(cos+0xf9)[0x4fa459]
Aborted (core dumped)
=====
$ llc --version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.2
  Optimized build with assertions.
=====

>From some further experimentation inspired by the error message (it wants
"getOpcode() == ISD::LOAD") it appears this happens whenever the function
pointer isn't a constant but wasn't explicitly loaded from memory (i.e. besides
when the function pointer was passed as a parameter, it also happens when
obtained from inttoptr, but not when the function called is a global constant).


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 14 11:43:56 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 14 Apr 2008 11:43:56 -0500
Subject: [LLVMbugs] [Bug 2222] llvm-gcc-4.2 fails to pass the unittest c++
	test suite.
In-Reply-To: <bug-2222-206@http.llvm.org/bugs/>
Message-ID: <200804141643.m3EGhugJ012969@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2222


Dave Chand <devchan1 at bellsouth.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #3 from Dave Chand <devchan1 at bellsouth.net>  2008-04-14 11:43:56 ---
I must apologize, the test failed because, it was inheriting CXXFLAGS,
from the shell environment and ran using those. If the CXXFLAGS are unset the
llvm-gcc compilers passes the test.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 14 13:17:58 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 14 Apr 2008 13:17:58 -0500
Subject: [LLVMbugs] [Bug 1522] [C++ EH] 471.omnetpp dies at LLC compile on
	X86
In-Reply-To: <bug-1522-206@http.llvm.org/bugs/>
Message-ID: <200804141817.m3EIHwms015995@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1522


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #7 from Chris Lattner <sabre at nondot.org>  2008-04-14 13:17:49 ---
This passes on darwin/x86.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 15 07:14:52 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 15 Apr 2008 07:14:52 -0500
Subject: [LLVMbugs] [Bug 2062] build: cannot build llvm from source on
 read-only file system
In-Reply-To: <bug-2062-206@http.llvm.org/bugs/>
Message-ID: <200804151214.m3FCEqJo023907@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2062


Markus F.X.J. Oberhumer <markus at oberhumer.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #3 from Markus F.X.J. Oberhumer <markus at oberhumer.com>  2008-04-15 07:14:51 ---
I've reopened this bug - as of rev 49724 it seems that lex/yacc still want to
generate files in the source directory.

Makefile.rules probably need some changes to address this issue.


[...]
make[2]: Entering directory
`/home/mfx/tmp/llvm-ro-mount-build-test/lib/AsmParser'
llvm[2]: Bisoning llvmAsmParser.y
/mnt/net/smb-work-ro/cvs/llvm/llvm/llvm/lib/AsmParser/llvmAsmParser.y:
conflicts: 4 shift/reduce, 118 reduce/reduce
/bin/mv: cannot create regular file
`/mnt/net/smb-work-ro/cvs/llvm/llvm/llvm/lib/AsmParser/llvmAsmParser.cpp':
Read-only file system
make[2]: ***
[/mnt/net/smb-work-ro/cvs/llvm/llvm/llvm/lib/AsmParser/llvmAsmParser.h] Error 1
make[2]: Leaving directory
`/home/mfx/tmp/llvm-ro-mount-build-test/lib/AsmParser'
make[1]: *** [AsmParser/.makeall] Error 2
make[1]: Leaving directory `/home/mfx/tmp/llvm-ro-mount-build-test/lib'
make: *** [all] Error 1


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 15 14:10:50 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 15 Apr 2008 14:10:50 -0500
Subject: [LLVMbugs] [Bug 2224] New: Buffer overflow in WriteConstantInt
Message-ID: <bug-2224-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2224

           Summary: Buffer overflow in WriteConstantInt
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Detected by running the testcase
test/CFrontend/2008-01-21-PackedStructField.c
under valgrind:

Invalid read of size 4
   at 0x8A926B0: WriteConstantInt(std::ostream&, llvm::Constant const*,
std::map<llvm::Type const*, std::string, std::less<llvm::Type const*>,
std::allocator<std::pair<llvm::Type const* const, std::string> > >&,
llvm::SlotMachine*) (AsmWriter.cpp:531)
   by 0x8A8F170: WriteAsOperandInternal(std::ostream&, llvm::Value const*,
std::map<llvm::Type const*, std::string, std::less<llvm::Type const*>,
std::allocator<std::pair<llvm::Type const* const, std::string> > >&,
llvm::SlotMachine*) (AsmWriter.cpp:654)
   by 0x8A92A44: WriteConstantInt(std::ostream&, llvm::Constant const*,
std::map<llvm::Type const*, std::string, std::less<llvm::Type const*>,
std::allocator<std::pair<llvm::Type const* const, std::string> > >&,
llvm::SlotMachine*) (AsmWriter.cpp:579)
   by 0x8A8F170: WriteAsOperandInternal(std::ostream&, llvm::Value const*,
std::map<llvm::Type const*, std::string, std::less<llvm::Type const*>,
std::allocator<std::pair<llvm::Type const* const, std::string> > >&,
llvm::SlotMachine*) (AsmWriter.cpp:654)
   by 0x8A8F4AA: llvm::AssemblyWriter::writeOperand(llvm::Value const*, bool)
(AsmWriter.cpp:837)
   by 0x8A91A6D: llvm::AssemblyWriter::printGlobal(llvm::GlobalVariable const*)
(AsmWriter.cpp:959)
   by 0x8A92079: llvm::AssemblyWriter::printModule(llvm::Module const*)
(AsmWriter.cpp:908)
   by 0x8A962B1: llvm::AssemblyWriter::write(llvm::Module const*)
(AsmWriter.cpp:735)
   by 0x8A93445: llvm::Module::print(std::ostream&,
llvm::AssemblyAnnotationWriter*) const (AsmWriter.cpp:1462)
   by 0x8410199: llvm::PrintModulePass::runOnModule(llvm::Module&)
(Module.h:353)
   by 0x8AEECF1: llvm::MPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1248)
   by 0x8AEEEA9: llvm::PassManagerImpl::run(llvm::Module&)
(PassManager.cpp:1322)

 Address 0x433b26c is 4 bytes after a block of size 16 alloc'd
   at 0x4022F44: operator new[](unsigned) (vg_replace_malloc.c:268)
   by 0x8B2D0DF: getClearedMemory(unsigned) (APInt.cpp:40)
   by 0x8B3559E: llvm::APInt::APInt(unsigned, unsigned, unsigned long long
const*) (APInt.cpp:79)
   by 0x8B2527F: llvm::APFloat::convertF80LongDoubleAPFloatToAPInt() const
(APFloat.cpp:2489)
   by 0x8B25341: llvm::APFloat::convertToAPInt() const (APFloat.cpp:2614)
   by 0x8A925FB: WriteConstantInt(std::ostream&, llvm::Constant const*,
std::map<llvm::Type const*, std::string, std::less<llvm::Type const*>,
std::allocator<std::pair<llvm::Type const* const, std::string> > >&,
llvm::SlotMachine*) (AsmWriter.cpp:519)
   by 0x8A8F170: WriteAsOperandInternal(std::ostream&, llvm::Value const*,
std::map<llvm::Type const*, std::string, std::less<llvm::Type const*>,
std::allocator<std::pair<llvm::Type const* const, std::string> > >&,
llvm::SlotMachine*) (AsmWriter.cpp:654)
   by 0x8A92A44: WriteConstantInt(std::ostream&, llvm::Constant const*,
std::map<llvm::Type const*, std::string, std::less<llvm::Type const*>,
std::allocator<std::pair<llvm::Type const* const, std::string> > >&,
llvm::SlotMachine*) (AsmWriter.cpp:579)
   by 0x8A8F170: WriteAsOperandInternal(std::ostream&, llvm::Value const*,
std::map<llvm::Type const*, std::string, std::less<llvm::Type const*>,
std::allocator<std::pair<llvm::Type const* const, std::string> > >&,
llvm::SlotMachine*) (AsmWriter.cpp:654)
   by 0x8A8F4AA: llvm::AssemblyWriter::writeOperand(llvm::Value const*, bool)
(AsmWriter.cpp:837)
   by 0x8A91A6D: llvm::AssemblyWriter::printGlobal(llvm::GlobalVariable const*)
(AsmWriter.cpp:959)
   by 0x8A92079: llvm::AssemblyWriter::printModule(llvm::Module const*)
(AsmWriter.cpp:908)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 15 14:38:24 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 15 Apr 2008 14:38:24 -0500
Subject: [LLVMbugs] [Bug 2225] New: Use-after-free in removeIntervalIfEmpty
Message-ID: <bug-2225-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2225

           Summary: Use-after-free in removeIntervalIfEmpty
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running the testcase 2007-03-27-RegScavengerAssert.ll under valgrind shows
removeIntervalIfEmpty (SimpleRegisterCoalescing.cpp:557) reading from memory
freed by removeInterval (LiveIntervalAnalysis.h:227):

$ llvm-as < 2007-03-27-RegScavengerAssert.ll -o - | valgrind
~/LLVM/llvm-objects/Debug/bin/llc -march=arm -mtriple=arm-linux-gnueabi
...
Invalid read of size 4
   at 0x88F896E: removeIntervalIfEmpty(llvm::LiveInterval&,
llvm::LiveIntervals*, llvm::TargetRegisterInfo const*)
(SimpleRegisterCoalescing.cpp:557)
   by 0x88FB6A8:
llvm::SimpleRegisterCoalescing::ShortenDeadCopySrcLiveRange(llvm::LiveInterval&,
llvm::MachineInstr*) (SimpleRegisterCoalescing.cpp:670)
   by 0x88FF162:
llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&)
(SimpleRegisterCoalescing.cpp:1940)
   by 0x842728B: llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(MachineFunctionPass.h:41)
   by 0x8A3AAD6: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1178)
   by 0x8A3AD33: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1133)
   by 0x8A3AE8A: llvm::FunctionPassManager::run(llvm::Function&)
(PassManager.cpp:1078)
   by 0x83D50CA: main (llc.cpp:296)

 Address 0x430eb88 is 32 bytes inside a block of size 144 free'd
   at 0x402231C: operator delete(void*) (vg_replace_malloc.c:342)
   by 0x89025A2: __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<unsigned
const, llvm::LiveInterval> >
>::deallocate(std::_Rb_tree_node<std::pair<unsigned const, llvm::LiveInterval>
>*, unsigned) (new_allocator.h:97)
   by 0x89025C7: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> >
>::_M_put_node(std::_Rb_tree_node<std::pair<unsigned const, llvm::LiveInterval>
>*) (stl_tree.h:371)
   by 0x890294B: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> >
>::_M_destroy_node(std::_Rb_tree_node<std::pair<unsigned const,
llvm::LiveInterval> >*) (stl_tree.h:401)
   by 0x8904CBD: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> > >::erase(std::_Rb_tree_iterator<std::pair<unsigned
const, llvm::LiveInterval> >) (stl_tree.h:1248)
   by 0x8905AD1: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> > >::erase(std::_Rb_tree_iterator<std::pair<unsigned
const, llvm::LiveInterval> >, std::_Rb_tree_iterator<std::pair<unsigned const,
llvm::LiveInterval> >) (stl_tree.h:1340)
   by 0x8905B32: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> > >::erase(unsigned const&) (stl_tree.h:1274)
   by 0x8905B5F: std::map<unsigned, llvm::LiveInterval, std::less<unsigned>,
std::allocator<std::pair<unsigned const, llvm::LiveInterval> >
>::erase(unsigned const&) (stl_map.h:469)
   by 0x8905B7C: llvm::LiveIntervals::removeInterval(unsigned)
(LiveIntervalAnalysis.h:227)
   by 0x88F896A: removeIntervalIfEmpty(llvm::LiveInterval&,
llvm::LiveIntervals*, llvm::TargetRegisterInfo const*)
(SimpleRegisterCoalescing.cpp:556)
   by 0x88FB6A8:
llvm::SimpleRegisterCoalescing::ShortenDeadCopySrcLiveRange(llvm::LiveInterval&,
llvm::MachineInstr*) (SimpleRegisterCoalescing.cpp:670)
   by 0x88FF162:
llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&)
(SimpleRegisterCoalescing.cpp:1940)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 15 20:06:50 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 15 Apr 2008 20:06:50 -0500
Subject: [LLVMbugs] [Bug 2226] New: use of uninitialized variables in
 SimpleRegisterCoalescing. cpp
Message-ID: <bug-2226-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2226

           Summary: use of uninitialized variables in
                    SimpleRegisterCoalescing.cpp
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


SimpleRegisterCoalescing.cpp at line 1937 calls TargetInstrInfo::isMoveInstr
to get the source and destination registers of a move without checking
the result value to see if the instruction was actually a move. It looks like
it should be, but currently there are cases where this assumption doesn't
hold. When it doesn't the following code ends up referencing the
variables uninitialized.

For example, when compiling
test/CodeGen/Generic/2003-07-08-BadCastToBool.ll
on x86 the code at line 1073 inserts a non-move instruction into
JoinedCopies.

The attached patch demonstrates the problem by using an assert.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 15 20:22:59 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 15 Apr 2008 20:22:59 -0500
Subject: [LLVMbugs] [Bug 2225] Use-after-free in removeIntervalIfEmpty
In-Reply-To: <bug-2225-206@http.llvm.org/bugs/>
Message-ID: <200804160122.m3G1MxKB016643@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2225


Evan Cheng <evan.cheng at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Evan Cheng <evan.cheng at apple.com>  2008-04-15 20:22:59 ---
Doh. Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061144.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 12:19:44 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 12:19:44 -0500
Subject: [LLVMbugs] [Bug 2227] New: Use of uninitialized variable in
 ParseSubtargetFeatures ( X86Subtarget)
Message-ID: <bug-2227-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2227

           Summary: Use of uninitialized variable in ParseSubtargetFeatures
                    (X86Subtarget)
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/CodeGen/X86/2007-07-10-StackerAssert.ll under valgrind gives:

Conditional jump or move depends on uninitialised value(s)
   at 0x8732294: llvm::X86Subtarget::ParseSubtargetFeatures(std::string const&,
std::string const&) (X86GenSubtarget.inc:100)
   by 0x8732498: llvm::X86Subtarget::X86Subtarget(llvm::Module const&,
std::string const&, bool) (X86Subtarget.cpp:256)
   by 0x87348D2: llvm::X86TargetMachine::X86TargetMachine(llvm::Module const&,
std::string const&, bool) (X86TargetMachine.cpp:120)
   by 0x8734BE8: llvm::X86_32TargetMachine::X86_32TargetMachine(llvm::Module
const&, std::string const&) (X86TargetMachine.cpp:104)
   by 0x87409D6:
llvm::RegisterTarget<llvm::X86_32TargetMachine>::Allocator(llvm::Module const&,
std::string const&) (TargetMachineRegistry.h:90)
   by 0x83D4B17: main (llc.cpp:221)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 12:24:27 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 12:24:27 -0500
Subject: [LLVMbugs] [Bug 2228] New: Use of uninitialized value in
 findRegisterDefOperandIdx
Message-ID: <bug-2228-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2228

           Summary: Use of uninitialized value in findRegisterDefOperandIdx
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/CodeGen/X86/2008-03-23-DarwinAsmComments.ll under valgrind shows:

Conditional jump or move depends on uninitialised value(s)
   at 0x88B1F99: llvm::MachineInstr::findRegisterDefOperandIdx(unsigned, bool,
llvm::TargetRegisterInfo const*) const (MachineInstr.cpp:565)
   by 0x8904B38: llvm::MachineInstr::registerDefIsDead(unsigned,
llvm::TargetRegisterInfo const*) const (MachineInstr.h:169)
   by 0x88FF124:
llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&)
(SimpleRegisterCoalescing.cpp:1938)
   by 0x842728B: llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(MachineFunctionPass.h:41)
   by 0x8A3AAD6: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1178)
   by 0x8A3AD33: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1133)
   by 0x8A3AE8A: llvm::FunctionPassManager::run(llvm::Function&)
(PassManager.cpp:1078)
   by 0x83D50CA: main (llc.cpp:296)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 12:27:49 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 12:27:49 -0500
Subject: [LLVMbugs] [Bug 2229] New: Use of uninitialized value in
 bitwiseIsEqual from visitFMUL
Message-ID: <bug-2229-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2229

           Summary: Use of uninitialized value in bitwiseIsEqual from
                    visitFMUL
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/CodeGen/PowerPC/ppcf128-4.ll under valgrind shows:

Conditional jump or move depends on uninitialised value(s)
   at 0x8A700E2: llvm::APFloat::bitwiseIsEqual(llvm::APFloat const&) const
(APFloat.cpp:631)
   by 0x87B1342: llvm::ConstantFPSDNode::isExactlyValue(llvm::APFloat const&)
const (SelectionDAG.cpp:70)
   by 0x854E707: llvm::ConstantFPSDNode::isExactlyValue(double) const
(SelectionDAGNodes.h:1446)
   by 0x877E2EF: (anonymous namespace)::DAGCombiner::visitFMUL(llvm::SDNode*)
(DAGCombiner.cpp:3667)
   by 0x877F6CB: (anonymous namespace)::DAGCombiner::visit(llvm::SDNode*)
(DAGCombiner.cpp:715)
   by 0x877F9A2: (anonymous namespace)::DAGCombiner::combine(llvm::SDNode*)
(DAGCombiner.cpp:743)
   by 0x878120C: (anonymous namespace)::DAGCombiner::Run(bool)
(DAGCombiner.cpp:622)
   by 0x87815F6: llvm::SelectionDAG::Combine(bool, llvm::AliasAnalysis&)
(DAGCombiner.cpp:5545)
   by 0x87BDE10: llvm::SelectionDAGISel::CodeGenAndEmitDAG(llvm::SelectionDAG&)
(SelectionDAGISel.cpp:4704)
   by 0x87D690E: llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::MachineFunction&, llvm::FunctionLoweringInfo&)
(SelectionDAGISel.cpp:4748)
   by 0x87D8935: llvm::SelectionDAGISel::runOnFunction(llvm::Function&)
(SelectionDAGISel.cpp:4414)
   by 0x85B0282: (anonymous
namespace)::PPCDAGToDAGISel::runOnFunction(llvm::Function&)
(PPCISelDAGToDAG.cpp:56)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 12:34:49 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 12:34:49 -0500
Subject: [LLVMbugs] [Bug 2224] Buffer overflow in WriteConstantInt
In-Reply-To: <bug-2224-206@http.llvm.org/bugs/>
Message-ID: <200804161734.m3GHYnUn025133@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2224


Dale Johannesen <dalej at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Dale Johannesen <dalej at apple.com>  2008-04-16 12:34:48 ---
Didn't mean to save so soon, I hate bugzilla.  

My bad, above patch should fix it, please confirm.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 13:49:00 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 13:49:00 -0500
Subject: [LLVMbugs] [Bug 2226] use of uninitialized variables in
 SimpleRegisterCoalescing.cpp
In-Reply-To: <bug-2226-206@http.llvm.org/bugs/>
Message-ID: <200804161849.m3GIn0R9030359@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2226


Evan Cheng <evan.cheng at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Evan Cheng <evan.cheng at apple.com>  2008-04-16 13:49:00 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061177.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 14:03:40 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 14:03:40 -0500
Subject: [LLVMbugs] [Bug 2227] Use of uninitialized variable in
 ParseSubtargetFeatures ( X86Subtarget)
In-Reply-To: <bug-2227-206@http.llvm.org/bugs/>
Message-ID: <200804161903.m3GJ3emi031481@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2227


Evan Cheng <evan.cheng at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |evan.cheng at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Evan Cheng <evan.cheng at apple.com>  2008-04-16 14:03:39 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061180.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 15:11:05 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 15:11:05 -0500
Subject: [LLVMbugs] [Bug 2225] Use-after-free in removeIntervalIfEmpty
In-Reply-To: <bug-2225-206@http.llvm.org/bugs/>
Message-ID: <200804162011.m3GKB5hB004619@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2225


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #2 from Duncan Sands <baldrick at free.fr>  2008-04-16 15:11:04 ---
Memory freed by removeInterval is still being used, but now by
FindLiveRangeContaining, so it seems best to re-open this bug.

Invalid read of size 4
   at 0x8852766: llvm::SmallVectorImpl<llvm::LiveRange>::end()
(SmallVector.h:106)
   by 0x885277F: llvm::LiveInterval::end() (LiveInterval.h:118)
   by 0x88940DF: llvm::LiveInterval::FindLiveRangeContaining(unsigned)
(LiveInterval.cpp:351)
   by 0x886BEC9:
llvm::SimpleRegisterCoalescing::ShortenDeadCopyLiveRange(llvm::LiveInterval&,
llvm::MachineInstr*) (SimpleRegisterCoalescing.cpp:585)
   by 0x886FABA:
llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&)
(SimpleRegisterCoalescing.cpp:1956)
   by 0x8421FEB: llvm::MachineFunctionPass::runOnFunction(llvm::Function&)
(MachineFunctionPass.h:41)
   by 0x89AB822: llvm::FPPassManager::runOnFunction(llvm::Function&)
(PassManager.cpp:1178)
   by 0x89ABA7F: llvm::FunctionPassManagerImpl::run(llvm::Function&)
(PassManager.cpp:1133)
   by 0x89ABBD6: llvm::FunctionPassManager::run(llvm::Function&)
(PassManager.cpp:1078)
   by 0x83D35F1: main (llc.cpp:297)
 Address 0x4306c6c is 52 bytes inside a block of size 144 free'd
   at 0x402231C: operator delete(void*) (vg_replace_malloc.c:342)
   by 0x8872EDE: __gnu_cxx::new_allocator<std::_Rb_tree_node<std::pair<unsigned
const, llvm::LiveInterval> >
>::deallocate(std::_Rb_tree_node<std::pair<unsigned const, llvm::LiveInterval>
>*, unsigned) (new_allocator.h:97)
   by 0x8872F03: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> >
>::_M_put_node(std::_Rb_tree_node<std::pair<unsigned const, llvm::LiveInterval>
>*) (stl_tree.h:371)
   by 0x8873287: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> >
>::_M_destroy_node(std::_Rb_tree_node<std::pair<unsigned const,
llvm::LiveInterval> >*) (stl_tree.h:401)
   by 0x88755F9: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> > >::erase(std::_Rb_tree_iterator<std::pair<unsigned
const, llvm::LiveInterval> >) (stl_tree.h:1248)
   by 0x887640D: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> > >::erase(std::_Rb_tree_iterator<std::pair<unsigned
const, llvm::LiveInterval> >, std::_Rb_tree_iterator<std::pair<unsigned const,
llvm::LiveInterval> >) (stl_tree.h:1340)
   by 0x887646E: std::_Rb_tree<unsigned, std::pair<unsigned const,
llvm::LiveInterval>, std::_Select1st<std::pair<unsigned const,
llvm::LiveInterval> >, std::less<unsigned>, std::allocator<std::pair<unsigned
const, llvm::LiveInterval> > >::erase(unsigned const&) (stl_tree.h:1274)
   by 0x887649B: std::map<unsigned, llvm::LiveInterval, std::less<unsigned>,
std::allocator<std::pair<unsigned const, llvm::LiveInterval> >
>::erase(unsigned const&) (stl_map.h:469)
   by 0x88764B8: llvm::LiveIntervals::removeInterval(unsigned)
(LiveIntervalAnalysis.h:227)
   by 0x88691CA: removeIntervalIfEmpty(llvm::LiveInterval&,
llvm::LiveIntervals*, llvm::TargetRegisterInfo const*)
(SimpleRegisterCoalescing.cpp:575)
   by 0x886BE88:
llvm::SimpleRegisterCoalescing::ShortenDeadCopySrcLiveRange(llvm::LiveInterval&,
llvm::MachineInstr*) (SimpleRegisterCoalescing.cpp:681)
   by 0x886FA9E:
llvm::SimpleRegisterCoalescing::runOnMachineFunction(llvm::MachineFunction&)
(SimpleRegisterCoalescing.cpp:1955)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 15:17:00 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 15:17:00 -0500
Subject: [LLVMbugs] [Bug 2228] Use of uninitialized value in
	findRegisterDefOperandIdx
In-Reply-To: <bug-2228-206@http.llvm.org/bugs/>
Message-ID: <200804162017.m3GKH0XT005135@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2228


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Duncan Sands <baldrick at free.fr>  2008-04-16 15:16:59 ---
I can't reproduce this with an up-to-date tree, so it looks like it was
already fixed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 18:41:54 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 18:41:54 -0500
Subject: [LLVMbugs] [Bug 2207] pred_iterator out of range
In-Reply-To: <bug-2207-206@http.llvm.org/bugs/>
Message-ID: <200804162341.m3GNfsSL021983@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2207


Scott Michel <scottm at aero.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #11 from Scott Michel <scottm at aero.org>  2008-04-16 18:41:54 ---
Tracked down the trigger for the pred_iterator assert to llvm::isCriticalEdge
in BreakCriticalEdges.cpp. The patch seems to work around the gcc 4.0.1 bug and
'make check' runs through to completion.

I'll commit it (unless something else untoward happens, at which point it's
easy to back out).


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 16 19:29:25 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 16 Apr 2008 19:29:25 -0500
Subject: [LLVMbugs] [Bug 2230] New: va_copy on x86-64
Message-ID: <bug-2230-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2230

           Summary: va_copy on x86-64
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


For this testcase:

#include <stdarg.h>
void foo(va_list *a, va_list *b) {
  va_copy(*a, *b);
}

llvm-gcc -m64 emits this:

define void @foo([1 x %struct.__va_list_tag]* %a, [1 x %struct.__va_list_tag]*
%b) nounwind  {
entry:
        %memtmp = alloca %struct.__va_list_tag*
        %tmp1 = getelementptr [1 x %struct.__va_list_tag]* %b, i32 0, i32 0     
        store %struct.__va_list_tag* %tmp1, %struct.__va_list_tag** %memtmp
        %tmp234 = bitcast [1 x %struct.__va_list_tag]* %a to i8*
        %memtmp5 = bitcast %struct.__va_list_tag** %memtmp to i8*
        call void @llvm.va_copy( i8* %tmp234, i8* %memtmp5 )
        ret void
}

It's storing the second argument to a stack location, and passing the address
of that location to @llvm.va_copy instead of passing the value of the second
argument itself.

The LLVM Language Reference entry for va_copy says that
"The second argument is a pointer to a va_list element to copy from."

As it happens, LLVM codegen is currently compensating for this bug by
performing an extra load on the second argument. As a result, the llvm-gcc
compiler produces correct code, but the intermediate form is incorrect and
other frontends won't work properly.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 18 09:03:44 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 18 Apr 2008 09:03:44 -0500
Subject: [LLVMbugs] [Bug 2231] New: opt -internalize -std-compile-opts
 should run internalize first
Message-ID: <bug-2231-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2231

           Summary: opt -internalize -std-compile-opts should run
                    internalize first
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


If you run
  opt -internalize -std-compile-opts
then internalize is run after the standard passes.
It would be convenient if it was run first.  More
generally it would be nice if
  opt -pass1 ... -passN -std-compile-opts -passN+1 ... -passM
would result in passes 1 .. N being run, then
the standard passes, then passes N+1 .. M.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 18 11:06:33 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 18 Apr 2008 11:06:33 -0500
Subject: [LLVMbugs] [Bug 2232] New: empty MBB results in incorrect
 MBB2IdxMap and Idx2MBBMap
Message-ID: <bug-2232-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2232

           Summary: empty MBB results in incorrect MBB2IdxMap and Idx2MBBMap
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: scott.llvm at h4ck3r.net
                CC: llvmbugs at cs.uiuc.edu


In the LiveIntervalAnalysis::runOnMachineFunction, there is a code to
compute the MBB2IdxMap and Idx2MBBMap, by remembering for each MBB its start
and end instruction numbers.

If an MBB is empty, the end index will be larger than the start in MBB2IdxMap,
and multiple entries of .first Idx2MBBMap will identical. On some platforms
this causes an assert later (in e.g. LiveIntervals::findLiveinMBBs
std::lower_bound), and possibly incorrect search behaviour.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 18 15:57:14 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 18 Apr 2008 15:57:14 -0500
Subject: [LLVMbugs] [Bug 2230] va_copy on x86-64
In-Reply-To: <bug-2230-206@http.llvm.org/bugs/>
Message-ID: <200804182057.m3IKvE7R011991@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2230


Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Dan Gohman <gohman at apple.com>  2008-04-18 15:57:13 ---
Fixed with these two commits:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061247.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061249.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 18 18:20:37 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 18 Apr 2008 18:20:37 -0500
Subject: [LLVMbugs] [Bug 2233] New: LLVMTutorial1 references to IRBuilder
 while LLVMBuilder is the right name
Message-ID: <bug-2233-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2233

           Summary: LLVMTutorial1 references to IRBuilder while LLVMBuilder
                    is the right name
           Product: Documentation
           Version: trunk
          Platform: All
               URL: http://llvm.org/docs/tutorial/JITTutorial1.html
        OS/Version: All
            Status: NEW
          Severity: trivial
          Priority: P2
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: avuori at cs.helsinki.fi
                CC: llvmbugs at cs.uiuc.edu


The example code will compile fine after replacing all IRBuilder references to
LLVMBuilder references.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 18 22:59:47 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 18 Apr 2008 22:59:47 -0500
Subject: [LLVMbugs] [Bug 2233] LLVMTutorial1 references to IRBuilder while
 LLVMBuilder is the right name
In-Reply-To: <bug-2233-206@http.llvm.org/bugs/>
Message-ID: <200804190359.m3J3xlqO025182@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2233


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-18 22:59:47 ---
IRBuilder is correct for SVN head.  If you're working with llvm 2.2, use the
snapshot of the tutorial from your tree.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr 19 02:08:41 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 19 Apr 2008 02:08:41 -0500
Subject: [LLVMbugs] [Bug 2199] llvm-test/MultiSource/Benchmarks/MiBench/
 security-rijndael fails on x86-64
In-Reply-To: <bug-2199-206@http.llvm.org/bugs/>
Message-ID: <200804190708.m3J78fLu029991@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2199


T??r??k Edwin <edwintorok at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #10 from T??r??k Edwin <edwintorok at gmail.com>  2008-04-19 02:08:40 ---
(In reply to comment #9)
> Very nice! Please commit the fix.
> 

Applied in r49952.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr 19 02:18:04 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 19 Apr 2008 02:18:04 -0500
Subject: [LLVMbugs] [Bug 2156] x86-64
	test/CodeGen/X86/2006-05-02-InstrSched2.ll fails
In-Reply-To: <bug-2156-206@http.llvm.org/bugs/>
Message-ID: <200804190718.m3J7I4gZ030264@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2156


T??r??k Edwin <edwintorok at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #1 from T??r??k Edwin <edwintorok at gmail.com>  2008-04-19 02:18:03 ---
This test no longer fails, and it doesn't fail with the attached testcase
either.
Closing.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr 19 14:35:44 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 19 Apr 2008 14:35:44 -0500
Subject: [LLVMbugs] [Bug 2234] New: llvm-gcc duplicates code for no reason?
Message-ID: <bug-2234-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2234

           Summary: llvm-gcc duplicates code for no reason?
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


Consider:
extern int bar (); 
volatile int w; 
int bar (void) { 
if (bar()) 
return 0; 
else 
return w; 
}

-O0 with opt -std-compile-opts compiles this to very reasonable code:

...
define i32 @bar() nounwind  {
entry:
        %tmp1 = tail call i32 @bar( ) nounwind          ; <i32> [#uses=1]
        %tmp2 = icmp eq i32 %tmp1, 0            ; <i1> [#uses=1]
        br i1 %tmp2, label %bb4, label %UnifiedReturnBlock
bb4:            ; preds = %entry
        %tmp5 = volatile load i32* @w, align 4          ; <i32> [#uses=1]
        ret i32 %tmp5
UnifiedReturnBlock:             ; preds = %entry
        ret i32 0
}


When using llvm-gcc -O3 however, I get this crazy code:

define i32 @bar() nounwind  {
entry:
        %tmp17 = tail call i32 @bar( ) nounwind                 ; <i32>
[#uses=1]
        %tmp18 = icmp eq i32 %tmp17, 0          ; <i1> [#uses=1]
        br i1 %tmp18, label %bb20, label %bb29
bb20:           ; preds = %entry
        %tmp21 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        %phitmp103 = icmp eq i32 %tmp21, 0              ; <i1> [#uses=1]
        br i1 %phitmp103, label %bb29, label %bb38
bb29:           ; preds = %bb20, %entry
        %tmp30 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        %phitmp102 = icmp eq i32 %tmp30, 0              ; <i1> [#uses=1]
        br i1 %phitmp102, label %bb38, label %bb47
bb38:           ; preds = %bb29, %bb20
        %tmp39 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        %phitmp101 = icmp eq i32 %tmp39, 0              ; <i1> [#uses=1]
        br i1 %phitmp101, label %bb47, label %bb56
bb47:           ; preds = %bb38, %bb29
        %tmp48 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        %phitmp100 = icmp eq i32 %tmp48, 0              ; <i1> [#uses=1]
        br i1 %phitmp100, label %bb56, label %bb65
bb56:           ; preds = %bb47, %bb38
        %tmp57 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        %phitmp99 = icmp eq i32 %tmp57, 0               ; <i1> [#uses=1]
        br i1 %phitmp99, label %bb65, label %bb74
bb65:           ; preds = %bb56, %bb47
        %tmp66 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        %phitmp98 = icmp eq i32 %tmp66, 0               ; <i1> [#uses=1]
        br i1 %phitmp98, label %bb74, label %bb83
bb74:           ; preds = %bb65, %bb56
        %tmp75 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        %phitmp97 = icmp eq i32 %tmp75, 0               ; <i1> [#uses=1]
        br i1 %phitmp97, label %bb83, label %bb92
bb83:           ; preds = %bb74, %bb65
        %tmp84 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        %phitmp = icmp eq i32 %tmp84, 0         ; <i1> [#uses=1]
        br i1 %phitmp, label %bb92, label %UnifiedReturnBlock
bb92:           ; preds = %bb83, %bb74
        %tmp93 = volatile load i32* @w, align 4         ; <i32> [#uses=1]
        ret i32 %tmp93
UnifiedReturnBlock:             ; preds = %bb83
        ret i32 0
}

This is a miscompilation, because it causes multiple accesses to the volatile
value, and seems pretty pointless in general.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr 19 17:18:26 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 19 Apr 2008 17:18:26 -0500
Subject: [LLVMbugs] [Bug 2206] The bitwise-instruction optimizer doesn' t
 know about alignment of globals.
In-Reply-To: <bug-2206-206@http.llvm.org/bugs/>
Message-ID: <200804192218.m3JMIQR8032398@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2206


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Severity|normal                      |enhancement
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #4 from Chris Lattner <sabre at nondot.org>  2008-04-19 17:18:26 ---
implemented:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061282.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 00:08:18 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 00:08:18 -0500
Subject: [LLVMbugs] [Bug 2235] New: llvm-g++ generates awful code for
	insertion sort
Message-ID: <bug-2235-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2235

           Summary: llvm-g++ generates awful code for insertion sort
           Product: libraries
           Version: 2.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


llvm-g++ -O3 compiles this:

void ins_sort(double *end, double *begin) {
  double *p = begin;
  ++p;

  while (p != end) {
    double tmp = *p;
    double *j = p;
    double *prev = j;

    for (  ; j != begin && tmp < *--prev; --j )
     *j = *prev;

    *j = tmp;
    ++p;
  }
}

into some horrible code that includes:

LBB1_7: ## bb19.bb30_crit_edge
        xorb    %bl, %bl
LBB1_8: ## bb30
        notb    %bl
        testb   $1, %bl
        jne     LBB1_5  ## bb8

This comes from this block:

bb30:           ; preds = %bb19, %bb29
        %j.0.reg2mem.2 = phi double* [ %j.0.reg2mem.1, %bb29 ], [
%j.0.reg2mem.0, %bb19 ]               ; <double*> [#uses=3]
        %prev.1 = phi double* [ %prev.0, %bb29 ], [ %tmp21, %bb19 ]            
; <double*> [#uses=3]
        %iftmp.1.0 = phi i1 [ true, %bb29 ], [ false, %bb19 ]           ; <i1>
[#uses=1]
        br i1 %iftmp.1.0, label %bb34, label %bb8

I will work on simplifycfg to try to eliminate this.  One odd thing is that we
generate reasonable code with llvm-gcc, but not llvm-g++.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 01:30:53 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 01:30:53 -0500
Subject: [LLVMbugs] [Bug 1998] clang codegens unused stuff
In-Reply-To: <bug-1998-206@http.llvm.org/bugs/>
Message-ID: <200804200630.m3K6UrPp014126@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1998


Nate Begeman <natebegeman at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |natebegeman at mac.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Nate Begeman <natebegeman at mac.com>  2008-04-20 01:30:52 ---
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080414/005369.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 02:58:31 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 02:58:31 -0500
Subject: [LLVMbugs] [Bug 2236] New: Bogus defined but not used diagnostics.
Message-ID: <bug-2236-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2236

           Summary: Bogus  defined but not used diagnostics.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: neil at daikokuya.co.uk
                CC: llvmbugs at cs.uiuc.edu


Nate's recent changes cause a bogus diagnostic:

static void a (void);
void b (void) { a (); }
static void a(void) {}

/tmp/bug.c:3:13: warning: static 'a' defined but not used


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 03:15:09 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 03:15:09 -0500
Subject: [LLVMbugs] [Bug 2237] New: request: add '-emit-llvm' switch to
	'gnatmake'
Message-ID: <bug-2237-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2237

           Summary: request: add '-emit-llvm' switch to 'gnatmake'
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rodkay at dodo.com.au
                CC: llvmbugs at cs.uiuc.edu


Hi folks,

   Would it be possible to add an '-emit-llvm' switch to gnatmake ?


cheers,
Rod.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 03:19:48 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 03:19:48 -0500
Subject: [LLVMbugs] [Bug 2238] New: Read-after-free in IPConstantPropagation
Message-ID: <bug-2238-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2238

           Summary: Read-after-free in IPConstantPropagation
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Running test/Transforms/IPConstantProp/return-constants.ll under valgrind
shows:

Invalid read of size 8
   at 0x7A5064: llvm::Use::getNext() const (Use.h:67)
   by 0x7A65A8: llvm::value_use_iterator<llvm::User>::operator++() (Use.h:132)
   by 0x7F4CF4: (anonymous
namespace)::IPCP::PropagateConstantReturn(llvm::Function&)
(IPConstantPropagation.cpp:200)
   by 0x7F545C: (anonymous namespace)::IPCP::runOnModule(llvm::Module&)
(IPConstantPropagation.cpp:65)
   by 0xA6111F: llvm::MPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1248)
   by 0xA612AF: llvm::PassManagerImpl::run(llvm::Module&)
(PassManager.cpp:1322)
   by 0xA61312: llvm::PassManager::run(llvm::Module&) (PassManager.cpp:1354)
   by 0x7B31FF: main (opt.cpp:428)

 Address 0x40536B8 is 80 bytes inside a block of size 120 free'd
   at 0x4C2153D: operator delete(void*) (vg_replace_malloc.c:244)
   by 0xA4CC4D: llvm::GetResultInst::~GetResultInst() (Instructions.h:2553)
   by 0x7D7DC9: llvm::iplist<llvm::Instruction,
llvm::ilist_traits<llvm::Instruction>
>::erase(llvm::ilist_iterator<llvm::Instruction>) (ilist:377)
   by 0xA3C7CF: llvm::Instruction::eraseFromParent() (Instruction.cpp:68)
   by 0x7F4CE8: (anonymous
namespace)::IPCP::PropagateConstantReturn(llvm::Function&)
(IPConstantPropagation.cpp:205)
   by 0x7F545C: (anonymous namespace)::IPCP::runOnModule(llvm::Module&)
(IPConstantPropagation.cpp:65)
   by 0xA6111F: llvm::MPPassManager::runOnModule(llvm::Module&)
(PassManager.cpp:1248)
   by 0xA612AF: llvm::PassManagerImpl::run(llvm::Module&)
(PassManager.cpp:1322)
   by 0xA61312: llvm::PassManager::run(llvm::Module&) (PassManager.cpp:1354)
   by 0x7B31FF: main (opt.cpp:428)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 04:06:11 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 04:06:11 -0500
Subject: [LLVMbugs] [Bug 2239] New: Call result #2 has unhandled type i32
Message-ID: <bug-2239-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2239

           Summary: Call result #2 has unhandled type i32
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When compiling http://llvm.org/bugs/attachment.cgi?id=1566 I get
an error in LLC:

$ llc bugpoint-reduced-simplified.bc
Call result #2 has unhandled type i32
llc[0x9c68c9]
/lib/libc.so.6[0x3ccc631240]
/lib/libc.so.6(gsignal+0x35)[0x3ccc6311d5]
/lib/libc.so.6(abort+0x110)[0x3ccc632680]
llc(_ZN4llvm7CCState17AnalyzeCallResultEPNS_6SDNodeEPFbjjjNS_11CCValAssign7LocInfoENS_3ISD10ArgFlagsTyERS0_E+0x12c)[0x69499c]
llc(_ZN4llvm17X86TargetLowering15LowerCallResultENS_9SDOperandES1_PNS_6SDNodeEjRNS_12SelectionDAGE+0xce)[0x5acb9e]
llc(_ZN4llvm17X86TargetLowering9LowerCALLENS_9SDOperandERNS_12SelectionDAGE+0x2a88)[0x5bfc38]
llc(_ZN4llvm17X86TargetLowering14LowerOperationENS_9SDOperandERNS_12SelectionDAGE+0x380)[0x5d3e50]
llc[0x75598c]
llc[0x791a22]
llc[0x7922a5]
llc(_ZN4llvm12SelectionDAG8LegalizeEv+0x1c2)[0x792df2]
llc(_ZN4llvm16SelectionDAGISel17CodeGenAndEmitDAGERNS_12SelectionDAGE+0x7e)[0x6f990e]
llc(_ZN4llvm16SelectionDAGISel16SelectBasicBlockEPNS_10BasicBlockERNS_15MachineFunctionERNS_20FunctionLoweringInfoE+0xe7)[0x7216c7]
llc(_ZN4llvm16SelectionDAGISel13runOnFunctionERNS_8FunctionE+0x283)[0x723dd3]
llc[0x4c6b73]
llc(_ZN4llvm13FPPassManager13runOnFunctionERNS_8FunctionE+0x25d)[0x9640cd]
llc(_ZN4llvm23FunctionPassManagerImpl3runERNS_8FunctionE+0x1c9)[0x964fc9]
llc(_ZN4llvm19FunctionPassManager3runERNS_8FunctionE+0x31)[0x965121]
llc(main+0x9a8)[0x4b6b08]
/lib/libc.so.6(__libc_start_main+0xf4)[0x3ccc61e1c4]
llc(_ZNSt8ios_base4InitD1Ev+0x41)[0x4b4599]
Aborted

To reproduce use the testcase below (I manually reduced it after bugpoint by
eliminating some arguments):
llvm-as bugpoint-reduced-simplified.ll -o -|llc

; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-unknown-linux-gnu"

declare i256 @_ZNK4llvm12LSBaseSDNode13getMemOperandEv()

define i32 @main() nounwind  {
entry:
        %tmp107 = call i256 @_ZNK4llvm12LSBaseSDNode13getMemOperandEv( )       
        ; <i256> [#uses=0]
        unreachable
}

P.S.: I compiled with llvm-g++ -m32 -O0, so i256 is not the result of some
optimization in opt.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 04:09:03 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 04:09:03 -0500
Subject: [LLVMbugs] [Bug 2240] New: FunctionAddressAlignment and
 ConstantExprFold tests fail
Message-ID: <bug-2240-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2240

           Summary: FunctionAddressAlignment and  ConstantExprFold tests
                    fail
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Using SVN r49986 on x86-32 Linux, I get 2 tests failed in make check:

FAIL:
/home/edwin/llvm/llvm-svn/trunk/test/Assembler/2004-03-07-FunctionAddressAlignment.ll
Failed with exit(1) at line 1
while running: llvm-as <
/home/edwin/llvm/llvm-svn/trunk/test/Assembler/2004-03-07-FunctionAddressAlignment.ll
| llvm-dis | not grep ptrtoint
        ret i32 and (i32 ptrtoint (i32 ()* @foo to i32), i32 1)
        ret i32 and (i32 1, i32 ptrtoint (i32 ()* @foo2 to i32))
child process exited abnormally
FAIL: /home/edwin/llvm/llvm-svn/trunk/test/Assembler/ConstantExprFold.ll for
PR2206
Failed with exit(1) at line 1
while running: llvm-as <
/home/edwin/llvm/llvm-svn/trunk/test/Assembler/ConstantExprFold.ll | llvm-dis |
not grep {(}
global i64 and (i64 ptrtoint (i32* @cons to i64), i64 7)                ;
<i64*>:12 [#uses=0]
child process exited abnormally


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 08:14:24 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 08:14:24 -0500
Subject: [LLVMbugs] [Bug 2241] New: Suboptimal error recovery in initializers
Message-ID: <bug-2241-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2241

           Summary: Suboptimal error recovery in initializers
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: neil at daikokuya.co.uk
                CC: llvmbugs at cs.uiuc.edu


Once clang finds an erroneous literal in an initializer, it seems to give up on
the whole initializer and not diagnose subsequent problems.  For example:

float f[] = { 1e, 1ee0 };

$ clang /tmp/test.c
/tmp/test.c:1:15: error: exponent has no digits
float f[] = { 1e, 1ee0 };
              ^
1 diagnostic generated.

GCC diagnoses both problems:

$ gcc /tmp/test.c
/tmp/test.c:1:15: error: exponent has no digits
/tmp/test.c:1:19: error: exponent has no digits


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 10:51:26 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 10:51:26 -0500
Subject: [LLVMbugs] [Bug 2239] Call result #2 has unhandled type i32
In-Reply-To: <bug-2239-206@http.llvm.org/bugs/>
Message-ID: <200804201551.m3KFpQbF029725@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2239


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from Duncan Sands <baldrick at free.fr>  2008-04-20 10:51:26 ---
An x86-64 issue.  Fixed here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061310.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 11:11:22 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 11:11:22 -0500
Subject: [LLVMbugs] [Bug 2225] Use-after-free in removeIntervalIfEmpty
In-Reply-To: <bug-2225-206@http.llvm.org/bugs/>
Message-ID: <200804201611.m3KGBMSt030319@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2225


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Duncan Sands <baldrick at free.fr>  2008-04-20 11:11:21 ---
I'm not seeing this anymore.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 12:23:39 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 12:23:39 -0500
Subject: [LLVMbugs] [Bug 2242] New: Canonicalization of induction variables
 needs some heuristics
Message-ID: <bug-2242-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2242

           Summary: Canonicalization of induction variables needs some
                    heuristics
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dalej at apple.com
                CC: llvmbugs at cs.uiuc.edu


The optimization to construct canonical induction variables needs some
heuristics to determine whether it's a good idea to do this.  Take the example
in UnitTests/2008-04-18-LoopBug.c.  Using opt -std-compile-opts we get this on
Darwin x86-32:
LBB1_1: ## bb.preheader
        movl    $3, %edx
        subl    %eax, %edx
        movl    %eax, %esi
        notl    %esi
        cmpl    $4294967293, %esi
        movl    $1, %esi
        cmovb   %esi, %edx
        xorl    %esi, %esi
        movl    %ecx, %edi
        .align  4,0x90
LBB1_2: ## bb
        movl    8(%edi), %ebx
        movl    %ebx, 12(%edi)
        addl    $4294967292, %edi
        incl    %esi
        cmpl    %edx, %esi
        jne     LBB1_2  ## bb
Removing -indvars from the opt line results in:
LBB1_1: ## entry.bb_crit_edge
        movl    $3, %edx
        movl    %ecx, %esi
        .align  4,0x90
LBB1_2: ## bb
        movl    8(%esi), %edi
        movl    %edi, 12(%esi)
        addl    $4294967292, %esi
        decl    %edx
        cmpl    %eax, %edx
        ja      LBB1_2  ## bb
Not much of an optimization.  Things to consider in the heuristics (there are
probably more):
- If we can share/eliminate multiple induction variables by using a canonical
form, that is a good thing.
- If the replacement initialization expression is more complex than the
original, that's a bad thing.  (that's what happens here)
- Testing against a constant can be better than against a non-constant because
of register pressure.
- Some targets have a decrement-and-branch-on-nonzero instruction; using that
is a win when available (currently unimplemented in llvm).
The tradeoff among these is not obvious and is target-dependent.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 13:51:49 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 13:51:49 -0500
Subject: [LLVMbugs] [Bug 2241] Suboptimal error recovery in initializers
In-Reply-To: <bug-2241-206@http.llvm.org/bugs/>
Message-ID: <200804201851.m3KIpnM2002972@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2241


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-20 13:51:48 ---
This is by design.  If an error is caught during sema, the entire rest of the
subexpression is ignored for Sema purposes to avoid cascading error messages. 
For example, a malformed numeric literal will still have to have a type
assigned to it.  IMO it is better to just give up on the expression.  


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 14:05:32 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 14:05:32 -0500
Subject: [LLVMbugs] [Bug 2241] Suboptimal error recovery in initializers
In-Reply-To: <bug-2241-206@http.llvm.org/bugs/>
Message-ID: <200804201905.m3KJ5WwN003385@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2241


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|WONTFIX                     |




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2008-04-20 14:05:31 ---
Actually, there is a way.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 14:08:37 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 14:08:37 -0500
Subject: [LLVMbugs] [Bug 2241] Suboptimal error recovery in initializers
In-Reply-To: <bug-2241-206@http.llvm.org/bugs/>
Message-ID: <200804201908.m3KJ8bbv003487@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2241


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Chris Lattner <sabre at nondot.org>  2008-04-20 14:08:37 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080414/005373.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 14:59:46 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 14:59:46 -0500
Subject: [LLVMbugs] [Bug 2240] FunctionAddressAlignment and ConstantExprFold
	tests fail
In-Reply-To: <bug-2240-206@http.llvm.org/bugs/>
Message-ID: <200804201959.m3KJxk4W004955@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2240


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #6 from Chris Lattner <sabre at nondot.org>  2008-04-20 14:59:45 ---
This should fix it, nice catch!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080414/061317.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 15:40:56 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 15:40:56 -0500
Subject: [LLVMbugs] [Bug 2236] Bogus  defined but not used diagnostics.
In-Reply-To: <bug-2236-206@http.llvm.org/bugs/>
Message-ID: <200804202040.m3KKeuCY006235@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2236


Nate Begeman <natebegeman at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Nate Begeman <natebegeman at mac.com>  2008-04-20 15:40:56 ---
Fixed here, and added the example as a test.  Let me know if you find anything
else that doesn't work :)

http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080414/005374.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 17:45:26 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 17:45:26 -0500
Subject: [LLVMbugs] [Bug 2243] New: PHI coalescing / tail merging missing
	opportunity
Message-ID: <bug-2243-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2243

           Summary: PHI coalescing / tail merging missing opportunity
           Product: libraries
           Version: 2.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: resistor at mac.com, evan.cheng at apple.com, dalej at apple.com,
                    llvmbugs at cs.uiuc.edu


Running llc on the attached bc file produces this code:

__Z9ins_innerPdS_:
        pushl   %esi
        movl    8(%esp), %eax
        movl    12(%esp), %ecx
        cmpl    %ecx, %eax
        movsd   (%eax), %xmm0
        je      LBB1_5  ## bb30
...

LBB1_4: ## bb26.bb30_crit_edge
        movl    %edx, %eax
LBB1_5: ## bb30
        movsd   %xmm0, (%eax)
        popl    %esi
        ret
LBB1_6: ## bb15.bb30_crit_edge
        movl    %edx, %eax
        jmp     LBB1_5  ## bb30

Tail merging should have eliminated LBB1_6, replacing references to it (there
is only one) with LBB1_4.  However, the fault was really originally PHI elims
fault: it should have only inserted a copy for the entry block, instead of
inserting two copies elsewhere.  Owen's strong phi elim will hopefully fix this
one day.  Until then, tail merging should do the right thing.

This comes from a version of the testcase from PR2235.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 20 22:41:06 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 20 Apr 2008 22:41:06 -0500
Subject: [LLVMbugs] [Bug 2229] Use of uninitialized value in bitwiseIsEqual
 from visitFMUL
In-Reply-To: <bug-2229-206@http.llvm.org/bugs/>
Message-ID: <200804210341.m3L3f6ei018539@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2229


Dale Johannesen <dalej at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #4 from Dale Johannesen <dalej at apple.com>  2008-04-20 22:41:05 ---
Should be fixed now, please confirm.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 01:15:52 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 01:15:52 -0500
Subject: [LLVMbugs] [Bug 2244] New: LLVM inliner not run at -O2
Message-ID: <bug-2244-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2244

           Summary: LLVM inliner not run at -O2
           Product: tools
           Version: 2.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


This trivial function isn't inlined at -O2:

void factorial(int a, int* b) {
 *b = a + 1;
}
int main() {
 int a = 4;
 int b;
 factorial(a,&b);
 return b;
}

The reason is this code in llvm-backend.cpp:

    if (optimize > 1) {
      if (flag_inline_trees > 1)                // respect
-fno-inline-functions
        PM->add(createFunctionInliningPass());  // Inline small functions

At -O2, flag_inline_trees is equal to 1, so this is not run.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 03:27:39 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 03:27:39 -0500
Subject: [LLVMbugs] [Bug 2244] LLVM inliner not run at -O2
In-Reply-To: <bug-2244-206@http.llvm.org/bugs/>
Message-ID: <200804210827.m3L8Rdq0002363@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2244


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Duncan Sands <baldrick at free.fr>  2008-04-21 03:27:38 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061359.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 03:35:17 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 03:35:17 -0500
Subject: [LLVMbugs] [Bug 2219] make test failures on SVN r49608
In-Reply-To: <bug-2219-206@http.llvm.org/bugs/>
Message-ID: <200804210835.m3L8ZHRU002581@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2219


T??r??k Edwin <edwintorok at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from T??r??k Edwin <edwintorok at gmail.com>  2008-04-21 03:35:16 ---
I updated to SVN r50039, and all tests succeed in make check!

===  Summary ===

# of expected passes            2532
# of expected failures          5

Thanks for fixing this!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From neil at daikokuya.co.uk  Mon Apr 21 08:27:12 2008
From: neil at daikokuya.co.uk (Neil Booth)
Date: Mon, 21 Apr 2008 22:27:12 +0900
Subject: [LLVMbugs] [Bug 2236] Bogus  defined but not used diagnostics.
In-Reply-To: <200804202040.m3KKeuCY006235@zion.cs.uiuc.edu>
References: <bug-2236-206@http.llvm.org/bugs/>
	<200804202040.m3KKeuCY006235@zion.cs.uiuc.edu>
Message-ID: <20080421132712.GP18285@daikokuya.co.uk>

bugzilla-daemon at cs.uiuc.edu wrote:-

> http://llvm.org/bugs/show_bug.cgi?id=2236
> 
> 
> Nate Begeman <natebegeman at mac.com> changed:
> 
>            What    |Removed                     |Added
> ----------------------------------------------------------------------------
>              Status|ASSIGNED                    |RESOLVED
>          Resolution|                            |FIXED
> 
> 
> 
> 
> --- Comment #2 from Nate Begeman <natebegeman at mac.com>  2008-04-20 15:40:56 ---
> Fixed here, and added the example as a test.  Let me know if you find anything
> else that doesn't work :)
> 
> http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20080414/005374.html

No, it doesn't work yet.  Apparently you need -emit-llvm to cause the
problem.

Hopefully this isn't one of those diagnostics that depends upon code
generation or optimization....  It is easy to emit this diagnostic
correctly with simple semantic analysis.

Neil.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 08:45:31 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 08:45:31 -0500
Subject: [LLVMbugs] [Bug 2236] Bogus  defined but not used diagnostics.
In-Reply-To: <bug-2236-206@http.llvm.org/bugs/>
Message-ID: <200804211345.m3LDjVIV014245@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2236


Neil Booth <neil at daikokuya.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #3 from Neil Booth <neil at daikokuya.co.uk>  2008-04-21 08:45:30 ---
So this ... system ... doesn't let me reply to its mails....

No, this is still broken Nate.  Apparently --emit-llvm is required.

That sends warning bells ringing in my mind ... this diagnostic is easy to do
with simple semantic analysis, no codegen or optimization should be necessary.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 08:59:48 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 08:59:48 -0500
Subject: [LLVMbugs] [Bug 2245] New: Misleading parameter name in
 llvm-c/Core.h:LLVMConstArray
Message-ID: <bug-2245-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2245

           Summary: Misleading parameter name in llvm-
                    c/Core.h:LLVMConstArray
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fvbommel at wxs.nl
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1596)
 --> (http://llvm.org/bugs/attachment.cgi?id=1596)
Patch to fix this.

LLVMConstArray is declared in include/llvm-c/Core.h as:
===
LLVMValueRef LLVMConstArray(LLVMTypeRef ArrayTy,
                            LLVMValueRef *ConstantVals, unsigned Length);
===
But is defined in lib/VMCore/Core.cpp as:
===
LLVMValueRef LLVMConstArray(LLVMTypeRef ElementTy,
                            LLVMValueRef *ConstantVals, unsigned Length) {
  return wrap(ConstantArray::get(ArrayType::get(unwrap(ElementTy), Length),
                                 unwrap<Constant>(ConstantVals, Length),
                                 Length));
}
===
Note in particular the name of the first parameter.

While C++ allows this to compile and link without problems, this creates the
unfortunate impression to those reading the header that the first parameter
should be the type of the array, while it should actually be the type of the
*elements* of the array.

Trivial patch attached.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 11:55:11 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 11:55:11 -0500
Subject: [LLVMbugs] [Bug 2237] request: add '-emit-llvm' switch to 'gnatmake'
In-Reply-To: <bug-2237-206@http.llvm.org/bugs/>
Message-ID: <200804211655.m3LGtBrL021135@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2237


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Duncan Sands <baldrick at free.fr>  2008-04-21 11:55:08 ---
Fixed here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061370.html

Things are not perfect though: -emit-llvm is not recorded in the ali file.
The reason for this is that gnatmake passes an invisible -gnatez argument
to the compiler to indicate the end of the arguments that should be placed
in the ali file.  So gcc gets invoked something like this:
  gcc -emit-llvm -gnatez -c file.adb
However gcc rewrites -emit-llvm into -emit-llvm-bc if used with -c.
Actually what it apparently does is turn the -c into -emit-llvm-bc.
This gives
  gcc -gnatez -emit-llvm-bc file.adb
Since -emit-llvm-bc is now after the -gnatez, it is no longer placed
in the ali file.

This means (for example) that gnatlink will not use -emit-llvm when
compiling the binder generated main; and that gnatmake -s will always
think there is a switch mismatch and recompile every time.

These issues should probably get their own bugreport.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 15:22:53 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 15:22:53 -0500
Subject: [LLVMbugs] [Bug 2246] New: llvm2cpp not updated to new API
Message-ID: <bug-2246-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2246

           Summary: llvm2cpp not updated to new API
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


llvm2cpp still generates code with new PHINode(...), instead of using the new
API ::Create.

Thus llvm2cpp generated sources fail to compile:
$ llvm2cpp y.bc -f
$ g++ y.bc.cpp -D_DEBUG  -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -O2
/usr/local/include/llvm/User.h: In function ???llvm::Module*
makeLLVMModule()???:
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:57: error: within this context
/usr/local/include/llvm/Function.h:113: error:
???llvm::Function::Function(const llvm::FunctionType*,
llvm::GlobalValue::LinkageTypes, const std::string&, llvm::Module*)??? is
private
y.bc.cpp:57: error: within this context
y.bc.cpp:59: error: conversion from ???int??? to non-scalar type
???llvm::PAListPtr??? requested
y.bc.cpp:61: error: ???SmallVector??? was not declared in this scope
y.bc.cpp:61: error: expected primary-expression before ???,??? token
y.bc.cpp:61: error: ???Attrs??? was not declared in this scope
y.bc.cpp:63: error: ???struct llvm::ParamAttrsWithIndex??? has no member named
???index???
y.bc.cpp:63: error: ???struct llvm::ParamAttrsWithIndex??? has no member named
???attrs???
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:90: error: within this context
/usr/local/include/llvm/BasicBlock.h:74: error:
???llvm::BasicBlock::BasicBlock(const std::string&, llvm::Function*,
llvm::BasicBlock*, llvm::BasicBlock*)??? is private
y.bc.cpp:90: error: within this context
......


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 16:35:18 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 16:35:18 -0500
Subject: [LLVMbugs] [Bug 2246] llvm2cpp not updated to new API
In-Reply-To: <bug-2246-206@http.llvm.org/bugs/>
Message-ID: <200804212135.m3LLZIPf030367@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2246


Gabor Greif <ggreif at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |ggreif at gmail.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Gabor Greif <ggreif at gmail.com>  2008-04-21 16:35:17 ---
fixed by r50062. there was one left-back occurrence of "new PHINode" in
llvm/tools/llvm2cpp/CppWriter.cpp


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 21:54:52 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 21:54:52 -0500
Subject: [LLVMbugs] [Bug 2235] llvm-g++ generates awful code for insertion
	sort
In-Reply-To: <bug-2235-206@http.llvm.org/bugs/>
Message-ID: <200804220254.m3M2sq3i007685@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2235


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #8 from Chris Lattner <sabre at nondot.org>  2008-04-21 21:54:33 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061395.html

This speeds up insertion sort loop by 45%.

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 21 23:32:30 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 21 Apr 2008 23:32:30 -0500
Subject: [LLVMbugs] [Bug 2247] New: llvm needs an 'exact divide'
	flag/instruction
Message-ID: <bug-2247-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2247

           Summary: llvm needs an 'exact divide' flag/instruction
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality, new-feature
          Severity: enhancement
          Priority: P2
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


We need to add a flag of some sort to the sdiv instruction, indicating that the
division is exact: there is known to be no remainder.  This allows us to turn
things like "x /s 4" into "x >>s 2" for example, and would allow us to
eliminate special case handling code of pointer subtraction (which detects
power of two sizes and has a special case) and move this into the optimizer
where it should be.

In addition to cleaning up the front-ends, this would also improve
optimization.  For example, consider these two functions with identical
semantics:

int test(double *s, double *e) {
  return (e-s) > 1;
}
int test2(double *s, double *e) {
  long diff = e-s;
  return diff > 1;
}

Pointer subtraction is codegen'd as the difference between the two pointers
with a signed divide by the element size.

Amusingly both GCC and llvm-gcc generate exactly the same code for these two
functions (instruction for instruction).  We produce:

_test:
        movl    8(%esp), %eax
        subl    4(%esp), %eax
        cmpl    $15, %eax
        setg    %al
        movzbl  %al, %eax
        ret
_test2:
        movl    8(%esp), %eax
        subl    4(%esp), %eax
        sarl    $3, %eax
        cmpl    $1, %eax
        setg    %al
        movzbl  %al, %eax
        ret

Note that the first has significantly better codegen.  This comes from this IR:

define i32 @test(double* %s, double* %e) nounwind  {
        %tmp12 = ptrtoint double* %e to i32             ; <i32> [#uses=1]
        %tmp34 = ptrtoint double* %s to i32             ; <i32> [#uses=1]
        %tmp5 = sub i32 %tmp12, %tmp34          ; <i32> [#uses=1]
        %tmp6 = icmp sgt i32 %tmp5, 15          ; <i1> [#uses=1]
        %tmp67 = zext i1 %tmp6 to i32           ; <i32> [#uses=1]
        ret i32 %tmp67
}
define i32 @test2(double* %s, double* %e) nounwind  {
        %tmp12 = ptrtoint double* %e to i32             ; <i32> [#uses=1]
        %tmp34 = ptrtoint double* %s to i32             ; <i32> [#uses=1]
        %tmp5 = sub i32 %tmp12, %tmp34          ; <i32> [#uses=1]
        %tmp6 = ashr i32 %tmp5, 3               ; <i32> [#uses=1]
        %tmp8 = icmp sgt i32 %tmp6, 1           ; <i1> [#uses=1]
        %tmp89 = zext i1 %tmp8 to i32           ; <i32> [#uses=1]
        ret i32 %tmp89
}

The critical difference here is that GCC's fold() routine merges the divide
(aka ashr) into the comparison in the first case.  GCC does this because it
operates on instruction trees which are expression based and don't see across
statements.

In this case, the transformation is *not safe* to perform for arbitrary
pointers and an arbitrary ashr in llvm IR.  We have to know that the divide (in
this case by 8) is always exact (which is guaranteed for pointer arithmetic) to
know that that xform is safe to perform on llvm ir.  Knowing this, we could
handle both cases uniformly and remove reliance on the GCC f.e. doing this
xform.

This optimization is important, because the GCC front-end misses many other
cases as well, such as when the pointers are wrapped in iterators.  Getting
this requires SROA to happen before the pointer subtraction is exposed.

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 22 01:17:03 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 22 Apr 2008 01:17:03 -0500
Subject: [LLVMbugs] [Bug 2246] llvm2cpp not updated to new API
In-Reply-To: <bug-2246-206@http.llvm.org/bugs/>
Message-ID: <200804220617.m3M6H3Zs013951@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2246


T??r??k Edwin <edwintorok at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #3 from T??r??k Edwin <edwintorok at gmail.com>  2008-04-22 01:17:02 ---
(In reply to comment #2)
> fixed by r50062. there was one left-back occurrence of "new PHINode" in
> llvm/tools/llvm2cpp/CppWriter.cpp
> 

It still fails for me, new BasicBlock, new BranchInst...

Here is the full error output, I'll attach the generated .cpp file too:
/usr/local/include/llvm/User.h: In function ???llvm::Module*
makeLLVMModule()???:
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:57: error: within this context
/usr/local/include/llvm/Function.h:113: error:
???llvm::Function::Function(const llvm::FunctionType*,
llvm::GlobalValue::LinkageTypes, const std::string&, llvm::Module*)??? is
private
y.bc.cpp:57: error: within this context
y.bc.cpp:59: error: conversion from ???int??? to non-scalar type
???llvm::PAListPtr??? requested
y.bc.cpp:61: error: ???SmallVector??? was not declared in this scope
y.bc.cpp:61: error: expected primary-expression before ???,??? token
y.bc.cpp:61: error: ???Attrs??? was not declared in this scope
y.bc.cpp:63: error: ???struct llvm::ParamAttrsWithIndex??? has no member named
???index???
y.bc.cpp:63: error: ???struct llvm::ParamAttrsWithIndex??? has no member named
???attrs???
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:90: error: within this context
/usr/local/include/llvm/BasicBlock.h:74: error:
???llvm::BasicBlock::BasicBlock(const std::string&, llvm::Function*,
llvm::BasicBlock*, llvm::BasicBlock*)??? is private
y.bc.cpp:90: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:91: error: within this context
/usr/local/include/llvm/BasicBlock.h:74: error:
???llvm::BasicBlock::BasicBlock(const std::string&, llvm::Function*,
llvm::BasicBlock*, llvm::BasicBlock*)??? is private
y.bc.cpp:91: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:92: error: within this context
/usr/local/include/llvm/BasicBlock.h:74: error:
???llvm::BasicBlock::BasicBlock(const std::string&, llvm::Function*,
llvm::BasicBlock*, llvm::BasicBlock*)??? is private
y.bc.cpp:92: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:93: error: within this context
/usr/local/include/llvm/BasicBlock.h:74: error:
???llvm::BasicBlock::BasicBlock(const std::string&, llvm::Function*,
llvm::BasicBlock*, llvm::BasicBlock*)??? is private
y.bc.cpp:93: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:94: error: within this context
/usr/local/include/llvm/BasicBlock.h:74: error:
???llvm::BasicBlock::BasicBlock(const std::string&, llvm::Function*,
llvm::BasicBlock*, llvm::BasicBlock*)??? is private
y.bc.cpp:94: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:95: error: within this context
/usr/local/include/llvm/BasicBlock.h:74: error:
???llvm::BasicBlock::BasicBlock(const std::string&, llvm::Function*,
llvm::BasicBlock*, llvm::BasicBlock*)??? is private
y.bc.cpp:95: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:96: error: within this context
/usr/local/include/llvm/BasicBlock.h:74: error:
???llvm::BasicBlock::BasicBlock(const std::string&, llvm::Function*,
llvm::BasicBlock*, llvm::BasicBlock*)??? is private
y.bc.cpp:96: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:101: error: within this context
/usr/local/include/llvm/Instructions.h:1601: error:
???llvm::BranchInst::BranchInst(llvm::BasicBlock*, llvm::BasicBlock*,
llvm::Value*, llvm::BasicBlock*)??? is private
y.bc.cpp:101: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:120: error: within this context
/usr/local/include/llvm/Instructions.h:1601: error:
???llvm::BranchInst::BranchInst(llvm::BasicBlock*, llvm::BasicBlock*,
llvm::Value*, llvm::BasicBlock*)??? is private
y.bc.cpp:120: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:128: error: within this context
/usr/local/include/llvm/Instructions.h:1601: error:
???llvm::BranchInst::BranchInst(llvm::BasicBlock*, llvm::BasicBlock*,
llvm::Value*, llvm::BasicBlock*)??? is private
y.bc.cpp:128: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:133: error: within this context
/usr/local/include/llvm/Instructions.h:1599: error:
???llvm::BranchInst::BranchInst(llvm::BasicBlock*, llvm::BasicBlock*)??? is
private
y.bc.cpp:133: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:154: error: within this context
/usr/local/include/llvm/Instructions.h:1599: error:
???llvm::BranchInst::BranchInst(llvm::BasicBlock*, llvm::BasicBlock*)??? is
private
y.bc.cpp:154: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:169: error: within this context
/usr/local/include/llvm/Instructions.h:1601: error:
???llvm::BranchInst::BranchInst(llvm::BasicBlock*, llvm::BasicBlock*,
llvm::Value*, llvm::BasicBlock*)??? is private
y.bc.cpp:169: error: within this context
/usr/local/include/llvm/User.h:28: error: ???static void* llvm::User::operator
new(size_t)??? is private
y.bc.cpp:172: error: within this context
/usr/local/include/llvm/Instructions.h:1520: error:
???llvm::ReturnInst::ReturnInst(llvm::Value*, llvm::BasicBlock*)??? is private
y.bc.cpp:172: error: within this context


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 22 07:22:36 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 22 Apr 2008 07:22:36 -0500
Subject: [LLVMbugs] [Bug 2248] New: Clang cannot compile its preprocessed
 output with same flags
Message-ID: <bug-2248-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2248

           Summary: Clang cannot compile its preprocessed output with same
                    flags
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: neil at daikokuya.co.uk
                CC: llvmbugs at cs.uiuc.edu


For the following file:

#include <stdarg.h>
void d (int tag, ...)
{
  va_list ap;

  va_start (ap, tag);
  va_end (ap);
}

we get the following effect:

$ clang -pedantic-errors -E /tmp/bug.c > /tmp/bug.i
$ clang -pedantic-errors /tmp/bug.i
/tmp/bug.i:60:3: error: implicit declaration of function
'__builtin_stdarg_start' is invalid in C99
  __builtin_stdarg_start((ap), (tag));
  ^
1 diagnostic generated.
$


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 22 17:32:42 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 22 Apr 2008 17:32:42 -0500
Subject: [LLVMbugs] [Bug 2249] New: Diagnostic dependent on -emit-llvm
Message-ID: <bug-2249-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2249

           Summary: Diagnostic dependent on -emit-llvm
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: neil at daikokuya.co.uk
                CC: llvmbugs at cs.uiuc.edu


Just a separate tracker issue that a diagnostic (defined but not used statics)
currently requires -emit-llvm.

I believe it's generally agreed that it is desirable that diagnostics not
depend on codegen, i.e. diagnostic output is the same with and without it.  If
not then please close this issue.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 22 17:41:54 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 22 Apr 2008 17:41:54 -0500
Subject: [LLVMbugs] [Bug 2223] llc fails on tailcall to function pointer
In-Reply-To: <bug-2223-206@http.llvm.org/bugs/>
Message-ID: <200804222241.m3MMfs3O019856@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2223


Arnold Schwaighofer <arnold.schwaighofer at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Arnold Schwaighofer <arnold.schwaighofer at gmail.com>  2008-04-22 17:41:54 ---
Marking as fixed since it is resolved in r47594. See comments above.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 23 00:59:48 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 23 Apr 2008 00:59:48 -0500
Subject: [LLVMbugs] [Bug 2238] Read-after-free in IPConstantPropagation
In-Reply-To: <bug-2238-206@http.llvm.org/bugs/>
Message-ID: <200804230559.m3N5xmd8032300@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2238


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Chris Lattner <sabre at nondot.org>  2008-04-23 00:59:47 ---
This should fix it, please verify:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061454.html

Thanks!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 23 02:13:49 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 23 Apr 2008 02:13:49 -0500
Subject: [LLVMbugs] [Bug 2246] llvm2cpp not updated to new API
In-Reply-To: <bug-2246-206@http.llvm.org/bugs/>
Message-ID: <200804230713.m3N7Dnfn002192@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2246


Bill Wendling <isanbard at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |isanbard at gmail.com
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from Bill Wendling <isanbard at gmail.com>  2008-04-23 02:13:48 ---
Fixed with:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061458.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 23 13:45:34 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 23 Apr 2008 13:45:34 -0500
Subject: [LLVMbugs] [Bug 1649] Invalid alignment for SSE2 code
In-Reply-To: <bug-1649-206@http.llvm.org/bugs/>
Message-ID: <200804231845.m3NIjYVL030070@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1649


Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #10 from Anton Korobeynikov <asl at math.spbu.ru>  2008-04-23 13:45:33 ---
This should be fixed by series of patches r50152-r50173.

Stack realignment is currently enabled in 'easy' cases, when no dynamic-sized
objects are present.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 23 15:43:18 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 23 Apr 2008 15:43:18 -0500
Subject: [LLVMbugs] [Bug 1636] [llvm-gcc 4.2] Should handle ;
 force_align_arg_pointer'   gcc attribute
In-Reply-To: <bug-1636-206@http.llvm.org/bugs/>
Message-ID: <200804232043.m3NKhIjN001607@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1636


Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from Anton Korobeynikov <asl at math.spbu.ru>  2008-04-23 15:43:17 ---
Actually, we can easily ignore this attribute. New stack realignment code
handles this case (attribute was introduced to workaround poor gcc's stack
realignment support) without any problems.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 23 15:58:38 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 23 Apr 2008 15:58:38 -0500
Subject: [LLVMbugs] [Bug 951] Use of SSE vectors on linux requires stack
	realignment
In-Reply-To: <bug-951-206@http.llvm.org/bugs/>
Message-ID: <200804232058.m3NKwcWL002130@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=951


Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #10 from Anton Korobeynikov <asl at math.spbu.ru>  2008-04-23 15:58:37 ---
This is really fixed now :)


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr 24 12:57:49 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 24 Apr 2008 12:57:49 -0500
Subject: [LLVMbugs] [Bug 1347] llvm/test are not run using -m64
In-Reply-To: <bug-1347-206@http.llvm.org/bugs/>
Message-ID: <200804241757.m3OHvnd8016079@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=1347


Devang Patel <dpatel at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #4 from Devang Patel <dpatel at apple.com>  2008-04-24 12:57:48 ---
Fixed.
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061550.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr 24 14:33:49 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 24 Apr 2008 14:33:49 -0500
Subject: [LLVMbugs] [Bug 2250] New: multiple return values breaks x86-64
 linux llvm-gcc build
Message-ID: <bug-2250-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2250

           Summary: multiple return values breaks x86-64 linux llvm-gcc
                    build
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1602)
 --> (http://llvm.org/bugs/attachment.cgi?id=1602)
testcase .ll

bugpoint reduced testcase attached (bugpoint aborted
when trying to reduce the final function - this should
probably be investigated too).

This was reduced from libstdc++-v3/src/locale-inst.cc

It causes llc to abort with:

lib/VMCore/ValueTypes.cpp:108: llvm::MVT::ValueType
llvm::MVT::getValueType(const llvm::Type*, bool): Assertion `0 && "Unknown
type!"' failed.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr 24 21:54:56 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 24 Apr 2008 21:54:56 -0500
Subject: [LLVMbugs] [Bug 2202] LLVMCreateInterpreter creates a JIT
In-Reply-To: <bug-2202-206@http.llvm.org/bugs/>
Message-ID: <200804250254.m3P2suKI032640@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2202


Gordon Henriksen <gordonhenriksen at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Gordon Henriksen <gordonhenriksen at mac.com>  2008-04-24 21:54:56 ---
Okay. Applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061573.html

Thanks Frits.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Thu Apr 24 22:22:34 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 24 Apr 2008 22:22:34 -0500
Subject: [LLVMbugs] [Bug 2245] Misleading parameter name in
	llvm-c/Core.h:LLVMConstArray
In-Reply-To: <bug-2245-206@http.llvm.org/bugs/>
Message-ID: <200804250322.m3P3MYeA000970@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2245


Gordon Henriksen <gordonhenriksen at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Gordon Henriksen <gordonhenriksen at mac.com>  2008-04-24 22:22:33 ---
Applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061574.html

Thanks, Frits.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 25 01:46:54 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 25 Apr 2008 01:46:54 -0500
Subject: [LLVMbugs] [Bug 2152] g++ 4.3.0 report a compiling error
In-Reply-To: <bug-2152-206@http.llvm.org/bugs/>
Message-ID: <200804250646.m3P6ksAP006599@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2152


Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #4 from Anton Korobeynikov <asl at math.spbu.ru>  2008-04-25 01:46:53 ---
Ok


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 25 08:14:53 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 25 Apr 2008 08:14:53 -0500
Subject: [LLVMbugs] [Bug 2251] New: request: enable gnatlink to use
 -emit-llvm when compiling the binder generated main
Message-ID: <bug-2251-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2251

           Summary: request: enable gnatlink to use -emit-llvm when
                    compiling the binder generated main
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rodkay at dodo.com.au
                CC: llvmbugs at cs.uiuc.edu


Hi,

   When gnatmake is invoked with -emil-llvm, '-emit-llvm' is not recorded in
the ali file.The reason for this is that gnatmake passes an invisible -gnatez
argument to the compiler to indicate the end of the arguments that should be
placed in the ali file.  So gcc gets invoked something like this:

  gcc -emit-llvm -gnatez -c file.adb

However gcc rewrites -emit-llvm into -emit-llvm-bc if used with -c.
Actually what it apparently does is turn the -c into -emit-llvm-bc.

This gives

  gcc -gnatez -emit-llvm-bc file.adb

Since -emit-llvm-bc is now after the -gnatez, it is no longer placed
in the ali file.

This means (for example) that gnatlink will not use -emit-llvm when
compiling the binder generated main; and that gnatmake -s will always
think there is a switch mismatch and recompile every time.


cheers,
Rod.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Fri Apr 25 13:32:14 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 25 Apr 2008 13:32:14 -0500
Subject: [LLVMbugs] [Bug 2250] multiple return values breaks x86-64 linux
	llvm-gcc build
In-Reply-To: <bug-2250-206@http.llvm.org/bugs/>
Message-ID: <200804251832.m3PIWE72004087@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2250


Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Dan Gohman <gohman at apple.com>  2008-04-25 13:32:14 ---
This is fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061608.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr 26 01:51:17 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 26 Apr 2008 01:51:17 -0500
Subject: [LLVMbugs] [Bug 2249] Diagnostic dependent on -emit-llvm
In-Reply-To: <bug-2249-206@http.llvm.org/bugs/>
Message-ID: <200804260651.m3Q6pGVM025811@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2249


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2008-04-26 01:51:15 ---
There are now no diagnostics emitted by codegen now other than "codegen doesn't
support this feature yet".


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr 26 02:04:07 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 26 Apr 2008 02:04:07 -0500
Subject: [LLVMbugs] [Bug 2252] New: Unexpected diagnostics in PP expression
Message-ID: <bug-2252-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2252

           Summary: Unexpected diagnostics in PP expression
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: preprocessor
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: neil at daikokuya.co.uk
                CC: llvmbugs at cs.uiuc.edu


For

#if -0x8000000000000000
#endif

Clang gives:

$ clang -pedantic-errors /tmp/bug.c
/tmp/bug.c:1:6: warning: integer constant is so large that it is unsigned
#if -0x8000000000000000
     ^
/tmp/bug.c:1:5: warning: integer overflow in preprocessor expression
#if -0x8000000000000000
    ^
2 diagnostics generated.

I don't think either of these is warranted.

It is true the integer is so large it is unsigned, but that is an expected
outcome for hex constants and shouldn't require a suffix - this is unlike
unsuffixed decimal constants.

The second diagnostic is simply wrong: unsigned arithmetic never overflows.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr 26 13:45:16 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 26 Apr 2008 13:45:16 -0500
Subject: [LLVMbugs] [Bug 2253] New: getTripCount() of a Loop does not seem
 to give the correct trip count
Message-ID: <bug-2253-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2253

           Summary: getTripCount() of a Loop does not seem to give the
                    correct trip count
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: prakash.prabhu at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hi,

I am trying to add a new loop pass in which I making a call to get the trip
count of the loop using

Value *TripCountValue = L->getTripCount()

However I am always getting NULL for TripCountValue (confirmed through gdb). I
am running this pass after the canonicalization of induction variables:

opt --debug-pass=Structure -stats -indvars -loop-rotate -my-loop-pass < main.bc
> main.unroll.s
Pass Arguments:  -domtree -loops -scalar-evolution -loopsimplify -domfrontier
-scalar-evolution -lcssa -indvars -loop-rotate -domfrontier -scalar-evolution
-lcssa -my-loop-pass -preverify -domtree -verify
Target Data Layout
  ModulePass Manager
    FunctionPass Manager
      Dominator Tree Construction
      Natural Loop Construction
      Scalar Evolution Analysis
--      Scalar Evolution Analysis
      Canonicalize natural loops
      Dominance Frontier Construction
      Scalar Evolution Analysis
      Loop Pass Manager
        Loop-Closed SSA Form Pass
        Canonicalize Induction Variables
--        Canonicalize Induction Variables
        Rotate Loops
--        Loop-Closed SSA Form Pass
--        Rotate Loops
--      Dominance Frontier Construction
--      Scalar Evolution Analysis
      Dominance Frontier Construction
      Scalar Evolution Analysis
      Loop Pass Manager
        Loop-Closed SSA Form Pass
        <My Loop Pass>
--        <My Loop Pass>
--        Loop-Closed SSA Form Pass
--      Natural Loop Construction
--      Canonicalize natural loops
--      Dominance Frontier Construction
--      Dominator Tree Construction
--      Scalar Evolution Analysis
      Preliminary module verification
      Dominator Tree Construction
      Module Verifier
--      Preliminary module verification
--      Dominator Tree Construction
--      Module Verifier
    Bitcode Writer
--    Bitcode Writer

I have two loops in my source program which have statically-determinable
bounds:

for (i=1; i < 99999; i++)
{
....
}

Is there anything else I should be doing before invoking the getTripCount()
method ?

thanks,
Prakash


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sat Apr 26 23:46:08 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 26 Apr 2008 23:46:08 -0500
Subject: [LLVMbugs] [Bug 2254] New: bugpoint's steps-to-reproduce forget
	tool-args
Message-ID: <bug-2254-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2254

           Summary: bugpoint's steps-to-reproduce forget tool-args
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: bugpoint
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1606)
 --> (http://llvm.org/bugs/attachment.cgi?id=1606)
testcase

This file x.bc reduces when run with:
  bugpoint x.bc -mem2reg -loop-rotate -indvars -loop-unroll --tool-args --
-unroll-threshold 1000 -unroll-count 2

But the steps to reproduce show only:
*** You can reproduce the problem with: opt bugpoint-reduced-simplified.bc
-mem2reg -loop-rotate -indvars -loop-unroll

which fails to reproduce the problem. If you add on the "-unroll-threshold 1000
-unroll-count 2" then it works fine (by crashing).


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 27 00:10:50 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 27 Apr 2008 00:10:50 -0500
Subject: [LLVMbugs] [Bug 2254] bugpoint's steps-to-reproduce forget tool-args
In-Reply-To: <bug-2254-206@http.llvm.org/bugs/>
Message-ID: <200804270510.m3R5Aodw007697@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2254


Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Nick Lewycky <nicholas at mxc.ca>  2008-04-27 00:10:49 ---
Doh. Testcase doesn't reproduce problem as claimed. I'll reopen it if I succeed
in pulling my head out of my


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 27 18:16:31 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 27 Apr 2008 18:16:31 -0500
Subject: [LLVMbugs] [Bug 2143] glibc depends on order of top-level asm
 blocks and functions
In-Reply-To: <bug-2143-206@http.llvm.org/bugs/>
Message-ID: <200804272316.m3RNGVbw006874@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2143


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #9 from Chris Lattner <sabre at nondot.org>  2008-04-27 18:16:30 ---
This is a bug in glibc, not llvm.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 27 18:17:26 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 27 Apr 2008 18:17:26 -0500
Subject: [LLVMbugs] [Bug 2093] inlineasm regression from PR2076
In-Reply-To: <bug-2093-206@http.llvm.org/bugs/>
Message-ID: <200804272317.m3RNHQYO006918@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2093


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from Chris Lattner <sabre at nondot.org>  2008-04-27 18:17:26 ---
This got applied


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 27 18:35:52 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 27 Apr 2008 18:35:52 -0500
Subject: [LLVMbugs] [Bug 2255] New: getCopyRegToReg() does not support ST(1)
 as dest register
Message-ID: <bug-2255-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2255

           Summary: getCopyRegToReg() does not support ST(1) as dest
                    register
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1607)
 --> (http://llvm.org/bugs/attachment.cgi?id=1607)
Test bytecode

Consider attached testcase. I'm having:

llc: /home/asl/proj/llvm/src/lib/Target/X86/X86InstrInfo.cpp:1593: virtual void
llvm::X86InstrInfo::copyRegToReg(llvm::MachineBasicBlock&,
llvm::ilist_iterator<llvm::MachineInstr>, unsigned int, unsigned int, const
llvm::TargetRegisterClass*, const llvm::TargetRegisterClass*) const: Assertion
`DestReg == X86::ST0 && "Can only copy to TOS right now"' failed.

This currently prevents mingw64 CRT bootstrap with llvm-gcc


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 27 18:49:34 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 27 Apr 2008 18:49:34 -0500
Subject: [LLVMbugs] [Bug 2256] New: simplifycfg produces invalid bytecode
Message-ID: <bug-2256-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2256

           Summary: simplifycfg produces invalid bytecode
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1608)
 --> (http://llvm.org/bugs/attachment.cgi?id=1608)
Bytecode

Consider attached bytecode. Running opt -simplifycfg yields:

Instruction does not dominate all uses!
        %tmp184 = mul x86_fp80 %mrv_gr181, 0xKBFFE8000000000000000             
; <x86_fp80> [#uses=3]
        ret x86_fp80 %tmp184, x86_fp80 %tmp191
Instruction does not dominate all uses!
        %tmp184 = mul x86_fp80 %mrv_gr181, 0xKBFFE8000000000000000             
; <x86_fp80> [#uses=3]
        ret x86_fp80 %tmp184, x86_fp80 %tmp191
Broken module found, compilation aborted!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 27 18:59:15 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 27 Apr 2008 18:59:15 -0500
Subject: [LLVMbugs] [Bug 2257] New: Assertion in FP stackifier
Message-ID: <bug-2257-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2257

           Summary: Assertion in FP stackifier
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1609)
 --> (http://llvm.org/bugs/attachment.cgi?id=1609)
Bytecode

Consider attached bytecode.

$ ./llc bugpoint-reduced-simplified.bc 
llc: /home/asl/proj/llvm/src/lib/Target/X86/X86FloatingPoint.cpp:975:
void<unnamed>::FPS::handleSpecialFP(llvm::ilist_iterator<llvm::MachineInstr>&):
Assertion `StackTop == 1 && "Stack should have one element on it to return!"'
failed.
./llc[0x878a1ad]
/lib/libc.so.6(abort+0xe8)[0xb7c687e8]
/lib/libc.so.6(__assert_fail+0xdf)[0xb7c6040f]
./llc[0x82a9f66]


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Sun Apr 27 19:19:45 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 27 Apr 2008 19:19:45 -0500
Subject: [LLVMbugs] [Bug 2256] simplifycfg produces invalid bytecode
In-Reply-To: <bug-2256-206@http.llvm.org/bugs/>
Message-ID: <200804280019.m3S0JjJn008997@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2256


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #2 from Chris Lattner <sabre at nondot.org>  2008-04-27 19:19:44 ---
Fixed, patch here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080421/061655.html

Thanks!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 28 03:10:59 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 28 Apr 2008 03:10:59 -0500
Subject: [LLVMbugs] [Bug 2132] x86_64: Compiling
 gcc.c-torture/compile/20050622-1. c exhausts physical memory
In-Reply-To: <bug-2132-206@http.llvm.org/bugs/>
Message-ID: <200804280810.m3S8Ax55030020@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2132


T??r??k Edwin <edwintorok at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #5 from T??r??k Edwin <edwintorok at gmail.com>  2008-04-28 03:10:59 ---
This no longer fails, closing bug.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 28 09:01:35 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 28 Apr 2008 09:01:35 -0500
Subject: [LLVMbugs] [Bug 2258] New: LLVM does not properly handle compile
 units in debug records
Message-ID: <bug-2258-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2258

           Summary: LLVM does not properly handle compile units in debug
                    records
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard.smith at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


This was discussed on the llvmdev mailing list.

The short problem description is that llvm does not distinguish between compile
units and source files in its debug records. Without this distinction it is not
possible to emit dwarf records correctly. This could be resolved if there was
some way of linking the source files common to a compile unit together.

The longer problem description follows:

Consider these two modules which I will compile and link together using gcc:

Module 1 is comprised of one source file:

main.c:
  static int a = 1;
  extern int fn1(void);

  int main (int argc, char **argv) {
    return fn1();
  }

I compile this with the command-line

gcc main.c -g -c -o main.o

Module 2 is comprised of three source files:

file1.c:
  #include "file2.h"
  #include "file3.h"
  int fn1(void) {
    return fn2(a);
  }

file2.h:
  static int a = 2;

file3.h:
  int fn2(int p) {
    return p * 2;
  }

I compile this with the command-line

gcc file1.c -g -c -o file1.o

Finally I link the modules

gcc main.o file1.o -o main

In the non-llvm sense, each of these two modules is a compile unit.

To see the debug records I use:

objdump -W main > objdump.gcc.txt

Looking at this file, I see two compile units as I would expect (plus the C
libraries):

Compilation Unit @ offset 0x1a1:
...
<0><1ac>: Abbrev Number: 1 (DW_TAG_compile_unit)
...
DW_AT_name        : main.c
...
<1><208>: Abbrev Number: 2 (DW_TAG_subprogram)
...
DW_AT_name        : main
...
<1><25a>: Abbrev Number: 6 (DW_TAG_variable)
DW_AT_name        : a

and

Compilation Unit @ offset 0x25b:
...
<0><266>: Abbrev Number: 1 (DW_TAG_compile_unit)
...
DW_AT_name        : file1.c
...
<1><2c3>: Abbrev Number: 2 (DW_TAG_subprogram)
...
DW_AT_name        : fn2
...
<1><2f4>: Abbrev Number: 5 (DW_TAG_subprogram)
...
DW_AT_name        : fn1
...
<1><30d>: Abbrev Number: 6 (DW_TAG_variable)
DW_AT_name        : a

The problem I have is that llvm considers a _source file_ to be a compile
unit. My code generator - a back-end I have built for llc - uses the compile
unit information in the llvm *but an llvm compile unit is indistinct from a
source file*. It is true that I _also_ want to know what source file the
declarations are in, but using the information I have, my code generator
erroneously emits debug records for _four_ different compile units: the one
named "main.c" contains the definition of main and variable a, compile unit
"file1.c" contains the definition of fn1, compile unit "file2.h" contains
the definition of variable a and compile unit "file3.h" contains the
definition of fn2.

The existing dwarf writer used in the existing back-ends makes no attempt to
distinguish compile units and emits all the records within a single unit, which
is also wrong. If I compile my sources as follows:

llvm-gcc -c -g main.c -o main.o
llvm-gcc -c -g file1.c -o file1.o
llvm-ld -disable-opt main.o file1.o -o main
llc main.bc -f -o main -march=x86
gcc main.s -o main
objdump -W main > objdump.llvm.txt

I find that the debug records claim that everything is contained in a single
compile unit named "file1.c". I also note that because both of the compile
units contained variables named a, llvm has only emitted one debug record
for such a variable and no matter where I query the value of it when
debugging I always get given the value of the variable in main.c.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 28 12:13:41 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 28 Apr 2008 12:13:41 -0500
Subject: [LLVMbugs] [Bug 2259] New: LLVM installs stkrc and tblgen man pages
Message-ID: <bug-2259-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2259

           Summary: LLVM installs stkrc and tblgen man pages
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


The LLVM "make install" process installs 
  share/man/man1/stkrc.1
  share/man/man1/tblgen.1
but it does not install either a stkrc or tbgen command.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 28 14:16:39 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 28 Apr 2008 14:16:39 -0500
Subject: [LLVMbugs] [Bug 2260] New: sin of omission: load from volatile
Message-ID: <bug-2260-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2260

           Summary: sin of omission: load from volatile
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


This is observed for llvm + gcc-4.2 version 50368, on Ubuntu Feisty on x86-32.

This input:

volatile int g_1;
void foo (void)
{
  g_1;
}

Compiled like this:

llvm-gcc -O1 -S small.c

Produces:

foo:
        pushl   %ebp
        movl    %esp, %ebp
        popl    %ebp
        ret

It is necessary to load from g_1.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Mon Apr 28 14:52:15 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 28 Apr 2008 14:52:15 -0500
Subject: [LLVMbugs] [Bug 2260] sin of omission: load from volatile
In-Reply-To: <bug-2260-206@http.llvm.org/bugs/>
Message-ID: <200804281952.m3SJqFhi019421@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2260


Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gohman at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Dan Gohman <gohman at apple.com>  2008-04-28 14:52:15 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080428/061708.html


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 29 00:56:28 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 29 Apr 2008 00:56:28 -0500
Subject: [LLVMbugs] [Bug 2094] Inefficient code generated for inline asm
 with multiple in-out register operands
In-Reply-To: <bug-2094-206@http.llvm.org/bugs/>
Message-ID: <200804290556.m3T5uS96005652@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2094


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |code-quality
         Resolution|                            |FIXED




--- Comment #6 from Chris Lattner <sabre at nondot.org>  2008-04-29 00:56:27 ---
Implemented.

Here's the last codegen pieces:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080428/061730.html
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080428/061731.html

Here's the CFE piece:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080428/061739.html

-Chris


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 29 00:57:03 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 29 Apr 2008 00:57:03 -0500
Subject: [LLVMbugs] [Bug 2095] [meta] Multiple return value support
In-Reply-To: <bug-2095-206@http.llvm.org/bugs/>
Message-ID: <200804290557.m3T5v3Oi005721@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2095


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Chris Lattner <sabre at nondot.org>  2008-04-29 00:57:02 ---
#6 is done.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 29 08:22:26 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 29 Apr 2008 08:22:26 -0500
Subject: [LLVMbugs] [Bug 2261] New: SCEV creates unneeded SMAX node
Message-ID: <bug-2261-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2261

           Summary: SCEV creates unneeded SMAX node
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


This (unremarkable) testcase from the GCC testsuite
gcc/testsuite/gcc.apple/i386-bitmask1.c compiles into:

entry:
        %tmp2126 = icmp sgt i32 %count, 0               ; <i1> [#uses=1]
        br i1 %tmp2126, label %bb.preheader, label %return

bb.preheader:           ; preds = %entry
        %tmp = icmp slt i32 %count, 1           ; <i1> [#uses=1]
        %smax = select i1 %tmp, i32 1, i32 %count               ; <i32>
[#uses=1]
        br label %bb
..

This is because a SCEV is created with an SMAX(count,1) node, even though the
whole loop is dominated by a check that count is > 0.  SCEV should do a little
bit of analysis of dominating branches to simplify the SCEV expressions in this
extremely common case.  While we could make follow-on optimizations catch this,
it is better to just not insert it in the first place, and having more precise
SCEV expressions is always good.

The full test is:

unsigned char lut[256];
void foo( int count, unsigned int *srcptr, unsigned *dstptr ) {
  int j;
    for (j = 0; j < count; j++) {
    unsigned int tmp = *srcptr;
    unsigned int alpha = (tmp&255);
    tmp &= 0xffffff00;
    alpha =lut[alpha];
    tmp |= alpha<<0;
    *dstptr = tmp;
  }
}


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 29 10:26:53 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 29 Apr 2008 10:26:53 -0500
Subject: [LLVMbugs] [Bug 2262] New: volatile load should not be moved inside
	loop
Message-ID: <bug-2262-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2262

           Summary: volatile load should not be moved inside loop
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


This is observed for recent SVN of llvm + gcc-4.2 on Ubuntu Feisty on x86-32.

This program:

volatile int g_1;

void loop (void)
{
  int b;
  for (b = 0; b < 10; b++)
    {
      g_1 += 5;
    }
}

int foo (void)
{
  loop ();
  return g_1;
}

compiled like this:

llvm-gcc -Os -S -Wall small.c

gives this output:

foo:
        pushl   %ebp
        movl    %esp, %ebp
        xorl    %ecx, %ecx
        movl    g_1, %eax
        .align  16
.LBB2_1:        # bb
        addl    $5, %eax
        movl    %eax, g_1
        incl    %ecx
        cmpl    $10, %ecx
        movl    g_1, %eax
        jne     .LBB2_1 # bb
.LBB2_2:        # bb9
        popl    %ebp
        ret

The final move of g_1 into eax should be outside of the loop.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 29 12:29:54 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 29 Apr 2008 12:29:54 -0500
Subject: [LLVMbugs] [Bug 2262] volatile load should not be moved inside loop
In-Reply-To: <bug-2262-206@http.llvm.org/bugs/>
Message-ID: <200804291729.m3THTsCa003435@zion.cs.uiuc.edu>

http://llvm.org/bugs/show_bug.cgi?id=2262


Chris Lattner <sabre at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |miscompilation
         Resolution|                            |FIXED




--- Comment #6 from Chris Lattner <sabre at nondot.org>  2008-04-29 12:29:52 ---
Second fix here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20080428/061771.html

We now get:

_main:
        subl    $12, %esp
        xorl    %eax, %eax
        movl    _g_1, %ecx
        .align  4,0x90
LBB3_1: ## bb
        addl    $5, %ecx
        movl    %ecx, _g_1
        incl    %eax
        cmpl    $10, %eax
        movl    _g_1, %ecx
        jne     LBB3_1  ## bb
LBB3_2: ## bb11
        movl    $_.str, (%esp)
        call    _puts
        xorl    %eax, %eax
        addl    $12, %esp
        ret

with llvm-gcc -Os -S t.c -Wall -o - -static -fomit-frame-pointer, which I
believe to be right.

Thanks!


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 29 14:51:33 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 29 Apr 2008 14:51:33 -0500
Subject: [LLVMbugs] [Bug 2263] New: clang doesn't pick up type attribute on
	argument
Message-ID: <bug-2263-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2263

           Summary: clang doesn't pick up type attribute on argument
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sabre at nondot.org
                CC: llvmbugs at cs.uiuc.edu


Clang doesn't parse this because the attr isn't applied to the type correctly:

float vf(__attribute__((vector_size(16))) float a, int b) {
   return a[b];
}


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Tue Apr 29 18:45:25 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 29 Apr 2008 18:45:25 -0500
Subject: [LLVMbugs] [Bug 2264] New: internal compiler error
Message-ID: <bug-2264-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2264

           Summary: internal compiler error
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


Using recent svn on x86-32 compiling this fragment:

typedef signed char int8_t;
typedef short int int16_t;
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
uint32_t g_2 = 8L;
volatile int16_t g_133 = 0x7EAAL;
uint32_t g_139 = 0L;
volatile uint8_t g_160 = 6L;
int32_t func_31 (int16_t p_33, int16_t p_34, int32_t p_35);
int32_t func_97 (uint32_t p_98);
int32_t
func_97 (uint32_t p_98)
{
  uint8_t l_190 = 0xFAL;
  int8_t l_163 = 1L;
  for (p_98 = -26; ((g_160) >= -29); (g_160)--)
    {
      int8_t l_192 = 0x85L;
      func_31 (((((l_190 / 1L) - p_98) ^ ((g_139 + p_98) ^ 0xA2D7L))
                && g_2), (((((g_133) && l_192) || p_98) | l_163) > 1L), p_98);
    }
}

Gives this:

[regehr at babel tmp1]$ llvm-gcc -O0 -S small.c
small.c: In function 'func_97':
small.c:17: warning: comparison is always true due to limited range of data
type
small.c:14: internal compiler error: in lhd_set_decl_assembler_name, at
langhooks.c:165
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 30 02:27:59 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 30 Apr 2008 02:27:59 -0500
Subject: [LLVMbugs] [Bug 2265] New: Can't solve trip count for simple loop
Message-ID: <bug-2265-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2265

           Summary: Can't solve trip count for simple loop
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: resistor at mac.com
                CC: llvmbugs at cs.uiuc.edu


Here's a pretty simple loop:

define i32 @"test function"(i32 %i0, i32 %j0) {
BB1:
        br label %BB2

BB2:            ; preds = %BB5, %BB1
        %k2 = phi i32 [ 0, %BB1 ], [ %k3, %BB5 ]                ; <i32>
[#uses=2]
        %kcond = icmp slt i32 %k2, 100          ; <i1> [#uses=1]
        br i1 %kcond, label %BB5, label %BB4

BB4:            ; preds = %BB2
        ret i32 1

BB5:            ; preds = %BB2
        %k3 = add i32 %k2, 1            ; <i32> [#uses=1]
        br label %BB2
}

The {BB2, BB5} loop has an obvious trip count of 100, Loop::getTripCount fails
to realize this.  This is blocking loop deletion from removing the loop.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 30 11:43:12 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 30 Apr 2008 11:43:12 -0500
Subject: [LLVMbugs] [Bug 2266] New: semantic analyzer assertion on malformed
 code: " The next DeclContext should be directly contained in the current
 one."
Message-ID: <bug-2266-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2266

           Summary: semantic analyzer assertion on malformed code: "The next
                    DeclContext should be directly contained in the current
                    one."
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kremenek at cs.stanford.edu
                CC: llvmbugs at cs.uiuc.edu


We're seeing an assertion failure that appears to be a regression in handling
malformed code.  The following code triggers an assertion:

int f1 (struct X *x, struct Y *y) {
  int error = 0;
  error = f2 (x, y);
  return error;
}

int
f2 (struct X *x, struct Y *y)
{

I am at revision r50483 of clang.  I am using Mac OS X (Leopard), although I
believe the bug will appear on other platforms (haven't tested yet).

The output of clang:

$ clang /tmp/t.c
Assertion failed: (( (isa<ObjCMethodDecl>(DC) &&
isa<TranslationUnitDecl>(CurContext)) || DC->getParent() == CurContext ) &&
"The next DeclContext should be directly contained in the current one."),
function PushDeclContext, file SemaDecl.cpp, line 48.
0   clang                               0x00297b19 _ZNK4llvm3sys4PathneERKS1_ +
79
1   clang                               0x00297d15
_ZN4llvm3sys28PrintStackTraceOnErrorSignalEv + 387
2   libSystem.B.dylib                   0x915d65eb _sigtramp + 43
3   ???                                 0xffffffff 0x0 + 4294967295
4   libSystem.B.dylib                   0x9164f3f2 raise + 26
5   libSystem.B.dylib                   0x9165e9af abort + 73
6   libSystem.B.dylib                   0x91650593 __assert_rtn + 101
7   clang                               0x000e1cb3
_ZN5clang4Sema15PushDeclContextEPNS_11DeclContextE + 135
8   clang                               0x000e2112
_ZN5clang4Sema23ActOnStartOfFunctionDefEPNS_5ScopeERNS_10DeclaratorE + 1104
9   clang                               0x00171425
_ZN5clang6Parser23ParseFunctionDefinitionERNS_10DeclaratorE + 505
10  clang                               0x0017198b
_ZN5clang6Parser36ParseDeclarationOrFunctionDefinitionEv + 1333
11  clang                               0x00171ae5
_ZN5clang6Parser24ParseExternalDeclarationEv + 85
12  clang                               0x00171d03
_ZN5clang6Parser17ParseTopLevelDeclERPv + 61
13  clang                               0x000d6f5f
_ZN5clang8ParseASTERNS_12PreprocessorEPNS_11ASTConsumerEb + 339
14  clang                               0x00028de4
_Z16InitializeGCModeRN5clang11LangOptionsE + 5620
15  clang                               0x0002b917 main + 1345
16  clang                               0x00001b62 start + 54


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 30 14:07:10 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 30 Apr 2008 14:07:10 -0500
Subject: [LLVMbugs] [Bug 2267] New: llvm-gcc no longer accepts some
 assembly: Invalid or unsupported inline assembly!
Message-ID: <bug-2267-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2267

           Summary: llvm-gcc no longer accepts some assembly: Invalid or
                    unsupported inline assembly!
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I tried to build glibc with llvm-gcc4.2, and I get lots of there errors:

abort.c: In function ???abort???:
abort.c:86: error: Invalid or unsupported inline assembly!

This errors is shown many times, I picked the error from abort.c:

$ grep "unsupported inline assembly" ../../i386-libc/log|wc -l
1043

The reduced testcase shows it is a libc asm low-level lock function that is not
accepted by llvm-gcc. A while ago (I don't remember which revision) I was able
to compile glibc without these errors.

To reproduce:
$ gcc testcase-min.i -fsyntax-only
$ llvm-gcc testcase-min.i -fsyntax-only
testcase-min.i: In function ???abort???:
testcase-min.i:10: error: Invalid or unsupported inline assembly!

$ uname -a
Linux thunder 2.6.25-rc6-00268-gd2532dd-dirty #23 SMP PREEMPT Sun Mar 23
18:34:55 EET 2008 i686 GNU/Linux

testcase-min.i:
typedef struct {
              int lock;
              int cnt;
              }
                   __libc_lock_recursive_t;
                   static int stage;
                   static __libc_lock_recursive_t lock;
                   void abort (void) {
                if (stage == 2)     {
                 do {        if (--(lock).cnt == 0) {      (void) ({    int
ignore;    if (__builtin_constant_p (0) && (0) == 0) __asm __volatile ("cmpl
$0, %%gs:%P3\n\t" "je 0f\n\t" "lock\n" "0:\tsubl $1,%0\n\t" "jne
_L_unlock_%=\n\t" ".subsection 1\n\t" ".type _L_unlock_%=, at function\n"
"_L_unlock_%=:\n" "1:\tleal %0, %%eax\n" "2:\tcall __lll_unlock_wake_private\n"
"3:\tjmp 18f\n" "4:\t.size _L_unlock_%=, 4b-1b\n\t" ".previous\n" ".section   
.eh_frame,\"a\", at progbits\n" "5:\t" ".long      7f-6f   # Length of Common
Information Entry\n" "6:\t" ".long   0x0     # CIE Identifier Tag\n\t" ".byte  
     0x1     # CIE Version\n\t" ".ascii \"zR\\0\"    # CIE Augmentation\n\t"
".uleb128 0x1   # CIE Code Alignment Factor\n\t" ".sleb128 -4   # CIE Data
Alignment Factor\n\t" ".byte 0x8     # CIE RA Column\n\t" ".uleb128 0x1      #
Augmentation size\n\t" ".byte 0x1b    # FDE Encoding (pcrel sdata4)\n\t" ".byte
      0xc     # DW_CFA_def_cfa\n\t" ".uleb128 0x4\n\t" ".uleb128 0x0\n\t"
".align 4\n" "7:\t" ".long  17f-8f  # FDE Length\n" "8:\t" ".long   8b-5b   #
FDE CIE offset\n\t" ".long    1b-.# FDE initial location\n\t" ".long  4b-1b   #
FDE address range\n\t" ".uleb128 0x0  # Augmentation size\n\t" ".byte 0x16    #
DW_CFA_val_expression\n\t" ".uleb128 0x8\n\t" ".uleb128 10f-9f\n" "9:\t" ".byte
      0x78    # DW_OP_breg8\n\t" ".sleb128 3b-1b\n" "10:\t" ".byte    0x40 +
(2b-1b) # DW_CFA_advance_loc\n\t" ".byte 0x16    # DW_CFA_val_expression\n\t"
".uleb128 0x8\n\t" ".uleb128 12f-11f\n" "11:\t" ".byte     0x78    #
DW_OP_breg8\n\t" ".sleb128 3b-2b\n" "12:\t" ".byte    0x40 + (3b-2b-1) #
DW_CFA_advance_loc\n\t" ".byte       0x16    # DW_CFA_val_expression\n\t"
".uleb128 0x8\n\t" ".uleb128 16f-13f\n" "13:\t" ".byte     0x78    #
DW_OP_breg8\n\t" ".sleb128 15f-14f\n\t" ".byte        0x0d    #
DW_OP_const4s\n" "14:\t" ".4byte      3b-.\n\t" ".byte        0x1c    #
DW_OP_minus\n\t" ".byte       0x0d    # DW_OP_const4s\n" "15:\t" ".4byte     
18f-.\n\t" ".byte       0x22    # DW_OP_plus\n" "16:\t" ".align 4\n" "17:\t"
".previous\n" "18:" : "=m" ((lock).lock), "=&a" (ignore) : "m" ((lock).lock),
"i" (12) : "memory");    }     );      }        }
           while (0);
               }
                while (1)     asm ("hlt");
              }


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 30 14:28:23 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 30 Apr 2008 14:28:23 -0500
Subject: [LLVMbugs] [Bug 2268] New:
 void<unnamed>::FPS::handleSpecialFP(llvm::ilist_iterator<
 llvm::MachineInstr>&): Assertion `StackTop == 1 && " Stack should have one
 element on it to return!"' failed
Message-ID: <bug-2268-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2268

           Summary: void<unnamed>::FPS::handleSpecialFP(llvm::ilist_iterator
                    <llvm::MachineInstr>&): Assertion `StackTop == 1 &&
                    "Stack should have one element on it to return!"' failed
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1611)
 --> (http://llvm.org/bugs/attachment.cgi?id=1611)
testcase

While building glibc I get:

cc1: /home/edwin/llvm/llvm-svn/trunk/lib/Target/X86/X86FloatingPoint.cpp:975:
void<unnamed>::FPS::handleSpecialFP(llvm::ilist_iterator<llvm::MachineInstr>&):
 Assertion `StackTop == 1 && "Stack should have one element on it to return!"'
failed.
../sysdeps/ieee754/dbl-64/e_j0.c:529: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://developer.apple.com/bugreporter> for instructions.
make[2]: *** [/home/edwin/glibc-2.7/build-tree/i386-libc/math/e_j0.o] Error 1

To reproduce:
$ llvm-gcc -c -O1 testcase-min.i
cc1: /home/edwin/llvm/llvm-svn/trunk/lib/Target/X86/X86FloatingPoint.cpp:975:
void<unnamed>::FPS::handleSpecialFP(llvm::ilist_iterator<llvm::MachineInstr>&):
Assertion `StackTop == 1 && "Stack should have one element on it to return!"'
failed.
testcase-min.i:53: internal compiler error: Aborted

This error occurs 27 times during the glibc build
$ grep "Stack should have one element on it to return" ../../i386-libc/log|wc
-l
27

I was able to build these files with an older llvm revision a while ago.

I am unable to reproduce this by generating llvm bitcode (does llvm-gcc run
another pass that is not in -std-compile-opts?)

These both work:

$ llvm-gcc -O1 testcase-min.i -c -emit-llvm -o -|opt -std-compile-opts|llc|as
$ llvm-gcc -O1 testcase-min.i -c -emit-llvm -o -|llc|as

$ uname -a
Linux thunder 2.6.25-rc6-00268-gd2532dd-dirty #23 SMP PREEMPT Sun Mar 23
18:34:55 EET 2008 i686 GNU/Linux


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 30 14:33:21 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 30 Apr 2008 14:33:21 -0500
Subject: [LLVMbugs] [Bug 2269] New: Assertion `DestReg == X86::ST0 && " Can
 only copy to TOS right now"' failed.
Message-ID: <bug-2269-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2269

           Summary: Assertion `DestReg == X86::ST0 && "Can only copy to TOS
                    right now"' failed.
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


While building glibc I get a new error:

cc1: /home/edwin/llvm/llvm-svn/trunk/lib/Target/X86/X86InstrInfo.cpp:1593:
virtual void llvm::X86InstrInfo::copyRegToReg(llvm::MachineBasicBlock&,
llvm::ilist_iterator<llvm::MachineInstr>, unsigned int, unsigned int, const
llvm::TargetRegisterClass*, const llvm::TargetRegisterClass*) const: Assertion
`DestReg == X86::ST0 && "Can only copy to TOS right now"' failed.
w_atan2.c:43: internal compiler error: Aborted

This error occurs 51 times during the build:
$ grep "TOS right now" ../../i386-libc/log|wc -l
51

$ uname -a
Linux thunder 2.6.25-rc6-00268-gd2532dd-dirty #23 SMP PREEMPT Sun Mar 23
18:34:55 EET 2008 i686 GNU/Linux

I have a bugpoint reduced file this time, to reproduce:
$ llc bugpoint-reduced-simplified.bc
llc: /home/edwin/llvm/llvm-svn/trunk/lib/Target/X86/X86InstrInfo.cpp:1593:
virtual void llvm::X86InstrInfo::copyRegToReg(llvm::MachineBasicBlock&,
llvm::ilist_iterator<llvm::MachineInstr>, unsigned int, unsigned int, const
llvm::TargetRegisterClass*, const llvm::TargetRegisterClass*) const: Assertion
`DestReg == X86::ST0 && "Can only copy to TOS right now"' failed.
llc[0x852b506]
/lib/i686/cmov/libc.so.6(abort+0x101)[0x4ecdc871]
/lib/i686/cmov/libc.so.6(__assert_fail+0xee)[0x4ecd40ee]
llc(_ZNK4llvm12X86InstrInfo12copyRegToRegERNS_17MachineBasicBlockENS_14ilist_iteratorINS_12MachineInstrEEEjjPKNS_19TargetRegisterClassES8_+0x607)[0x81f0427]
Aborted

; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"

@atan2 = alias double (double, double)* @__atan2                ; <double
(double, double)*> [#uses=0]

define double @__atan2(double %y, double %x) nounwind  {
entry:
        %asmtmp = tail call x86_fp80 asm sideeffect "fpatan\0A\09",
"={st},0,{st(1)},~{dirflag},~{fpsr},~{flags},~{st(1)}"( double %x, double %y )
nounwind ; <x86_fp80> [#uses=0]
        unreachable
}


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 30 14:37:52 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 30 Apr 2008 14:37:52 -0500
Subject: [LLVMbugs] [Bug 2270] New: Assertion `UpdatedSlot < StackTop &&
 Dest < 7' failed.
Message-ID: <bug-2270-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2270

           Summary: Assertion `UpdatedSlot < StackTop && Dest < 7' failed.
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=1612)
 --> (http://llvm.org/bugs/attachment.cgi?id=1612)
full testcase

While building glibc  this error occurs 3 times:

cc1: /home/edwin/llvm/llvm-svn/trunk/lib/Target/X86/X86FloatingPoint.cpp:858:
void<unnamed>::FPS::handleTwoArgFP(llvm::ilist_iterator<llvm::MachineInstr>&):
Assertion `UpdatedSlot < StackTop && Dest < 7' failed.
../sysdeps/ieee754/ldbl-96/e_asinl.c:161: internal compiler error: Aborted

To reproduce:

$ llc x.bc -f
llc: /home/edwin/llvm/llvm-svn/trunk/lib/Target/X86/X86FloatingPoint.cpp:858:
void<unnamed>::FPS::handleTwoArgFP(llvm::ilist_iterator<llvm::MachineInstr>&):
Assertion `UpdatedSlot < StackTop && Dest < 7' failed.
llc[0x852b506]
/lib/i686/cmov/libc.so.6(abort+0x101)[0x4ecdc871]
/lib/i686/cmov/libc.so.6(__assert_fail+0xee)[0x4ecd40ee]
llc[0x81012cc]
Aborted

$ llc bugpoint-reduced-simplified.bc -f
llc: /home/edwin/llvm/llvm-svn/trunk/lib/Target/X86/X86FloatingPoint.cpp:92:
unsigned int<unnamed>::FPS::getStackEntry(unsigned int) const: Assertion `STi <
StackTop && "Access past stack top!"' failed.
llc[0x852b506]
/lib/i686/cmov/libc.so.6(abort+0x101)[0x4ecdc871]
/lib/i686/cmov/libc.so.6(__assert_fail+0xee)[0x4ecd40ee]
llc[0x80ff2f4]
Aborted

; ModuleID = 'bugpoint-reduced-simplified.bc'
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-v64:64:64-v128:128:128-a0:0:64-f80:32:32"
target triple = "i386-pc-linux-gnu"

define x86_fp80 @__ieee754_asinl(x86_fp80 %x) nounwind  {
entry:
        %asmtmp = call x86_fp80 asm sideeffect "fsqrt",
"={st},0,~{dirflag},~{fpsr},~{flags}"( x86_fp80 0xK00000000000000000000 )
nounwind              ; <x86_fp80> [#uses=0]
        %tmp243 = sub x86_fp80 0xK80000000000000000000, 0xK00000000000000000000
        ; <x86_fp80> [#uses=1]
        ret x86_fp80 %tmp243
}


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at cs.uiuc.edu  Wed Apr 30 21:37:32 2008
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 30 Apr 2008 21:37:32 -0500
Subject: [LLVMbugs] [Bug 2271] New: bug?
Message-ID: <bug-2271-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=2271

           Summary: bug?
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu


Assuming integer types are 2's complement, the attached code appears to have
well-defined behavior.  If I am misunderstanding something about C arithmetic
then I apologize profusely for wasting peoples' time.  The source should be
small enough that someone can check this out relatively quickly.

With LLVM from recent svn on x86-32 I get the following:

[regehr at babel tmp1]$ llvm-gcc -O0 -fwrapv small.c ; ./a.out 
foo
[regehr at babel tmp1]$ llvm-gcc -O1 -fwrapv small.c ; ./a.out 
bar

For what it's worth "foo" is what gcc prints at all optimization levels.


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.