From bugzilla-daemon at cs.uiuc.edu  Fri Jan  1 12:36:41 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jan 2010 12:36:41 -0600
Subject: [LLVMbugs] [Bug 5284] missing instcombine for bswap(trunc(bswap x)))
In-Reply-To: <bug-5284-206@http.llvm.org/bugs/>
Message-ID: <201001011836.o01IafPZ027284@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #3 from Chris Lattner <clattner at apple.com>  2010-01-01 12:36:41 ---
Transformation implemented here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091228/093349.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 Jan  1 12:38:32 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jan 2010 12:38:32 -0600
Subject: [LLVMbugs] [Bug 5189] trichotomy of scalars not optimized
In-Reply-To: <bug-5189-206@http.llvm.org/bugs/>
Message-ID: <201001011838.o01IcWq2027345@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-01 12:38:32 ---
Looks like this got fixed along the way:

$ clang t.c -S -o - -O2 -emit-llvm
...
define i32 @main(i32 %argc, i8** nocapture %argv) nounwind readnone ssp {
entry:
  %0 = icmp eq i32 %argc, 42                      ; <i1> [#uses=1]
  %land.ext.i = zext i1 %0 to i32                 ; <i32> [#uses=1]
  ret i32 %land.ext.i
}


-- 
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 Jan  1 12:44:33 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jan 2010 12:44:33 -0600
Subject: [LLVMbugs] [Bug 3740] Odd missed optimization
In-Reply-To: <bug-3740-206@http.llvm.org/bugs/>
Message-ID: <201001011844.o01IiXQi027549@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #2 from Chris Lattner <clattner at apple.com>  2010-01-01 12:44:32 ---
This is now optimized away by both llvm-gcc and clang.


-- 
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 Jan  1 12:45:28 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jan 2010 12:45:28 -0600
Subject: [LLVMbugs] [Bug 2255] getCopyRegToReg() does not support ST(1) as
	dest register
In-Reply-To: <bug-2255-206@http.llvm.org/bugs/>
Message-ID: <201001011845.o01IjSSn027610@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #3 from Chris Lattner <clattner at apple.com>  2010-01-01 12:45:27 ---
Yep, looks 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  Fri Jan  1 17:47:13 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jan 2010 17:47:13 -0600
Subject: [LLVMbugs] [Bug 5927] New: error in backend: Cannot yet select
Message-ID: <bug-5927-206@http.llvm.org/bugs/>

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

           Summary: error in backend: Cannot yet select
           Product: new-bugs
           Version: trunk
          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, chenyang at cs.utah.edu


Seen on Ubuntu 9.10 on x86.

regehr at john-home:~/volatile/bugs/tmp251$ clang -w -c -O small.c

fatal error: error in backend: Cannot yet select: 0xa773d8c: i32 = shl
0xa794d14,
      0xa794d98

regehr at john-home:~/volatile/bugs/tmp251$ clang -v

clang version 1.1 (trunk 92359)
Target: i386-pc-linux-gnu
Thread model: posix

regehr at john-home:~/volatile/bugs/tmp251$ cat small.c

typedef short int int16_t;
typedef int int32_t;
typedef unsigned char uint8_t;
typedef unsigned int uint32_t;
__extension__ typedef unsigned long long int uint64_t;

static int16_t
safe_mul_func_int16_t_s_s (int16_t si1, uint8_t si2)
{
  return si1 && si2 && si1 > 32767 + si2 || si1 && si2 <= 0 && si2 + si1
    || si1 && si2 && si1 < (1 / si2) || si1 && si2 <= 0 && si1
    && si2 + si1 ? : si1 * si2;
}

static uint8_t
safe_mul_func_uint8_t_u_u (uint8_t ui1, uint8_t ui2)
{
  return ui1 * ui2;
}

static uint32_t
safe_sub_func_uint64_t_u_u (uint64_t ui1, uint64_t ui2)
{
  return ui1 - ui2;
}

struct S1
{
  uint8_t f1;
};

uint8_t *volatile g_19;
uint8_t g_20;

struct S1 g_111 = {
};

void uint81 (void)
{
  uint8_t l;
  uint8_t **l_27 = &g_19;
  uint8_t *l_24 = &g_20;
  int32_t **l_139 = &l_24;
  uint8_t l_161 = 0xF2A7L;
  *l_27 =
    func_79 (&g_111.f1,
             &l < safe_sub_func_uint64_t_u_u (safe (1),
                                              safe_mul_func_int16_t_s_s
                                              (safe_mul_func_uint8_t_u_u
                                               (l_161,
                                                **l_139) ^ **l_27 == *l_24,
                                               0x30AC0004L)));
}


-- 
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 Jan  1 19:23:03 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jan 2010 19:23:03 -0600
Subject: [LLVMbugs] [Bug 3351] constant folding should fold this constant
	expr
In-Reply-To: <bug-3351-206@http.llvm.org/bugs/>
Message-ID: <201001020123.o021N32P009332@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #9 from Chris Lattner <clattner at apple.com>  2010-01-01 19:23:03 ---
This kills off the constantexprs for llvm-gcc:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20091228/093359.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 Jan  1 22:27:32 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 1 Jan 2010 22:27:32 -0600
Subject: [LLVMbugs] [Bug 5928] New: maybe a resource hog bug
Message-ID: <bug-5928-206@http.llvm.org/bugs/>

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

           Summary: maybe a resource hog bug
           Product: new-bugs
           Version: trunk
          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


Created an attachment (id=3996)
 --> (http://llvm.org/bugs/attachment.cgi?id=3996)
hog-inducing input

Here's a case where clang r92404 uses ~1.5 GB of RAM to compile a relatively
small (<100 KB after preprocessing) input.

Sorry for the non-reduced testcase, I can't easily delta on a resource bug.

Commandline is "clang -O3 foo.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  Sat Jan  2 14:07:17 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 2 Jan 2010 14:07:17 -0600
Subject: [LLVMbugs] [Bug 4912] "opt -insert-rs-profiling-framework" seems
 stuck in an infinite loop
In-Reply-To: <bug-4912-206@http.llvm.org/bugs/>
Message-ID: <201001022007.o02K7HJj028644@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #6 from Chris Lattner <clattner at apple.com>  2010-01-02 14:07:16 ---
Ok, thanks, I removed it in r92422


-- 
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 Jan  3 05:30:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jan 2010 05:30:21 -0600
Subject: [LLVMbugs] [Bug 5929] New: difference of blockaddress goes into
 .data.rel. ro instead of .rodata
Message-ID: <bug-5929-206@http.llvm.org/bugs/>

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

           Summary: difference of blockaddress goes into .data.rel.ro
                    instead of .rodata
           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


The array in this function should go into a .rodata section, but with clang it
only goes into .data.rel.ro (with -fPIC):
int test(int i) {
    static const int array[] = { &&foo - &&foo, &&bar - &&foo,
                                  &&hack - &&foo };
     goto *(&&foo + array[i]);
foo:
     return 1;
bar:
     return 2;
hack:
     return 3;
}

$ clang foo.c -O1 -S -m32 -fPIC -o -
..
        .section        .data.rel.ro,"aw", at progbits
        .align  4
test.array:
        .long   (.LBA4_test_return) - (.LBA4_test_return)
        .long   (.LBA4_test_bar) - (.LBA4_test_return)
        .long   (.LBA4_test_hack) - (.LBA4_test_return)
        .size   test.array, 12

$ gcc foo.c -O1 -S -m32 -fPIC -o -
...
.section        .rodata
        .align 4
        .type   array.1248, @object
        .size   array.1248, 12
array.1248:
        .long   0
        .long   .L4-.L2
        .long   .L5-.L2

This can be reproduced by running llc on the attached testcase too.


-- 
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 Jan  3 05:35:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jan 2010 05:35:09 -0600
Subject: [LLVMbugs] [Bug 5930] New: codegen: should support trunc of
 blockaddress difference
Message-ID: <bug-5930-206@http.llvm.org/bugs/>

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

           Summary: codegen: should support trunc of blockaddress difference
           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


Compiling the testcase from PR5929 in 64-bit mode crashes codegen:
$ llvm-git/obj/Release/bin/clang x.c
FIXME: Don't support this constant cast expr      
UNREACHABLE executed at
/home/edwin/llvm-git/llvm/lib/CodeGen/AsmPrinter/AsmPrinter.cpp:831!
0  clang           0x00000000013b912f
1  clang           0x00000000013b993d
2  libpthread.so.0 0x000000317a40e990
3  libc.so.6       0x0000003179831f55 gsignal + 53
4  libc.so.6       0x0000003179834d90 abort + 384
5  clang           0x000000000139b014
6  clang           0x0000000001018a01
7  clang           0x0000000001018eef
8  clang           0x00000000010196bf
9  clang           0x0000000001018f1e
10 clang           0x0000000000d24b24
11 clang           0x0000000001016b8f
12 clang           0x00000000013495d1
13 clang           0x0000000001349699
14 clang           0x00000000004afcab
15 clang           0x00000000004b05a5
16 clang           0x00000000006a2044
17 clang           0x000000000040d500
18 clang           0x000000000040feb3 main + 1523
19 libc.so.6       0x000000317981eabd __libc_start_main + 253
20 clang           0x000000000040b0e9
Stack dump:
0.      Program arguments: /home/edwin/llvm-git/obj/Release/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -S -disable-free -main-file-name x.c
-mrelocation-model static -mdisable-fp-elim -munwind-tables -target-cpu x86-64
-resource-dir /home/edwin/llvm-git/obj/Release/lib/clang/1.1 -fmessage-length
139 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-iydhUp.s -x c x.c
1.      <eof> parser at end of file
2.      Code generation
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

Attached is a bitcode testcase, the problem seems to be this constant:
i32 trunc (i64 sub (i64 ptrtoint (i8* blockaddress(@test, %return) to i64), i64
ptrtoint (i8* blockaddress(@test, %return) to i64)) to i32)

Truncating a 64-bit pointer to 32-bit isn't a good thing to do in general,
however both blockaddresses are in the same function, thus the difference can't
overflow a 32-bit number. So LLC shouldn't crash when trying to codegen 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 bugzilla-daemon at cs.uiuc.edu  Sun Jan  3 12:10:42 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jan 2010 12:10:42 -0600
Subject: [LLVMbugs] [Bug 5929] difference of blockaddress goes into
 .data.rel.ro instead of . rodata
In-Reply-To: <bug-5929-206@http.llvm.org/bugs/>
Message-ID: <201001031810.o03IAgXO012164@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #2 from Chris Lattner <clattner at apple.com>  2010-01-03 12:10:39 ---
Fixed in r92450, 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 Jan  3 12:12:43 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jan 2010 12:12:43 -0600
Subject: [LLVMbugs] [Bug 5901] Optimization changes behavior
In-Reply-To: <bug-5901-206@http.llvm.org/bugs/>
Message-ID: <201001031812.o03IChmw012271@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




-- 
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 Jan  3 12:33:31 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jan 2010 12:33:31 -0600
Subject: [LLVMbugs] [Bug 5930] codegen: should support trunc of blockaddress
	difference
In-Reply-To: <bug-5930-206@http.llvm.org/bugs/>
Message-ID: <201001031833.o03IXV4d013143@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #2 from Chris Lattner <clattner at apple.com>  2010-01-03 12:33:30 ---
Fixed in r92455, 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 Jan  3 19:53:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 3 Jan 2010 19:53:46 -0600
Subject: [LLVMbugs] [Bug 5540] Partial loop unwinding with variable
	iteration count
In-Reply-To: <bug-5540-206@http.llvm.org/bugs/>
Message-ID: <201001040153.o041rko6027868@zion.cs.uiuc.edu>

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


bearophile <bearophile at mailas.com> changed:

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




--- Comment #5 from bearophile <bearophile at mailas.com>  2010-01-03 19:53:46 ---
Thank you for your explanation, that shows me how to act :-)

This optimization is present and often done by the Java HotSpot, so Sun
engineers think it's not a waste of their time. And my experiments show they
are right.

In the last C attach I've shown a better example, it's a stripped down version
of the SciMark2 benchmark in C language that performs the LU benchmark only, it
prints the MFlops. It contains a part that performs conditional compilation, if
you define DO_UNROLL it performs the optimization quite similar to the one done
by HotSpot, otherwise uses the original SciMark2 code, so you can compare the
performance improvement. Timings are more info are at the top of the code.

Note that in this code I assume the loop count is NOT known at compile-time.

If you want I can show you another code example where this optimization is
useful.

Note that generally the more code there's in the loop, the less number of times
it's useful to perform such partial unwinding. Here HotSpot unwinds 8 times
(but I've seen that about 10 is optimal) because in the inner loop there's just
one line:
Aii[jj] -= AiiJ * Aj[jj];
But in another example, where there's more stuff inside the loop, HotSpot
unwinds 4 times only, because unwinding more probably puts the CPU code cache
under too much pressure, reducing performance. Life is made of compromises.

I think it's not too much hard to implement this feature, and I think it can be
useful if applied wisely. But there's a problem: I think a static compiler
generally doesn't know what loops to partially unroll. HotSpot knows it because
the Java code is usually under profiling, while C/C++/D code compiled by LLVM
is not (unless LLVM profile-guided optimization is used). So this may require
user annotations, or profile-guided optimization, or smart compiler heuristics
to understand where and what partially unroll (how much unroll is probably not
hard to determine, just counting how many instructions are present inside the
loop). Both the annotation route and the profile-guided optimization route seem
doable and not too much hard. The heuristics route looks harder to 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  Mon Jan  4 00:52:14 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 00:52:14 -0600
Subject: [LLVMbugs] [Bug 5933] New: bogus unused variable warning after error
Message-ID: <bug-5933-206@http.llvm.org/bugs/>

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

           Summary: bogus unused variable warning after error
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu, rjmccall at apple.com


$ cat t2.c 

int foo() {
  int X = 4;
  return Y + X;
}
$  clang t2.c -Wall
t2.c:4:10: error: use of undeclared identifier 'Y'
  return Y + X;
         ^
t2.c:3:7: warning: unused variable 'X' [-Wunused-variable]
  int X = 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 Jan  4 03:49:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 03:49:10 -0600
Subject: [LLVMbugs] [Bug 3498] meta: __sync_ builtins not properly lowered
	to LLVM IR
In-Reply-To: <bug-3498-206@http.llvm.org/bugs/>
Message-ID: <201001040949.o049nABq026164@zion.cs.uiuc.edu>

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


Owen Anderson <resistor at mac.com> changed:

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




--- Comment #4 from Owen Anderson <resistor at mac.com>  2010-01-04 03:49:09 ---
This has been done for a while.


-- 
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 Jan  4 03:56:13 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 03:56:13 -0600
Subject: [LLVMbugs] [Bug 5934] New: Incorrect atomic op codegen for (buggy)
	Opterons
Message-ID: <bug-5934-206@http.llvm.org/bugs/>

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

           Summary: Incorrect atomic op codegen for (buggy) Opterons
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: resistor at mac.com
                CC: llvmbugs at cs.uiuc.edu


Apparently some Opterons have a memory consistency bug where a locked
instruction followed by a non-locked RMW instruction can violate consistency
guarantees.  The work around is to emit an lfence between the two.

Should we consider generating code with the fix?

Reference for the Operton bug: line 99 of
http://code.google.com/p/google-perftools/source/browse/trunk/src/base/atomicops-internals-x86.cc


-- 
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 Jan  4 11:57:28 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 11:57:28 -0600
Subject: [LLVMbugs] [Bug 5935] New: TargetOptions::Target is documented
	wrong.
Message-ID: <bug-5935-206@http.llvm.org/bugs/>

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

           Summary: TargetOptions::Target is documented wrong.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Documentation
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: wlynch at wlynch.cx
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4002)
 --> (http://llvm.org/bugs/attachment.cgi?id=4002)
Code to show the problem.

Currently, the doxygen string for TargetOptions::Target is as follows:

If given, the name of the target triple to compile for. If not given the target
will be selected to match the host.

I'm reading that as:

if (TargetOptions.Target == "")
    TargetOptions.Target = llvm::sys::getHostTriple();

However, it appears that the system instead leaves the triple as the empty
string, which causes later code to throw errors (expecting a target when
instead given the empty string).

Attached is some code that has this occur. There are two versions included, one
using CompilerInstance, and one breaking that down. 

It appears that the best place to fix this would be in the constructor to the
llvm::Triple class. See:
http://clang.llvm.org/doxygen/Targets_8cpp-source.html#l02194

Of course, the other alternative fix is to change the documentation.

Other comments include:
 * Compiling with LLVM and Clang trunks.
 * Compile command: g++ `/Users/wlynch/Downloads/llvm/_/bin/llvm-config
--cxxflags` -fno-rtti -gstabs+ `/Users/wlynch/Downloads/llvm/_/bin/llvm-config
--ldflags --libs`  -lclangAST  -lclangAnalysis  -lclangBasic  -lclangCodeGen 
-lclangDriver  -lclangFrontend  -lclangIndex  -lclangLex  -lclangParse 
-lclangRewrite  -lclangSema  foo.cpp   -o foo
 * For the doxygen comment of TargetOptions, see:
http://clang.llvm.org/doxygen/TargetOptions_8h-source.html#l00022


-- 
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 Jan  4 15:53:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 15:53:09 -0600
Subject: [LLVMbugs] [Bug 5936] New: [LLVMPoly] Convert scalar evolution
 results to linear expression
Message-ID: <bug-5936-206@http.llvm.org/bugs/>

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

           Summary: [LLVMPoly] Convert scalar evolution results to linear
                    expression
           Product: libraries
           Version: trunk
          Platform: All
               URL: http://wiki.llvm.org/Polyhedral_optimization_framework#T
                    oDo
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P2
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: grosser at fim.uni-passau.de
                CC: llvmbugs at cs.uiuc.edu, grosser at fim.uni-passau.de


Created an attachment (id=4003)
 --> (http://llvm.org/bugs/attachment.cgi?id=4003)
A simple test file

It would be great to have a pass that takes a chain of recurrences, obtained by
calling the scalar evolution analysis for a value and converts this chain of
recurrences to a linear expression if possible.

Example:

int A[200];

int *foo(unsigned int b, unsigned int c) {
  unsigned int i, j;
  int x;

  for (i = 0; i < 100 + 5 * b; i++)    // A
    for (j = i; j < 200 + 7 * c; j++) {// B
      x = i + j + 800 + b;
      A[i * j] = x;
    }

  return A;
}

Here we could obtain the scalar evolution for every scalar value in this C
program by calling "opt -O3 -scalar-evolution -analyze test.bc" on the bytecode
of test.c.

Here are some of these chain of recurrences and what I would expect to get.
The values in <> are the virtual induction variables of the loops. They are
supposed to count the loop iterations. % values are parameters.

Loop for.body9: backedge-taken count is
scev: {(199 + (7 * %c)),+,-1}<for.cond3.preheader>
Linear expression: 199 + 7 c - <for.cond3.preheader>

Loop for.cond3.preheader: backedge-taken count is
scev: (-1 + %tmp34)
Linear expression: -1 + %tmp34

Or this one:
%add15 = add i32 %indvar, %tmp17                ; <i32> [#uses=1]
  -->  {{(800 + %b),+,2}<for.cond3.preheader>,+,1}<for.body9> 
Linear expression: 800 + %b + 2 * <for.cond3.preheader> + <for.body9>

As a first draft it should be enough to print the linear expressions, if called
with "opt -analyze" for all the scevs available.


-- 
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 Jan  4 18:33:56 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 18:33:56 -0600
Subject: [LLVMbugs] [Bug 5942] New: Assertion during dwarf asmprinting
Message-ID: <bug-5942-206@http.llvm.org/bugs/>

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

           Summary: Assertion during dwarf asmprinting
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4005)
 --> (http://llvm.org/bugs/attachment.cgi?id=4005)
Bytecode

Consider the .bc file attached. I have:

$ ./llc eh_catch.o 
llc: /home/asl/proj/llvm/src_arm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp:2064:
bool llvm::DwarfDebug::extractScopeInformation(llvm::MachineFunction*):
Assertion `MI && "DbgScope does not have last instruction!"' failed

This break cross-build of llvm-gcc for ARM


-- 
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 Jan  4 20:12:35 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 20:12:35 -0600
Subject: [LLVMbugs] [Bug 5944] New: no misspelling info for struct field
Message-ID: <bug-5944-206@http.llvm.org/bugs/>

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

           Summary: no misspelling info for struct field
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


$ cat t.c
struct foo {
  int xyz;
};

void t(struct foo *P) {
  P->x;
}
$ clang t.c
t.c:7:6: error: no member named 'x' in 'struct foo'
  P->x;
  ~  ^

this should suggest "xyz" :)


-- 
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 Jan  4 20:12:35 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 20:12:35 -0600
Subject: [LLVMbugs] [Bug 5943] New: no misspelling info for struct field
Message-ID: <bug-5943-206@http.llvm.org/bugs/>

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

           Summary: no misspelling info for struct field
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


$ cat t.c
struct foo {
  int xyz;
};

void t(struct foo *P) {
  P->x;
}
$ clang t.c
t.c:7:6: error: no member named 'x' in 'struct foo'
  P->x;
  ~  ^

this should suggest "xyz" :)


-- 
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 Jan  4 20:13:05 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 20:13:05 -0600
Subject: [LLVMbugs] [Bug 5944] no misspelling info for struct field
In-Reply-To: <bug-5944-206@http.llvm.org/bugs/>
Message-ID: <201001050213.o052D5lX001426@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-04 20:13:05 ---


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


-- 
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 Jan  4 22:03:41 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 4 Jan 2010 22:03:41 -0600
Subject: [LLVMbugs] [Bug 5943] no misspelling info for struct field
In-Reply-To: <bug-5943-206@http.llvm.org/bugs/>
Message-ID: <201001050403.o0543fwN004873@zion.cs.uiuc.edu>

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


Douglas Gregor <dgregor at apple.com> changed:

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




--- Comment #2 from Douglas Gregor <dgregor at apple.com>  2010-01-04 22:03:40 ---
The heuristic is that you get one typo for every 3 characters you type. Being
more lenient would make this example work, but it's also likely to make
nonsensical suggestions. Let's see how typo correction works in practice before
we consider tweaking the heuristics. 


-- 
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 Jan  5 01:00:17 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 01:00:17 -0600
Subject: [LLVMbugs] [Bug 5945] New: Missed optimisation on clamp to zero
Message-ID: <bug-5945-206@http.llvm.org/bugs/>

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

           Summary: Missed optimisation on clamp to zero
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arplynn at gmail.com
                CC: llvmbugs at cs.uiuc.edu


In the following testcase:

define i32 @clamp0g(i32 %a)
{
entry:
        %cmp = icmp slt i32 %a, 0
        %sel = select i1 %cmp, i32 0, i32 %a
        ret i32 %sel
}

Currently, the PowerPC (32-bit) backend generates:

_clamp0g:
        cmpwi cr0, r3, 0
        li r2, 0
        blt cr0, LBB1_2
; BB#1:                                                     ; %entry
        mr r2, r3
LBB1_2:                                                     ; %entry
        mr r3, r2
        blr

This could be reduced to the much simpler:

_clamp0g:
        srawi r2, r3, 31
        andc r3, r3, r2
        blr


-- 
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 Jan  5 06:01:40 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 06:01:40 -0600
Subject: [LLVMbugs] [Bug 3989] C99 inline + extern decl merging problems
In-Reply-To: <bug-3989-206@http.llvm.org/bugs/>
Message-ID: <201001051201.o05C1ehr003306@zion.cs.uiuc.edu>

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


Richard Frith-Macdonald <richard at tiptree.demon.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |richard at tiptree.demon.co.uk
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |




--- Comment #10 from Richard Frith-Macdonald <richard at tiptree.demon.co.uk>  2010-01-05 06:01:38 ---
I'm not sure why this was marked as resolved/fixed ... perhaps it was fixed but
has been broken again.
I found this pre-existing report when thinking about reporting the same issue
with r92723 from subversion.  The problem is that clang appears to be
generating a reference to an external version of the function when no such
external version can be assumed to exist, resulting in unresolved references at
link time.

I wrote a test program containing a simple inline function x() called from
main()

Now this function is not declared extern or static, and is used in the file.
As it's not declared 'extern' it can't depend on linking to an external
version, yet the .o file produced by clang lists it as undefined so that the
linker tries to resolve it.

See http://www.greenend.org.uk/rjk/2003/03/inline.html for a nice summary of
the rules about inline functions I found.

Here's a log of the results of compiling this code unit with gcc (which seems
to do the right thing) and with clang (followed by a listing of the test code):

[richard at centos libobjc2]$ gcc a.c -std=c99 -c
[richard at centos libobjc2]$ nm a.o | fgrep objc_read_int
[richard at centos libobjc2]$ nm a.o | fgrep x
00000000 T x
[richard at centos libobjc2]$ clang a.c -std=c99 -c
[richard at centos libobjc2]$ nm a.o | fgrep x
         U x
[richard at centos libobjc2]$ cat a.c

inline int
x ()
{
  return 1;
}

int
main()
{
  return x();
}

[richard at centos libobjc2]$ 


-- 
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 Jan  5 07:10:12 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 07:10:12 -0600
Subject: [LLVMbugs] [Bug 5946] New: X86GenFastISel.inc uses out-of-range
	case values
Message-ID: <bug-5946-206@http.llvm.org/bugs/>

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

           Summary: X86GenFastISel.inc uses out-of-range case values
           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: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Here is an example warning from g++-4.5:

llvm-objects/lib/Target/X86/X86GenFastISel.inc:1286:3: warning: case value
???172??? not in enumerated type ???llvm::ISD::NodeType???

The warning seems to be correct.  The line in question is

  case X86ISD::BSF: return FastEmit_X86ISD_BSF_r(VT, RetVT, Op0);

where the switch is

unsigned FastEmit_r(MVT VT, MVT RetVT, ISD::NodeType Opcode, unsigned Op0) {
  switch (Opcode) {

and since Opcode has type ISD::NodeType it is impossible for it to be
equal to X86ISD::BSF, which belongs to X86ISD and does not belong to
ISD.  Presumably this will result in X86GenFastISel.inc not working
properly when built with g++-4.5.

Lots of warnings of this kind are generated when compiling X86GenFastISel.inc.


-- 
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 Jan  5 09:19:33 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 09:19:33 -0600
Subject: [LLVMbugs] [Bug 3989] C99 inline + extern decl merging problems
In-Reply-To: <bug-3989-206@http.llvm.org/bugs/>
Message-ID: <201001051519.o05FJX46010980@zion.cs.uiuc.edu>

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


Douglas Gregor <dgregor at apple.com> changed:

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




--- Comment #11 from Douglas Gregor <dgregor at apple.com>  2010-01-05 09:19:32 ---
(In reply to comment #10)
> I'm not sure why this was marked as resolved/fixed ... perhaps it was fixed but
> has been broken again.
> I found this pre-existing report when thinking about reporting the same issue
> with r92723 from subversion.  The problem is that clang appears to be
> generating a reference to an external version of the function when no such
> external version can be assumed to exist, resulting in unresolved references at
> link time.

Clang is behaving correctly; see below.

> I wrote a test program containing a simple inline function x() called from
> main()
> 
> Now this function is not declared extern or static, and is used in the file.
> As it's not declared 'extern' it can't depend on linking to an external
> version, yet the .o file produced by clang lists it as undefined so that the
> linker tries to resolve it.

That's not quite correct. Functions that do not have any storage specifier have
external linkage, so "x" can depend on linking to an external version.

> See http://www.greenend.org.uk/rjk/2003/03/inline.html for a nice summary of
> the rules about inline functions I found.

It's better to refer to the C99 spec, in which 6.7.4p6 says:

  If all of the file scope declarations for a function in a translation unit
include the inline function specifier without extern, then the definition in
that translation unit is an inline definition. An inline definition does not
provide an external definition for the function, and does not forbid an
external definition in another translation unit. An inline definition provides
an alternative to an external definition, which a translator may use to
implement any call to the function in the same translation unit. It is
unspecified whether a call to the function uses the inline definition or the
external definition.

Now, "x" is an "inline definition", since all of the file-scope declarations
have "inline" but not "extern". Then, the second sentence kicks in: an inline
definition does *not* provide an external definition in that translation unit,
meaning that we aren't allowed to emit a definition of "x" at all. Finally, the
last sentence says that C99 doesn't tell us which x() to call---the inline
definition defined here, or some other, external definition in another
translation unit. In practice, we end up calling the external definition when
optimization is turned off (default, -O0) and the inlined version when inlining
is turned on (-O2).

> Here's a log of the results of compiling this code unit with gcc (which seems
> to do the right thing) and with clang (followed by a listing of the test code):
> 
> [richard at centos libobjc2]$ gcc a.c -std=c99 -c
> [richard at centos libobjc2]$ nm a.o | fgrep objc_read_int
> [richard at centos libobjc2]$ nm a.o | fgrep x
> 00000000 T x

This doesn't match what I'm seeing with gcc 4.2:

blackthorn:clang dgregor$ gcc a.c -std=c99 -c
blackthorn:clang dgregor$ nm a.o | fgrep objc_read_int
blackthorn:clang dgregor$ nm a.o | fgrep x
                 U _x

and it isn't correct, either: when compiling in C99 mode, GCC should not be
emitting an external definition for "x".

Note, however, that with the default language variant for GCC (gnu89), we will
get an external definition for "x", because GNU inline semantics are different
from C99 inline semantics. Clang defaults to C99, so this is a common source of
confusion.

> [richard at centos libobjc2]$ clang a.c -std=c99 -c
> [richard at centos libobjc2]$ nm a.o | fgrep x
>          U x

This is correct behavior.


-- 
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 Jan  5 11:04:07 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 11:04:07 -0600
Subject: [LLVMbugs] [Bug 5942] Assertion during dwarf asmprinting
In-Reply-To: <bug-5942-206@http.llvm.org/bugs/>
Message-ID: <201001051704.o05H470l015091@zion.cs.uiuc.edu>

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


devang.patel <devang.patel at gmail.com> changed:

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




--- Comment #2 from devang.patel <devang.patel at gmail.com>  2010-01-05 11:04:06 ---
Fixed. r92736


-- 
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 Jan  5 11:28:36 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 11:28:36 -0600
Subject: [LLVMbugs] [Bug 5948] New: llvm-gcc not turning 'restrict' into
	'noalias'
Message-ID: <bug-5948-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc not turning 'restrict' into 'noalias'
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


$ cat t.cc
#include <stdlib.h>
struct Ramp
{
   float phase;
   inline float process() { return phase++; }
} ramp;

void fill_buffer( __restrict float *__restrict buf, size_t nframes )
{
        for( size_t i=0; i<nframes; i++ )
                buf[i] = ramp.process();
}
$ llvm-gcc t.cc -S -o - -O3 -fstrict-aliasing -emit-llvm
...
define void @_Z11fill_bufferPfm(float* nocapture %buf, i32 %nframes) nounwind {


shouldn't 'buf' be marked noalias?


-- 
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 Jan  5 12:01:13 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 12:01:13 -0600
Subject: [LLVMbugs] [Bug 5804] building with STL in parallel mode gets
	tblgen stuck
In-Reply-To: <bug-5804-206@http.llvm.org/bugs/>
Message-ID: <201001051801.o05I1DTC017411@zion.cs.uiuc.edu>

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


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

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




--- Comment #3 from T??r??k Edwin <edwintorok at gmail.com>  2010-01-05 12:01:12 ---
Opened a bug here, libstdc++ also deadlocks in another case:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=42624

Closing this bug, since it doesn't appear to be anything wrong in LLVM itself.


-- 
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 Jan  5 14:17:01 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 14:17:01 -0600
Subject: [LLVMbugs] [Bug 5951] New: Unknown pragmas not ignored with
	-Wunknown-pragmas
Message-ID: <bug-5951-206@http.llvm.org/bugs/>

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

           Summary: Unknown pragmas not ignored with -Wunknown-pragmas
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Basic
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu


$ cat test.c
#pragma GCC diagnostic ignored "-Wvla"
$ ./Debug/bin/clang  -Wunknown-pragmas test.c
test.c:1:32: warning: unknown warning group '-Wvla', ignored
[-Wunknown-pragmas]
#pragma GCC diagnostic ignored "-Wvla"
                               ^
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 Jan  5 14:20:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 14:20:21 -0600
Subject: [LLVMbugs] [Bug 5952] New: pragmas not copied to the preprocessed
	output
Message-ID: <bug-5952-206@http.llvm.org/bugs/>

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

           Summary: pragmas not copied to the preprocessed output
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: preprocessor
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ cat test.c
#pragma GCC diagnostic ignored "-Wall"
$ ./Debug/bin/clang  test.c -E | grep pragma
$ gcc  test.c -E | grep pragma
#pragma GCC diagnostic ignored "-Wall"


-- 
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 Jan  5 14:22:52 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 14:22:52 -0600
Subject: [LLVMbugs] [Bug 5953] New: -Wvla not supported
Message-ID: <bug-5953-206@http.llvm.org/bugs/>

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

           Summary: -Wvla not supported
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Basic
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ cat test.c
void g(int n) {
  int v[n];
}
$ ./Debug/bin/clang -c -Wvla  test.c
warning: unknown warning option '-Wvla' [-Wunknown-warning-option]
1 diagnostic generated.
$ gcc -c -Wvla  ~/test.c
test.c: In function ???g???:
test.c:2:3: warning: variable length array ???v??? is 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  Tue Jan  5 16:26:53 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 16:26:53 -0600
Subject: [LLVMbugs] [Bug 5946] X86GenFastISel.inc uses out-of-range case
	values
In-Reply-To: <bug-5946-206@http.llvm.org/bugs/>
Message-ID: <201001052226.o05MQrqO028657@zion.cs.uiuc.edu>

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


Dan Gohman <gohman at apple.com> changed:

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




--- Comment #2 from Dan Gohman <gohman at apple.com>  2010-01-05 16:26:52 ---
Fixed in r92794.


-- 
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 Jan  5 16:52:27 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 16:52:27 -0600
Subject: [LLVMbugs] [Bug 5954] New: TableGen fails to link because of
 __progname and environ needed by DSO
Message-ID: <bug-5954-206@http.llvm.org/bugs/>

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

           Summary: TableGen fails to link because of __progname and environ
                    needed by DSO
           Product: new-bugs
           Version: 2.6
          Platform: Other
        OS/Version: NetBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: aran at 100acres.us
                CC: llvmbugs at cs.uiuc.edu


Building a release version of 2.6 fails when linking TableGen.  The problem is
that all of the symbols are local except for main.  The libc needs access to
both __progname and environ. 

The fix is to export both of these symbols in ExportMap.  The new export map
is:

{
        global: main;
                __progname;
                environ;
        local: *;
};


-- 
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 Jan  5 20:35:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 5 Jan 2010 20:35:48 -0600
Subject: [LLVMbugs] [Bug 5955] New: Another regscavenger assertion
Message-ID: <bug-5955-206@http.llvm.org/bugs/>

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

           Summary: Another regscavenger assertion
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: evan.cheng at apple.com, llvmbugs at cs.uiuc.edu,
                    grosbach at apple.com, stoklund at 2pi.dk


Conider attached testcase. llc -mattr=+neon yields:

$ ./llc -mattr=+neon bugpoint-reduced-simplified2.ll
llc: /home/asl/proj/llvm/src_arm/lib/CodeGen/RegisterScavenging.cpp:342:
unsigned int llvm::RegScavenger::scavengeRegister(const
llvm::TargetRegisterClass*, llvm::ilist_iterator<llvm::MachineInstr>, int):
Assertion `ScavengingFrameIndex >= 0 && "Cannot scavenge register without an
emergency spill slot!"' 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  Wed Jan  6 10:18:20 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jan 2010 10:18:20 -0600
Subject: [LLVMbugs] [Bug 5959] New: Results obtained from an asm volatile
 corrupted by optimiser
Message-ID: <bug-5959-206@http.llvm.org/bugs/>

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

           Summary: Results obtained from an asm volatile corrupted by
                    optimiser
           Product: libraries
           Version: 2.6
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: miscompilation
          Severity: major
          Priority: P2
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mark.i.r.muir at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4007)
 --> (http://llvm.org/bugs/attachment.cgi?id=4007)
Test case demonstrating the problem

When inline assembly appears inside a loop, where the result is intentionally
delayed into a later iteration (e.g. to form a shift chain), the optimiser
incorrectly eliminates the delay elements, resulting in corruption.  

This seems to affect all back-ends (the attached example demonstrates it on at
least X86 and PPC). The code pattern exhibiting the bug - a shift chain - is
rather contrived for regular microprocessors, but is an important construct for
highly parallel data-path architectures, for efficiently loading-in streams of
data into registers. They achieve the same thing as the following on a regular
microprocessor architecture:

for (i = 0; i < n; i ++)
    value[i] = stream_get(i);

where stream_get(i) would be inline assembly reading the nth item from the
stream. The shift chain construct allows value[] to be an array of registers,
initialised from a single loop, with only one instance of the inline assembly
in the loop body.

The problem is visible with -O1 from either clang or llvm-gcc, where the loop
remains intact, but the shift chain is optimised away.

With -O2 however, the loop is unrolled, and the program behaves correctly.

See attached source code for an example.

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 Jan  6 11:17:12 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jan 2010 11:17:12 -0600
Subject: [LLVMbugs] [Bug 5960] New: Enable GNU inline semantics selectively
	in C99 mode
Message-ID: <bug-5960-206@http.llvm.org/bugs/>

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

           Summary: Enable GNU inline semantics selectively in C99 mode
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: other
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu


Per David Chisnall's comments in PR 3989, some platforms have glibc headers
that expect GNU inline semantics even in C99 mode, which causes linking
problems when building with Clang. 

Implementing -fgnu89-inline works around part of the problem (and is probably a
good idea in general), but that's a big hammer: we really want only those
functions defined in the glibc headers to get GNU inline semantics.


-- 
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 Jan  6 13:42:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jan 2010 13:42:29 -0600
Subject: [LLVMbugs] [Bug 5959] Results obtained from an asm volatile
 corrupted by optimiser
In-Reply-To: <bug-5959-206@http.llvm.org/bugs/>
Message-ID: <201001061942.o06JgTnR024818@zion.cs.uiuc.edu>

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


Dale Johannesen <dalej at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dalej at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #1 from Dale Johannesen <dalej at apple.com>  2010-01-06 13:42:28 ---
This test isn't compilable as it uses #elseif instead of #elif.

Fixing that manually and using the appropriate -D, I don't see the effect you
mention on either X86-32 or PPC with the current TOT.  Presumably this has been
fixed since 2.6.  Inner loop on PPC-32 at -O1:
LBB1_1:
        mr r4, r6
        mr r6, r7
        addi r7, r3, 1
        cmplwi cr0, r7, 4
        ; InlineAsm Start
        addi r8, r3, 100
        ; InlineAsm End
        mr r3, r7
        mr r7, r5
        mr r5, r8
        bne cr0, LBB1_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  Wed Jan  6 15:34:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jan 2010 15:34:59 -0600
Subject: [LLVMbugs] [Bug 5961] New: Assertion failed:
 (unsignedRange.NonNegative && " unsigned range includes negative?"),
 function CheckSignCompare, file SemaChecking.cpp, line 1882.
Message-ID: <bug-5961-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (unsignedRange.NonNegative &&
                    "unsigned range includes negative?"), function
                    CheckSignCompare, file SemaChecking.cpp, line 1882.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: rjmccall at apple.com
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta$ cat 185.c
typedef unsigned long __uint64_t;
typedef __uint64_t __uintfptr_t;
typedef __uintptr_t uintptr_t;
extern uintptr_t *__start_set_pcpu;
typedef long db_expr_t;
db_value_of_name_pcpu(name, valuep)
{
 db_expr_t value;
 if (value < (uintptr_t)&__start_set_pcpu || value >=
(uintptr_t)&__stop_set_pcpu)


pes delta$ clang 185.c
185.c:3:9: error: unknown type name '__uintptr_t'; did you mean '__uintfptr_t'?
typedef __uintptr_t uintptr_t;
        ^~~~~~~~~~~
        __uintfptr_t
185.c:6:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
db_value_of_name_pcpu(name, valuep)
^
Assertion failed: (unsignedRange.NonNegative && "unsigned range includes
negative?"), function CheckSignCompare, file SemaChecking.cpp, line 1882.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name 185.c
-mrelocation-model static -mdisable-fp-elim -munwind-tables -target-cpu x86-64
-resource-dir /usr/local/lib/clang/1.1 -fmessage-length 152 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-DW7iWU.s -x c 185.c
1.      185.c:9:43: current parser token '||'
2.      185.c:7:1: parsing function body 'db_value_of_name_pcpu'
3.      185.c:7:1: in compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


-- 
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 Jan  6 16:05:39 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jan 2010 16:05:39 -0600
Subject: [LLVMbugs] [Bug 5817] sema crashes when initializing an array where
 the type was defined within a typedef
In-Reply-To: <bug-5817-206@http.llvm.org/bugs/>
Message-ID: <201001062205.o06M5dHF031246@zion.cs.uiuc.edu>

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


Douglas Gregor <dgregor at apple.com> changed:

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




--- Comment #3 from Douglas Gregor <dgregor at apple.com>  2010-01-06 16:05:39 ---
This works with TOT. It was probably fixed when I eliminated TypeLoc from
InitializedEntity entirely.


-- 
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 Jan  6 16:59:06 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jan 2010 16:59:06 -0600
Subject: [LLVMbugs] [Bug 5961] Assertion failed: (unsignedRange.NonNegative
 && " unsigned range includes negative?"), function CheckSignCompare,
 file SemaChecking.cpp, line 1882.
In-Reply-To: <bug-5961-206@http.llvm.org/bugs/>
Message-ID: <201001062259.o06Mx6J6001379@zion.cs.uiuc.edu>

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


John McCall <rjmccall at apple.com> changed:

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




--- Comment #1 from John McCall <rjmccall at apple.com>  2010-01-06 16:59:05 ---
Fixed in r92866.


-- 
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 Jan  6 17:46:44 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 6 Jan 2010 17:46:44 -0600
Subject: [LLVMbugs] [Bug 5955] Another regscavenger assertion
In-Reply-To: <bug-5955-206@http.llvm.org/bugs/>
Message-ID: <201001062346.o06NkixO003350@zion.cs.uiuc.edu>

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


Jim Grosbach <grosbach at apple.com> changed:

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




--- Comment #4 from Jim Grosbach <grosbach at apple.com>  2010-01-06 17:46:43 ---
Fixed in r92871.


-- 
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 mark_wezelenburg at edpnet.be  Wed Jan  6 14:45:20 2010
From: mark_wezelenburg at edpnet.be (Mark Wezelenburg)
Date: Wed, 6 Jan 2010 21:45:20 +0100
Subject: [LLVMbugs] llvm-gcc4.2-2.6.source fails to build out of the box
Message-ID: <48B8D57B66CE4A3E88683896BAEDFBEB@emerald>

Hi,

Minor OOB compile fail of llvm-gcc4.2-2.6-source on cygwin, platform & compiler details below

llvm-gcc4.2-2.6.source\libiberty\strsignal.c line 409

#ifndef HAVE_STRSIGNAL

// <string.h> defines char *
const char *
strsignal (int signo)
{

See comment on line 11: /*  With luck, this will always work. */

Regards

Mark



  $ ./configure 

## --------- ##
## Platform. ##
## --------- ##

hostname = emerald
uname -m = i686
uname -r = 1.7.1(0.218/5/3)
uname -s = CYGWIN_NT-5.1
uname -v = 2009-12-07 11:48

configure:2804: checking for C compiler version
configure:2811: gcc --version >&5
gcc (GCC) 4.3.4 20090804 (release) 1



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmbugs/attachments/20100106/abb69b0d/attachment-0001.html 

From mark_wezelenburg at edpnet.be  Wed Jan  6 16:32:24 2010
From: mark_wezelenburg at edpnet.be (Mark Wezelenburg)
Date: Wed, 6 Jan 2010 23:32:24 +0100
Subject: [LLVMbugs] warning on "used but not defined structure" during OOB
	llvm-gcc4.2-2.6.source compilation
Message-ID: <D65F4522C38C48B9A4BDAB964A4DB3B2@emerald>

Hi,

As LLVM is compiled with all warnings and pedantics on, I guess
this may interest you.

when compiling the target ./build/gengtype.exe there are multiple
identical warnings, the first being:

warning structure 'eh_range' used but not defined

Unfortunately I only caught it when the log info scrolled by (and out of)
the window, but you probably know better where in the build process
this target is.

Mark

  $ ./configure 

## --------- ##
## Platform. ##
## --------- ##

hostname = emerald
uname -m = i686
uname -r = 1.7.1(0.218/5/3)
uname -s = CYGWIN_NT-5.1
uname -v = 2009-12-07 11:48

configure:2804: checking for C compiler version
configure:2811: gcc --version >&5
gcc (GCC) 4.3.4 20090804 (release) 1
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmbugs/attachments/20100106/e71bf951/attachment-0001.html 

From baldrick at free.fr  Wed Jan  6 23:40:52 2010
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 07 Jan 2010 06:40:52 +0100
Subject: [LLVMbugs] warning on "used but not defined structure" during
 OOB	llvm-gcc4.2-2.6.source compilation
In-Reply-To: <D65F4522C38C48B9A4BDAB964A4DB3B2@emerald>
References: <D65F4522C38C48B9A4BDAB964A4DB3B2@emerald>
Message-ID: <4B4573E4.8030300@free.fr>

Hi Mark,

> As LLVM is compiled with all warnings and pedantics on, I guess
> this may interest you.
>  
> when compiling the target ./build/gengtype.exe there are multiple
> identical warnings, the first being:
>  
> warning structure   'eh_range' used but not defined

you would doubtless find exactly the same issue if you tried to compile gcc-4.2
with all warnings on.  Since llvm-gcc is based on gcc-4.2, it inherits this kind
of thing from it.  I'm confident that no-one here is interested in fixing this,
but maybe the gcc people are - if you care enough, and it still happens with gcc
TOT, I suggest you open a gcc bug report.

Ciao,

Duncan.

From bugzilla-daemon at cs.uiuc.edu  Thu Jan  7 01:37:30 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 7 Jan 2010 01:37:30 -0600
Subject: [LLVMbugs] [Bug 5948] llvm-gcc not turning 'restrict' into 'noalias'
In-Reply-To: <bug-5948-206@http.llvm.org/bugs/>
Message-ID: <201001070737.o077bUYS019928@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #5 from Chris Lattner <clattner at apple.com>  2010-01-07 01:37:30 ---
Ah, __restrict__ is the keyword I wanted.  This:

#include <stdlib.h>
struct Ramp
{
   float phase;
   inline float process() { return phase++; }
} ramp;

void fill_buffer( float *__restrict__ buf, size_t nframes )
{
        for( size_t i=0; i<nframes; i++ )
                buf[i] = ramp.process();
}

compiles to nicely optimized code.


-- 
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 Jan  7 02:54:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 7 Jan 2010 02:54:46 -0600
Subject: [LLVMbugs] [Bug 5968] New: Some useless load/stores in a kernel
Message-ID: <bug-5968-206@http.llvm.org/bugs/>

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

           Summary: Some useless load/stores in a kernel
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bearophile at mailas.com
                CC: llvmbugs at cs.uiuc.edu


In the attach there is a small C program that shows a number of redundant
load/stores from memory.

On Windows I compile it with (or the same with gcc):

llvm-gcc -Wall -O3 -s -S -fomit-frame-pointer -Wl,--enable-stdcall-fixup -msse3
-march=native lsolver.c -o lsolver_llvm.s

Where -Wl,--enable-stdcall-fixup fixes a llvm bug.


This is the good asm generated by gcc 4.3.3:

L26:
    fldl    -8(%edx,%eax,8)
    fldl    -8(%ebx,%eax,8)
    faddl   -8(%ecx,%eax,8)
    fmul    %st(4), %st
    fldl    -16(%edx,%eax,8)
    faddl   (%edx,%eax,8)
    fmul    %st(6), %st
    faddp   %st, %st(1)
    fmul    %st(3), %st
    fstl    -8(%edx,%eax,8)
    incl    %eax
    fsubp   %st, %st(1)
    cmpl    %edi, %eax
    fmul    %st(0), %st
    faddp   %st, %st(1)
    jne L26


Again with gcc, but with -mfpmath=sse for force the usage of SSE, uses 5 loads
and 1 store:
L26:
    movsd   -8(%edx,%eax,8), %xmm0
    movsd   -8(%ebx,%eax,8), %xmm1
    movsd   -16(%edx,%eax,8), %xmm2
    addsd   -8(%ecx,%eax,8), %xmm1
    addsd   (%edx,%eax,8), %xmm2
    mulsd   %xmm5, %xmm1
    mulsd   %xmm6, %xmm2
    addsd   %xmm2, %xmm1
    mulsd   %xmm4, %xmm1
    movsd   %xmm1, -8(%edx,%eax,8)
    subsd   %xmm0, %xmm1
    incl    %eax
    mulsd   %xmm1, %xmm1
    cmpl    %edi, %eax
    addsd   %xmm1, %xmm3
    jne L26


Compiled with LLVM-gcc 2.6 (32 bit), uses 11 loads and 1 store (very similar
asm is produced by the D LDC compiler too):

LBB5_4:
    movl    8(%eax,%ecx,4), %ebx
    movl    (%eax,%ecx,4), %ebp
    movsd   8(%ebp,%esi,8), %xmm4
    addsd   8(%ebx,%esi,8), %xmm4
    mulsd   %xmm1, %xmm4
    movsd   (%edx,%esi,8), %xmm5
    addsd   16(%edx,%esi,8), %xmm5
    mulsd   %xmm2, %xmm5
    addsd   %xmm4, %xmm5
    mulsd   %xmm3, %xmm5
    movsd   8(%edi,%esi,8), %xmm4 ; ***
    movsd   %xmm5, 8(%edi,%esi,8) ; ***
    movl    4(%eax,%ecx,4), %edx
    movsd   8(%edx,%esi,8), %xmm5 ; ***
    subsd   %xmm4, %xmm5
    mulsd   %xmm5, %xmm5
    addsd   %xmm5, %xmm0
    incl    %esi
    cmpl    4(%esp), %esi
    movl    %edx, %edi
    jne LBB5_4


Compiled with llvm-gcc (V. 2.7 trunk) x86-64 linux, asm by <baldrick> on IRC,
the situation is a little better, 20 instructions instead of 21, 8 loads + 1
store:

.LBB5_4:
    movq    (%rcx,%rdi,8), %r11
    movq    16(%rcx,%rdi,8), %r10
    addsd   16(%r8,%r9,8), %xmm4
    movsd   8(%r8,%r9,8), %xmm6
    mulsd   %xmm1, %xmm4
    movsd   8(%r11,%r9,8), %xmm5
    addsd   8(%r10,%r9,8), %xmm5
    mulsd   %xmm2, %xmm5
    addsd   %xmm4, %xmm5
    mulsd   %xmm3, %xmm5
    movsd   %xmm5, 8(%r8,%r9,8)
    movq    8(%rcx,%rdi,8), %r8
    movsd   8(%r8,%r9,8), %xmm4
    incq    %r9
    cmpq    %rsi, %r9
    movapd  %xmm4, %xmm5
    subsd   %xmm6, %xmm5
    mulsd   %xmm5, %xmm5
    addsd   %xmm5, %xmm0
    jne .LBB5_4


Those redudant loads and stores (in the 32 bit version) can also be seen
comparing the running time of the llvm-gcc version with the gcc version.


-- 
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 baldrick at free.fr  Thu Jan  7 05:41:28 2010
From: baldrick at free.fr (Duncan Sands)
Date: Thu, 07 Jan 2010 12:41:28 +0100
Subject: [LLVMbugs] llvm-gcc4.2-2.6.source fails to build out of the box
In-Reply-To: <48B8D57B66CE4A3E88683896BAEDFBEB@emerald>
References: <48B8D57B66CE4A3E88683896BAEDFBEB@emerald>
Message-ID: <4B45C868.1060304@free.fr>

Hi Mark, does the following patch fix it for you?

Index: strsignal.c
===================================================================
--- strsignal.c	(revision 92897)
+++ strsignal.c	(working copy)
@@ -404,12 +404,11 @@

  #ifndef HAVE_STRSIGNAL

-const char *
+char *
  strsignal (int signo)
  {
-  const char *msg;
+  char *msg;
    static char buf[32];
-
  #ifndef HAVE_SYS_SIGLIST

    if (signal_names == NULL)
@@ -428,12 +427,12 @@
      {
        /* In range, but no sys_siglist or no entry at this index. */
        sprintf (buf, "Signal %d", signo);
-      msg = (const char *) buf;
+      msg = buf;
      }
    else
      {
        /* In range, and a valid message.  Just return the message. */
-      msg = (const char *) sys_siglist[signo];
+      msg = (char *) sys_siglist[signo];
      }

    return (msg);

From mark_wezelenburg at edpnet.be  Thu Jan  7 07:59:28 2010
From: mark_wezelenburg at edpnet.be (Mark Wezelenburg)
Date: Thu, 7 Jan 2010 14:59:28 +0100
Subject: [LLVMbugs] Intermittent issues with OOB build of llvm-gcc4.2-2.6 &
	llvm-2.6 using cygwin 1.7.1 w gcc 4.3.4
Message-ID: <C6F650BC79A14F499E0E118F844165F8@emerald>

Hi,

Not sure if this really helps, but I suppose it cannot hurt. All of the
remarks concern the build environment rather than the source/tools.
Nothing major except the last point which I suspect to be an error
on my side.

1) platform details from "configure"
2) source & output dir tree structure
3) sequence of actions
4) report

Hope this helps

Regards

Mark


1) platform details from "configure"

## --------- ##
## Platform. ##
## --------- ##

hostname = emerald
uname -m = i686
uname -r = 1.7.1(0.218/5/3)
uname -s = CYGWIN_NT-5.1
uname -v = 2009-12-07 11:48

configure:2804: checking for C compiler version
configure:2811: gcc --version >&5
gcc (GCC) 4.3.4 20090804 (release) 1


2) source & output dir tree structure
/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6                                                    // OBJ_ROOT (for llvm-gcc)
/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/Release                                       // LLVM output
/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/llvm-gcc/llvm-gcc4.2-2.6.source      // LLVM-GCC sources
/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/llvm-gcc/install
/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/llvm-gcc/obj
/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/projects/llvm-test                           // LLVM test sources


3) sequence of actions
in "/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6"
./configure
make tools-only

in "/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/llvm-gcc/obj"
../llvm-gcc4.2-x.y.source/configure --prefix=/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/llvm-gcc/install --program-prefix=llvm- --enable-llvm=/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6 --enable-languages=c,c++
make LLVM_VERSION_INFO=2.6
make install

in "/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6"
./configure --with-llvmgccdir=/cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/llvm-gcc/install/bin
make
make install

in /cygdrive/g/tools/cygwin/compilers/llvm/llvm-2.6/projects/llvm-test
./configure
make


4) report
- From the readme's FAQ and docs it is not so clear that there is a circular
  dependency between llvm and llvm-gcc, to save recompile in (3) one ought
  to use "./configure" already with "--with-llvmgccdir"

- after llvm configure, the makefile as a linker option incompatble with gcc 4.3.4
  it suggests to change:
#RDYNAMIC := -Wl,-export-dynamic
RDYNAMIC := -Wl,-export-all-symbols

- llvm configure reports:
  mmap() of a fixed address is required but not supported
  it does not seem to be a requirement as the build process succeeds though

- the llvm build process has intermittent errors with conftest.c or contest.exe being unaccessible
  my guess is that the cygwin emulation is a bit slow and that the processes does not wait
  to check for the status of the files
  -> As certain tests fails but configure completes succesfully I have no idea on the impact

- the llvm-gcc build process has MANY intermittent errors with conftest.c or contest.exe being unaccessible
  probably same reason as above. here the build process terminates in error but restarting (quite a few times)
  results in a (apparently) operational llvm-gcc (compiles hello.c & llvm --help gives proper version)

- the llvm-gcc build process fails regurarly, but not systematically, on a gcc test
  "can gcc produce an executable ... No"
  typically at the later stages

- running the tests in .../projects/llvm-tests fails systematically
  make cannot resolve *.rbc dependencies in the first single source test

- running the hello.c test (from the web tutorial) produces hell.exe and hello.bc, but not "lli hello.bc" (see below)
  lli cannot find "put()" (cannot find the dynamic lib containing "put()") I may have simply missed a cygwin
  specific dynamic link flag / configure option (the web doc make mention of dynamic linkage on cygwin with
  the platform notes, so perhaps this is what's meant)




 



-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.cs.uiuc.edu/pipermail/llvmbugs/attachments/20100107/39b2939a/attachment-0001.html 

From bugzilla-daemon at cs.uiuc.edu  Thu Jan  7 14:57:22 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 7 Jan 2010 14:57:22 -0600
Subject: [LLVMbugs] [Bug 5968] Some useless load/stores in a kernel
In-Reply-To: <bug-5968-206@http.llvm.org/bugs/>
Message-ID: <201001072057.o07KvM0L005774@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #4 from Chris Lattner <clattner at apple.com>  2010-01-07 14:57:21 ---
Ok, this is because we need type based alias analysis.

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


-- 
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 Jan  7 22:36:47 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 7 Jan 2010 22:36:47 -0600
Subject: [LLVMbugs] [Bug 5975] New: Missed removal of loads after undef
	stores
Message-ID: <bug-5975-206@http.llvm.org/bugs/>

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

           Summary: Missed removal of loads after undef stores
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arplynn at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Consider the following test-case:

define i8 @foo(i8* %ptr) nounwind {
entry:
        store i8 undef, i8* %ptr
        %val = load i8* %ptr
        ret i8 %val
}

This could be reduced to ret i8 undef, but instead the load remains.


-- 
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 baldrick at free.fr  Fri Jan  8 02:30:32 2010
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 08 Jan 2010 09:30:32 +0100
Subject: [LLVMbugs] ERROR: Source to source transformation of LLVM
In-Reply-To: <003501ca8900$eb715980$2b00030a@c8d07e44d243485>
References: <003501ca8900$eb715980$2b00030a@c8d07e44d243485>
Message-ID: <4B46ED28.3040409@free.fr>

Hi Shengmei,

>          I use llvm to do the source to source transformation of SPEC 
> CPU2000.
> 
> The problems occur when doing the source to source transformation. I 
> listed some error messages as follows.

no-one seems very interested in maintaining the C backend (CBE), which is why
it is not as capable as you might wish.

> 1. 164.gzip
> 
> LLVM ERROR: The C backend does not currently support integer types of 
> widths other than 1, 8, 16, 32, 64.
> 
> This is being tracked as PR 4158.

I think it would be pretty easy to teach the CBE to handle arbitrary precision
loads, stores, truncations, extensions and shifts.  This would already improve
the situation a lot.

> 2. 253.perlbmk
> 
> MD5.c...
> 
> In file included from perl.h:1276,
> 
>                  from MD5.c:28:
> 
> cop.h:217: error: expected specifier-qualifier-list before 'bool'

Please open a bug report with a reduced testcase.

> 
> 3. 255.gap
> 
> oa1.c: In function 'OaCompare':
> 
> oa1.c:1714: error: duplicate case value
> 
> oa1.c:1705: error: previously used here

Please open a bug report with a reduced testcase.

Best wishes,

Duncan.

From bugzilla-daemon at cs.uiuc.edu  Fri Jan  8 11:33:45 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Jan 2010 11:33:45 -0600
Subject: [LLVMbugs] [Bug 5977] New: llc generates incorrect exception
 handling tables when generating PIC code
Message-ID: <bug-5977-206@http.llvm.org/bugs/>

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

           Summary: llc generates incorrect exception handling tables when
                    generating PIC code
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vargaz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

To reproduce (on amd64 linux):
llc -f -relocation-model=pic -o temp.s temp.bc

The generated assembly contains:
        .byte   0x9B                                        # @TType format
(indirect pcrel sdata4)
and later:
        .quad   type_info_1                                 # TypeInfo

the two don't match, also the TType Base Offset is wrong too, since it assumes
that TypeInfo entries are 4 byte long, which is not true on amd64.

I think this is caused by this code in DwarfException.cpp:

    if (LSDASection->getKind().isWriteable() ||
        Asm->TM.getRelocationModel() == Reloc::Static)
      TTypeFormat = dwarf::DW_EH_PE_absptr;
    else
      TTypeFormat = dwarf::DW_EH_PE_indirect | dwarf::DW_EH_PE_pcrel |
        dwarf::DW_EH_PE_sdata4;

Here, the else part is executed, but later, the typeinfo is emitted as:
      O << Asm->Mang->getMangledName(GV);

I think the fix is to always use absptr, the ELF linker can and does fixup the
type info even if the section it is in is read-only.


-- 
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 Jan  8 11:40:05 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Jan 2010 11:40:05 -0600
Subject: [LLVMbugs] [Bug 5977] llc generates incorrect exception handling
 tables when generating PIC code
In-Reply-To: <bug-5977-206@http.llvm.org/bugs/>
Message-ID: <201001081740.o08He5kZ011479@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asl at math.spbu.ru
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru>  2010-01-08 11:40:05 ---
Strictly speaking, this is just another manifestation of PR5004.

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


-- 
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 Jan  8 12:34:16 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Jan 2010 12:34:16 -0600
Subject: [LLVMbugs] [Bug 5978] New: ipsccp crash: Assertion `shiftAmt <=
 BitWidth && " Invalid shift amount"' failed
Message-ID: <bug-5978-206@http.llvm.org/bugs/>

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

           Summary: ipsccp crash: Assertion `shiftAmt <= BitWidth &&
                    "Invalid shift amount"' 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: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


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

Reduced from clangs Builtins.cpp, as compiled by dragonegg.

$ opt -ipsccp builtins.bc -disable-output
opt: /home/duncan/LLVM/llvm.top/llvm/include/llvm/ADT/APInt.h:682: llvm::APInt
llvm::APInt::shl(unsigned int) const: Assertion `shiftAmt <= BitWidth &&
"Invalid shift amount"' 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  Fri Jan  8 13:02:39 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Jan 2010 13:02:39 -0600
Subject: [LLVMbugs] [Bug 5978] ipsccp crash: Assertion `shiftAmt <= BitWidth
 && " Invalid shift amount"' failed
In-Reply-To: <bug-5978-206@http.llvm.org/bugs/>
Message-ID: <201001081902.o08J2dnd014700@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #3 from Chris Lattner <clattner at apple.com>  2010-01-08 13:02:39 ---
Fixed in r93018, 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  Fri Jan  8 14:24:37 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Jan 2010 14:24:37 -0600
Subject: [LLVMbugs] [Bug 5979] New: msp430 backend: incorrect conditional
	jump
Message-ID: <bug-5979-206@http.llvm.org/bugs/>

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

           Summary: msp430 backend: incorrect conditional jump
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ransford at cs.umass.edu
                CC: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu


Created an attachment (id=4014)
 --> (http://llvm.org/bugs/attachment.cgi?id=4014)
Tiny test case

Given this C code:

% cat tiny.c
int main (void) {
    int i;
    for (i = 0; i < 100; ++i) {
        asm("NOP");
    }
}

In LLVM IR, the loop header looks like this:

for.cond:                                         ; preds = %for.inc, %entry
  %tmp = load i16* %i                             ; <i16> [#uses=1]
  %cmp = icmp slt i16 %tmp, 100                   ; <i1> [#uses=1]
  br i1 %cmp, label %for.body, label %for.end

... which says "go to %for.body if %i < 100, else go to %for.end -- this is
correct. However, run that IR through llc -march=msp430 and you get this
incorrect MSP430 code:

main:
; BB#0:                                                     ; %entry
        sub.w   #4, r1
        mov.w   #0, 2(r1)
        mov.w   #0, 0(r1)
.LBB1_1:                                                    ; %for.cond
                                                            ; Loop Depth 1
                                                            ; Loop Header
                                                            ; Inner Loop
        cmp.w   #99, 0(r1)
        jl      .LBB1_3
; BB#2:                                                     ; %for.body
                                                            ; Loop Depth 1
                                                            ; Loop Header is
BB1_1
                                                            ; Inner Loop
        ;APP
        NOP
        ;NO_APP
        add.w   #1, 0(r1)
        jmp     .LBB1_1
.LBB1_3:                                                    ; %for.end
        mov.w   2(r1), r15
        add.w   #4, r1
        ret
        .size   main, .-main

The conditional branch goes the wrong way! Of course 0 < 99, so the loop body
(BB#2) never gets executed.


-- 
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 Jan  8 19:30:27 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Jan 2010 19:30:27 -0600
Subject: [LLVMbugs] [Bug 5980] New: Dangling PHI argument causing crashes
Message-ID: <bug-5980-206@http.llvm.org/bugs/>

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

           Summary: Dangling PHI argument causing crashes
           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: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4016)
 --> (http://llvm.org/bugs/attachment.cgi?id=4016)
Reduced test case

The attached test case causes ISel to produce a PHI instruction that refers to
an MBB not in the CFG

BB#11: derived from LLVM BB %bb886.i.preheader
    Predecessors according to CFG: BB#4 BB#25
        %reg1025<def> = PHI %reg1026, <BB#4>, %reg1024, <BB#25>, %reg1024,
<BB#22>
    Successors according to CFG: BB#12

This looks innocent, but when -pre-regalloc-taildup later deletes BB#22, we
have a dangling pointer. Thing get worse from there.

Reproducible with

llc -verify-machineinstrs bugpoint-reduced-simplified.ll
llc -pre-regalloc-taildup -tail-dup-verify bugpoint-reduced-simplified.ll
llc -pre-regalloc-taildup bugpoint-reduced-simplified.ll


-- 
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 Jan  8 22:57:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 8 Jan 2010 22:57:59 -0600
Subject: [LLVMbugs] [Bug 5981] New: Assertion failed: (use_empty() && " Uses
 remain when a value is destroyed!")
Message-ID: <bug-5981-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (use_empty() && "Uses remain when a
                    value is destroyed!")
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lessen42 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4018)
 --> (http://llvm.org/bugs/attachment.cgi?id=4018)
bugpoint

from ffmpeg libavcodec/twinvq.c

$ opt bugpoint-reduced-simplified.bc -reassociate
WARNING: You're attempting to print out a bitcode file.
This is inadvisable as it may cause display problems. If
you REALLY want to taste LLVM bitcode first-hand, you
can force output with the `-f' option.

While deleting: i32 %
Use still stuck around after Def is destroyed:  %7 = add nsw i32 undef,
<badref>, !dbg !1373    ; <i32> [#uses=0]
Assertion failed: (use_empty() && "Uses remain when a value is destroyed!"),
function ~Value, file /usr/local/src/llvm/lib/VMCore/Value.cpp, line 75.
0  opt               0x00000001003ff3c2 PrintStackTrace(void*) + 34
1  opt               0x00000001003ffbac SignalHandler(int) + 652
2  libSystem.B.dylib 0x00007fff83e42eaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff83de7bea tiny_malloc_from_free_list + 1196
4  libSystem.B.dylib 0x00007fff83ebee74 __pthread_markcancel + 0
5  opt               0x00000001003b0683 llvm::Value::~Value() + 979
6  opt               0x000000010037c83b llvm::BinaryOperator::~BinaryOperator()
+ 27
7  opt               0x0000000100367944 llvm::Instruction::eraseFromParent() +
84
8  opt               0x00000001000eceeb (anonymous
namespace)::Reassociate::RemoveFactorFromExpression(llvm::Value*, llvm::Value*)
+ 1067
9  opt               0x00000001000ee03a (anonymous
namespace)::Reassociate::OptimizeAdd(llvm::Instruction*,
llvm::SmallVectorImpl<(anonymous namespace)::ValueEntry>&) + 4074
10 opt               0x00000001000ee890 (anonymous
namespace)::Reassociate::OptimizeExpression(llvm::BinaryOperator*,
llvm::SmallVectorImpl<(anonymous namespace)::ValueEntry>&) + 496
11 opt               0x00000001000eebf9 (anonymous
namespace)::Reassociate::ReassociateExpression(llvm::BinaryOperator*) + 377
12 opt               0x00000001000ef24b (anonymous
namespace)::Reassociate::ReassociateBB(llvm::BasicBlock*) + 523
13 opt               0x00000001000ef91b (anonymous
namespace)::Reassociate::runOnFunction(llvm::Function&) + 59
14 opt               0x000000010039b92b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 475
15 opt               0x000000010039ba9b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
16 opt               0x000000010039d1d3
llvm::MPPassManager::runOnModule(llvm::Module&) + 435
17 opt               0x000000010039d393
llvm::PassManagerImpl::run(llvm::Module&) + 147
18 opt               0x000000010039d41d llvm::PassManager::run(llvm::Module&) +
13
19 opt               0x0000000100043c07 main + 2999
20 opt               0x000000010003a0a8 start + 52
Stack dump:
0.      Program arguments: opt bugpoint-reduced-simplified.bc -reassociate 
1.      Running pass 'Function Pass Manager' on module
'bugpoint-reduced-simplified.bc'.
2.      Running pass 'Reassociate expressions' on function '@twin_decode_init'
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  Sat Jan  9 00:02:20 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 9 Jan 2010 00:02:20 -0600
Subject: [LLVMbugs] [Bug 5981] Assertion failed: (use_empty() && " Uses
 remain when a value is destroyed!")
In-Reply-To: <bug-5981-206@http.llvm.org/bugs/>
Message-ID: <201001090602.o0962KXW004599@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-09 00:02:19 ---
Fixed here, thanks for the report!
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100104/093909.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 Jan  9 12:34:23 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 9 Jan 2010 12:34:23 -0600
Subject: [LLVMbugs] [Bug 5983] New: asmparser accepts {} as function body
Message-ID: <bug-5983-206@http.llvm.org/bugs/>

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

           Summary: asmparser accepts {} as function body
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM assembly language parser
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


The asm parser accepts this code:

define void @def() {}

Running opt -S on it silently turns it into this:

declare void @def()

It would be better to issue an error for this case.

This came up because in some hand-written IR where an empty function body was
intended, but the "ret void" was forgotten. It's confusing for this to be
silently accepted and converted to a declaration.


-- 
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 Jan  9 13:06:24 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 9 Jan 2010 13:06:24 -0600
Subject: [LLVMbugs] [Bug 5729] Certain tail calls cause assertion failure
In-Reply-To: <bug-5729-206@http.llvm.org/bugs/>
Message-ID: <201001091906.o09J6OSe013452@zion.cs.uiuc.edu>

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


Jeffrey Yasskin <jyasskin at google.com> changed:

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




--- Comment #3 from Jeffrey Yasskin <jyasskin at google.com>  2010-01-09 13:06:22 ---
Fixed and tested in r93065.


-- 
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 Jan  9 13:20:36 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 9 Jan 2010 13:20:36 -0600
Subject: [LLVMbugs] [Bug 5983] asmparser accepts {} as function body
In-Reply-To: <bug-5983-206@http.llvm.org/bugs/>
Message-ID: <201001091920.o09JKabS013928@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-09 13:20:36 ---
Right, fixed in r93067, we now produce:

llvm-as: t.ll:1:21: error: function body requires at least one basic block
define void @def() {}
                    ^


-- 
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 Jan 10 03:48:02 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 10 Jan 2010 03:48:02 -0600
Subject: [LLVMbugs] [Bug 5984] New: Bogus 'use of undeclared identifier'
 error causing compilation to fail
Message-ID: <bug-5984-206@http.llvm.org/bugs/>

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

           Summary: Bogus 'use of undeclared identifier' error causing
                    compilation to fail
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: parser
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard at tiptree.demon.co.uk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4019)
 --> (http://llvm.org/bugs/attachment.cgi?id=4019)
sys/wait.h header from centos-5.4 with glibc-2.11.1 built from source

When compiling the gnustep-base library (objective-c ) I encountered
compilation failure related to sys/wait.h
It appears that something about the wait definitions causes clang to lose track
of the visibility of the objective-c class instance variable being used.
I simplified this to a tiny test program:

#include <sys/wait.h>
#include <objc/Object.h>

@interface      MyClass : Object
{
  int myStatus;
}
- (int) test;
@end

@implementation MyClass
- (int) test
{
  if (WIFEXITED(myStatus))
    return 1;
  return 0;
}
@end

int
main()
{
}


When I compile this test using clang (and a -I option to tell it where my
objective-c headers are) I get the following:

clang a.m -I /usr/GNUstep/Local/Library/Headers -lobjc
a.m:14:7: error: use of undeclared identifier 'myStatus'
  if (WIFEXITED(myStatus))
      ^
In file included from a.m:1:
/usr/include/sys/wait.h:85:28: note: instantiated from:
# define WIFEXITED(status)      __WIFEXITED (__WAIT_INT (status))
                                ^
In file included from a.m:1:
In file included from /usr/include/sys/wait.h:80:
/usr/include/bits/waitstatus.h:38:30: note: instantiated from:
#define __WIFEXITED(status)     (__WTERMSIG(status) == 0)
                                 ^
a.m:14:7: note: instantiated from:
  if (WIFEXITED(myStatus))
      ^
In file included from a.m:1:
/usr/include/sys/wait.h:85:28: note: instantiated from:
# define WIFEXITED(status)      __WIFEXITED (__WAIT_INT (status))
                                ^
a.m:14:7: note: instantiated from:
  if (WIFEXITED(myStatus))
      ^
In file included from a.m:1:
/usr/include/sys/wait.h:85:41: note: instantiated from:
# define WIFEXITED(status)      __WIFEXITED (__WAIT_INT (status))
                                             ^
a.m:14:7: note: instantiated from:
  if (WIFEXITED(myStatus))
      ^
a.m:14:17: note: instantiated from:
  if (WIFEXITED(myStatus))
                ^
a.m:14:7: error: member reference base type 'void' is not a structure or union
  if (WIFEXITED(myStatus))
      ^~~~~~~~~~~~~~~~~~~
In file included from a.m:1:
/usr/include/sys/wait.h:85:28: note: instantiated from:
# define WIFEXITED(status)      __WIFEXITED (__WAIT_INT (status))
                                ^
In file included from a.m:1:
In file included from /usr/include/sys/wait.h:80:
/usr/include/bits/waitstatus.h:38:30: note: instantiated from:
#define __WIFEXITED(status)     (__WTERMSIG(status) == 0)
                                 ^
a.m:14:7: note: instantiated from:
  if (WIFEXITED(myStatus))
      ^
In file included from a.m:1:
/usr/include/sys/wait.h:85:28: note: instantiated from:
# define WIFEXITED(status)      __WIFEXITED (__WAIT_INT (status))
                                ^
a.m:14:7: note: instantiated from:
  if (WIFEXITED(myStatus))
      ^
In file included from a.m:1:
/usr/include/sys/wait.h:85:41: note: instantiated from:
# define WIFEXITED(status)      __WIFEXITED (__WAIT_INT (status))
                                             ^
/usr/include/sys/wait.h:48:42: note: instantiated from:
                   { .__in = (status) }).__i))
                   ~~~~~~~~~~~~~~~~~~~~~ ^
2 diagnostics generated.




As you can see, the compiler appears to have forgotten about the myStatus
instance variable.

An easy workaround is to copy myStatus to a local integer variable, and use
that copy as the argument to WIFEXITED, so this bug is annoying, but not
critical.

I attach a copy of the sys/wait.h file involved.


-- 
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 Jan 10 12:20:47 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 10 Jan 2010 12:20:47 -0600
Subject: [LLVMbugs] [Bug 5986] New: Objective-C instance variable confused
 with builtin C function
Message-ID: <bug-5986-206@http.llvm.org/bugs/>

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

           Summary: Objective-C instance variable confused with builtin C
                    function
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: parser
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: truls.becken at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hi,

Clang sometimes confuses instance variables with C functions it thinks should
exist. A common ivar name is index, which also happens to be the name of a
standard string function. On Linux, this could result in the error shown below.
This does supposedly not happen on FreeBSD because index is not treated as
builtin there.

Making all for framework EtoileXML...
 Compiling file ETXMLNode.m ...
clang: warning: argument unused during compilation: '-march=i686'
ETXMLNode.m:76:8: error: implicitly declaring C library function
'index' with type
     'char *(char const *, int)'
       while(index < count)
             ^
ETXMLNode.m:76:8: note: please include the header <strings.h> or
explicitly provide a declaration
     for 'index'


Best regards,
Truls


-- 
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 Jan 10 14:18:04 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 10 Jan 2010 14:18:04 -0600
Subject: [LLVMbugs] [Bug 2701] LLVM/Clang Static Analyzer 0.79: reported
 memory leak ( in GC mode) is false positive
In-Reply-To: <bug-2701-206@http.llvm.org/bugs/>
Message-ID: <201001102018.o0AKI4Gj007181@zion.cs.uiuc.edu>

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


Sean McBride <sean at rogue-research.com> changed:

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




--- Comment #3 from Sean McBride <sean at rogue-research.com>  2010-01-10 14:18:03 ---
This seems to have been fixed at some point... it does'n repro for me anymore. 
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 Jan 10 18:03:13 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 10 Jan 2010 18:03:13 -0600
Subject: [LLVMbugs] [Bug 5990] New: [x86,
 x86-64] MMX vectors trample on FP stack, breaking 80-bit floats
Message-ID: <bug-5990-206@http.llvm.org/bugs/>

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

           Summary: [x86, x86-64] MMX vectors trample on FP stack, breaking
                    80-bit floats
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: ABI, miscompilation
          Severity: major
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu


The following code should print "1.000000", but prints "-nan" on both x86 (with
MMX) and x86-64. Removing the (dead) store to the vector fixes it again.

My guess is that LLVM doesn't realize that the MMX operation it emits sets the
upper 16 bits of the FPU stack registers to 1, thus NaN-ifying anything that
was there.


@s = internal constant [5 x i8] c"%Lf\0A\00"

define i32 @main(i32, i8**) {
entry:
  %x = alloca <2 x i32>, align 8
  store <2 x i32> zeroinitializer, <2 x i32>* %x, align 8
  call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([5 x i8]* @s, i64 0,
i64 0), x86_fp80 0xK3FFF8000000000000000)
  ret i32 0
}

declare i32 @printf(i8* nocapture, ...) 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 Jan 10 19:46:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 10 Jan 2010 19:46:59 -0600
Subject: [LLVMbugs] [Bug 5991] New: Need to spill more than one physical
 registers with inline asm
Message-ID: <bug-5991-206@http.llvm.org/bugs/>

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

           Summary: Need to spill more than one physical registers with
                    inline asm
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lessen42 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


>From ffmpeg libavcodec/x86/dsputil_mmx.c

$ llc bugpoint-reduced-simplified.bc -relocation-model=pic
Need to spill more than one physical registers!
UNREACHABLE executed at
/usr/local/src/llvm/lib/CodeGen/VirtRegRewriter.cpp:1674!
0  llc               0x00000001008f8162 PrintStackTrace(void*) + 34
1  llc               0x00000001008f89ec SignalHandler(int) + 652
2  libSystem.B.dylib 0x00007fff83e42eaa _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2082197872
4  llc               0x00000001008daf6d llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 381
5  llc               0x00000001006e8511 (anonymous
namespace)::LocalRewriter::RewriteMBB(llvm::MachineBasicBlock&,
llvm::VirtRegMap&, llvm::LiveIntervals*, (anonymous
namespace)::AvailableSpills&, llvm::BitVector&,
std::vector<llvm::MachineOperand*, std::allocator<llvm::MachineOperand*> >&) +
13809
6  llc               0x00000001006ed540 (anonymous
namespace)::LocalRewriter::runOnMachineFunction(llvm::MachineFunction&,
llvm::VirtRegMap&, llvm::LiveIntervals*) + 1280
7  llc               0x0000000100658636 (anonymous
namespace)::RALinScan::runOnMachineFunction(llvm::MachineFunction&) + 886
8  llc               0x000000010060ab2b
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 43
9  llc               0x000000010088615b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 475
10 llc               0x000000010088639b
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 139
11 llc               0x00000001008865be
llvm::FunctionPassManager::run(llvm::Function&) + 78
12 llc               0x00000001000260a8 main + 5672
13 llc               0x0000000100024a78 start + 52
Stack dump:
0.      Program arguments: llc bugpoint-reduced-simplified.bc
-relocation-model=pic 
1.      Running pass 'Linear Scan Register Allocator' on function
'@put_no_rnd_qpel8_mc03_mmx2'
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  Mon Jan 11 00:56:42 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 00:56:42 -0600
Subject: [LLVMbugs] [Bug 4216] missing bitfield optimization for a series of
 stores of constants
In-Reply-To: <bug-4216-206@http.llvm.org/bugs/>
Message-ID: <201001110656.o0B6ugta028488@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #20 from Chris Lattner <clattner at apple.com>  2010-01-11 00:56:41 ---
Finally fixed with r93147 as the last patch:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100111/093983.html

clang now generates this at -m64:

_test_bitfield:
        orl     $32962, %edi
        movl    $4294941946, %eax
        andq    %rdi, %rax
        ret


-- 
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 Jan 11 06:11:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 06:11:09 -0600
Subject: [LLVMbugs] [Bug 5992] New: OCAML binding;
 llvm_create_module uses wrong parameters
Message-ID: <bug-5992-206@http.llvm.org/bugs/>

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

           Summary: OCAML binding; llvm_create_module uses wrong parameters
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: evilkidder at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


bindings/ocaml/llvm/llvm.ml, line 137;

create_module declared taking 2 parameters; llcontext + string

bindings/ocaml/llvm/llvm_ocaml.c, line 121;

llvm_create_module takes 1 parameter; string.  Note: within the binding the
llcontext is effectively passed as the string name which leads to a corrupt
module name.  The following fix seems to work.

CAMLprim LLVMModuleRef llvm_create_module(LLVMContextRef c, value ModuleID) {
  return LLVMModuleCreateWithNameInContext(String_val(ModuleID), 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 Jan 11 12:59:28 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 12:59:28 -0600
Subject: [LLVMbugs] [Bug 5990] [x86, x86-64] MMX vectors trample on FP stack,
 breaking 80-bit floats
In-Reply-To: <bug-5990-206@http.llvm.org/bugs/>
Message-ID: <201001111859.o0BIxSjo006701@zion.cs.uiuc.edu>

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


Dale Johannesen <dalej at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dalej at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #4 from Dale Johannesen <dalej at apple.com>  2010-01-11 12:59:25 ---
You don't provide source.  If the compiler is producing the MM vector operation
from source that doesn't use MM vectors, that's wrong.  However, if the vector
operation is in the source, it's the user's responsibility to insert EMMS at
the right places.  Both gcc (4.2) and llvm-gcc work this way.  This is
obviously not ideal, but fixing it is a big job and there is not much interest
in doing so.

Long doubles are passed to printf normally; there wouldn't be much point in the
%L modifier if you couldn't.


-- 
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 Jan 11 13:20:33 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 13:20:33 -0600
Subject: [LLVMbugs] [Bug 5994] New: configure might find multiple ffi.h files
Message-ID: <bug-5994-206@http.llvm.org/bugs/>

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

           Summary: configure might find multiple ffi.h files
           Product: Build scripts
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: autoconf
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: skip at pobox.com
                CC: llvmbugs at cs.uiuc.edu


On my mac I have DarwinPorts/MacPorts installed in /opt/local.  When
configuring the Unladen Swallow project I was getting compile errors
because the configure script was finding both /usr/include/ffi/ffi.h and
/opt/local/include/ffi.h and defining both HAVE_FFI_H and HAVE_FFI_FFI_H.
I got compilation errors because (for whatever reason) the version of ffi.h
in /opt/local/include wasn't found by the compiler.  In any case, had it
found both ffi.h files I probably would have gotten some other errors.
After I deactivated the libffi port in MacPorts compilation went swimmingly.

At any rate, the configure script should define at most one of HAVE_FFI_H or
HAVE_FFI_FFI_H, no matter how many it finds.  (If both exist maybe it should
just be treated as a compilation error.)


-- 
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 Jan 11 13:27:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 13:27:09 -0600
Subject: [LLVMbugs] [Bug 5990] [x86, x86-64] MMX vectors trample on FP stack,
 breaking 80-bit floats
In-Reply-To: <bug-5990-206@http.llvm.org/bugs/>
Message-ID: <201001111927.o0BJR9Dd007859@zion.cs.uiuc.edu>

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


Matti Niemenmaa <matti.niemenmaa+llvmbugs at iki.fi> changed:

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




--- Comment #5 from Matti Niemenmaa <matti.niemenmaa+llvmbugs at iki.fi>  2010-01-11 13:27:08 ---
The compiler producing code using such vectors is my own. Does it have to be a
bug in llvm-gcc or clang to be a valid LLVM bug?!

It seems a reasonable expectation to me that if I emit such LLVM code I
shouldn't have to worry about the details of how it's codegenned. For some
operations, the <2 x i32> will be split into two separate operations on i32, in
which case the EMMS won't be needed. Putting such platform-specific logic into
my compiler really doesn't seem like the "right" thing to do here. I don't mind
if you leave this open with the admission that it probably won't be looked at,
but I honestly don't think INVALID is at all appropriate.

If you insist on C, here's something which makes clang behave the same way
(without optimizations). Judging from the codegen at http://www.llvm.org/demo/,
llvm-gcc does the same. Remove the line initializing 'vec b' to print 1.000000
instead of -nan:

#include <stdio.h>
typedef int vec __attribute__ ((vector_size (8)));
int main() {
        vec a;
        vec b = a + a;
        printf("%Lf\n", 1.0L);
}

GCC appears to refuse to emit MMX instructions, explaining why it doesn't break
the above code.


-- 
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 Jan 11 13:42:44 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 13:42:44 -0600
Subject: [LLVMbugs] [Bug 5995] New: Strange/incorrect field access code
Message-ID: <bug-5995-206@http.llvm.org/bugs/>

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

           Summary: Strange/incorrect field access code
           Product: tools
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: major
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: av1474 at comtv.ru
                CC: llvmbugs at cs.uiuc.edu


Here:
~$ uname -a               
Linux linmac 2.6.23-exp #1 Thu Oct 11 07:23:51 MSD 2007 ppc GNU/Linux

llvm-gcc:
~$ ~/x/dev/llvm/bin/gcc -v
Using built-in specs.
Target: powerpc-unknown-linux-gnu
Configured with: ../../llvm-gcc-4.2/configure --prefix=/home/malc/x/dev/llvm
--enable-languages=c --enable-llvm=/home/malc/x/rcs/svn/llvm/build/llvm/
--disable-bootstrap --disable-multilib : (reconfigured)
../../llvm-gcc-4.2/configure --prefix=/home/malc/x/dev/llvm
--enable-languages=c --enable-llvm=/home/malc/x/rcs/svn/llvm/build/llvm/
--disable-bootstrap --disable-multilib --disable-libgomp
Thread model: posix
gcc version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)


produces unusual code in response to:
struct s {
    int word;
    struct {
        int filler __attribute__ ((aligned (8)));
    };
};

void func (struct s *s)
{
    s->word = 0;
}

namely:
        .ident  "GCC: (GNU) 4.2.1 (Based on Apple Inc. build 5658) (LLVM
build)"
        .file   "a.c"


        .text
        .global func
        .type   func, @function
        .align  2
func:
        li 4, 0
        stb 4, 2(3)
        stb 4, 1(3)
        stb 4, 3(3)
        stb 4, 0(3)
        blr 
        .size   func,.-func


[ If one substitutes `int word' with `volatile sig_atomic_t word' the code
  becomes incorrect AFAICS ]

P.S. This is reduced test-cases for the problem encountered with QEMU which
     has jmp_buf[1] inside important structure along with a word-sized field
     accessed from the signal handler.

[1] jmp_buf has similar aligned field within a structure layout which seems
    to be required for this issue to trigger


-- 
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 Jan 11 13:59:07 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 13:59:07 -0600
Subject: [LLVMbugs] [Bug 5990] [x86, x86-64] MMX vectors trample on FP stack,
 breaking 80-bit floats
In-Reply-To: <bug-5990-206@http.llvm.org/bugs/>
Message-ID: <201001111959.o0BJx7Wu009122@zion.cs.uiuc.edu>

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


Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gohman at apple.com
             Status|REOPENED                    |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #6 from Dan Gohman <gohman at apple.com>  2010-01-11 13:59:06 ---
It's a serious bug in LLVM's MMX support, and it's also reported as PR1838.
It's been open for a long time, and to date no one has stepped forward to fix
it.

If you have a front-end which wants to emit vector code and not care about the
capabilities of the target, the -disable-mmx option is highly recommended. With
this option, <2 x i32> vectors are handled in SSE registers, with the compiler
doing all the bookkeeping necessary.

I agree that this state of affairs is not ideal, but LLVM is attempting to meet
the needs of several different classes of users, with drastically different
needs.

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


-- 
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 Jan 11 15:12:07 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 15:12:07 -0600
Subject: [LLVMbugs] [Bug 5996] New: ARM: llvm-gcc assertion failure
 converting a union type
Message-ID: <bug-5996-206@http.llvm.org/bugs/>

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

           Summary: ARM: llvm-gcc assertion failure converting a union type
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bob.wilson at apple.com
                CC: llvmbugs at cs.uiuc.edu


The SingleSource/UnitTests/2006-01-23-UnionInit.c nightly test causes as
assertion failure for arm-darwin:

Assertion failed: (LLVMStructSize < GCCTypeSize && "LLVM type size doesn't
match GCC type size!"), function ConvertRECORD, file llvm-types.cpp, line 2201.

(Normally I run the nightly testsuite with a release build so this assertion
isn't checked.  Apparently the
failure is relatively harmless because the test passes.)

I looked at this briefly.  The offending type is:

struct bt1 {
  signed dv1:4;
  signed ev1:6;
  unsigned char fv1[1];
}

For the llvm type, the 2 bitfields are translated to an i16 type, since they
are too big for an i8.   That causes the alignment of the struct to increase to
16 bits, which then causes the size to be padded out to 32 bits.  This may be
fallout from my change r82630, so I'll take a look at it.


-- 
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 Jan 11 15:21:23 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 15:21:23 -0600
Subject: [LLVMbugs] [Bug 5980] Dangling PHI argument causing crashes
In-Reply-To: <bug-5980-206@http.llvm.org/bugs/>
Message-ID: <201001112121.o0BLLN4L012437@zion.cs.uiuc.edu>

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


Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

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




--- Comment #1 from Jakob Stoklund Olesen <stoklund at 2pi.dk>  2010-01-11 15:21:22 ---
Fixed here: http://llvm.org/viewvc/llvm-project/?view=rev&revision=93184


-- 
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 Jan 11 16:41:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 16:41:10 -0600
Subject: [LLVMbugs] [Bug 5883] NULL pointer dereference in sema
In-Reply-To: <bug-5883-206@http.llvm.org/bugs/>
Message-ID: <201001112241.o0BMfA34015934@zion.cs.uiuc.edu>

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


Douglas Gregor <dgregor at apple.com> changed:

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




--- Comment #2 from Douglas Gregor <dgregor at apple.com>  2010-01-11 16:41:10 ---
Fixed here:

 
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100111/026222.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 Jan 11 16:41:52 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 16:41:52 -0600
Subject: [LLVMbugs] [Bug 5997] New: [x86-64] regalloc not sharing 32-bit
 subregs of 64-bit regs aggressively
Message-ID: <bug-5997-206@http.llvm.org/bugs/>

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

           Summary: [x86-64] regalloc not sharing 32-bit subregs of 64-bit
                    regs aggressively
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


This (odd) testcase is a reduction of a larger pair of testcases from 256.bzip2
that I'll attach next.  This:

define i64 @test1a(i64 %A, i64 %B, i32* %P, i64 *%P2) nounwind {
  %C = add i64 %A, %B
  %D = trunc i64 %C to i32
  volatile store i32 %D, i32* %P
  %E = shl i64 %C, 32
  %F = ashr i64 %E, 32  
  volatile store i64 %F, i64 *%P2
  volatile store i32 %D, i32* %P
  ret i64 undef
}

LLC's into:

_test1a:                                                    ## @test1a
## BB#0:
        addq    %rsi, %rdi
                                                            ## kill: EDI<def>
RDI<kill>
        movl    %edi, (%rdx)
        movslq  %edi, %rax
        movq    %rax, (%rcx)
        movl    %edi, (%rdx)
        ret

This has unneccesarily high register pressure, it doesn't need to use RAX at
all.  I'd expect something like this:

_test1a:
        addq    %rsi, %rdi
        movl    %edi, (%rdx)
        movslq  %edi, %rdi
        movq    %rdi, (%rcx)
        movl    %edi, (%rdx)
        ret

Same # instructions, one fewer register.  This sort of thing happens quite
often for int induction variables (when dan's index promotion stuff doesn't
kick in) because GEP's implicitly sext their indices to i64, but the original
int is used for other things.  They should both share the same 64-bit GPR.

This is aka rdar://7529457


-- 
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 Jan 11 16:49:58 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 16:49:58 -0600
Subject: [LLVMbugs] [Bug 5998] New: thumb2 UBFX not generated
Message-ID: <bug-5998-206@http.llvm.org/bugs/>

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

           Summary: thumb2 UBFX not generated
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bagel99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4027)
 --> (http://llvm.org/bugs/attachment.cgi?id=4027)
SBFX and UBFX test

Although the signed bit-field extract pattern appears to match and generate,
the unsigned version does not.  The attached test file has three test
functions.  The first shows the SBFX generation working and the last two show
UBFX not working.  The first and second test function differ only in sext vs.
zext.


-- 
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 Jan 11 20:57:20 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 20:57:20 -0600
Subject: [LLVMbugs] [Bug 6004] New: clang does not generate a warning for
 division by zero.
Message-ID: <bug-6004-206@http.llvm.org/bugs/>

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

           Summary: clang does not generate a warning for division by zero.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sanjiv.gupta at microchip.com
                CC: llvmbugs at cs.uiuc.edu


gcc generates a warning 

C16-115-1.c:7: warning: division by zero

for the following code:


char *pc = (char *) 0xA0;

volatile signed char char1 = 0xFF;

int main(void)
{
  if ( char1 % 0) {
    *pc = 1;
  }
  else
    *pc = 0;
}



Why clang doesn't ?


-- 
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 Jan 11 22:42:00 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 22:42:00 -0600
Subject: [LLVMbugs] [Bug 6006] New: Change ContentCache::getBuffer to
 support failure properly.
Message-ID: <bug-6006-206@http.llvm.org/bugs/>

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

           Summary: Change ContentCache::getBuffer to support failure
                    properly.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Basic
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: clattner at apple.com, llvmbugs at cs.uiuc.edu,
                    dgregor at apple.com


Currently, PCH works by creating file and content cache entries for files in
the PCH, which may not actually exist on disk anymore. There is currently a
huge hack in ContentCache::getBuffer which just manufactures file contents if
the file is ever referenced and turns out not to exist. This should be fixed,
by changing ContentCache::getBuffer to return failures properly. Clients could
then give a nice error about an inconsistent PCH state being detected.

This is a large project, as it involves also adding failure support to all of
the APIs which may transitively use getBuffer, and updating all of their
clients. Notable clients include SourceManager::getCharacterData and
Preprocessor::getSpelling.


-- 
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 Jan 11 23:10:40 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 11 Jan 2010 23:10:40 -0600
Subject: [LLVMbugs] [Bug 6007] New: using __attribute__ on local variables
 does not generate an error.
Message-ID: <bug-6007-206@http.llvm.org/bugs/>

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

           Summary: using __attribute__ on local variables does not generate
                    an error.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: parser
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sanjiv.gupta at microchip.com
                CC: llvmbugs at cs.uiuc.edu


# 1 "/tmp/b.c"
# 1 "/tmp/b.c" 1
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 88 "<built-in>" 3
# 88 "<command line>" 1
# 1 "/tmp/b.c" 2
__attribute__((section("NEAR"))) int a1=0Xffff;
volatile char pt1;



int main()
{
 __attribute__((section("NEAR"))) int n1;
 a1=0xFFFF;
 if (a1=0XFFFF)
 n1=0x00FF;

}




$ gcc -c b.i
line-map.c: file "/tmp/b.c" left but not entered
In file included from /tmp/b.c:2,
                 from /tmp/b.c:2:
<built-in>: In function ???main???:

<built-in>:96: error: section attribute cannot be specified for local variables


-- 
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 Jan 12 06:31:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 06:31:29 -0600
Subject: [LLVMbugs] [Bug 6009] New: Improved switch conversion
Message-ID: <bug-6009-206@http.llvm.org/bugs/>

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

           Summary: Improved switch conversion
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bearophile at mailas.com
                CC: llvmbugs at cs.uiuc.edu


<baldrick> on the IRC channel has suggested me to put this here, despite this
doesn't come from a performance problem in real code (usually I report things
here after I have seen an actual performance problem in some of my code).

In the attach there's a small C program, compiled with gcc 4.3, gcc 4.4 and
llvm-gcc 2.6, it shows an improvement in the compilation of switch tables done
by gcc 4.4 and absent in llvm 2.6.

It looks like a cute optimization, but:
1) It's easy to manually do this optimization (using a constant mapping array
that generally doesn't start from index 0, shifting the starting pointer)
2) I don't think this situation happens often enough in real code.


-- 
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 Jan 12 07:08:37 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 07:08:37 -0600
Subject: [LLVMbugs] [Bug 6009] Improved switch conversion
In-Reply-To: <bug-6009-206@http.llvm.org/bugs/>
Message-ID: <201001121308.o0CD8bFk029602@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asl at math.spbu.ru
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #2 from Anton Korobeynikov <asl at math.spbu.ru>  2010-01-12 07:08:36 ---


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


-- 
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 Jan 12 07:39:37 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 07:39:37 -0600
Subject: [LLVMbugs] [Bug 6010] New: Accumulator not pulled out of a loop
Message-ID: <bug-6010-206@http.llvm.org/bugs/>

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

           Summary: Accumulator not pulled out of a loop
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bearophile at mailas.com
                CC: llvmbugs at cs.uiuc.edu


See the attach for full info.

At the moment this problem is shown here in some D code compiled with ldc D
compiler. I can translate that D program in C, but it will require probably one
hour or more of work, so I'd like to avoid it if possible (or I may I may be
able to produce a reduced C version).

I don't know the cause of this problem, it may be again a "restrict"-related
thing, as shown in bugs 5968 and 2547. Even if this is true, this can be useful
to show that this is a common enough problem. In the meantime in attach there
is the LL code of both conditionally compiled versions.


-- 
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 Jan 12 12:53:30 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 12:53:30 -0600
Subject: [LLVMbugs] [Bug 6016] New: llvm.x86.ssse3.pabs intrinsics should be
	removed
Message-ID: <bug-6016-206@http.llvm.org/bugs/>

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

           Summary: llvm.x86.ssse3.pabs intrinsics should be removed
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-cleanup, code-quality
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


the llvm.x86.ssse3.pabs* intrinsics can all be expressed as an AND with a
constant vector.  We should eliminate these intrinsics and just pattern match
the appropriate and.  This allows us to generate pabsw and friends for the
corresponding pattern.


-- 
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 Jan 12 08:58:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 08:58:09 -0600
Subject: [LLVMbugs] [Bug 6010] Accumulator not pulled out of a loop
In-Reply-To: <bug-6010-206@http.llvm.org/bugs/>
Message-ID: <201001121458.o0CEw9uu001644@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #8 from Anton Korobeynikov <asl at math.spbu.ru>  2010-01-12 08:58:06 ---
Another testcase for TBAA

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


-- 
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 Jan 12 14:59:19 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 14:59:19 -0600
Subject: [LLVMbugs] [Bug 6007] using __attribute__((section)) on local
 variables does not generate an error.
In-Reply-To: <bug-6007-206@http.llvm.org/bugs/>
Message-ID: <201001122059.o0CKxJ5g016173@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-12 14:59:19 ---
implemented here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100111/026264.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 Jan 12 15:24:25 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 15:24:25 -0600
Subject: [LLVMbugs] [Bug 6004] clang does not generate a warning for
	division by zero.
In-Reply-To: <bug-6004-206@http.llvm.org/bugs/>
Message-ID: <201001122124.o0CLOPD4017134@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-12 15:24:23 ---
Implemented here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100111/026265.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 Jan 12 16:42:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 16:42:59 -0600
Subject: [LLVMbugs] [Bug 6019] New: LLVM Creates a Cyclic SelectionDAG
Message-ID: <bug-6019-206@http.llvm.org/bugs/>

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

           Summary: LLVM Creates a Cyclic SelectionDAG
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: greened at obbligato.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4043)
 --> (http://llvm.org/bugs/attachment.cgi?id=4043)
Testcase to trigger a topological sort failure

The attached testcase triggers the following assert in llc:

llc:
/ptmp/dag/llvm-project.official/llvm/trunk/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5202:
unsigned int llvm::SelectionDAG::AssignTopologicalOrder(): Assertion `SortedPos
== AllNodes.end() && "Topological sort incomplete!"' failed.
0  llc       0x000000000172e71e
1  llc       0x000000000172ed04
2  libc.so.6 0x00002b15e6b10c10
3  libc.so.6 0x00002b15e6b10b95 gsignal + 53
4  libc.so.6 0x00002b15e6b11f90 abort + 272
5  libc.so.6 0x00002b15e6b0a256 __assert_fail + 246
6  llc       0x000000000126368f llvm::SelectionDAG::AssignTopologicalOrder() +
715
7  llc       0x0000000000bc4dad llvm::SelectionDAGISel::SelectRootInit() + 25
8  llc       0x000000000119c7f3 (anonymous
namespace)::X86DAGToDAGISel::SelectRoot(llvm::SelectionDAG&) + 37
9  llc       0x000000000102ac7f (anonymous
namespace)::X86DAGToDAGISel::InstructionSelect() + 189
10 llc       0x00000000012dc1cb llvm::SelectionDAGISel::CodeGenAndEmitDAG() +
3713
11 llc       0x00000000012ddefa
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::ilist_iterator<llvm::Instruction>,
llvm::ilist_iterator<llvm::Instruction>, bool&) + 686
12 llc       0x00000000012de89f
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&,
llvm::MachineFunction&, llvm::MachineModuleInfo*, llvm::DwarfWriter*,
llvm::TargetInstrInfo const&) + 2419
13 llc       0x00000000012df2ab
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 931
14 llc       0x00000000013ea4f5
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 83
15 llc       0x00000000016ac020
llvm::FPPassManager::runOnFunction(llvm::Function&) + 336
16 llc       0x00000000016adbe5
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 79
17 llc       0x00000000016add86 llvm::FunctionPassManager::run(llvm::Function&)
+ 112
18 llc       0x0000000000b2221c main + 3166
19 libc.so.6 0x00002b15e6afe154 __libc_start_main + 244
20 llc       0x0000000000b207a9
Stack dump:
0.      Program arguments:
/ptmp/dag/build.llvm.trunk.official.debug/x86_64-unknown-linux-gnu/Debug/bin/llc
bugpoint-reduced-simplified.bc -f -o bugpoint-reduced-simplified.s
1.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@numvec_'
Abort

Examination of the SelectionDAG reveals a cyclic graph:

Offending node:
0x1a8fd00: i64 = add 0x1a8cce0, 0x1a6b970Comments: # 
  0x1a8cce0: i64 = shl 0x1a6bae0, 0x1a8e3e0Comments: # 
    0x1a6bae0: i64 = sign_extend 0x1a8de20Comments: # 
      0x1a8de20: i32 = extract_vector_elt 0x1a8db40, 0x1a8dcb0Comments: # 
        0x1a8db40: v4i32 = vector_shuffle 0x1a8fb90, 0x1a6c0a0,
0x1a8d130<3,u,u,u>Comments: # 
          0x1a8fb90: v4i32 = bit_convert 0x1a6bf30Comments: # 
            0x1a6bf30: v2i64,ch = load 0x1a8cfc0, 0x1a6bdc0, 0x1a8fa20
<0x1a431d8:0> alignment=4Comments: # 
              0x1a8cfc0: ch = TokenFactor 0x1a6b690, 0x1a6c210:1Comments: # 
                0x1a6b690: ch = EntryToken Comments: # 
                0x1a6c210: i32,ch = load 0x1a6b690, 0x1a8e550, 0x1a8fa20
<0x1a434f8:0> alignment=4Comments: # 
                  0x1a6b690: ch = EntryToken Comments: # 
                  0x1a8e550: i64 = add 0x1a8fd00, 0x1a8cb70Comments: # 
                    0x1a8fd00: i64 = add 0x1a8cce0, 0x1a6b970Comments: # 
                      0x1a8cce0: i64 = shl 0x1a6bae0, 0x1a8e3e0Comments: # 
                        0x1a6bae0: i64 = sign_extend 0x1a8de20Comments: # 
                          0x1a8de20: i32 = extract_vector_elt 0x1a8db40,
0x1a8dcb0Comments: # 
                            0x1a8db40: v4i32 = vector_shuffle 0x1a8fb90,
0x1a6c0a0, 0x1a8d130<3,u,u,u>Comments: # 
                              0x1a8fb90: v4i32 = bit_convert 0x1a6bf30Comments:
# 
                                0x1a6bf30: v2i64,ch = load 0x1a8cfc0,
0x1a6bdc0, 0x1a8fa20 <0x1a431d8:0> alignment=4Comments: # 
                                  0x1a8cfc0: ch = TokenFactor 0x1a6b690,
0x1a6c210:1Comments: # 
                                    0x1a6b690: ch = EntryToken Comments: # 
                                    0x1a6c210: i32,ch = load 0x1a6b690,
0x1a8e550, 0x1a8fa20 <0x1a434f8:0> alignment=4Comments: # 
                                      0x1a6b690: ch = EntryToken Comments: # 
                                      0x1a8e550: i64 = add 0x1a8fd00,
0x1a8cb70Comments: # 
                                        0x1a8fd00: i64 = add 0x1a8cce0,
0x1a6b970Comments: # 
                                          0x1a8cce0: i64 = shl 0x1a6bae0,
0x1a8e3e0Comments: # 

Note the reuse of 0x1a8e550.  I don't believe that is allowed.  In the final
loop nest of the topological sort code in SelectionDAG.cpp, the iterator I
eventually runs ahead of SortedPos, which is a no-no given that nodes referred
to by I are assumed to be already sorted.  I believe this is due to the cyclic
structure 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  Tue Jan 12 18:00:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 18:00:29 -0600
Subject: [LLVMbugs] [Bug 5986] Objective-C instance variable confused with
 builtin C function
In-Reply-To: <bug-5986-206@http.llvm.org/bugs/>
Message-ID: <201001130000.o0D00TLd023104@zion.cs.uiuc.edu>

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


Fariborz Jahanian <fjahanian at apple.com> changed:

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




--- Comment #5 from Fariborz Jahanian <fjahanian at apple.com>  2010-01-12 18:00:28 ---
Fixed in TOT: http://llvm.org/viewvc/llvm-project?view=rev&revision=93271


-- 
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 Jan 12 20:35:12 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 20:35:12 -0600
Subject: [LLVMbugs] [Bug 5323] Compiler-RT needs crtbegin/crtend stuff.
In-Reply-To: <bug-5323-206@http.llvm.org/bugs/>
Message-ID: <201001130235.o0D2ZCu7029153@zion.cs.uiuc.edu>

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


Daniel Dunbar <daniel at zuster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at zuster.org
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Daniel Dunbar <daniel at zuster.org>  2010-01-12 20:35:11 ---
This isn't a compiler-rt bug, compiler-rt is useful without it. This bug
belongs in whatever target needs crtbegin/crtend support to adopt compiler-rt.
If they want to contribute that support back into compiler-rt, great.


-- 
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 Jan 12 23:34:56 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 12 Jan 2010 23:34:56 -0600
Subject: [LLVMbugs] [Bug 5724] restFP should use lfd, not stfd
In-Reply-To: <bug-5724-206@http.llvm.org/bugs/>
Message-ID: <201001130534.o0D5YuiM002670@zion.cs.uiuc.edu>

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


Nick Kledzik <kledzik at apple.com> changed:

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




--- Comment #2 from Nick Kledzik <kledzik at apple.com>  2010-01-12 23:34:54 ---
Fixed in
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100111/094107.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 Jan 13 09:08:42 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 09:08:42 -0600
Subject: [LLVMbugs] [Bug 6027] New: ssertion `Bits != 0 && "Cannot print
 this instruction."'
Message-ID: <bug-6027-206@http.llvm.org/bugs/>

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

           Summary: ssertion `Bits != 0 && "Cannot print this instruction."'
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nunoplopes at sapo.pt
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4045)
 --> (http://llvm.org/bugs/attachment.cgi?id=4045)
test case

$ llc -o a.o a.ll
llc: llvm/lib/Target/X86/AsmPrinter/../X86GenAsmWriter.inc:2728: void
llvm::X86ATTInstPrinter::printInstruction(const llvm::MCInst*): Assertion `Bits
!= 0 && "Cannot print this instruction."' 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  Wed Jan 13 09:09:42 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 09:09:42 -0600
Subject: [LLVMbugs] [Bug 6028] New: APInt assertion failure in interpreter
Message-ID: <bug-6028-206@http.llvm.org/bugs/>

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

           Summary: APInt assertion failure in interpreter
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Interpreter
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jay.foad at antixlabs.com
                CC: llvmbugs at cs.uiuc.edu


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

With the attached .bc file, I get the following assertion failure:

$ lli -force-interpreter s.bc
0
1
2
0
lli: /home/foad/svn/llvm-project/llvm/trunk/lib/Support/APInt.cpp:551: bool
llvm::APInt::slt(const llvm::APInt&) const: Assertion `BitWidth == RHS.BitWidth
&& "Bit widths must be same for comparison"' failed.
0  lli       0x08a59e51
1  lli       0x08a5a41d
2            0xb7f64400 __kernel_sigreturn + 0
3  libc.so.6 0xb7ce2018 abort + 392
4  libc.so.6 0xb7cd95be __assert_fail + 238
5  lli       0x08a1d5c8 llvm::APInt::slt(llvm::APInt const&) const + 76
6  lli       0x0868242b
7  lli       0x0868910e llvm::Interpreter::visitICmpInst(llvm::ICmpInst&) + 828
8  lli       0x0868ea3a llvm::InstVisitor<llvm::Interpreter,
void>::visitICmp(llvm::ICmpInst&) + 36
9  lli       0x0868f0ce llvm::InstVisitor<llvm::Interpreter,
void>::visit(llvm::Instruction&) + 1048
10 lli       0x08689dd0 llvm::Interpreter::run() + 216
11 lli       0x0867f873 llvm::Interpreter::runFunction(llvm::Function*,
std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&) +
189
12 lli       0x086bceff
llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::vector<std::string, std::allocator<std::string> > const&, char const*
const*) + 1019
13 lli       0x084c605f main + 2093
14 libc.so.6 0xb7ccb455 __libc_start_main + 229
15 lli       0x084c5161
Stack dump:
0.      Program arguments: ./lli -force-interpreter s.bc 
Aborted

I'm using a debug build of svn trunk rev 93317 on Debian Linux/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  Wed Jan 13 11:51:26 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 11:51:26 -0600
Subject: [LLVMbugs] [Bug 6030] New: confusing warning from clang re.
 incompatible pointer types
Message-ID: <bug-6030-206@http.llvm.org/bugs/>

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

           Summary: confusing warning from clang re. incompatible pointer
                    types
           Product: new-bugs
           Version: trunk
          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


The second warning effectively says "X is wrong, expected X".  Obviously the
code is bogus but the warning could be better!


regehr at john-home:~/volatile/bugs/tmp256$ clang small.c -c
small.c:5:25: warning: declaration of 'struct archive_read' will not be visible
      outside of this function
  int (*finish) (struct archive_read *);
                        ^
small.c:18:29: warning: incompatible pointer types assigning 'int (*)(struct
      archive_read *)', expected 'int (*)(struct archive_read *)'
  (a->decompressor)->finish = &archive_decompressor_none_finish;
                            ^ ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 diagnostics generated.
regehr at john-home:~/volatile/bugs/tmp256$ cat small.c
typedef unsigned long size_t;

struct decompressor_t
{
  int (*finish) (struct archive_read *);
};

struct archive_read
{
  struct decompressor_t *decompressor;
};

int archive_decompressor_none_finish (struct archive_read *a);

int archive_decompressor_none_init (struct archive_read *a, void const *buff,
                                    size_t n)
{
  (a->decompressor)->finish = &archive_decompressor_none_finish;
  return 0;
}
regehr at john-home:~/volatile/bugs/tmp256$ clang -v
clang version 1.1 (trunk 93238)
Target: i386-pc-linux-gnu
Thread model: posix


-- 
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 Jan 13 12:25:42 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 12:25:42 -0600
Subject: [LLVMbugs] [Bug 5323] Compiler-RT needs crtbegin/crtend for
 linux/solaris/others.
In-Reply-To: <bug-5323-206@http.llvm.org/bugs/>
Message-ID: <201001131825.o0DIPguu014245@zion.cs.uiuc.edu>

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


Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nlewycky at google.com
             Status|RESOLVED                    |REOPENED
         Resolution|INVALID                     |
            Summary|Compiler-RT needs           |Compiler-RT needs
                   |crtbegin/crtend stuff.      |crtbegin/crtend for
                   |                            |linux/solaris/others.




--- Comment #2 from Nick Lewycky <nlewycky at google.com>  2010-01-13 12:25:42 ---
This is a missing feature in compiler-rt. Reopening this bug on the grounds
that linux needs it, and updating the summary to that effect.


-- 
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 Jan 13 13:17:08 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 13:17:08 -0600
Subject: [LLVMbugs] [Bug 6027] Assertion `Bits != 0 && "Cannot print this
	instruction."'
In-Reply-To: <bug-6027-206@http.llvm.org/bugs/>
Message-ID: <201001131917.o0DJH868016586@zion.cs.uiuc.edu>

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


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>  2010-01-13 13:17:08 ---
Fixed: r93335.


-- 
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 Jan 13 16:35:15 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 16:35:15 -0600
Subject: [LLVMbugs] [Bug 6032] New: Unnecesary branching generated for "x ==
 x ? x : x + x; "   floating point expr
Message-ID: <bug-6032-206@http.llvm.org/bugs/>

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

           Summary: Unnecesary branching generated for "x == x  ? x : x +
                    x;" floating point expr
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jan_sjodin at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


For the C function

double d1(double x) { return x == x ? x : x + x; }

The LLVM CPU back end is generating branches.  E.g. ToT clang produces:

d1:
.Leh_func_begin1:
        pushq   %rbp
.Llabel1:
        movq    %rsp, %rbp
.Llabel2:
        ucomisd %xmm0, %xmm0
        jnp     .LBB1_2
        addsd   %xmm0, %xmm0
.LBB1_2:
        popq    %rbp
        ret

However, it is possible to handle this in a branch free fashion using the CMPSD
instruction to produce a mask which can then be used in simple logical
operations to produce the desired result.


-- 
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 Jan 13 17:23:36 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 17:23:36 -0600
Subject: [LLVMbugs] [Bug 6033] New: clang analyzer bug: Assertion
 `isdigit(*DiagStr) && " Invalid format for argument in diagnostic"' failed.
Message-ID: <bug-6033-206@http.llvm.org/bugs/>

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

           Summary: clang analyzer bug: Assertion `isdigit(*DiagStr) &&
                    "Invalid format for argument in diagnostic"' failed.
           Product: new-bugs
           Version: trunk
          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


regehr at john-home:~/volatile/bugs/tmp257$ clang --analyze small.c
small.c:3:21: warning: declaration of 'struct userconf' will not be visible
      outside of this function
pw_password (struct userconf *cnf, struct cargs *args, char const *user)
                    ^
small.c:3:43: warning: declaration of 'struct cargs' will not be visible
outside
      of this function
pw_password (struct userconf *cnf, struct cargs *args, char const *user)
                                          ^
small.c:10:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
small.c:7:28: warning: clang: Diagnostic.cpp:755: void
clang::DiagnosticInfo::FormatDiagnostic(llvm::SmallVectorImpl<char>&) const:
Assertion `isdigit(*DiagStr) && "Invalid format for argument in diagnostic"'
failed.
0  clang 0x090ee918
Stack dump:
0.      Program arguments: /home/regehr/z/tmp/llvm-gcc-r93238-install/bin/clang
-cc1 -triple i386-pc-linux-gnu -analyze -disable-free -main-file-name small.c
-analyzer-store=region -analyzer-opt-analyze-nested-blocks -warn-dead-stores
-warn-security-syntactic -checker-cfref -analyzer-eagerly-assume
-warn-objc-methodsigs -warn-objc-unused-ivars -analyzer-output plist
-mrelocation-model static -mdisable-fp-elim -target-cpu pentium4 -resource-dir
/home/regehr/z/tmp/llvm-gcc-r93238-install/lib/clang/1.1 -fmessage-length 80
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o small.plist -x c
small.c 
1.      <eof> parser at end of file
clang: error: analyzer command failed due to signal 6 (use -v to see
invocation)
regehr at john-home:~/volatile/bugs/tmp257$ cat small.c
typedef unsigned int __uint32_t;
char *
pw_password (struct userconf *cnf, struct cargs *args, char const *user)
{
  __uint32_t tmp;
  int __tmp__110;
  while (__tmp__110 < (tmp % 1))
    {
    }
}
regehr at john-home:~/volatile/bugs/tmp257$ clang -v
clang version 1.1 (trunk 93238)
Target: i386-pc-linux-gnu
Thread model: posix


-- 
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 Jan 13 17:29:32 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 17:29:32 -0600
Subject: [LLVMbugs] [Bug 6032] Unnecesary branching generated for "x == x ?
 x : x + x; "   floating point expr
In-Reply-To: <bug-6032-206@http.llvm.org/bugs/>
Message-ID: <201001132329.o0DNTWQ1027183@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-13 17:29:32 ---
Nice.  I added it to the X86 readme, where we keep specific microoptimizations:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100111/094163.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 Jan 13 17:29:54 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 17:29:54 -0600
Subject: [LLVMbugs] [Bug 6034] New: clang ice: Assertion `SS ==
 (SwitchStmt*)Switch.get() && " switch stack missing push/pop!"' failed.
Message-ID: <bug-6034-206@http.llvm.org/bugs/>

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

           Summary: clang ice: Assertion `SS == (SwitchStmt*)Switch.get() &&
                    "switch stack missing push/pop!"' failed.
           Product: new-bugs
           Version: trunk
          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


Code is invalid for clang, but valid for gcc.

regehr at john-home:~/volatile/bugs/tmp258$ clang small.c
small.c:6:30: error: global register variables are not supported
register struct CPUPPCState *env __asm__ ("ebp");
                             ^
clang: SemaStmt.cpp:491: virtual
clang::ASTOwningResult<&clang::ActionBase::DeleteStmt>
clang::Sema::ActOnFinishSwitchStmt(clang::SourceLocation,
clang::ASTOwningResult<&clang::ActionBase::DeleteStmt>,
clang::ASTOwningResult<&clang::ActionBase::DeleteStmt>): Assertion `SS ==
(SwitchStmt*)Switch.get() && "switch stack missing push/pop!"' failed.
0  clang 0x090ee918
Stack dump:
0.      Program arguments: /home/regehr/z/tmp/llvm-gcc-r93238-install/bin/clang
-cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name small.c
-mrelocation-model static -mdisable-fp-elim -target-cpu pentium4 -resource-dir
/home/regehr/z/tmp/llvm-gcc-r93238-install/lib/clang/1.1 -fmessage-length 80
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-oIVWaL.s
-x c small.c 
1.      small.c:14:1: current parser token '}'
2.      small.c:9:1: parsing function body 'helpersetbit'
3.      small.c:9:1: in compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

regehr at john-home:~/volatile/bugs/tmp258$ cat small.c

typedef unsigned int uint32_t;
struct CPUPPCState
{
  uint32_t fpscr;
};
register struct CPUPPCState *env __asm__ ("ebp");
void
helpersetbit (uint32_t bit)
{
  switch (bit)
    switch (env->fpscr)
      {
      }
}

regehr at john-home:~/volatile/bugs/tmp258$ clang -v

clang version 1.1 (trunk 93238)
Target: i386-pc-linux-gnu
Thread model: posix


-- 
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 Jan 13 17:32:45 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 17:32:45 -0600
Subject: [LLVMbugs] [Bug 6035] New: clang analyzer bug: Assertion
 `Loc::IsLocType(castTy)' failed.
Message-ID: <bug-6035-206@http.llvm.org/bugs/>

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

           Summary: clang analyzer bug: Assertion `Loc::IsLocType(castTy)'
                    failed.
           Product: new-bugs
           Version: trunk
          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


regehr at john-home:~/volatile/bugs/tmp258$ clang --analyze small.c -c
clang: warning: argument unused during compilation: '-c'
small.c:10:43: warning: declaration of 'struct pcm' will not be visible outside
      of this function
feed_swaplr (struct pcm_feeder *f, struct pcm *c, uint8_t * b, uint32_t count,
                                          ^
small.c:15:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
small.c:14:3: warning: Value stored to 'bps' is never read
  bps = (long) f->data;
  ^     ~~~~~~~~~~~~~~
clang: SValuator.cpp:119: clang::SValuator::CastResult
clang::SValuator::EvalCast(clang::SVal, const clang::GRState*, clang::QualType,
clang::QualType): Assertion `Loc::IsLocType(castTy)' failed.
0  clang 0x090ee918
Stack dump:
0.      Program arguments: /home/regehr/z/tmp/llvm-gcc-r93238-install/bin/clang
-cc1 -triple i386-pc-linux-gnu -analyze -disable-free -main-file-name small.c
-analyzer-store=region -analyzer-opt-analyze-nested-blocks -warn-dead-stores
-warn-security-syntactic -checker-cfref -analyzer-eagerly-assume
-warn-objc-methodsigs -warn-objc-unused-ivars -analyzer-output plist
-mrelocation-model static -mdisable-fp-elim -target-cpu pentium4 -resource-dir
/home/regehr/z/tmp/llvm-gcc-r93238-install/lib/clang/1.1 -fmessage-length 80
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o small.plist -x c
small.c 
1.      <eof> parser at end of file
2.      small.c:14:3: Error evaluating statement
3.      small.c:14:3: Error evaluating statement
4.      small.c:14:9: Error evaluating statement
clang: error: analyzer command failed due to signal 6 (use -v to see
invocation)
regehr at john-home:~/volatile/bugs/tmp258$ cat small.c
typedef unsigned char __uint8_t;
typedef unsigned int __uint32_t;
typedef __uint8_t uint8_t;
typedef __uint32_t uint32_t;
struct pcm_feeder
{
  void *data;
};
int
feed_swaplr (struct pcm_feeder *f, struct pcm *c, uint8_t * b, uint32_t count,
             void *source)
{
  int bps;
  bps = (long) f->data;
}
regehr at john-home:~/volatile/bugs/tmp258$ clang -v
clang version 1.1 (trunk 93238)
Target: i386-pc-linux-gnu
Thread model: posix


-- 
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 Jan 13 17:42:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 17:42:48 -0600
Subject: [LLVMbugs] [Bug 5406] Invalid call lowering on ARM
In-Reply-To: <bug-5406-206@http.llvm.org/bugs/>
Message-ID: <201001132342.o0DNgmKx027758@zion.cs.uiuc.edu>

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


Bob Wilson <bob.wilson at apple.com> changed:

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




--- Comment #12 from Bob Wilson <bob.wilson at apple.com>  2010-01-13 17:42:48 ---
After looking at what it would take to implement "byval", I figured out how to
fix up the previous patches to work correctly.  This should be fixed as of svn
r93368 (with some subsequent tidying in r93374).


-- 
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 Jan 13 17:59:04 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 17:59:04 -0600
Subject: [LLVMbugs] [Bug 6036] New: clang analyzer crash with signal 8
Message-ID: <bug-6036-206@http.llvm.org/bugs/>

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

           Summary: clang analyzer crash with signal 8
           Product: new-bugs
           Version: trunk
          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


Valgrind says it's a divide by zero.

regehr at john-home:~/volatile/bugs/tmp258$ clang --analyze small.c
small.c:6:20: warning: declaration of 'struct work' will not be visible outside
      of this function
u132monitk (struct work *work)
                   ^
small.c:8:68: warning: expression result unused [-Wunused-value]
  ((struct usb_hcd *) (unsigned long (*)[0]) ((char *) work - 1))->state;
  ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~  ^~~~~
0  clang 0x090ee918
Stack dump:
0.      Program arguments: /home/regehr/z/tmp/llvm-gcc-r93238-install/bin/clang
-cc1 -triple i386-pc-linux-gnu -analyze -disable-free -main-file-name small.c
-analyzer-store=region -analyzer-opt-analyze-nested-blocks -warn-dead-stores
-warn-security-syntactic -checker-cfref -analyzer-eagerly-assume
-warn-objc-methodsigs -warn-objc-unused-ivars -analyzer-output plist
-mrelocation-model static -mdisable-fp-elim -target-cpu pentium4 -resource-dir
/home/regehr/z/tmp/llvm-gcc-r93238-install/lib/clang/1.1 -fmessage-length 80
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o small.plist -x c
small.c 
1.      <eof> parser at end of file
2.      small.c:8:3: Error evaluating statement
3.      small.c:8:3: Error evaluating statement
4.      small.c:8:4: Error evaluating statement
5.      small.c:8:23: Error evaluating statement
clang: error: analyzer command failed due to signal 8 (use -v to see
invocation)
regehr at john-home:~/volatile/bugs/tmp258$ cat small.c
struct usb_hcd
{
  int state;
};
void
u132monitk (struct work *work)
{
  ((struct usb_hcd *) (unsigned long (*)[0]) ((char *) work - 1))->state;
}
regehr at john-home:~/volatile/bugs/tmp258$ clang -v
clang version 1.1 (trunk 93238)
Target: i386-pc-linux-gnu
Thread model: posix


-- 
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 Jan 13 21:46:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 21:46:09 -0600
Subject: [LLVMbugs] [Bug 6035] clang analyzer bug: Assertion
 `Loc::IsLocType(castTy)' failed.
In-Reply-To: <bug-6035-206@http.llvm.org/bugs/>
Message-ID: <201001140346.o0E3k9dn004391@zion.cs.uiuc.edu>

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


Zhongxing Xu <xuzhongxing at gmail.com> changed:

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




--- Comment #1 from Zhongxing Xu <xuzhongxing at gmail.com>  2010-01-13 21:46:09 ---
Fixed in r93422.


-- 
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 Jan 13 22:08:19 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 13 Jan 2010 22:08:19 -0600
Subject: [LLVMbugs] [Bug 6038] New: Fails to build libgomp
Message-ID: <bug-6038-206@http.llvm.org/bugs/>

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

           Summary: Fails to build libgomp
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Found this while trying to build llvm-gcc for arm to work on another bug :-(

$ llc test.ll  -march=arm
LLVM ERROR: Cannot yet select: 0x1eeb170: ch = ARMISD::MEMBARRIER 0x1eeacf0,
0x1eeb458
$ cat test.ll
define arm_aapcscc void @f() {
entry:
  tail call void @llvm.memory.barrier(i1 true, i1 true, i1 true, i1 true, i1
false)
  unreachable
}

declare void @llvm.memory.barrier(i1, i1, i1, i1, i1) 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  Thu Jan 14 04:55:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 04:55:29 -0600
Subject: [LLVMbugs] [Bug 6039] New: Fix compilation in mingw32
Message-ID: <bug-6039-206@http.llvm.org/bugs/>

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

           Summary: Fix compilation in mingw32
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: System Library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: diegoiast at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4047)
 --> (http://llvm.org/bugs/attachment.cgi?id=4047)
Compilationerror on mingw32

I had problems compiling trunk on win32 (trying to build clang), bootstraping
from mingw with gcc 4.3. See attached error.

The fix is also attached here, small fixes in
lib/System/Win32/DynamicLibrary.inc, inside a block #ifdef'ed __MINGW32__


-- 
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 Jan 14 10:58:35 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 10:58:35 -0600
Subject: [LLVMbugs] [Bug 6040] New: error: invalid redefinition of function
	'free'
Message-ID: <bug-6040-206@http.llvm.org/bugs/>

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

           Summary: error: invalid redefinition of function 'free'
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM assembly language parser
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


The following IR doesn't parse:

  define void @foo(i8* %x) {
    free i8* %x
    ret void
  }

  define void @free(i8*) nounwind {
    ret void
  }

but it would if you removed the call to free in @foo, or if you put @free
before @foo. The error is:

llvm-as: <stdin>:6:15: error: invalid redefinition of function 'free'
  define void @free(i8*) 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  Thu Jan 14 11:54:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 11:54:59 -0600
Subject: [LLVMbugs] [Bug 6040] error: invalid redefinition of function 'free'
In-Reply-To: <bug-6040-206@http.llvm.org/bugs/>
Message-ID: <201001141754.o0EHsx12018310@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-14 11:54:59 ---
free is not a valid IR instruction anymore, it is only preserved in the .ll
parser for backwards compatibility


-- 
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 Jan 14 14:20:03 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 14:20:03 -0600
Subject: [LLVMbugs] [Bug 6039] Fix compilation in mingw32
In-Reply-To: <bug-6039-206@http.llvm.org/bugs/>
Message-ID: <201001142020.o0EKK3vJ025213@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #2 from Anton Korobeynikov <asl at math.spbu.ru>  2010-01-14 14:20:02 ---
Applied in r93450, 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  Thu Jan 14 14:59:05 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 14:59:05 -0600
Subject: [LLVMbugs] [Bug 6041] New: Make bugzilla tickets visible to search
	engines
Message-ID: <bug-6041-206@http.llvm.org/bugs/>

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

           Summary: Make bugzilla tickets visible to search engines
           Product: Bugzilla Admin
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: UI
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm at henning-thielemann.de
                CC: llvmbugs at cs.uiuc.edu


It seems that tickets are not exposed to the outside world, such that it can be
indexed by a search engine.
Since I do not know whether my problem was discussed on a mailing list, in a
Bugzilla ticket, or anywhere else, I like to use my prefered web search engine
to scan all of them.


-- 
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 Jan 14 15:06:01 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 15:06:01 -0600
Subject: [LLVMbugs] [Bug 6042] New: Assembly Language Reference lacks 'exp'
 and 'log' and friends
Message-ID: <bug-6042-206@http.llvm.org/bugs/>

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

           Summary: Assembly Language Reference lacks 'exp' and 'log' and
                    friends
           Product: Documentation
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm at henning-thielemann.de
                CC: llvmbugs at cs.uiuc.edu


http://llvm.org/docs/LangRef.html
does not mention exponential and logarithm functions, although I find them in
/usr/include/llvm/Intrinsics.gen


-- 
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 Jan 14 15:13:58 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 15:13:58 -0600
Subject: [LLVMbugs] [Bug 6043] New: DSE misses easy optimization
Message-ID: <bug-6043-206@http.llvm.org/bugs/>

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

           Summary: DSE misses easy optimization
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4052)
 --> (http://llvm.org/bugs/attachment.cgi?id=4052)
Simple dse test

The attached test case has two i32 stores that should be eliminated pretty
easily.
Running it through opt -dse does nothing, though.

The code is generated by llvm-gcc from this union:

union {
  int64_t a;
  struct {
    int32_t x,y;
  };
};


-- 
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 Jan 14 15:15:41 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 15:15:41 -0600
Subject: [LLVMbugs] [Bug 6044] New: Horizontal SIMD functions
Message-ID: <bug-6044-206@http.llvm.org/bugs/>

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

           Summary: Horizontal SIMD functions
           Product: libraries
           Version: 2.5
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm at henning-thielemann.de
                CC: llvmbugs at cs.uiuc.edu


It would be nice to be able to use the horizontal add instruction of ix86
processors. E.g. HADDPD adds the two 'double' numbers of a SIMD register (and
does the same for another register, too). Currently I can only manually extract
the vector components with LLVM's extractelement instruction and add them,
which will be translated to ix86 assembly code this 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  Thu Jan 14 16:10:24 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 16:10:24 -0600
Subject: [LLVMbugs] [Bug 2608] The function to stub map in JITResolverState
 does not get updated when a function is released
In-Reply-To: <bug-2608-206@http.llvm.org/bugs/>
Message-ID: <201001142210.o0EMAOWx029783@zion.cs.uiuc.edu>

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


Damien <ddneff at hotmail.com> 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  Thu Jan 14 16:47:22 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 16:47:22 -0600
Subject: [LLVMbugs] [Bug 6041] Make bugzilla tickets visible to search
	engines
In-Reply-To: <bug-6041-206@http.llvm.org/bugs/>
Message-ID: <201001142247.o0EMlMPS031555@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-14 16:47:21 ---
We're not going to do this, because it puts too much load on the server. 
Bugzilla has a builtin search capability.


-- 
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 Jan 14 20:48:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 20:48:29 -0600
Subject: [LLVMbugs] [Bug 6046] New: make install DESTDIR=/ foo attempts to
 create symlink outside DESTDIR
Message-ID: <bug-6046-206@http.llvm.org/bugs/>

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

           Summary: make install DESTDIR=/foo attempts to create symlink
                    outside DESTDIR
           Product: Build scripts
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: cmake
        AssignedTo: ofv at wanadoo.es
        ReportedBy: ingmar at exherbo.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4055)
 --> (http://llvm.org/bugs/attachment.cgi?id=4055)
Respect DESTDIR when creating clang++ symlink

In Exherbo everything is built inside a sandbox (known as sydbox), which
doesn't allow writes outside of the build directory for security reasons.

Using CMake, make DESTDIR=/foo install attempts to create a symlink 
/usr/bin/clang++ rather than ${DESTDIR}/usr/bin/clang++:

sydbox at 1263522575: Access Violation!                                            
sydbox at 1263522575: Child Process ID: 3155                                       
sydbox at 1263522575: Child CWD:
/var/tmp/paludis/build/sys-devel-clang-scm/work/build/tools/clang               
sydbox at 1263522575: Last Exec: execve("/usr/bin/cmake", ["/usr/bin/cmake", "-E",
"create_symlink", "/usr/bin/clang", "/usr/bin/clang++"])                        
sydbox at 1263522575: Reason: symlink(?, "/usr/bin/clang++", ...)                  

Fairly sure the attached patch should work, but I can't test it atm.


-- 
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 Jan 14 21:47:53 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 14 Jan 2010 21:47:53 -0600
Subject: [LLVMbugs] [Bug 5814] msp430 backend: memory safety problem
In-Reply-To: <bug-5814-206@http.llvm.org/bugs/>
Message-ID: <201001150347.o0F3lrJP009257@zion.cs.uiuc.edu>

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


John Regehr <regehr at cs.utah.edu> changed:

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




-- 
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 Jan 15 01:28:43 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 01:28:43 -0600
Subject: [LLVMbugs] [Bug 6033] clang analyzer bug: Assertion
 `isdigit(*DiagStr) && " Invalid format for argument in diagnostic"' failed.
In-Reply-To: <bug-6033-206@http.llvm.org/bugs/>
Message-ID: <201001150728.o0F7ShlJ016363@zion.cs.uiuc.edu>

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


Ted Kremenek <kremenek at apple.com> changed:

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




--- Comment #2 from Ted Kremenek <kremenek at apple.com>  2010-01-15 01:28:43 ---
This looks like a transient crash.  It is no longer appearing for me in
top-of-tree. (r93505)

John: Are you still seeing this crash?


-- 
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 Jan 15 01:31:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 01:31:18 -0600
Subject: [LLVMbugs] [Bug 6033] clang analyzer bug: Assertion
 `isdigit(*DiagStr) && " Invalid format for argument in diagnostic"' failed.
In-Reply-To: <bug-6033-206@http.llvm.org/bugs/>
Message-ID: <201001150731.o0F7VIxf016558@zion.cs.uiuc.edu>

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


Ted Kremenek <kremenek at apple.com> changed:

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




-- 
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 Jan 15 01:57:28 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 01:57:28 -0600
Subject: [LLVMbugs] [Bug 6033] '%' character in static analyzer diagnostic
 causes assertion failure in FormatDiagnostics
In-Reply-To: <bug-6033-206@http.llvm.org/bugs/>
Message-ID: <201001150757.o0F7vSNC017551@zion.cs.uiuc.edu>

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


Ted Kremenek <kremenek at apple.com> changed:

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




--- Comment #5 from Ted Kremenek <kremenek at apple.com>  2010-01-15 01:57:27 ---
Fixed:

http://llvm.org/viewvc/llvm-project?view=rev&revision=93507


-- 
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 Jan 15 02:53:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 02:53:48 -0600
Subject: [LLVMbugs] [Bug 6047] New: Post-Dominator Tree Construction bug
Message-ID: <bug-6047-206@http.llvm.org/bugs/>

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

           Summary: Post-Dominator Tree Construction bug
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kuba at gcc.gnu.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4056)
 --> (http://llvm.org/bugs/attachment.cgi?id=4056)
test-case

$ opt -postdomtree j.ll -disable-output
0   opt               0x0042a288 PrintStackTrace(void*) + 40
1   opt               0x0042a9f9 SignalHandler(int) + 713
2   libSystem.B.dylib 0x95fce9bb _sigtramp + 43
3   libSystem.B.dylib 0xffffffff _sigtramp + 1778587247
4   opt               0x003bb9c5 void
llvm::DominatorTreeBase<llvm::BasicBlock>::recalculate<llvm::Function>(llvm::Function&)
+ 5717
5   opt               0x00294587
llvm::PostDominatorTree::runOnFunction(llvm::Function&) + 39
6   opt               0x003b479e
llvm::FPPassManager::runOnFunction(llvm::Function&) + 382
7   opt               0x003b4c77
llvm::FPPassManager::runOnModule(llvm::Module&) + 167
8   opt               0x003b1f43
llvm::MPPassManager::runOnModule(llvm::Module&) + 803
9   opt               0x003b250c llvm::PassManagerImpl::run(llvm::Module&) +
156
10  opt               0x003b260b llvm::PassManager::run(llvm::Module&) + 27
11  opt               0x0003f946 main + 2582
12  opt               0x00036e79 start + 53
13  opt               0x00000003 start + 4294742463
Stack dump:
0.      Running pass 'Function Pass Manager' on module 'j.bc'.
1.      Running pass 'Post-Dominator Tree Construction' on function '@f'


-- 
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 Jan 15 05:30:37 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 05:30:37 -0600
Subject: [LLVMbugs] [Bug 6028] APInt assertion failure in interpreter
In-Reply-To: <bug-6028-206@http.llvm.org/bugs/>
Message-ID: <201001151130.o0FBUbS1008733@zion.cs.uiuc.edu>

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


Jay Foad <jay.foad at antixlabs.com> changed:

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




--- Comment #4 from Jay Foad <jay.foad at antixlabs.com>  2010-01-15 05:30:36 ---
Test case committed here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100111/094277.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 Jan 15 07:18:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 07:18:59 -0600
Subject: [LLVMbugs] [Bug 6048] New: ms crt8 64bit release misses
 _byteswap_ushort and friends
Message-ID: <bug-6048-206@http.llvm.org/bugs/>

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

           Summary: ms crt8 64bit release misses _byteswap_ushort and
                    friends
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sherpya at gmail.com
                CC: llvmbugs at cs.uiuc.edu


as I see in include/llvm/Support/MathExtras.h

there is a note about
_byteswap_ulong
_byteswap_ushort
_byteswap_uint64

but on win64 release (vc 2005 - crt 8)

the compiler is not even unable to parse the ms header (broken?)

why not use at all provided functions in MathExtras.h?

I'm compiling clamav llvm backend

did I misconfigured something?

Regards


-- 
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 Jan 15 13:18:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 13:18:46 -0600
Subject: [LLVMbugs] [Bug 5979] msp430 backend: incorrect conditional jump
In-Reply-To: <bug-5979-206@http.llvm.org/bugs/>
Message-ID: <201001151918.o0FJIk8Q027287@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #3 from Anton Korobeynikov <asl at math.spbu.ru>  2010-01-15 13:18:45 ---
(In reply to comment #2)
> Anton appears to have fixed this in r93496.  The problem was that MSP430 cmp
> had its arguments reversed.
> (I'm not sure why it's eating another register now.)
It's eating the register since imm can be only source operand. We need to
transform such cmp into

cmp #100, 0(r12)
jge <>

I did this yesterday, but haven't committed the patch 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  Fri Jan 15 15:52:00 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 15:52:00 -0600
Subject: [LLVMbugs] [Bug 6050] New: floating-point operations have side
	effects
Message-ID: <bug-6050-206@http.llvm.org/bugs/>

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

           Summary: floating-point operations have side effects
           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


Floating-point instructions, such as add, sub, mul, and div, as well as math
library functions in -fno-math-errno mode, are considered to have no side
effects in LLVM.  This is incorrect; they may set floating-point exception
flags, and they may trap if the processor is configured to trap on
floating-point exceptions.

As a consequence of this, these side effects may be reordered or eliminated by
the optimizer and codegen.


-- 
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 Jan 15 17:24:20 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 17:24:20 -0600
Subject: [LLVMbugs] [Bug 6019] LLVM Creates a Cyclic SelectionDAG
In-Reply-To: <bug-6019-206@http.llvm.org/bugs/>
Message-ID: <201001152324.o0FNOKsG004883@zion.cs.uiuc.edu>

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


David Greene <greened at obbligato.org> changed:

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




--- Comment #10 from David Greene <greened at obbligato.org>  2010-01-15 17:24:20 ---
r93576 fixes 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 bugzilla-daemon at cs.uiuc.edu  Fri Jan 15 17:32:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 17:32:29 -0600
Subject: [LLVMbugs] [Bug 6052] New: DIDescriptor (etc) constructors don't
 take const arguments
Message-ID: <bug-6052-206@http.llvm.org/bugs/>

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

           Summary: DIDescriptor (etc) constructors don't take const
                    arguments
           Product: new-bugs
           Version: trunk
          Platform: All
        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 constructors for DIDescriptor and its derived classes do not accept const
MDNode* arguments.  They should, and much existing code should make use of
them.


-- 
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 Jan 15 17:50:16 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 15 Jan 2010 17:50:16 -0600
Subject: [LLVMbugs] [Bug 5992] OCAML binding;
	llvm_create_module uses wrong parameters
In-Reply-To: <bug-5992-206@http.llvm.org/bugs/>
Message-ID: <201001152350.o0FNoGka005853@zion.cs.uiuc.edu>

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


Erick Tryzelaar <idadesub at users.sourceforge.net> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |idadesub at users.sourceforge.n
                   |                            |et
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Erick Tryzelaar <idadesub at users.sourceforge.net>  2010-01-15 17:50:16 ---
Thanks for catching this! Fixed in r93588.


-- 
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 Jan 16 03:14:49 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jan 2010 03:14:49 -0600
Subject: [LLVMbugs] [Bug 6054] New: Virtual methods de-virtualization
Message-ID: <bug-6054-206@http.llvm.org/bugs/>

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

           Summary: Virtual methods de-virtualization
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Keywords: code-quality, new-feature
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bearophile at mailas.com
                CC: llvmbugs at cs.uiuc.edu


A good way to spot places where a compiler can be improved is to compare the
runtime of a compiled program with different compilers. This must be done with
care to be sure to compare apples with apples if the two compilers are very
different.

This small program stresses virtual method calls. I have compared a small C++
program compiled with llvm-g++ with a similar Java program JIT-compiled with
Java HotSpot.

The program creates a binary tree with 932465 nodes, and then scans it 600
times computing the sum of the values stored in the leaves, and increments such
leave values each time. The tree contains two different kinds of nodes,
internal ones and leaves, so the walking on the tree is done with a virtual
function (the same problem can be solved in other ways, using tagged structs or
tagged struct pointers, but such ways are quite bug-prone and require a good
amount of time to be implemented, so in most situations it's much better if the
compiler is able to optimize things better). Here de-virtualizing the two
virtual calls probably leads to a performance improvement.

I have used a little portable random number generator to create the same trees
in both C++ and Java.


Code compiled with:

LLVM 2.6 gcc version 4.2.1 (Based on Apple Inc. build 5649) (LLVM build)

Java build 1.7.0-ea-b76

llvm-g++ -Wall -O3 -s -Wl,--enable-stdcall-fixup -fomit-frame-pointer
-march=native -ffast-math

java -server SumTree

CPU: Celeron 2.33 GHz, on Windows Vista 32 bit

As you can see from the timings it's not a matter of GC and memory allocations,
the building phase in the C++ is actually faster:

Timings, just tree building, best of 3, seconds:
  C++:   0.17
  Java:  0.55

Timings full program, best of 3, seconds:
  C++:  12.47
  Java:  7.90

--------------------------------------------

Asm of Internal.walkSum produced by llvm-g++:

    pushl   %edi
    pushl   %esi
    subl    $4, %esp
    movl    16(%esp), %esi
    movl    4(%esi), %eax
    testl   %eax, %eax
    je  LBB2_5
    movl    (%eax), %ecx
    movl    %eax, (%esp)
    call    *(%ecx)
LBB2_2:
    movl    %eax, %edi
    movl    8(%esi), %eax
    testl   %eax, %eax
    je  LBB2_6
    movl    (%eax), %ecx
    movl    %eax, (%esp)
    call    *(%ecx)
LBB2_4:
    addl    %edi, %eax
    addl    $4, %esp
    popl    %esi
    popl    %edi
    ret
LBB2_5:
    xorl    %eax, %eax
    jmp LBB2_2
LBB2_6:
    xorl    %eax, %eax
    jmp LBB2_4

--------------------------------------------

In attach you can find the asm produced by the JVM too, but it's not easy to
read.

Asm of Internal.walkSum from the Java version.
time java -XX:+PrintOptoAssembly -server SumTree
JVM build 1.7.0-ea-fastdebug-b76


-- 
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 Jan 16 07:45:00 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jan 2010 07:45:00 -0600
Subject: [LLVMbugs] [Bug 6047] Post-Dominator Tree Construction bug
In-Reply-To: <bug-6047-206@http.llvm.org/bugs/>
Message-ID: <201001161345.o0GDj0pN016990@zion.cs.uiuc.edu>

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


Tobias Grosser <grosser at fim.uni-passau.de> changed:

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




--- Comment #7 from Tobias Grosser <grosser at fim.uni-passau.de>  2010-01-16 07:44:59 ---
And mark it as 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  Sat Jan 16 08:07:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jan 2010 08:07:29 -0600
Subject: [LLVMbugs] [Bug 4957] find-cycles.pl incompatible with MinGW headers
In-Reply-To: <bug-4957-206@http.llvm.org/bugs/>
Message-ID: <201001161407.o0GE7TDh017861@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

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




--- Comment #11 from Anton Korobeynikov <asl at math.spbu.ru>  2010-01-16 08:07:28 ---
Fixed in r93635


-- 
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 Jan 16 11:21:30 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jan 2010 11:21:30 -0600
Subject: [LLVMbugs] [Bug 6058] New: self-build crash on IsInf.cpp
Message-ID: <bug-6058-206@http.llvm.org/bugs/>

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

           Summary: self-build crash on IsInf.cpp
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I could only reproduce this on Mac OS X and trying to reduce with --emit-llvm
and llc did not cause this crash either.

clang version 1.1 (trunk 93639)
Target: x86_64-apple-darwin10

llvm[1]: Compiling IsInf.cpp for Debug build
0  clang             0x0000000100eab792 PrintStackTrace(void*) + 34
1  clang             0x0000000100eac01c SignalHandler(int) + 652
2  libSystem.B.dylib 0x00007fff87253eaa _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2027602288
4  clang             0x0000000100884217
llvm::FastISel::SelectOperator(llvm::User*, unsigned int) + 551
5  clang             0x0000000100885cb2
llvm::FastISel::SelectInstruction(llvm::Instruction*) + 34
6  clang             0x00000001009f9d7d
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&,
llvm::MachineFunction&, llvm::MachineModuleInfo*, llvm::DwarfWriter*,
llvm::TargetInstrInfo const&) + 1005
7  clang             0x00000001009faedd
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1341
8  clang             0x0000000100ad28bb
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 43
9  clang             0x0000000100e3afcb
llvm::FPPassManager::runOnFunction(llvm::Function&) + 475
10 clang             0x0000000100e3b20b
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 139
11 clang             0x0000000100e3b42e
llvm::FunctionPassManager::run(llvm::Function&) + 78
12 clang             0x0000000100030c85 (anonymous
namespace)::BackendConsumer::EmitAssembly() + 645
13 clang             0x00000001000312b1 (anonymous
namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 129
14 clang             0x0000000100338d73 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 387
15 clang             0x0000000100038959
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393
16 clang             0x000000010001d5b0 cc1_main(char const**, char const**,
char const*, void*) + 2000
17 clang             0x000000010001fda4 main + 2052
18 clang             0x000000010001b318 start + 52
Stack dump:
0.      Program arguments: /Users/pwo/src/llvm-obj/Release/bin/clang -cc1
-triple x86_64-apple-darwin10.0 -S -disable-free -main-file-name IsInf.cpp
-pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -g
-resource-dir /Users/pwo/src/llvm-obj/Release/lib/clang/1.1 -dependency-file
/Users/pwo/src/llvm-selfhost/lib/Support/Debug/IsInf.d.tmp -MP -MT
/Users/pwo/src/llvm-selfhost/lib/Support/Debug/IsInf.o -MT
/Users/pwo/src/llvm-selfhost/lib/Support/Debug/IsInf.d -D_DEBUG -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-I/Users/pwo/src/llvm-selfhost/include
-I/Users/pwo/src/llvm-selfhost/lib/Support -I/Users/pwo/src/llvm/include
-I/Users/pwo/src/llvm/lib/Support -Woverloaded-virtual -Wno-long-long -Wall -W
-Wno-unused-parameter -Wwrite-strings -pedantic -fmessage-length 80
-stack-protector 1 -fblocks -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/HV/HVYbz+scFaWJdUHdYZJeAE+++TM/-Tmp-/cc-MOpqMj.s -x c++
/Users/pwo/src/llvm/lib/Support/IsInf.cpp 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@_ZN4llvm5IsInfEf'
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)


-- 
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 Jan 16 11:29:26 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jan 2010 11:29:26 -0600
Subject: [LLVMbugs] [Bug 6054] Virtual methods de-virtualization
In-Reply-To: <bug-6054-206@http.llvm.org/bugs/>
Message-ID: <201001161729.o0GHTQDE025041@zion.cs.uiuc.edu>

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


Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |nlewycky at google.com,
                   |                            |nicholas at mxc.ca
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #4 from Nick Lewycky <nicholas at mxc.ca>  2010-01-16 11:29:24 ---
Yup. I've been looking into on the stuff needed to make devirt happen for over
a year now... let me give you a summary:

The 'noalias' attribute on function return. We need to know that the pointer
returned by malloc() or _Znwj (operator new) is a new pointer and not one to an
existing object. Clang defaults to -fassume-sane-operator-new which marks
global operator new with this attribute.

The 'nocapture' attribute on pointer arguments. In C++, every method receives a
pointer to 'this', and if that pointer is written elsewhere in memory then its
type could be manipulated by functions that otherwise seem to have no
connection to the object.

With those two combined, we can (for example) receive FILE* from fopen, and
pass it in to fread/fseek/fwrite then fclose, knowing that the pointer never
aliases anything else at any time, not even an inttoptr instruction. LLVM's
-functionattrs pass will calculate both 'noalias' and 'nocapture' and propagate
them through the call graph.

The 'available_externally' linkage is used to expose the contents of a global
to the optimizers without causing it to be emitted anywhere. In our case, we
use this for the vtables. So far, clang isn't emitting vtables in all the cases
we need it to.

The final piece of the puzzle is an interprocedural field-sensitive constant
propagation pass. It would start at the point of allocation and follow writes
of constants to the fields of the structure and propagate that value out to
replace loads of that field. The goal is to replace the 'load the vtable from
the object's vptr' operation of a virtual method call with the target vtable
constant, and from there LLVM will optimize away the load of fptr and replace
the indirect call with a direct one.


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


-- 
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 Jan 16 13:37:28 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jan 2010 13:37:28 -0600
Subject: [LLVMbugs] [Bug 6059] New: Insuficent allignment on call on ARM
Message-ID: <bug-6059-206@http.llvm.org/bugs/>

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

           Summary: Insuficent allignment on call on ARM
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The code
-----------------------
#include <stdio.h>

typedef struct QuadWordS_struct { int i; double d; } QuadWordS;

void test(int a, QuadWordS qw);

int main() {
  QuadWordS qw = { 19, 0.0 };
  test(0, qw);
  return 0;
}
-----------------------

gets compiled to

------------------------
target datalayout =
"e-p:32:32:32-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-n32"
target triple = "armv5-none-linux-gnueabi"

%struct.QuadWordS = type { i32, double }

define arm_aapcscc i32 @main() nounwind optsize {
entry:
  tail call arm_aapcscc  void @test(i32 0, i32 19, i32 0, i32 0, i32 0)
nounwind
  ret i32 0
}

declare arm_aapcscc void @test(i32, i32, i32, i32, i32)
------------------------

The problem is that the struct requires 64 bit alignment. The correct lowering
of the call is

tail call arm_aapcscc  void @test(i32 0, i32 0, i32 19, i32 0, i32 0, i32 0)
nounwind

and "test" should be declared as

declare arm_aapcscc void @test(i32, i32, i32, i32, i32, i32)


-- 
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 Jan 16 13:39:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jan 2010 13:39:48 -0600
Subject: [LLVMbugs] [Bug 6060] New: Crash in 2D VLA arrays in function
	arguments
Message-ID: <bug-6060-206@http.llvm.org/bugs/>

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

           Summary: Crash in 2D VLA arrays in function arguments
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: cianci66 at mac.com
                CC: llvmbugs at cs.uiuc.edu


The following code causes clang to crash.

void foo(int i, int j, double array[i][j]) {
}

void bar() {
    int i = 3, j = 2;
    double array[i][j];

    foo(i, j, array);
}

Clang produces

$ clang -v -c test.c
clang version 1.1 (trunk 93629)
Target: x86_64-apple-darwin10
Thread model: posix
 "/Users/mark/Programs/llvm/Release/bin/clang" -cc1 -triple
x86_64-apple-darwin10.0 -S -disable-free -main-file-name test.c -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -v -resource-dir
/Users/mark/Programs/llvm/Release/lib/clang/1.1 -fmessage-length 80
-stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/0W/0W0L1R9dEpmv7Y1akDNFUk+++TI/-Tmp-/cc-W4R0N3.s -x c test.c
clang -cc1 version 1.1 based upon llvm 2.7svn hosted on x86_64-apple-darwin10
#include "..." search starts here:
#include <...> search starts here:
 /Users/mark/Programs/llvm/Release/lib/clang/1.1/include
 /usr/local/include
 /usr/include
 /System/Library/Frameworks (framework directory)
 /Library/Frameworks (framework directory)
End of search list.
Assertion failed: (V && "DeclRefExpr not entered in LocalDeclMap?"), function
EmitDeclRefLValue, file CGExpr.cpp, line 1048.
0  clang             0x00000001012c5622 PrintStackTrace(void*) + 34
1  clang             0x00000001012c5eac SignalHandler(int) + 652
2  libSystem.B.dylib 0x00007fff80d3deaa _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2133598576
4  libSystem.B.dylib 0x00007fff80db9e74 __pthread_markcancel + 0
5  clang             0x000000010019a15f
clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(clang::DeclRefExpr const*) +
3551
6  clang             0x000000010019f245
clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) + 469
7  clang             0x00000001001a2f56
clang::CodeGen::CodeGenFunction::EmitCheckedLValue(clang::Expr const*) + 38
8  clang             0x00000001001bd904 (anonymous
namespace)::ScalarExprEmitter::EmitLoadOfLValue(clang::Expr const*) + 36
9  clang             0x00000001001c6d02 clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 5570
10 clang             0x00000001001c7269
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 121
11 clang             0x000000010022f3e5
clang::CodeGen::CodeGenFunction::EmitVLASize(clang::QualType) + 885
12 clang             0x000000010022f1a0
clang::CodeGen::CodeGenFunction::EmitVLASize(clang::QualType) + 304
13 clang             0x00000001001c70ff clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 6591
14 clang             0x00000001001c7269
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 121
15 clang             0x0000000100194882
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, llvm::Value*,
bool, bool, bool) + 82
16 clang             0x00000001001949c5
clang::CodeGen::CodeGenFunction::EmitAnyExprToTemp(clang::Expr const*, bool,
bool) + 85
17 clang             0x0000000100168db7
clang::CodeGen::CodeGenFunction::EmitCallArg(clang::Expr const*,
clang::QualType) + 87
18 clang             0x00000001001a3c3b void
clang::CodeGen::CodeGenFunction::EmitCallArgs<clang::FunctionProtoType>(llvm::SmallVector<std::pair<clang::CodeGen::RValue,
clang::QualType>, 16u>&, clang::FunctionProtoType const*,
clang::ConstExprIterator, clang::ConstExprIterator) + 427
19 clang             0x0000000100194c26
clang::CodeGen::CodeGenFunction::EmitCall(clang::QualType, llvm::Value*,
clang::CodeGen::ReturnValueSlot, clang::ConstExprIterator,
clang::ConstExprIterator, clang::Decl const*) + 470
20 clang             0x0000000100198c64
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 564
21 clang             0x00000001001c6c00 clang::StmtVisitor<(anonymous
namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) + 5312
22 clang             0x00000001001c7269
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 121
23 clang             0x0000000100194882
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*, llvm::Value*,
bool, bool, bool) + 82
24 clang             0x00000001002180c6
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 294
25 clang             0x000000010021abdb
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, llvm::Value*, bool) + 267
26 clang             0x000000010021af07
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 231
27 clang             0x0000000100217fd0
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48
28 clang             0x00000001002322f5
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 1989
29 clang             0x000000010023c4db
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl)
+ 1067
30 clang             0x000000010023cc0b
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 587
31 clang             0x000000010023ceac
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 396
32 clang             0x000000010023d4e2
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 290
33 clang             0x000000010024d51c (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 60
34 clang             0x0000000100048a2e (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 158
35 clang             0x0000000100351835 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 277
36 clang             0x0000000100052009
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393
37 clang             0x0000000100036bd0 cc1_main(char const**, char const**,
char const*, void*) + 2032
38 clang             0x0000000100039464 main + 2052
39 clang             0x0000000100034918 start + 52
Stack dump:
0.      Program arguments: /Users/mark/Programs/llvm/Release/bin/clang -cc1
-triple x86_64-apple-darwin10.0 -S -disable-free -main-file-name test.c
-pic-level 1 -mdisable-fp-elim -munwind-tables -target-cpu core2 -v
-resource-dir /Users/mark/Programs/llvm/Release/lib/clang/1.1 -fmessage-length
80 -stack-protector 1 -fblocks -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/0W/0W0L1R9dEpmv7Y1akDNFUk+++TI/-Tmp-/cc-W4R0N3.s -x c test.c 
1.      <eof> parser at end of file
2.      test.c:4:6: LLVM IR generation of declaration 'bar'
3.      test.c:4:6: Generating code for declaration 'bar'
4.      test.c:4:12: LLVM IR generation of compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


-- 
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 Jan 16 15:35:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 16 Jan 2010 15:35:21 -0600
Subject: [LLVMbugs] [Bug 4957] find-cycles.pl incompatible with MinGW headers
In-Reply-To: <bug-4957-206@http.llvm.org/bugs/>
Message-ID: <201001162135.o0GLZLR3001940@zion.cs.uiuc.edu>

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


Gianluigi Tiesi <sherpya at gmail.com> changed:

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




--- Comment #12 from Gianluigi Tiesi <sherpya at gmail.com>  2010-01-16 15:35:21 ---
hmm I've rebuilt it, and problem still persist

even add -D__NO_CTYPE_INLINE in toplevel Makefile.rules
on CPP.BaseFlags.

There is a way to known what is the function(s)?

find-cycles.pl: Circular dependency between *.a files:
find-cycles.pl:   libLLVMCore.a libLLVMMC.a libLLVMSupport.a libLLVMTarget.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  Sun Jan 17 00:37:45 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 17 Jan 2010 00:37:45 -0600
Subject: [LLVMbugs] [Bug 6065] New: ARM JIT should support
 ARMCompilationCallback in thumb2
Message-ID: <bug-6065-206@http.llvm.org/bugs/>

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

           Summary: ARM JIT should support ARMCompilationCallback in thumb2
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


This inline-asm in ARMJITInfo.cpp's ARMCompilationCallback:

    // Return to the (newly modified) stub to invoke the real function.
    // The above twiddling of the saved return addresses allows us to
    // deallocate everything, including the LR the stub saved, all in one
    // pop instruction.
    "ldmia  sp!, {r0, r1, r2, r3, lr, pc}\n"

does not assemble as thumb2:

llvm[3]: Compiling ARMJITInfo.cpp for Release-Asserts build
/tmp/ccWGkQ6d.s: Assembler messages:
/tmp/ccWGkQ6d.s:28: Error: LR and PC should not both be in register list --
`ldmia sp!,{r0,r1,r2,r3,lr,pc}'
make[3]: *** [/home/nlewycky/llvm/lib/Target/ARM/Release-Asserts/ARMJITInfo.o]
Error 1

with '-Os -mthumb' flags to gcc instead of -O2.


-- 
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 Jan 17 15:12:45 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 17 Jan 2010 15:12:45 -0600
Subject: [LLVMbugs] [Bug 6067] New: undefined reference in generating native
 Linux x86-32 code
Message-ID: <bug-6067-206@http.llvm.org/bugs/>

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

           Summary: undefined reference in generating native Linux x86-32
                    code
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stein at ir.iit.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4068)
 --> (http://llvm.org/bugs/attachment.cgi?id=4068)
Test case

Attached is the BitCode from a simple test program I have.
The program is essentially:
  for(i=10; i>0; i--) {printf("%d\n", i);}

Using the head version of LLVM, if I do
  lli bad.bc
it works properly.
However, I tried it on Linux x86-32, and it fails to assemble
the generated .s file with:
  bad.bc:(.text+0x17): undefined reference to `__unnamed_0'

With a slightly older version of LLVM, I got an invalid
optimization that caused it to segfault right away.
However, it worked properly with optimizations turned off.


-- 
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 Jan 17 17:01:43 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 17 Jan 2010 17:01:43 -0600
Subject: [LLVMbugs] [Bug 6068] New: clang crashes on the attached test cast,
 in fast-isel
Message-ID: <bug-6068-206@http.llvm.org/bugs/>

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

           Summary: clang crashes on the attached test cast, in fast-isel
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4069)
 --> (http://llvm.org/bugs/attachment.cgi?id=4069)
test

This is a file from compiler-rt.
--
$ ddunbar at giles:tmp$ clang -m32 -g t.i
0  clang             0x000000010128ba9b PrintStackTrace(void*) + 38
1  clang             0x000000010128c029 SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff82f1feaa _sigtramp + 26
3  libSystem.B.dylib 0x0000003f0005c870 _sigtramp + 2098448864
4  clang             0x00000001010c3645 bool llvm::isa_impl<llvm::Instruction,
llvm::Value>(llvm::Value const&) + 21
5  clang             0x0000000100e01509 llvm::isa_impl_wrap<llvm::Instruction,
llvm::Value const, llvm::Value const>::doit(llvm::Value const&) + 21
6  clang             0x00000001010c385d bool
llvm::isa_impl_cl<llvm::Value>::isa<llvm::Instruction>(llvm::Value const&) + 21
7  clang             0x0000000100f9f269 bool llvm::isa_impl_cl<llvm::Value
const>::isa<llvm::Instruction>(llvm::Value const&) + 21
8  clang             0x00000001010c3879 bool llvm::isa_impl_cl<llvm::Value
const*>::isa<llvm::Instruction>(llvm::Value const*) + 21
9  clang             0x0000000100f9f288 bool llvm::isa<llvm::Instruction,
llvm::Value const*>(llvm::Value const* const&) + 24
10 clang             0x00000001010c38c5 llvm::AllocaInst::classof(llvm::Value
const*) + 21
11 clang             0x00000001010c3909 bool llvm::isa_impl<llvm::AllocaInst,
llvm::Value>(llvm::Value const&) + 21
12 clang             0x0000000100aeedc1 llvm::isa_impl_wrap<llvm::AllocaInst,
llvm::Value const, llvm::Value const>::doit(llvm::Value const&) + 21
13 clang             0x00000001010c3925 bool
llvm::isa_impl_cl<llvm::Value>::isa<llvm::AllocaInst>(llvm::Value const&) + 21
14 clang             0x0000000100aeeddd bool
llvm::isa_impl_cl<llvm::Value*>::isa<llvm::AllocaInst>(llvm::Value*) + 21
15 clang             0x0000000100d1abd8 bool llvm::isa<llvm::AllocaInst,
llvm::Value*>(llvm::Value* const&) + 24
16 clang             0x0000000100e04eed llvm::cast_retty<llvm::AllocaInst,
llvm::Value*>::ret_type llvm::dyn_cast<llvm::AllocaInst,
llvm::Value*>(llvm::Value* const&) + 21
17 clang             0x0000000100d19126 llvm::FastISel::SelectCall(llvm::User*)
+ 292
18 clang             0x0000000100d1a438
llvm::FastISel::SelectOperator(llvm::User*, unsigned int) + 1130
19 clang             0x0000000100d1a66e
llvm::FastISel::SelectInstruction(llvm::Instruction*) + 40
20 clang             0x0000000100e13afa
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&,
llvm::MachineFunction&, llvm::MachineModuleInfo*, llvm::DwarfWriter*,
llvm::TargetInstrInfo const&) + 1744
21 clang             0x0000000100e14c23
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 969
22 clang             0x0000000100ed1e45
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 83
23 clang             0x000000010120fbbe
llvm::FPPassManager::runOnFunction(llvm::Function&) + 336
24 clang             0x00000001012118b9
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 79
25 clang             0x0000000101211a68
llvm::FunctionPassManager::run(llvm::Function&) + 112
26 clang             0x000000010003dc12 (anonymous
namespace)::BackendConsumer::EmitAssembly() + 682
27 clang             0x000000010003dce1 (anonymous
namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 145
28 clang             0x000000010030e398 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 776
29 clang             0x000000010005ef1a
clang::ASTFrontendAction::ExecuteAction() + 256
30 clang             0x000000010005f00a clang::FrontendAction::Execute() + 226
31 clang             0x0000000100044554
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
32 clang             0x0000000100025abd cc1_main(char const**, char const**,
char const*, void*) + 1273
33 clang             0x0000000100028f5a main + 252
34 clang             0x0000000100024b88 start + 52
35 clang             0x000000000000001b start + 4294816967
Stack dump:
0.      Program arguments:
/Volumes/Data/Users/ddunbar/llvm.obj.64/Debug/bin/clang -cc1 -triple
i386-apple-darwin10.0 -S -disable-free -main-file-name t.i -pic-level 1
-mdisable-fp-elim -target-cpu yonah -g -resource-dir
/Volumes/Data/Users/ddunbar/llvm.obj.64/Debug/lib/clang/1.1 -fmessage-length 88
-stack-protector 1 -fblocks -fdiagnostics-show-option -o
/var/folders/DQ/DQ8GT3++HESEzT1obWBynE+++TI/-Tmp-/cc-oy0gny.s -x cpp-output t.i 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@__divdc3'
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)
ddunbar at giles: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  Sun Jan 17 20:48:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 17 Jan 2010 20:48:29 -0600
Subject: [LLVMbugs] [Bug 6070] New: Verifier accetps alloca with i64 count
 when the asm defines it with a i32 (error when using llvm-as)
Message-ID: <bug-6070-206@http.llvm.org/bugs/>

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

           Summary: Verifier accetps alloca with i64 count when the asm
                    defines it with a i32 (error when using llvm-as)
           Product: libraries
           Version: 2.6
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: aelia at internux.ch
                CC: llvmbugs at cs.uiuc.edu


I just randomly found out that if I call
IRBuilder::CreateAlloca(Type::getInt32Ty(llvm::getGlobalContext()),
ConstantInt::get(llvm::Type::getInt64Ty(llvm::getGlobalContext(), 1),
"wrongalloca")

the resulting IR is invalid :
%wrongalloca = alloca i32, i64 1  ; <i32*>

of course it would be nothing if the verifier refused it... but it accepts.


-- 
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 Jan 18 00:51:38 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 00:51:38 -0600
Subject: [LLVMbugs] [Bug 5428] Get rid of darwin'isms in the build system
In-Reply-To: <bug-5428-206@http.llvm.org/bugs/>
Message-ID: <201001180651.o0I6pcGt021078@zion.cs.uiuc.edu>

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


Daniel Dunbar <daniel at zuster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at zuster.org
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #3 from Daniel Dunbar <daniel at zuster.org>  2010-01-18 00:51:38 ---
Fixed in a chain of commits ending at:
http://llvm.org/viewvc/llvm-project?view=rev&revision=93720

We still need better testing support, I plan to litify it at some point.


-- 
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 Jan 18 00:52:37 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 00:52:37 -0600
Subject: [LLVMbugs] [Bug 5429] Library should be configurable
In-Reply-To: <bug-5429-206@http.llvm.org/bugs/>
Message-ID: <201001180652.o0I6qbbi021137@zion.cs.uiuc.edu>

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


Daniel Dunbar <daniel at zuster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at zuster.org
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Daniel Dunbar <daniel at zuster.org>  2010-01-18 00:52:37 ---
Fixed in a chain of commits ending at:
http://llvm.org/viewvc/llvm-project?view=rev&revision=93720


-- 
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 Jan 18 05:04:16 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 05:04:16 -0600
Subject: [LLVMbugs] [Bug 6071] New: MIPS backend error,
 missing argument passing in generated code
Message-ID: <bug-6071-206@http.llvm.org/bugs/>

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

           Summary: MIPS backend error, missing argument passing in
                    generated code
           Product: libraries
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Archive library
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ihusar at fit.vutbr.cz
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4071)
 --> (http://llvm.org/bugs/attachment.cgi?id=4071)
C code

Please, assign this to the the correct component, in the backends in bugzilla,
there is no MIPS present.
For C code from some benchmark that calculates CRC compiled with web-site demo
frontend with no optimizations and then with llc -march=mips, incorrect code is
generated. (llvm v. 2.6).

Call in C code (crc.c):

crc = crc32buf(buf, 4);

is translated correctly to IR:

%1 = call i32 @crc32buf(i32* getelementptr ([4 x i32]* @buf, i32 0, i32 0), i32
4) nounwind         

but then the MIPS backend generates following code:

main:
        .frame  $sp,48,$ra
        .mask   0x80000000,-8
        .fmask  0x00000000,0

        .set    noreorder
        .cpload $25
        .set    nomacro
        addiu   $sp, $sp, -48
        sw      $ra, 40($sp)
        .cprestore      16

        sw      $4, 20($sp)
        sw      $5, 24($sp)
        sw      $zero, 32($sp)
        lw      $4, %got(buf)($gp)
        nop
        lw      $25, %call16(crc32buf)($gp)
        nop
        jalr    $25 #call - buf poiter is in $4, value 4 should be in $5, but 
                    #this assignement was not made
        nop
         ...


-- 
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 Jan 18 06:55:40 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 06:55:40 -0600
Subject: [LLVMbugs] [Bug 6068] clang crashes on the attached test cast,
	in fast-isel
In-Reply-To: <bug-6068-206@http.llvm.org/bugs/>
Message-ID: <201001181255.o0ICteAn017422@zion.cs.uiuc.edu>

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


Benjamin Kramer <benny.kra at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |benny.kra at gmail.com
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com>  2010-01-18 06:55:39 ---


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


-- 
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 Jan 18 08:40:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 08:40:29 -0600
Subject: [LLVMbugs] [Bug 6067] undefined reference in generating native
 Linux x86-32 code
In-Reply-To: <bug-6067-206@http.llvm.org/bugs/>
Message-ID: <201001181440.o0IEeTvY021735@zion.cs.uiuc.edu>

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


Benjamin Kramer <benny.kra at gmail.com> changed:

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




--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com>  2010-01-18 08:40:28 ---
Fixed in r93724.

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100118/094479.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 Jan 18 12:28:51 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 12:28:51 -0600
Subject: [LLVMbugs] [Bug 6046] make install DESTDIR=/ foo attempts to create
 symlink outside DESTDIR
In-Reply-To: <bug-6046-206@http.llvm.org/bugs/>
Message-ID: <201001181828.o0IISpse029692@zion.cs.uiuc.edu>

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


Douglas Gregor <dgregor at apple.com> changed:

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




--- Comment #4 from Douglas Gregor <dgregor at apple.com>  2010-01-18 12:28:50 ---
Fixed here:

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

With a slight tweak to the patch itself.


-- 
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 Jan 18 13:41:02 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 13:41:02 -0600
Subject: [LLVMbugs] [Bug 6074] New: Invalid optimization on x86-32
Message-ID: <bug-6074-206@http.llvm.org/bugs/>

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

           Summary: Invalid optimization on x86-32
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stein at ir.iit.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4074)
 --> (http://llvm.org/bugs/attachment.cgi?id=4074)
Original BitCode

Attached is the BitCode from a simple test program I have.
The program is essentially:
  for(i=10; i>0; i--) {printf("%d\n", i);}

Using the head version of LLVM, if I do
  lli bad.bc
it works properly.

  llvm-ld -native -o=x bad.bc -disable-opt
makes a working program.  However,
  llvm-ld -native -o=x bad.bc
segfaults, as does running lli on the resulting x.bc.
This happens on Linux x86-32.


-- 
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 Jan 18 13:50:44 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 13:50:44 -0600
Subject: [LLVMbugs] [Bug 6070] Verifier accetps alloca with i64 count when
 the asm defines it with a i32 (error when using llvm-as)
In-Reply-To: <bug-6070-206@http.llvm.org/bugs/>
Message-ID: <201001181950.o0IJoija000724@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-18 13:50:43 ---
Done in r93756.


-- 
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 Jan 18 13:51:00 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 13:51:00 -0600
Subject: [LLVMbugs] [Bug 6070] Verifier accetps alloca with i64 count when
 the asm defines it with a i32 (error when using llvm-as)
In-Reply-To: <bug-6070-206@http.llvm.org/bugs/>
Message-ID: <201001181951.o0IJp05i000749@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|INVALID                     |FIXED




--- Comment #2 from Chris Lattner <clattner at apple.com>  2010-01-18 13:51:00 ---
-> 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 Jan 18 13:52:44 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 13:52:44 -0600
Subject: [LLVMbugs] [Bug 6058] self-build crash on IsInf.cpp
In-Reply-To: <bug-6058-206@http.llvm.org/bugs/>
Message-ID: <201001181952.o0IJqiIJ000933@zion.cs.uiuc.edu>

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


devang.patel <devang.patel at gmail.com> changed:

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




--- Comment #7 from devang.patel <devang.patel at gmail.com>  2010-01-18 13:52:43 ---
Fixed. r93757.


-- 
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 Jan 18 14:43:28 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 14:43:28 -0600
Subject: [LLVMbugs] [Bug 6075] New: Using atomic operations creates multiple,
 distinct function declarations
Message-ID: <bug-6075-206@http.llvm.org/bugs/>

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

           Summary: Using atomic operations creates multiple, distinct
                    function declarations
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu


As reported here:

  http://lists.cs.uiuc.edu/pipermail/cfe-dev/2010-January/007506.html

The following code creates two FunctionDecls for __sync_fetch_and_add, which do
*not* share a canonical declaration:

  void foo() {
   int i;
   __sync_fetch_and_add(&i, 1);
   __sync_fetch_and_add(&i, 1);
  }

We should probably just create one FunctionDecl, or at the very least be
careful to link the FunctionDecls together.


-- 
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 Jan 18 16:08:11 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 16:08:11 -0600
Subject: [LLVMbugs] [Bug 6077] New: Segfault in "X86 DAG->DAG Instruction
 Selection" when compiling simple file
Message-ID: <bug-6077-206@http.llvm.org/bugs/>

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

           Summary: Segfault in "X86 DAG->DAG Instruction Selection" when
                    compiling simple file
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: major
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4076)
 --> (http://llvm.org/bugs/attachment.cgi?id=4076)
A file that crash the compiler

I didn't managed to identify exactly the issue, but I have a simple test case:


# clang --version
clang version 1.1 (trunk 93721)
Target: x86_64-apple-darwin10
Thread model: posix

This is a Release-Assert build compiled using llvm-gcc-4.2 from Xcode 3.2.1 and
occurs when generating debugging symbols

-------------------------------- test.m --------------------------------
// clang -arch i386 -O0 -gdwarf-2 -c test.m

#import <Cocoa/Cocoa.h>

@interface SATrack : NSObject {
@private

}

- (CGSize)size;

- (id)valueForAttribute:(NSString *)anAttribute;

@end

@implementation SATrack

- (CGSize)size {
  NSValue *s = [self valueForAttribute:@"sapphire.aperture.clean"];
  if (!s)
    s = [self valueForAttribute:@"sapphire.track.size"];
  if (s)
    return NSSizeToCGSize([s sizeValue]);
  return CGSizeZero;
}

- (id)valueForAttribute:(NSString *)anAttribute { 
  return nil;
}

@end
--------------------------------------------------------------------------------

clang -arch i386 -O0 -gdwarf-2 -c test.m
0  clang             0x0000000100db9e62 PrintStackTrace(void*) + 34
1  clang             0x0000000100dba344 SignalHandler(int) + 468
2  libSystem.B.dylib 0x00007fff87ce4eaa _sigtramp + 26
3  libSystem.B.dylib 0x00000001013c7a50 _sigtramp + 2037263296
4  clang             0x000000010092f8d3
llvm::SelectionDAGBuilder::visitCall(llvm::CallInst&) + 787
5  clang             0x0000000100952233
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::ilist_iterator<llvm::Instruction>,
llvm::ilist_iterator<llvm::Instruction>, bool&) + 179
6  clang             0x00000001009529a3
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&,
llvm::MachineFunction&, llvm::MachineModuleInfo*, llvm::DwarfWriter*,
llvm::TargetInstrInfo const&) + 1619
7  clang             0x000000010095381c
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1084
8  clang             0x0000000100a1c44b
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 43
9  clang             0x0000000100d51acd
llvm::FPPassManager::runOnFunction(llvm::Function&) + 429
10 clang             0x0000000100d51ca4
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 100
11 clang             0x0000000100d51e4e
llvm::FunctionPassManager::run(llvm::Function&) + 78
12 clang             0x0000000100030515 (anonymous
namespace)::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 773
13 clang             0x0000000100304a93 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 387
14 clang             0x00000001000375ae
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 302
15 clang             0x000000010001f546 cc1_main(char const**, char const**,
char const*, void*) + 2102
16 clang             0x0000000100021a54 main + 2052
17 clang             0x000000010001d328 start + 52
18 clang             0x000000000000001d start + 4294847785
Stack dump:
0.      Program arguments:
/Users/jddupas/Projects/OpenSource/llvm/Release-Asserts/bin/clang -cc1 -triple
i386-apple-darwin10.0 -S -disable-free -main-file-name test.m -pic-level 1
-mdisable-fp-elim -target-cpu yonah -g -resource-dir
/Users/jddupas/Projects/OpenSource/llvm/Release-Asserts/lib/clang/1.1 -O0
-fmessage-length 172 -stack-protector 1 -fblocks -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/u-/u-YCVFReEbeFgXey1xAjx++++TI/-Tmp-/cc-RmAqfu.s -x objective-c
test.m 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@"\01-[SATrack size]"'
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)


-- 
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 Jan 18 16:51:25 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 18 Jan 2010 16:51:25 -0600
Subject: [LLVMbugs] [Bug 6077] Segfault in "X86 DAG->DAG Instruction
 Selection" when compiling simple file
In-Reply-To: <bug-6077-206@http.llvm.org/bugs/>
Message-ID: <201001182251.o0IMpPq8009454@zion.cs.uiuc.edu>

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


Pawel Worach <pawel.worach at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |pawel.worach at gmail.com
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #1 from Pawel Worach <pawel.worach at gmail.com>  2010-01-18 16:51:23 ---
This has already been fixed in r93757.

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


-- 
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 Jan 19 05:21:14 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 05:21:14 -0600
Subject: [LLVMbugs] [Bug 6080] New: regression with r93752
Message-ID: <bug-6080-206@http.llvm.org/bugs/>

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

           Summary: regression with r93752
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: quickslyver at free.fr
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4077)
 --> (http://llvm.org/bugs/attachment.cgi?id=4077)
testcase (c source)

the test source is from gcc regression suite (pr22098-1.c)
the code generated is incorrect.

files bug.c, bug-r93752.ll and bug-r93751.ll are in attachment

$clang bug.c -O0 -o bug && ./bug
Aborted

$clang bug.c -O1 -o bug && ./bug
Segmentation fault


-- 
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 Jan 19 10:36:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 10:36:59 -0600
Subject: [LLVMbugs] [Bug 6082] New: ELFWriter leaks memory
Message-ID: <bug-6082-206@http.llvm.org/bugs/>

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

           Summary: ELFWriter leaks memory
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tim at bioware.com
                CC: llvmbugs at cs.uiuc.edu


We use the ELF object file format in a persistent process and have seen issues
with leaked memory.

Specifically, the elements contained within the SectionList and SymbolList
containers leak.  Also, check the construction of the symbols that populate the
SymbolList.  I seem to remember that there is a PrivateList that can be
populated which doesn't seem to be getting freed.


-- 
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 Jan 19 11:04:50 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 11:04:50 -0600
Subject: [LLVMbugs] [Bug 6071] MIPS backend error,
 missing argument passing in generated code
In-Reply-To: <bug-6071-206@http.llvm.org/bugs/>
Message-ID: <201001191704.o0JH4o2S002671@zion.cs.uiuc.edu>

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


Bruno Cardoso Lopes <bruno.cardoso at gmail.com> changed:

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




--- Comment #6 from Bruno Cardoso Lopes <bruno.cardoso at gmail.com>  2010-01-19 11:04:50 ---
Hi Adam,

The argument bug is fixed in trunk (r93880):
http://llvm.org/viewvc/llvm-project?rev=93880&view=rev

For the address load, there is nothing wrong with it, MIPS uses two
instructions to load the address from GOT when using pic. It uses two
relocations for that, as an example:

  64:   8f820000        lw      v0,0(gp)
                        64: R_MIPS_GOT16        .data
  68:   00031880        sll     v1,v1,0x2
  6c:   24420000        addiu   v0,v0,0
                        6c: R_MIPS_LO16 .data

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 Jan 19 13:19:12 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 13:19:12 -0600
Subject: [LLVMbugs] [Bug 6084] New: Clang allows function-like macro
 argument lists to span files
Message-ID: <bug-6084-206@http.llvm.org/bugs/>

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

           Summary: Clang allows function-like macro argument lists to span
                    files
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: preprocessor
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu


blackthorn:clang dgregor$ cat t.h
#define FOO(X, Y) X + Y

int add() { return FOO(17, 
blackthorn:clang dgregor$ cat t.c
#include "t.h"

17); }


blackthorn:clang dgregor$ clang -fsyntax-only t.c
blackthorn:clang dgregor$ gcc -fsyntax-only t.c
In file included from t.c:1:
t.h:3:1: error: unterminated argument list invoking macro "FOO"
t.c: In function ???add???:
t.h:3: error: ???FOO??? undeclared (first use in this function)
t.h:3: error: (Each undeclared identifier is reported only once
t.h:3: error: for each function it appears in.)
t.c:3: error: expected ???;??? before numeric constant
t.c:3: error: expected statement before ???)??? token


-- 
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 Jan 19 13:30:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 13:30:46 -0600
Subject: [LLVMbugs] [Bug 6082] ELFWriter leaks memory
In-Reply-To: <bug-6082-206@http.llvm.org/bugs/>
Message-ID: <201001191930.o0JJUknY008766@zion.cs.uiuc.edu>

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


Bruno Cardoso Lopes <bruno.cardoso at gmail.com> changed:

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




--- Comment #5 from Bruno Cardoso Lopes <bruno.cardoso at gmail.com>  2010-01-19 13:30:45 ---
Hi Tim,

Ok. Thanks anyway for reporting, but they are probably solved in trunk in case
you want to stay up-to-date with mainline. Marked as WONTFIX.


-- 
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 Jan 19 16:39:13 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 16:39:13 -0600
Subject: [LLVMbugs] [Bug 6080] clang miscompiles compound initializers with
 incomplete array types
In-Reply-To: <bug-6080-206@http.llvm.org/bugs/>
Message-ID: <201001192239.o0JMdDbj016744@zion.cs.uiuc.edu>

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


John McCall <rjmccall at apple.com> changed:

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




--- Comment #5 from John McCall <rjmccall at apple.com>  2010-01-19 16:39:13 ---
When reviewing Enea's patch, I missed this case, which (stated generally) means
that the type of the expression doesn't always match the written type.

Fixed in r93933.


-- 
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 Jan 19 18:09:54 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 18:09:54 -0600
Subject: [LLVMbugs] [Bug 6085] New: code and text do not match
Message-ID: <bug-6085-206@http.llvm.org/bugs/>

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

           Summary: code and text do not match
           Product: Documentation
           Version: trunk
          Platform: All
               URL: http://llvm.org/docs/tutorial/LangImpl3.html#funcs
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: albert at mietus.nl
                CC: llvmbugs at cs.uiuc.edu


The text in the 2nd paragraph  below the first code-example in the 'Function
Code Generation' section says:
     "The call to Context.get creates ..."

The code-example however, has no 'Context.get()' method, it does have a
'getGlobalContext() function. Probably one of both are not updated after a
api-change in the past.

This happens a gew time in this section more.

Note, This seams and older doc-bug; it is available in the 'latest' version 
(see url), but also in several releases; at least in 2.6  which I'm studying.
The 2.2 version is "different", but seams consistent with itsefl

Note 2: The shown code excerpt is "repeated" in as whole program, at the bottom
of the file. There it seams different that in the code-example.

Hope this helps. Please contact me for more info when needed --Albert


-- 
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 Jan 19 19:57:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 19:57:09 -0600
Subject: [LLVMbugs] [Bug 6086] New: assertion failure in LiveIntervals
Message-ID: <bug-6086-206@http.llvm.org/bugs/>

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

           Summary: assertion failure in LiveIntervals
           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


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

llc aborts on the attached testcase with

llc: include/llvm/CodeGen/LiveIntervalAnalysis.h:87: llvm::LiveInterval&
llvm::LiveIntervals::getInterval(unsigned int): Assertion `I != r2iMap_.end()
&& "Interval does not exist for register"' 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  Tue Jan 19 20:14:53 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 19 Jan 2010 20:14:53 -0600
Subject: [LLVMbugs] [Bug 6087] New: SEGV when self-building
	RegisterInfoEmitter.cpp
Message-ID: <bug-6087-206@http.llvm.org/bugs/>

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

           Summary: SEGV when self-building RegisterInfoEmitter.cpp
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


self-build ends up in a SEGV when building TableGen.

clang version 1.1 (trunk 93965)
Target: x86_64-apple-darwin10

llvm[2]: Compiling RegisterInfoEmitter.cpp for Debug build
0  clang             0x0000000100eaabc2 PrintStackTrace(void*) + 34
1  clang             0x0000000100eab44c SignalHandler(int) + 652
2  libSystem.B.dylib 0x00007fff87253eaa _sigtramp + 26
3  clang             0x00000001002346e0 (anonymous
namespace)::CXXNameMangler::mangleTemplateArg(clang::TemplateArgument const&) +
240
4  clang             0x0000000100e4e95b llvm::Value::getContext() const + 43
5  clang             0x0000000100e4f426 llvm::ValueHandleBase::AddToUseList() +
38
6  clang             0x0000000100e2be1b
llvm::MDNode::MDNode(llvm::LLVMContext&, llvm::Value* const*, unsigned int,
bool) + 171
7  clang             0x0000000100e2bfa7
llvm::MDNode::getMDNode(llvm::LLVMContext&, llvm::Value* const*, unsigned int,
llvm::MDNode::FunctionLocalness) + 343
8  clang             0x0000000100cf778e
llvm::DIFactory::CreateSubprogram(llvm::DIDescriptor, llvm::StringRef,
llvm::StringRef, llvm::StringRef, llvm::DICompileUnit, unsigned int,
llvm::DIType, bool, bool, unsigned int, unsigned int, llvm::DIType) + 398
9  clang             0x000000010016ab3f
clang::CodeGen::CGDebugInfo::CollectCXXMemberFunctions(clang::CXXRecordDecl
const*, llvm::DICompileUnit, llvm::SmallVectorImpl<llvm::DIDescriptor>&,
llvm::DICompositeType&) + 959
10 clang             0x000000010016bf9b
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*,
llvm::DICompileUnit) + 2027
11 clang             0x000000010016c11e
clang::CodeGen::CGDebugInfo::CreateType(clang::TagType const*,
llvm::DICompileUnit) + 110
12 clang             0x0000000100164a57
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType,
llvm::DICompileUnit) + 1751
13 clang             0x0000000100164c9a
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType,
llvm::DICompileUnit) + 218
14 clang             0x000000010016c5e7
clang::CodeGen::CGDebugInfo::CreateType(clang::TypedefType const*,
llvm::DICompileUnit) + 87
15 clang             0x0000000100164a0a
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType,
llvm::DICompileUnit) + 1674
16 clang             0x0000000100164c9a
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType,
llvm::DICompileUnit) + 218
17 clang             0x000000010016b352
clang::CodeGen::CGDebugInfo::CollectRecordFields(clang::RecordDecl const*,
llvm::DICompileUnit, llvm::SmallVectorImpl<llvm::DIDescriptor>&) + 466
18 clang             0x000000010016bb13
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*,
llvm::DICompileUnit) + 867
19 clang             0x000000010016c11e
clang::CodeGen::CGDebugInfo::CreateType(clang::TagType const*,
llvm::DICompileUnit) + 110
20 clang             0x0000000100164a57
clang::CodeGen::CGDebugInfo::CreateTypeNode(clang::QualType,
llvm::DICompileUnit) + 1751
21 clang             0x0000000100164c9a
clang::CodeGen::CGDebugInfo::getOrCreateType(clang::QualType,
llvm::DICompileUnit) + 218
22 clang             0x00000001001671c7
clang::CodeGen::CGDebugInfo::EmitDeclare(clang::VarDecl const*, unsigned int,
llvm::Value*, llvm::IRBuilder<true, llvm::ConstantFolder,
llvm::IRBuilderDefaultInserter<true> >&) + 263
23 clang             0x0000000100172a23
clang::CodeGen::CodeGenFunction::EmitLocalBlockVarDecl(clang::VarDecl const&) +
3331
24 clang             0x00000001001752b0
clang::CodeGen::CodeGenFunction::EmitDecl(clang::Decl const&) + 480
25 clang             0x00000001001fd0bb
clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 171
26 clang             0x00000001002038bb
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 171
27 clang             0x00000001002009c0
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48
28 clang             0x00000001002035cb
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, llvm::Value*, bool) + 267
29 clang             0x00000001002038f7
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 231
30 clang             0x00000001002009c0
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48
31 clang             0x0000000100203302
clang::CodeGen::CodeGenFunction::EmitIfStmt(clang::IfStmt const&) + 450
32 clang             0x0000000100200d14
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 900
33 clang             0x00000001002035cb
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, llvm::Value*, bool) + 267
34 clang             0x00000001002038f7
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 231
35 clang             0x00000001002009c0
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48
36 clang             0x000000010021b035
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 1989
37 clang             0x00000001002251bb
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::CodeGen::GlobalDecl)
+ 1067
38 clang             0x00000001002258eb
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 587
39 clang             0x0000000100225b8c
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 396
40 clang             0x00000001002261c2
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 290
41 clang             0x00000001002361bc (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 60
42 clang             0x000000010002f95e (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 158
43 clang             0x000000010033b605 clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 277
44 clang             0x0000000100038f39
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 393
45 clang             0x000000010001dba0 cc1_main(char const**, char const**,
char const*, void*) + 2000
46 clang             0x0000000100020394 main + 2052
47 clang             0x000000010001b908 start + 52
48 clang             0x0000000000000035 start + 4294854497
Stack dump:
0.      Program arguments: /Users/pwo/src/llvm-obj/Release/bin/clang -cc1
-triple x86_64-apple-darwin10.0 -S -disable-free -main-file-name
RegisterInfoEmitter.cpp -pic-level 1 -mdisable-fp-elim -munwind-tables
-target-cpu core2 -g -resource-dir
/Users/pwo/src/llvm-obj/Release/lib/clang/1.1 -dependency-file
/Users/pwo/src/llvm-selfhost/utils/TableGen/Debug/RegisterInfoEmitter.d.tmp -MP
-MT /Users/pwo/src/llvm-selfhost/utils/TableGen/Debug/RegisterInfoEmitter.o -MT
/Users/pwo/src/llvm-selfhost/utils/TableGen/Debug/RegisterInfoEmitter.d
-D_DEBUG -D_GNU_SOURCE -D__STDC_LIMIT_MACROS -D__STDC_CONSTANT_MACROS
-I/Users/pwo/src/llvm-selfhost/include
-I/Users/pwo/src/llvm-selfhost/utils/TableGen -I/Users/pwo/src/llvm/include
-I/Users/pwo/src/llvm/utils/TableGen -Woverloaded-virtual -Wno-long-long -Wall
-W -Wno-unused-parameter -Wwrite-strings -pedantic -fmessage-length 80
-stack-protector 1 -fblocks -fexceptions -fno-common -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/HV/HVYbz+scFaWJdUHdYZJeAE+++TM/-Tmp-/cc-WxISS5.s -x c++
/Users/pwo/src/llvm/utils/TableGen/RegisterInfoEmitter.cpp 
1.      <eof> parser at end of file
2.      /Users/pwo/src/llvm/utils/TableGen/RegisterInfoEmitter.cpp:175:27: LLVM
IR generation of declaration 'llvm::RegisterInfoEmitter::run'
3.      /Users/pwo/src/llvm/utils/TableGen/RegisterInfoEmitter.cpp:175:27:
Generating code for declaration 'llvm::RegisterInfoEmitter::run'
4.      /Users/pwo/src/llvm/utils/TableGen/RegisterInfoEmitter.cpp:175:48: LLVM
IR generation of compound statement ('{}')
5.      /Users/pwo/src/llvm/utils/TableGen/RegisterInfoEmitter.cpp:235:33: LLVM
IR generation of compound statement ('{}')
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)


-- 
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 Jan 20 04:22:20 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 04:22:20 -0600
Subject: [LLVMbugs] [Bug 6090] New: html error on web page
Message-ID: <bug-6090-206@http.llvm.org/bugs/>

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

           Summary: html error on web page
           Product: Documentation
           Version: trunk
          Platform: All
               URL: http://clang-analyzer.llvm.org/scan-build.html
        OS/Version: All
            Status: NEW
          Severity: minor
          Priority: P2
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clwi at me.com
                CC: llvmbugs at cs.uiuc.edu


In the passage:

"Operationally, <tt>scan-build</tt> literally runs <command> with all of the
subsequent options passed to it. For example, one can pass
<nobr><tt>-j4</tt></nobr> to
<tt>make</tt> get a parallel build over 4 cores:"

command should have surrounding &lt; and &gt; instead of <>


-- 
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 Jan 20 05:38:33 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 05:38:33 -0600
Subject: [LLVMbugs] [Bug 6092] New: Kaleidoscope (toy-v3) does optimise,
 doc-text say not.   Unclear!
Message-ID: <bug-6092-206@http.llvm.org/bugs/>

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

           Summary: Kaleidoscope (toy-v3) does optimise, doc-text say not.
                    Unclear!
           Product: Documentation
           Version: 2.6
          Platform: Macintosh
               URL: http://llvm.org/releases/2.6/docs/tutorial/LangImpl3.htm
                    l#driver
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: albert at mietus.nl
                CC: llvmbugs at cs.uiuc.edu


This section, about code-generation say the code is not optimized. (will be
added in next chapter)
As an example the code for '4+5;' is given which should (by the text) result in
an add instruction.

Compling that code (with release 2.6) shows different, however. The shown code
is optimized; it becomes the value 9.0

Log:
|| ready> 4+5;
|| ready> Read top-level expression:
|| define double @2() {
|| entry:
||   ret double 9.000000e+00
|| }

Hope this helps --Albert


-- 
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 Jan 20 06:41:25 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 06:41:25 -0600
Subject: [LLVMbugs] [Bug 6090] html error on web page
In-Reply-To: <bug-6090-206@http.llvm.org/bugs/>
Message-ID: <201001201241.o0KCfPUm030764@zion.cs.uiuc.edu>

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


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baldrick at free.fr
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Duncan Sands <baldrick at free.fr>  2010-01-20 06:41:24 ---
Thanks - fixed in commit 94000.


-- 
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 Jan 20 08:47:32 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 08:47:32 -0600
Subject: [LLVMbugs] [Bug 6093] New: MCAsmStreamer:: EmitSymbolAttribute does
 not use MCAsmInfo settings
Message-ID: <bug-6093-206@http.llvm.org/bugs/>

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

           Summary: MCAsmStreamer::EmitSymbolAttribute does not use
                    MCAsmInfo settings
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: code-cleanup, miscompilation
          Severity: minor
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: martijn at martijnrutten.com
                CC: llvmbugs at cs.uiuc.edu


MCAsmStreamer::EmitSymbolAttribute in lib/MC/MCAsmStreamer.cpp prints
directives for symbols. The directives e.g. '.globl' for a global variable are
hardcoded. If a backend specifies a different GlobalDirective, e.g.
'\t.global\t' in an MCAsmInfo subclass, this directive is not used (triggered
in a custom backend).

AsmPrinter.cpp calls EmitSymbolAttribute in e.g. AsmPrinter::EmitGlobalVariable

Please update EmitSymbolAttribute function to use the MCAsmInfo directives.


-- 
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 Jan 20 11:50:50 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 11:50:50 -0600
Subject: [LLVMbugs] [Bug 6093] MCAsmStreamer:: EmitSymbolAttribute does not
 use MCAsmInfo settings
In-Reply-To: <bug-6093-206@http.llvm.org/bugs/>
Message-ID: <201001201750.o0KHooVx010235@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-20 11:50:49 ---
Oops, fixed in r94006


-- 
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 Jan 20 15:15:27 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 15:15:27 -0600
Subject: [LLVMbugs] [Bug 6096] New: opt assertion failed when constant
 folding vector-compare with undef-value
Message-ID: <bug-6096-206@http.llvm.org/bugs/>

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

           Summary: opt assertion failed when constant folding vector-
                    compare with undef-value
           Product: new-bugs
           Version: unspecified
          Platform: Sun
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bixia.zheng at amd.com
                CC: llvmbugs at cs.uiuc.edu


The problem can be reproduced with TOT LLVM

command line:
=============
    llvm-as c.ll -o c.bc
    opt -O3 c.bc -o t.bc -debug

Error message:
==============
INSTCOMBINE ITERATION #0 on hello
IC: ConstFold to: <4 x float> fdiv (<4 x float> undef, <4 x float> <float
1.000000e+000, float 1.000000e+000, float 1.000000e+000, float 1.000000e+000>)
from:
 %div = fdiv <4 x float> undef, <float 1.000000e+000, float 1.000000e+000,
float1.000000e+000, float 1.000000e+000> ; <<4 x float>> [#uses=1]

Assertion failed: begin() + idx < end(), file
\llvm\include\llvm/ADT/SmallVector.h, line 152

Test case:
==========
; ModuleID = 'c.bc'
target datalayout =
"e-p:32:32:32-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-f80:32:32"
target triple = "i686-pc-win32"

define void @hello() nounwind {
entry:
  %a = alloca <4 x float>, align 16               ; <<4 x float>*> [#uses=0]
  %b = alloca <4 x float>, align 16               ; <<4 x float>*> [#uses=1]
  %c = alloca <4 x float>, align 16               ; <<4 x float>*> [#uses=2]
  %zero4 = alloca <4 x float>, align 16           ; <<4 x float>*> [#uses=2]
  %i4 = alloca <4 x i32>, align 16                ; <<4 x i32>*> [#uses=1]
  store <4 x float> <float 1.000000e+000, float 1.000000e+000, float
1.000000e+000, float 1.000000e+000>, <4 x float>* %c
  store <4 x float> zeroinitializer, <4 x float>* %zero4
  %tmp = load <4 x float>* %b                     ; <<4 x float>> [#uses=1]
  %tmp1 = load <4 x float>* %c                    ; <<4 x float>> [#uses=1]
  %div = fdiv <4 x float> %tmp, %tmp1             ; <<4 x float>> [#uses=1]
  %tmp2 = load <4 x float>* %zero4                ; <<4 x float>> [#uses=1]
  %cmp = fcmp ole <4 x float> %div, %tmp2         ; <<4 x i1>> [#uses=1]
  %sext = sext <4 x i1> %cmp to <4 x i32>         ; <<4 x i32>> [#uses=1]
  store <4 x i32> %sext, <4 x i32>* %i4
  ret void
}


-- 
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 Jan 20 19:17:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 19:17:48 -0600
Subject: [LLVMbugs] [Bug 6097] New: BinaryOperators built in wrong order
Message-ID: <bug-6097-206@http.llvm.org/bugs/>

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

           Summary: BinaryOperators built in wrong order
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mrs at apple.com
                CC: llvmbugs at cs.uiuc.edu


$ cat t5.c
int foo1();
int foo2();
int main() {
  return foo1() + foo2();
}
mrs $ clang -cc1 -analyze -cfg-dump -fexceptions  t5.c

 [ B4 (ENTRY) ]
    Predecessors (0):
    Successors (1): B3

 [ B1 ]
      1: return [B2.1] + [B3.1];
    Predecessors (1): B2
    Successors (1): B0

 [ B2 ]
      1: foo1()
    Predecessors (1): B3
    Successors (2): B1 B0

 [ B3 ]
      1: foo2()
    Predecessors (1): B4
    Successors (2): B2 B0

 [ B0 (EXIT) ]
    Predecessors (3): B1 B2 B3
    Successors (0):
$ clang -S t5.c
$ grep foo t5.s
        callq   _foo1
        callq   _foo2

Order should be B4 -> B2 -> B3 -> B1.


-- 
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 Jan 20 19:48:35 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 19:48:35 -0600
Subject: [LLVMbugs] [Bug 6097] [clang cfg] BinaryOperators built in wrong
	order for CFG
In-Reply-To: <bug-6097-206@http.llvm.org/bugs/>
Message-ID: <201001210148.o0L1mZIf029638@zion.cs.uiuc.edu>

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


Ted Kremenek <kremenek at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |kremenek at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Ted Kremenek <kremenek at apple.com>  2010-01-20 19:48:34 ---
Right now the order is B4 -> B3 -> B2 -> B1.

Why is that not a valid ordering?  Does the standard say something about the
order of evaluation of the subexpressions of a binary 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  Wed Jan 20 19:51:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 19:51:29 -0600
Subject: [LLVMbugs] [Bug 6097] [clang cfg] BinaryOperators built in wrong
	order for CFG
In-Reply-To: <bug-6097-206@http.llvm.org/bugs/>
Message-ID: <201001210151.o0L1pTQo029761@zion.cs.uiuc.edu>

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


Ted Kremenek <kremenek at apple.com> changed:

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




--- Comment #3 from Ted Kremenek <kremenek at apple.com>  2010-01-20 19:51:28 ---
Ah, okay.  So the idea is to have the LHS evaluated first?


-- 
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 Jan 20 23:00:04 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 20 Jan 2010 23:00:04 -0600
Subject: [LLVMbugs] [Bug 6099] New: msp430 backend ice: long long is not
	intmax_t?
Message-ID: <bug-6099-206@http.llvm.org/bugs/>

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

           Summary: msp430 backend ice: long long is not intmax_t?
           Product: new-bugs
           Version: trunk
          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: asl at math.spbu.ru, llvmbugs at cs.uiuc.edu


regehr at john-home:~/volatile/bugs/tmp260$ clang -ccc-host-triple msp430-elf
small.c
small.c:3:10: warning: integer constant is too large for its type
  si == -9223372036854775807LL - 1 ? : -si;
         ^
clang: SemaExpr.cpp:1734: virtual
clang::ASTOwningResult<&clang::ActionBase::DeleteExpr>
clang::Sema::ActOnNumericConstant(const clang::Token&): Assertion
`Context.getTypeSize(Ty) == ResultVal.getBitWidth() && "long long is not
intmax_t?"' failed.
0  clang 0x0910d708
Stack dump:
0.      Program arguments: /home/regehr/z/tmp/llvm-gcc-r94064-install/bin/clang
-cc1 -triple msp430-elf- -S -disable-free -main-file-name small.c
-mrelocation-model static -mdisable-fp-elim -resource-dir
/home/regehr/z/tmp/llvm-gcc-r94064-install/lib/clang/1.1 -fmessage-length 80
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-jps8gO.s
-x c small.c 
1.      small.c:3:10: current parser token '9223372036854775807LL'
2.      small.c:2:1: parsing function body 'foo'
3.      small.c:2:1: in compound statement ('{}')
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
regehr at john-home:~/volatile/bugs/tmp260$ cat small.c
static void foo (long long si)
{
  si == -9223372036854775807LL - 1 ? : -si;
}
regehr at john-home:~/volatile/bugs/tmp260$ clang -v
clang version 1.1 (trunk 94064)
Target: i386-pc-linux-gnu
Thread model: posix


-- 
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 Jan 21 01:16:16 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 01:16:16 -0600
Subject: [LLVMbugs] [Bug 6096] opt assertion failed when constant folding
 vector-compare with undef-value
In-Reply-To: <bug-6096-206@http.llvm.org/bugs/>
Message-ID: <201001210716.o0L7GG96008261@zion.cs.uiuc.edu>

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


Nick Lewycky <nicholas at mxc.ca> changed:

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




--- Comment #1 from Nick Lewycky <nicholas at mxc.ca>  2010-01-21 01:16:15 ---
The original bug is fixed, but we should probably fold undef / X for floats.


-- 
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 Jan 21 06:46:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 06:46:59 -0600
Subject: [LLVMbugs] [Bug 6101] New: clang: preprocessor doesn't honor #line
	directives!
Message-ID: <bug-6101-206@http.llvm.org/bugs/>

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

           Summary: clang: preprocessor doesn't honor #line directives!
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: preprocessor
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Consider this testcase, clang -E only preserves the filenames, not the line
numbers!
int main()
{
#line 10 "foo1.c"
  printf("test\n");
#line 200 "foo2.c"
  printf("foo\n");
#line 10 "foo1.c"
}

clang -E gives:
# 1 "x.c"
# 1 "x.c" 1
# 1 "<built-in>" 1
# 1 "<built-in>" 3
# 113 "<built-in>" 3
# 113 "<command line>" 1
# 114 "<built-in>" 2
# 1 "x.c" 2
int main()
{
# 3 "foo1.c"

  printf("test\n");
# 5 "foo2.c"

  printf("foo\n");
# 7 "foo1.c"

}

gcc -E gives:
# 1 "x.c"
# 1 "<built-in>"
# 1 "<command-line>"
# 1 "x.c"
int main()
{
# 10 "foo1.c"
  printf("test\n");
# 200 "foo2.c"
  printf("foo\n");
# 10 "foo1.c"
}

The line numbers in #line must be honored to correctly compile output from
parser generators like bison, re2c, etc.
Otherwise warnings, and debug line numbers are all wrong.


-- 
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 Jan 21 08:27:43 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 08:27:43 -0600
Subject: [LLVMbugs] [Bug 6102] New: assertion " Not all catch info was
 assigned to a landing pad!"
Message-ID: <bug-6102-206@http.llvm.org/bugs/>

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

           Summary: assertion "Not all catch info was assigned to a landing
                    pad!"
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vargaz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

Not sure if this is a code generator or an optimizer problem.

In the attached testcase, llvm.eh.selector is called in a bblock which is a
target of an invoke, but the invoke is optimized away by 'opt' since it is in
an unreachable bblock, causing llc to crash with the following assertion:

llc: SelectionDAGISel.cpp:355: virtual bool
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&): Assertion
`FuncInfo->CatchInfoFound.size() == FuncInfo->CatchInfoLost.size() && "Not all
catch info was assigned to a landing pad!"' failed.                             

To reproduce:

llvm-as -o bug.bc bug.ll && opt bug.bc -O2 -o bug2.bc && llc bug2.bc

This is with llvm trunk on x86-64.


-- 
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 Jan 21 09:22:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 09:22:21 -0600
Subject: [LLVMbugs] [Bug 6103] New: Simple Register Coalescing assert
 failure: invalid register-register move instruction
Message-ID: <bug-6103-206@http.llvm.org/bugs/>

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

           Summary: Simple Register Coalescing assert failure: invalid
                    register-register move instruction
           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: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


$ llc crash.bc
llc: llvm/lib/Target/X86/X86InstrInfo.cpp:706: virtual bool
llvm::X86InstrInfo::isMoveInstr(const llvm::MachineInstr&, unsigned int&,
unsigned int&, unsigned int&, unsigned int&) const: Assertion
`MI.getNumOperands() >= 2 && MI.getOperand(0).isReg() &&
MI.getOperand(1).isReg() && "invalid register-register move instruction"'
failed.
...
6  llc       0x00000000010b314f
llvm::X86InstrInfo::isMoveInstr(llvm::MachineInstr const&, unsigned int&,
unsigned int&, unsigned int&, unsigned int&) const + 535
7  llc       0x00000000013d5105
llvm::LiveIntervals::getVNInfoSourceReg(llvm::VNInfo const*) const + 519
8  llc       0x000000000135205b
llvm::SimpleRegisterCoalescing::JoinIntervals(llvm::LiveInterval&,
llvm::LiveInterval&, bool&) + 2901
9  llc       0x000000000134febc
llvm::SimpleRegisterCoalescing::JoinCopy(llvm::CopyRec&, bool&) + 6760
10 llc       0x0000000001353114
llvm::SimpleRegisterCoalescing::CopyCoalesceInMBB(llvm::MachineBasicBlock*,
std::vector<llvm::CopyRec, std::allocator<llvm::CopyRec> >&) + 1240
11 llc       0x0000000001353482 llvm::SimpleRegisterCoalescing::joinIntervals()
+ 624
...
1.      Running pass 'Simple Register Coalescing' on function '@f'
Aborted (core dumped)


Testcase:

; ModuleID = 'crash.bc'
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-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

declare void @use(i32, i64)

define fastcc void @f(i64 %a, i64 %b) {
E:
  br label %A

A:                                                ; preds = %A, %E
  %0 = phi i31 [ 1, %E ], [ 0, %A ]               ; <i31> [#uses=1]
  %1 = sext i31 %0 to i64                         ; <i64> [#uses=1]
  call void @use(i32 0, i64 %1) nounwind
  br label %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  Thu Jan 21 10:22:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 10:22:10 -0600
Subject: [LLVMbugs] [Bug 6104] New: clang's Version.h shouldn't be
	subversion specific
Message-ID: <bug-6104-206@http.llvm.org/bugs/>

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

           Summary: clang's Version.h shouldn't be subversion specific
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Basic
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Clang's Version.h exposes two useful API calls, intended to get the "branch"
the source was built from and the "version". This APIs should be renamed, and
the version one changed to return an arbitrary string (which is assumed to name
a source version inside the particular branch), so as not to be subversion
specific.


-- 
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 Jan 21 12:36:16 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 12:36:16 -0600
Subject: [LLVMbugs] [Bug 6087] SEGV when self-building
	RegisterInfoEmitter.cpp
In-Reply-To: <bug-6087-206@http.llvm.org/bugs/>
Message-ID: <201001211836.o0LIaGEv023679@zion.cs.uiuc.edu>

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


Pawel Worach <pawel.worach at gmail.com> changed:

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




--- Comment #4 from Pawel Worach <pawel.worach at gmail.com>  2010-01-21 12:36:14 ---
This problem no longer exists with r94074.


-- 
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 Jan 21 13:36:43 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 13:36:43 -0600
Subject: [LLVMbugs] [Bug 6105] New: AsmStmt should not use SmallVector
Message-ID: <bug-6105-206@http.llvm.org/bugs/>

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

           Summary: AsmStmt should not use SmallVector
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: AST
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: kremenek at apple.com
                CC: llvmbugs at cs.uiuc.edu


AsmStmt uses SmallVector, which can allocate memory using 'malloc()'.  This can
lead to memory leaks when we use the BumpPtrAllocator to allocate AST nodes and
we do not call the destructor of AsmStmt objects.

Fix: AsmStmt should allocate all memory it uses with the allocator associated
with ASTContext.


-- 
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 Jan 21 15:19:19 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 15:19:19 -0600
Subject: [LLVMbugs] [Bug 6106] New: llvm::dbgs() causes endless loop on
	NDEBUG builds.
Message-ID: <bug-6106-206@http.llvm.org/bugs/>

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

           Summary: llvm::dbgs() causes endless loop on NDEBUG builds.
           Product: new-bugs
           Version: unspecified
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xerxes at zafena.se
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4086)
 --> (http://llvm.org/bugs/attachment.cgi?id=4086)
dbgs_to_errs.patch

When setting llvm::PrintMachineCode = 1; to make the llvm JIT print machine
code after each optimization pass and linked to a ReleaseWithDebInfo causes a
enless loop when creating the llvm jit execution engine.

debugging the running process (openjdk in this case) makes it clear that
Debug.cpp:119 needs fixing for NDEBUG builds, 

The proposed attached patch fixed this issue for NDEBUG builds by making
llvm::dbgs() return errs() instead of recursively returning itself.

(gdb) bt
#0  llvm::dbgs () at /sd/llvm/lib/Support/Debug.cpp:119
#1  0x40752cf0 in printAndVerify (PM=@0x94fb0, Banner=0x40a2ed5c "After
Instruction Selection", allowDoubleDefs=true) at
/sd/llvm/lib/CodeGen/LLVMTargetMachine.cpp:261
#2  0x40753118 in llvm::LLVMTargetMachine::addCommonCodeGenPasses
(this=0x95038, PM=@0x94fb0, OptLevel=llvm::CodeGenOpt::Default) at
/sd/llvm/lib/CodeGen/LLVMTargetMachine.cpp:340
#3  0x407536b0 in llvm::LLVMTargetMachine::addPassesToEmitMachineCode
(this=0x95038, PM=@0x94fb0, JCE=@0x99110, OptLevel=llvm::CodeGenOpt::Default)
at /sd/llvm/lib/CodeGen/LLVMTargetMachine.cpp:245
#4  0x40723eac in JIT (this=0x973b0, MP=<value optimized out>, tm=<value
optimized out>, tji=<value optimized out>, JMM=0x94ef8,
OptLevel=llvm::CodeGenOpt::Default, GVsWithCode=<value optimized out>) at
/sd/llvm/lib/ExecutionEngine/JIT/JIT.cpp:249
#5  0x40724080 in llvm::JIT::createJIT (MP=0x7eac8, ErrorStr=<value optimized
out>, JMM=0x94ef8, OptLevel=llvm::CodeGenOpt::Default, GVsWithCode=true,
CMM=28) at /sd/llvm/lib/ExecutionEngine/JIT/JIT.cpp:224
#6  0x404aa93c in SharkCompiler (this=0x8b780) at
/media/disk/icedtea6-tot/openjdk-ecj/hotspot/src/share/vm/shark/sharkCompiler.cpp:60
#7  0x402aa0a4 in CompileBroker::compilation_init () at
/media/disk/icedtea6-tot/openjdk-ecj/hotspot/src/share/vm/compiler/compileBroker.cpp:561
#8  0x404e7c20 in Threads::create_vm (args=<value optimized out>,
canTryAgain=<value optimized out>) at
/media/disk/icedtea6-tot/openjdk-ecj/hotspot/src/share/vm/runtime/thread.cpp:3141
#9  0x40372f44 in JNI_CreateJavaVM (vm=0x40d22dfc, penv=0x40d22df8,
args=0x40d22de8) at
/media/disk/icedtea6-tot/openjdk-ecj/hotspot/src/share/vm/prims/jni.cpp:3263
#10 0x0000a2d0 in JavaMain (_args=<value optimized out>) at
../../../../src/share/bin/java.c:1310
#11 0x4005e30c in start_thread () from /lib/vfp/libpthread.so.0
#12 0x40155d38 in clone () from /lib/vfp/libc.so.6
Backtrace stopped: frame did not save the PC
(gdb) 

(gdb) disassemble 
Dump of assembler code for function _ZN4llvm4dbgsEv:
0x409b6034 <llvm::dbgs()+0>:    b       0x409b6034 <llvm::dbgs()>
End of assembler dump.
(gdb)

Cheers
Xerxes


-- 
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 Jan 21 15:59:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 15:59:46 -0600
Subject: [LLVMbugs] [Bug 6106] llvm::dbgs() causes endless loop on NDEBUG
	builds.
In-Reply-To: <bug-6106-206@http.llvm.org/bugs/>
Message-ID: <201001212159.o0LLxkQt000312@zion.cs.uiuc.edu>

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


David Greene <greened at obbligato.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |greened at obbligato.org
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from David Greene <greened at obbligato.org>  2010-01-21 15:59:45 ---
Fixed with r94001.


-- 
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 Jan 21 18:08:58 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 18:08:58 -0600
Subject: [LLVMbugs] [Bug 5694] ARM backend miscompiles a <= (0 - b)
In-Reply-To: <bug-5694-206@http.llvm.org/bugs/>
Message-ID: <201001220008.o0M08wrN005508@zion.cs.uiuc.edu>

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


Jim Grosbach <grosbach at apple.com> changed:

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




--- Comment #2 from Jim Grosbach <grosbach at apple.com>  2010-01-21 18:08:58 ---
Fixed in r94119.


-- 
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 Jan 21 20:42:34 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 20:42:34 -0600
Subject: [LLVMbugs] [Bug 6108] New: Broken __mode__ (__DI__) on 64bit
	platforms
Message-ID: <bug-6108-206@http.llvm.org/bugs/>

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

           Summary: Broken __mode__ (__DI__) on 64bit platforms
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu, zhanyong.wan at gmail.com


An integer with this attribute in Clang will not be the same fundamental type
as 'long int', and instead will be 'long long'.

Testcase:
% cat test.cpp
typedef int int64_t __attribute__ ((__mode__ (__DI__)));
typedef long int intptr_t;
void f(int64_t* x) { (void)x; }
int test(intptr_t* y) { f(y); }
% clang++ -fsyntax-only -m64 test.cpp   
test.cpp:4:25: error: no matching function for call to 'f'
int test(intptr_t* y) { f(y); }
                        ^
test.cpp:3:6: note: candidate function not viable: no known conversion from
'intptr_t *' to
      'int64_t *' for 1st argument
void f(int64_t* x) { (void)x; }
     ^
2 diagnostics generated.


Useful program showing what is actually happening, and also highlighting *yet
another* aspect of this bug:

% cat ull.cpp 
#include <iostream>
#include <typeinfo>

typedef int my_int64_t __attribute__ ((__mode__ (__DI__)));
typedef long int my_intptr_t;

int main(void) {
  std::cout << typeid(long int).name() << "\n";
  std::cout << typeid(int __attribute__ ((__mode__ (__DI__)))).name() << "\n";
  std::cout << typeid(long long).name() << "\n";
  std::cout << typeid(my_int64_t).name() << "\n";
  std::cout << typeid(my_intptr_t).name() << "\n";
  return 0;
}
% clang++ -m64 ull.cpp -o ull; ./ull
l
i
x
x
l

The typeid seems to change based on whether or not its seen through a typedef.
=[


-- 
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 Jan 21 23:59:50 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 21 Jan 2010 23:59:50 -0600
Subject: [LLVMbugs] [Bug 6109] New: llvm-gcc fails to compile libgcc on
 linux arm (aapcs)
Message-ID: <bug-6109-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc fails to compile libgcc on linux arm (aapcs)
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

Attaching the .i too since the bug might be in llvm-gcc.
------------------------------
./cc1 -fpreprocessed libgcov.i -quiet -dumpbase libgcov.c -auxbase-strip
libgcc/./_gcov.o -g -g -O2 -O2 -O2 -W -Wall -Wwrite-strings -Wstrict-prototypes
-Wmissing-prototypes -Wold-style-definition -version -fPIC -o libgcov.s
GNU C version 4.2.1 (Based on Apple Inc. build 5658) (LLVM build)
(arm-none-linux-gnueabi)
        compiled by GNU C version 4.2.4 (Ubuntu 4.2.4-1ubuntu4).
GGC heuristics: --param ggc-min-expand=150 --param ggc-min-heapsize=131072
Compiler executable checksum: 733941845f500241ed6fb8c33dff1192
Instruction does not dominate all uses!
  %lsr.iv.next485 = add i32 %lsr.iv484, 131072    ; <i32> [#uses=2]
  %lsr.iv484 = phi i32 [ 27197440, %bb78.preheader ], [ %lsr.iv.next485, %bb77
] ; <i32> [#uses=1]
Broken module found, compilation aborted!
../../llvm-gcc-4.2/gcc/libgcov.c:644: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs/> for instructions.
--------------------------------
Using -O0 + llc works. Opt fails:

pt -std-compile-opts libgcov.ll -o test.ll
0  opt             0x0000000000ba096a
1  opt             0x0000000000ba0f06
2  libpthread.so.0 0x00007fc9c28237d0
3  opt             0x0000000000794e4e llvm::Value::getValueID() const + 12
4  opt             0x0000000000794e6d bool llvm::isa_impl<llvm::Constant,
llvm::Value>(llvm::Value const&) + 21
5  opt             0x00000000007955f9 llvm::isa_impl_wrap<llvm::Constant,
llvm::Value const, llvm::Value const>::doit(llvm::Value const&) + 21
6  opt             0x0000000000795613 bool
llvm::isa_impl_cl<llvm::Value>::isa<llvm::Constant>(llvm::Value const&) + 21
7  opt             0x000000000079562d bool
llvm::isa_impl_cl<llvm::Value*>::isa<llvm::Constant>(llvm::Value*) + 21
8  opt             0x00000000007cac0c bool llvm::isa<llvm::Constant,
llvm::Value*>(llvm::Value* const&) + 24
9  opt             0x00000000007cb469 llvm::cast_retty<llvm::Constant,
llvm::Value*>::ret_type llvm::dyn_cast<llvm::Constant,
llvm::Value*>(llvm::Value* const&) + 21
10 opt             0x0000000000b4bfbe
11 opt             0x0000000000b5257e
12 opt             0x0000000000b5259d
13 opt             0x0000000000b52924
14 opt             0x0000000000b52a3c
15 opt             0x0000000000b52a81
16 opt             0x0000000000b52ad6
17 opt             0x0000000000b52b1b
18 opt             0x0000000000b53492
19 opt             0x0000000000b534eb
20 opt             0x0000000000b21168
llvm::FPPassManager::runOnFunction(llvm::Function&) + 336
21 opt             0x0000000000b2132f
llvm::FPPassManager::runOnModule(llvm::Module&) + 81
22 opt             0x0000000000b20e54
llvm::MPPassManager::runOnModule(llvm::Module&) + 372
23 opt             0x0000000000b22c83 llvm::PassManagerImpl::run(llvm::Module&)
+ 111
24 opt             0x0000000000b22ce5 llvm::PassManager::run(llvm::Module&) +
33
25 opt             0x00000000007a27c2 main + 3488
26 libc.so.6       0x00007fc9c1b331c4 __libc_start_main + 244
27 opt             0x0000000000794619


bugpoint crashes too


-- 
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 Jan 22 00:36:05 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 00:36:05 -0600
Subject: [LLVMbugs] [Bug 888] [passmgr] Eliminate use of typeid/dynamic_cast
In-Reply-To: <bug-888-206@http.llvm.org/bugs/>
Message-ID: <201001220636.o0M6a5kN020260@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #11 from Chris Lattner <clattner at apple.com>  2010-01-22 00:36:04 ---
Passmanager no longer uses RTTI.


-- 
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 Jan 22 02:15:25 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 02:15:25 -0600
Subject: [LLVMbugs] [Bug 6111] New: ARM backend miscompiles indirect call
Message-ID: <bug-6111-206@http.llvm.org/bugs/>

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

           Summary: ARM backend miscompiles indirect call
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vargaz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

To reproduce:

llvm-as bug.ll && llc -march=arm bug.bc && cat bug.s

The indirect call in the testcase is compiled as:

mov     lr, pc
bx      lr

which skips the call.


-- 
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 Jan 22 03:48:40 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 03:48:40 -0600
Subject: [LLVMbugs] [Bug 6112] New: llvm-gcc: cast of pointer to constant
 value fails in llvm BitcodeWriter.cpp: 714
Message-ID: <bug-6112-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc: cast of pointer to constant value fails in
                    llvm BitcodeWriter.cpp: 714
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: martijn at martijnrutten.com
                CC: llvmbugs at cs.uiuc.edu


llvm-gcc (cc1) fails when writing bitcode for the test-suite application
MultiSource/Applications/Burg/main.c with -g and optimization > O0 enabled. The
normal testsuite compilation without -g compiles fine.

See the debug trace below. 
llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:714 "const Constant *C =
cast<Constant>(V);" fails with 'V' being a pointer type which is not a
constant.

How to reproduce:

cd llvm/projects/llvm-test/MultiSource/Applications/Burg
llvm-gcc -c -g -O1 main.c -emit-llvm

llvm-gcc output:

main.c: In function 'main':
main.c:22: warning: return type of 'main' is not 'int'
cc1: /home1/martijn/work/llvm-svn/llvm/include/llvm/Support/Casting.h:199:
typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
llvm::Constant, Y = const llvm::Value*]: Assertion `isa<X>(Val) && "cast<Ty>()
argument of incompatible type!"' failed.
main.c: At top level:
main.c:182: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <URL:http://llvm.org/bugs/> for instructions.

Debug trace:

Starting program:
/home1/martijn/work/llvm-svn/install/libexec/gcc/i686-pc-linux-gnu/4.2.1/cc1
-quiet -iprefix
/home1/martijn/work/llvm-svn/llvm-gcc-obj/gcc/../lib/gcc/i686-pc-linux-gnu/4.2.1/
main.c -emit-llvm-bc -o main.o -quiet -dumpbase main.c -mtune=generic -auxbase
main -g -O1
[Thread debugging using libthread_db enabled]
main.c: In function 'main':
main.c:22: warning: return type of 'main' is not 'int'
cc1: /home1/martijn/work/llvm-svn/llvm/include/llvm/Support/Casting.h:199:
typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
llvm::Constant, Y = const llvm::Value*]: Assertion `isa<X>(Val) && "cast<Ty>()
argument of incompatible type!"' failed.

Program received signal SIGABRT, Aborted.
0xb7fe2430 in __kernel_vsyscall ()
(gdb) bt
#0  0xb7fe2430 in __kernel_vsyscall ()
#1  0xb7d614d1 in raise () from /lib/tls/i686/cmov/libc.so.6
#2  0xb7d64932 in abort () from /lib/tls/i686/cmov/libc.so.6
#3  0xb7d5a648 in __assert_fail () from /lib/tls/i686/cmov/libc.so.6
#4  0x08570a9f in llvm::cast_retty<llvm::Constant, llvm::Value
const*>::ret_type llvm::cast<llvm::Constant, llvm::Value const*>(llvm::Value
const* const&)
    ()
#5  0x0856896a in WriteConstants (FirstVal=59, LastVal=176, VE=..., Stream=...,
isGlobal=true)
    at
/home1/martijn/work/llvm-svn/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:714
#6  0x08569e5e in WriteModuleConstants (VE=..., Stream=...) at
/home1/martijn/work/llvm-svn/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:894
#7  0x0856cd81 in WriteModule (M=0x91549c8, Stream=...) at
/home1/martijn/work/llvm-svn/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:1474
#8  0x0856d2c1 in llvm::WriteBitcodeToStream (M=0x91549c8, Stream=...) at
/home1/martijn/work/llvm-svn/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:1599
#9  0x0856d146 in llvm::WriteBitcodeToFile (M=0x91549c8, Out=...) at
/home1/martijn/work/llvm-svn/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:1569
#10 0x08564d5b in runOnModule (this=0x9151e00, M=...) at
/home1/martijn/work/llvm-svn/llvm/lib/Bitcode/Writer/BitcodeWriterPass.cpp:29
#11 0x08ccb336 in llvm::MPPassManager::runOnModule (this=0x91aa790, M=...) at
/home1/martijn/work/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1409
#12 0x08ccb810 in llvm::PassManagerImpl::run (this=0x91ab278, M=...) at
/home1/martijn/work/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1490
#13 0x08ccbaf5 in llvm::PassManager::run (this=0x916ba68, M=...) at
/home1/martijn/work/llvm-svn/llvm/lib/VMCore/PassManager.cpp:1519
#14 0x083ff2ff in llvm_asm_file_end () at
../../llvm-gcc/gcc/llvm-backend.cpp:955
#15 0x083a8f56 in compile_file (argc=16, argv=0xbffff214) at
../../llvm-gcc/gcc/toplev.c:1193
#16 do_compile (argc=16, argv=0xbffff214) at ../../llvm-gcc/gcc/toplev.c:2269
#17 toplev_main (argc=16, argv=0xbffff214) at ../../llvm-gcc/gcc/toplev.c:2301
#18 0x080e5aa7 in main (argc=16, argv=0xbffff214) at
../../llvm-gcc/gcc/llvm-main.cpp:47
(gdb) f 5
#5  0x0856896a in WriteConstants (FirstVal=59, LastVal=176, VE=..., Stream=...,
isGlobal=true)
    at
/home1/martijn/work/llvm-svn/llvm/lib/Bitcode/Writer/BitcodeWriter.cpp:714
714         const Constant *C = cast<Constant>(V);

(gdb) p *V->VTy->Ty
$1 = {<llvm::AbstractTypeUser> = {_vptr.AbstractTypeUser = 0x90764e8}, ID =
llvm::Type::PointerTyID, Abstract = false, SubclassData = 0, RefCount = 0, 
  Context = @0x912ab38, ForwardType = 0x0, AbstractTypeUsers =
{<std::_Vector_base<llvm::AbstractTypeUser*,
std::allocator<llvm::AbstractTypeUser*> >> = {
      _M_impl = {<std::allocator<llvm::AbstractTypeUser*>> =
{<__gnu_cxx::new_allocator<llvm::AbstractTypeUser*>> = {<No data fields>}, <No
data fields>}, 
        _M_start = 0x0, _M_finish = 0x0, _M_end_of_storage = 0x0}}, <No data
fields>}, NumContainedTys = 1, ContainedTys = 0x9188f30}


Environment:

llvm-gcc revision: r94023
llvm revision: r94077
uname -a: Linux martijn 2.6.31-17-generic-pae #54-Ubuntu SMP Thu Dec 10
17:23:29 UTC 2009 i686 GNU/Linux
gcc --version: gcc (Ubuntu 4.4.1-4ubuntu8) 4.4.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  Fri Jan 22 11:44:00 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 11:44:00 -0600
Subject: [LLVMbugs] [Bug 6114] New: XCore AsmPrinter - Missing break in
 printOperand causes failure
Message-ID: <bug-6114-206@http.llvm.org/bugs/>

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

           Summary: XCore AsmPrinter - Missing break in printOperand causes
                    failure
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: mwb.cde at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4092)
 --> (http://llvm.org/bugs/attachment.cgi?id=4092)
Add missing break statement to XCore AsmPrinter

XCore/AsmPrinter/XCoreAsmPrinter.cpp/printOperand is missing a break statement,
causing an assertion in GetBlockAddressSymbol when it is passed a
JumpTableIndex.

Reproduce by running llc -march=xcore on
tests/CodeGen/ARM/2009-02-16-SpillerBug.ll.

Attached patch adds the break.


-- 
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 Jan 22 11:46:00 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 11:46:00 -0600
Subject: [LLVMbugs] [Bug 6115] New: What does 'Cannot yet select: intrinsic
 %llvm.x86.sse41. dpps' mean?
Message-ID: <bug-6115-206@http.llvm.org/bugs/>

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

           Summary: What does 'Cannot yet select: intrinsic
                    %llvm.x86.sse41.dpps' mean?
           Product: Documentation
           Version: 2.6
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm at henning-thielemann.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4093)
 --> (http://llvm.org/bugs/attachment.cgi?id=4093)
LLVM assembly program that causes llvmc to abort with the strange message

In the attached LLVM assembly program I have manually replaced some vector
manipulations by the dot product instruction of ix86's SSE4 extension.
When I compile the file I get
$  llvmc -S dpps-test.ll
Cannot yet select: LLVM ERROR: Cannot yet select: intrinsic
%llvm.x86.sse41.dpps

What does it mean? Have I used the intrinsic in a wrong way, or is it just not
implemented? Or is the compiler uncertain about the CodeGen target?


-- 
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 Jan 22 13:12:07 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 13:12:07 -0600
Subject: [LLVMbugs] [Bug 6114] XCore AsmPrinter - Missing break in
 printOperand causes failure
In-Reply-To: <bug-6114-206@http.llvm.org/bugs/>
Message-ID: <201001221912.o0MJC7nW004628@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-22 13:12:07 ---
applied in r94197, 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  Fri Jan 22 17:33:24 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 17:33:24 -0600
Subject: [LLVMbugs] [Bug 6109] llvm-gcc fails to compile libgcc on linux arm
	(aapcs)
In-Reply-To: <bug-6109-206@http.llvm.org/bugs/>
Message-ID: <201001222333.o0MNXOUG015504@zion.cs.uiuc.edu>

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


Rafael ??vila de Esp??ndola <rafael.espindola at gmail.com> changed:

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




--- Comment #5 from Rafael ??vila de Esp??ndola <rafael.espindola at gmail.com>  2010-01-22 17:33:23 ---
It is 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  Fri Jan 22 18:06:56 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 18:06:56 -0600
Subject: [LLVMbugs] [Bug 5996] ARM: llvm-gcc assertion failure converting a
	union type
In-Reply-To: <bug-5996-206@http.llvm.org/bugs/>
Message-ID: <201001230006.o0N06uTL016759@zion.cs.uiuc.edu>

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


Bob Wilson <bob.wilson at apple.com> changed:

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




--- Comment #1 from Bob Wilson <bob.wilson at apple.com>  2010-01-22 18:06:56 ---
Fixed in llvm-gcc-4.2 svn r94257.


-- 
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 Jan 22 18:27:34 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 22 Jan 2010 18:27:34 -0600
Subject: [LLVMbugs] [Bug 6104] clang's Version.h shouldn't be subversion
	specific
In-Reply-To: <bug-6104-206@http.llvm.org/bugs/>
Message-ID: <201001230027.o0N0RY3x017530@zion.cs.uiuc.edu>

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


Daniel Dunbar <daniel at zuster.org> changed:

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




--- Comment #1 from Daniel Dunbar <daniel at zuster.org>  2010-01-22 18:27:34 ---
Ted fixed this: http://llvm.org/viewvc/llvm-project?view=rev&revision=94231


-- 
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 Jan 23 11:56:13 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 11:56:13 -0600
Subject: [LLVMbugs] [Bug 6119] New: Assertion failed: (isa<X>(Val) &&
 "cast<Ty>() argument of incompatible type!"), function cast,
 file /data/home/rdivacky/  llvm/include/llvm/Support/Casting.h, line 199.
Message-ID: <bug-6119-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (isa<X>(Val) && "cast<Ty>() argument
                    of incompatible type!"), function cast, file
                    /data/home/rdivacky/llvm/include/llvm/Support/Casting.h,
                    line 199.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4095)
 --> (http://llvm.org/bugs/attachment.cgi?id=4095)
test case

when compiling with clang the attached test file I am getting:

pes delta$ clang -O2 000.c
000.c:38:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
note_sets (rtx x, rtx set __attribute__ ((__unused__)), void *data)
^
000.c:40:1: warning: control reaches end of non-void function [-Wreturn-type]
}
^
000.c:42:1: warning: type specifier missing, defaults to 'int' [-Wimplicit-int]
scan_rtx_reg (rtx insn, rtx *loc, enum reg_class cl,
^
000.c:53:7: warning: non-void function 'scan_rtx_reg' should return a value
[-Wreturn-type]
      return;
      ^
000.c:68:1: warning: control may reach end of non-void function [-Wreturn-type]
}
^
Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"),
function cast, file /data/home/rdivacky/llvm/include/llvm/Support/Casting.h,
line 199.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name 000.c
-mrelocation-model static -mdisable-fp-elim -munwind-tables -target-cpu x86-64
-resource-dir /usr/local/lib/clang/1.1 -O2 -fmessage-length 152 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-7kADvx.s -x c 000.c 
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module '000.c'.
4.      Running pass 'Jump Threading' on function '@scan_rtx_reg'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

I am not sure about the bug component, feel free to recategorize


-- 
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 Jan 23 13:11:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 13:11:09 -0600
Subject: [LLVMbugs] [Bug 6120] New: Call to noreturn pointer not marked
	noreturn
Message-ID: <bug-6120-206@http.llvm.org/bugs/>

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

           Summary: Call to noreturn pointer not marked noreturn
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Testcase:
void (*a)(void) __attribute((noreturn));
void b() { a(); }

Code generated by clang -O2:
define void @b() nounwind {
entry:
  %tmp = load void ()** @a                        ; <void ()*> [#uses=1]
  tail call void %tmp() nounwind
  ret void
}

For comparison, code generated by llvm-gcc -O2:
define void @b() nounwind {
entry:
  %0 = load void ()** @a, align 4                 ; <void ()*> [#uses=1]
  tail call void %0() noreturn nounwind
  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  Sat Jan 23 13:22:33 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 13:22:33 -0600
Subject: [LLVMbugs] [Bug 6119] three jump threading crashes
In-Reply-To: <bug-6119-206@http.llvm.org/bugs/>
Message-ID: <201001231922.o0NJMXm5005175@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
            Summary|Assertion failed:           |three jump threading crashes
                   |(isa<X>(Val) && "cast<Ty>() |
                   |argument of incompatible    |
                   |type!"), function cast, file|
                   |/data/home/rdivacky/llvm/inc|
                   |lude/llvm/Support/Casting.h,|
                   |line 199.                   |




--- Comment #8 from Chris Lattner <clattner at apple.com>  2010-01-23 13:22:33 ---
Last fix here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100118/094934.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 Jan 23 14:49:21 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 14:49:21 -0600
Subject: [LLVMbugs] [Bug 6121] New: Operations among __m128 and -ffast-math
Message-ID: <bug-6121-206@http.llvm.org/bugs/>

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

           Summary: Operations among __m128 and -ffast-math
           Product: new-bugs
           Version: 2.6
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Keywords: code-quality
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bearophile at mailas.com
                CC: llvmbugs at cs.uiuc.edu


In the attach there is a small C++ program that performs few operators (* and
+) among SSE registers, that contains two versions of a function that computes
sin in a naive way (the program doesn't run, there's no main function, but it's
not hard to write a simple one). The first function is not manually optimized,
the second is a little more optimized.

If I compile both the code with llvm-g++ and -ffast-math those functions get
compiled to 66 and 43 instructions long. Without -ffast-math they become 85 and
43 instructions. So -ffast-math is doing something, but in theory when using
-ffast-math LLVM can compile the first function to something similar to the
second function. I can be wrong, I am not expert about 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 bugzilla-daemon at cs.uiuc.edu  Sat Jan 23 16:16:19 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 16:16:19 -0600
Subject: [LLVMbugs] [Bug 6122] New: libclang_rt support for FreeBSD
Message-ID: <bug-6122-206@http.llvm.org/bugs/>

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

           Summary: libclang_rt support for FreeBSD
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Here are two initial patch for compiler_rt and clang to use it on FreeBSD.
This was modeled after the Darwin support. Tested with a buildworld on FreeBSD.

Integration in FreeBSD sources will probably look different.


-- 
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 Jan 23 18:23:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 18:23:59 -0600
Subject: [LLVMbugs] [Bug 6121] Operations among __m128 and -ffast-math
In-Reply-To: <bug-6121-206@http.llvm.org/bugs/>
Message-ID: <201001240023.o0O0Nxtf016402@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #2 from Chris Lattner <clattner at apple.com>  2010-01-23 18:23:58 ---
This requires floating point reassociation.  We have a reassociation pass but
don't know about -ffast-math when it runs.  This is already covered by the
Targets/README.txt file.


-- 
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 Jan 23 19:50:58 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 19:50:58 -0600
Subject: [LLVMbugs] [Bug 6034] crash on invalid switch statement
In-Reply-To: <bug-6034-206@http.llvm.org/bugs/>
Message-ID: <201001240150.o0O1owRP019449@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
           Keywords|                            |crash-on-invalid
         Resolution|                            |FIXED




--- Comment #3 from Chris Lattner <clattner at apple.com>  2010-01-23 19:50:56 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20100118/026685.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 Jan 23 20:23:51 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 20:23:51 -0600
Subject: [LLVMbugs] [Bug 6016] llvm.x86.ssse3.pabs intrinsics should be
	removed
In-Reply-To: <bug-6016-206@http.llvm.org/bugs/>
Message-ID: <201001240223.o0O2Np6Y020596@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #4 from Chris Lattner <clattner at apple.com>  2010-01-23 20:23:51 ---
Actually, I don't think this is a good idea.  relying on pattern matching would
increase the risk that the pattern would get broken by random passes.  It is
still a good idea to have a target dag combine that forms these when done "the
hard way" of course.


-- 
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 Jan 23 20:27:29 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 20:27:29 -0600
Subject: [LLVMbugs] [Bug 5945] Missed optimisation on clamp to zero
In-Reply-To: <bug-5945-206@http.llvm.org/bugs/>
Message-ID: <201001240227.o0O2RToP020745@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-23 20:27:29 ---
Moved to the PPC README.txt file:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100118/094950.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 Jan 23 20:28:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 20:28:59 -0600
Subject: [LLVMbugs] [Bug 5927] error in backend: Cannot yet select
In-Reply-To: <bug-5927-206@http.llvm.org/bugs/>
Message-ID: <201001240228.o0O2Sxih020813@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-23 20:28:59 ---
This works for me with mainline.  If it still fails for you, please reopen and
include a bc file produced with -emit-llvm -O0, 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 Jan 23 21:24:08 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 21:24:08 -0600
Subject: [LLVMbugs] [Bug 6125] New: CIndex should implement iteration based
 interfaces for cursors
Message-ID: <bug-6125-206@http.llvm.org/bugs/>

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

           Summary: CIndex should implement iteration based interfaces for
                    cursors
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: AST
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Currently CIndex implements a callback interface for visiting the children of
cursors, with some helper features to recurse / break the visitation. This may
be "handy" for C, but it is cumbersome as an API for wrapping in other
languages, especially ones which have decent iteration support. It would be
nice to support an iteration interface which exposed an actual iterator object.
Clients can then implement whatever traversal scheme they like, and wrap it in
helper methods if need be.


-- 
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 Jan 23 21:26:20 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 23 Jan 2010 21:26:20 -0600
Subject: [LLVMbugs] [Bug 6126] New: ice: argument of incompatible type!
Message-ID: <bug-6126-206@http.llvm.org/bugs/>

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

           Summary: ice: argument of incompatible type!
           Product: new-bugs
           Version: trunk
          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


regehr at john-home:~/volatile/bugs/tmp262$ clang -O small.c
clang: /home/regehr/z/tmp/llvm-r94324/include/llvm/Support/Casting.h:199:
typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
llvm::AllocaInst, Y = llvm::Value*]: Assertion `isa<X>(Val) && "cast<Ty>()
argument of incompatible type!"' failed.
0  clang 0x09111cb8
Stack dump:
0.      Program arguments: /home/regehr/z/tmp/llvm-gcc-r94324-install/bin/clang
-cc1 -triple i386-pc-linux-gnu -S -disable-free -main-file-name small.c
-mrelocation-model static -mdisable-fp-elim -target-cpu pentium4 -resource-dir
/home/regehr/z/tmp/llvm-gcc-r94324-install/lib/clang/1.1 -O2 -fmessage-length
80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
/tmp/cc-5RrhCE.s -x c small.c 
1.      <eof> parser at end of file
2.      Per-function optimization
3.      Running pass 'Scalar Replacement of Aggregates' on function '@func_36'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)

regehr at john-home:~/volatile/bugs/tmp262$ cat small.c

struct S0
{
  const int uint32f0;
  unsigned char f1;
};

int g_4[6][9][1][1][1];
int g_7;
int *g_12 = &g_4[5][8][0][0][0];

int func_75 (int, int, struct S0);

int *func_36 (uint16p38)
{
  int l_118[10];
  int *const l_121 = &g_7;
  struct S0 l_122[1][1][1] = {
  };
  l_118[1] = 0;
  *g_12 = func_75 (l_118[1], *g_12 < (int)l_121, l_122[0][0][0]);
  return 0;
}

regehr at john-home:~/volatile/bugs/tmp262$ clang -v

clang version 1.1 (trunk 94324)
Target: i386-pc-linux-gnu
Thread model: posix


-- 
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 Jan 24 00:00:12 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 24 Jan 2010 00:00:12 -0600
Subject: [LLVMbugs] [Bug 6129] New: Explicit alignment not respected by
	PowerPC backend
Message-ID: <bug-6129-206@http.llvm.org/bugs/>

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

           Summary: Explicit alignment not respected by PowerPC backend
           Product: libraries
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: whitehorn at wisc.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4103)
 --> (http://llvm.org/bugs/attachment.cgi?id=4103)
Test case

Compiling the attached test program with LLVM/clang results in bar, explicitly
marked for 128 byte alignment, not ending up 128-byte aligned.

Output on x86:
bar: 0x600a80
bar % 128: 0

Output on PowerPC:
bar: 0x1810870
bar % 128: 112

Output on PowerPC when compiled with gcc:
bar: 0x1810a80
bar % 128: 0

Declaration of bar from the produced LLVM IR:
@bar = common global [75 x i8] zeroinitializer, align 128 ; <[75 x i8]*>
[#uses=
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  Sun Jan 24 11:44:14 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 24 Jan 2010 11:44:14 -0600
Subject: [LLVMbugs] [Bug 6132] New: Assertion on definition of method of
 inner class in outer class template
Message-ID: <bug-6132-206@http.llvm.org/bugs/>

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

           Summary: Assertion on definition of method of inner class in
                    outer class template
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: crash-on-invalid
          Severity: normal
          Priority: P2
         Component: Basic
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sebastian.redl at getdesigned.at
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4107)
 --> (http://llvm.org/bugs/attachment.cgi?id=4107)
Test Case

The attached test case leads to an assertion.


-- 
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 Jan 24 12:24:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 24 Jan 2010 12:24:48 -0600
Subject: [LLVMbugs] [Bug 5156] clang crashes on incorrect code
In-Reply-To: <bug-5156-206@http.llvm.org/bugs/>
Message-ID: <201001241824.o0OIOmLW026284@zion.cs.uiuc.edu>

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


Fariborz Jahanian <fjahanian at apple.com> changed:

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




--- Comment #2 from Fariborz Jahanian <fjahanian at apple.com>  2010-01-24 12:24:48 ---
It seems to have resolved itself. Closing.

> Is this still a problem?
> 


-- 
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 Jan 24 14:54:59 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 24 Jan 2010 14:54:59 -0600
Subject: [LLVMbugs] [Bug 6129] Explicit alignment not respected by PowerPC
	backend
In-Reply-To: <bug-6129-206@http.llvm.org/bugs/>
Message-ID: <201001242054.o0OKsxNW031902@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #4 from Chris Lattner <clattner at apple.com>  2010-01-24 14:54:59 ---
Fixed in r94381, please verify.


-- 
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 Jan 24 19:21:58 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 24 Jan 2010 19:21:58 -0600
Subject: [LLVMbugs] [Bug 6134] New: missing alginment directive
Message-ID: <bug-6134-206@http.llvm.org/bugs/>

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

           Summary: missing alginment directive
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


For a global like

@bar = common global [75 x i8] zeroinitializer, align 128 

The ARM backend is producing

        .type   bar,%object
        .comm   bar,75

The alignment is missing.


-- 
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 Jan 24 20:29:45 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 24 Jan 2010 20:29:45 -0600
Subject: [LLVMbugs] [Bug 6134] missing alginment directive
In-Reply-To: <bug-6134-206@http.llvm.org/bugs/>
Message-ID: <201001250229.o0P2TjUa011340@zion.cs.uiuc.edu>

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


Rafael ??vila de Esp??ndola <rafael.espindola at gmail.com> changed:

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




--- Comment #1 from Rafael ??vila de Esp??ndola <rafael.espindola at gmail.com>  2010-01-24 20:29:45 ---
Fix with revision r94400 (on ELF at least)


-- 
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 Jan 25 02:52:53 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Jan 2010 02:52:53 -0600
Subject: [LLVMbugs] [Bug 6136] New: Abort trap in Kaleidoscope/toy example,
 "at the end"
Message-ID: <bug-6136-206@http.llvm.org/bugs/>

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

           Summary: Abort trap in Kaleidoscope/toy example,  "at the end"
           Product: new-bugs
           Version: 2.6
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: albert at mietus.nl
                CC: llvmbugs at cs.uiuc.edu


The toy-example, build WITH interpreter (and probably without a working native
lib; see emails) seems to work, until one terminates the program with
end-of-file, (either ^D or ^Z)

As can be seen below, this results in a abort-trap.

This happens both with the 2.6 "PreBuid" (apple OS X 10.5.8)  and a "self build
2.6 Debug" (same) libs.

--------
 ./toy-example26
ready> ;
ready> 2+4;
ready> Evaluated to 6.000000
ready> <<EOF>>
ready> ; ModuleID = 'my cool jit'

define double @0() {
entry:
  ret double 6.000000e+00
}
While deleting: double ()* %
An asserting value handle still pointed to this value!
UNREACHABLE executed at Value.cpp:492!
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  Mon Jan 25 10:37:31 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Jan 2010 10:37:31 -0600
Subject: [LLVMbugs] [Bug 6137] New: unnecessary moves between XMM and
 general registers by x86 back end
Message-ID: <bug-6137-206@http.llvm.org/bugs/>

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

           Summary: unnecessary moves between XMM and general registers by
                    x86 back end
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: brian.sumner at amd.com
                CC: llvmbugs at cs.uiuc.edu


For the following C code:

---- example.c ----------------------
typedef unsigned int uint;
static inline float as_float(uint u) { union { float f; uint u; } v; v.u = u;
return v.f; }
static inline uint as_uint(float f) { union { float f; uint u; } v; v.f = f;
return v.u; }

static float
r(float x)
{
    uint u = as_uint(x);
    uint a = u & 0x7fffffffU;
    float v = (as_float(a) + 0x1.0p+23F) - 0x1.0p+23F;
    return a > 0x4affffffU ? x : as_float(as_uint(v) | (u ^ a));
}
---------------------------------------
The x86 back end is generating several unnecessary MOVD instructions to move
data between XMM and general purpose registers.  These moves are unnecessary
because the argument arrives in an XMM register, the result returns in an XMM
register, and all the operations performed can be done with XMM register
operations.

I would like the x86 back end to generate the same code for the function above
as it does for the following function which performs the same operation
entirely in XMM registers:
---- recoded-example.c -------------------------
#include <xmmintrin.h>
static inline __m128i as_m128i(__m128 f) { union { __m128i i; __m128 f; } v;
v.f=f; return v.i; }
static inline __m128 as_m128(__m128i i) { union { __m128i i; __m128 f; } v;
v.i=i; return v.f; }

static float
r(float xx)
{
    __m128 t = _mm_set_ss(0x1.0p+23F);
    __m128 x = _mm_set_ss(xx);
    __m128i a = _mm_and_si128(as_m128i(x), _mm_set1_epi32(0x7fffffff));
    __m128 v = _mm_sub_ss(_mm_add_ss(as_m128(a), t), t);
    a = _mm_xor_si128(as_m128i(x), a);
    v = as_m128(_mm_or_si128(as_m128i(v), a));
    __m128i m = _mm_cmpgt_epi32(a, _mm_set1_epi32(0x4affffff));
    v = as_m128(_mm_andnot_si128(m, as_m128i(v)));
    x = as_m128(_mm_and_si128(m, as_m128i(x)));
    x = as_m128(_mm_or_si128(as_m128i(x), as_m128i(v)));
    return _mm_cvtss_f32(x);
}
--------------------------------------------------------

Calling one of these functions in a loop (where it is probably inlined) of 1G
iterations with various compilers on an Phenom II processor, I get:

gcc 4.4.1:   orig:  7.99  new:  7.32
icc 11.0:    orig:  5.32  new: 20.50
clang trunk: orig: 11.53  new:  6.82


-- 
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 Jan 25 10:53:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Jan 2010 10:53:46 -0600
Subject: [LLVMbugs] [Bug 6138] New: x86 *mmintrin.h header problems
Message-ID: <bug-6138-206@http.llvm.org/bugs/>

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

           Summary: x86 *mmintrin.h header problems
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: brian.sumner at amd.com
                CC: llvmbugs at cs.uiuc.edu


There are a few problems in the x86 intrinsic headers emmintrin.h and
xmmintrin.h

This short patch will clean them up:
----------------- headers.patch -----------------------------
diff -u include/emmintrin.h include-fixed/emmintrin.h
--- include/emmintrin.h 2010-01-25 08:50:56.000000000 -0800
+++ include-fixed/emmintrin.h   2010-01-25 08:49:25.000000000 -0800
@@ -35,7 +35,7 @@

 typedef int __v4si __attribute__((__vector_size__(16)));
 typedef short __v8hi __attribute__((__vector_size__(16)));
-typedef char __v16qi __attribute__((__vector_size__(16)));
+typedef signed char __v16qi __attribute__((__vector_size__(16)));

 static inline __m128d __attribute__((__always_inline__, __nodebug__))
 _mm_add_sd(__m128d a, __m128d b)
@@ -1024,12 +1024,6 @@
 }

 static inline __m128i __attribute__((__always_inline__, __nodebug__))
-_mm_set_epi64x(long long q1, long long q0)
-{
-  return (__m128i){ q0, q1 };
-}
-
-static inline __m128i __attribute__((__always_inline__, __nodebug__))
 _mm_set_epi64(__m64 q1, __m64 q0)
 {
   return (__m128i){ (long long)q0, (long long)q1 };
@@ -1060,15 +1054,15 @@
 }

 static inline __m128i __attribute__((__always_inline__, __nodebug__))
-_mm_set1_epi64x(long long q)
+_mm_set1_epi64(__m64 q)
 {
-  return (__m128i){ q, q };
+  return (__m128i){ (long long)q, (long long)q };
 }

 static inline __m128i __attribute__((__always_inline__, __nodebug__))
-_mm_set1_epi64(__m64 q)
+_mm_set1_epi64x(long long q)
 {
-  return (__m128i){ (long long)q, (long long)q };
+  return (__m128i){ q, q };
 }

 static inline __m128i __attribute__((__always_inline__, __nodebug__))
Only in include: .svn
diff -u include/xmmintrin.h include-fixed/xmmintrin.h
--- include/xmmintrin.h 2010-01-25 08:50:56.000000000 -0800
+++ include-fixed/xmmintrin.h   2010-01-25 08:49:15.000000000 -0800
@@ -895,7 +895,7 @@
   (row0) = _mm_movelh_ps(tmp0, tmp2); \
   (row1) = _mm_movehl_ps(tmp2, tmp0); \
   (row2) = _mm_movelh_ps(tmp1, tmp3); \
-  (row3) = _mm_movelh_ps(tmp3, tmp1); \
+  (row3) = _mm_movehl_ps(tmp3, tmp1); \
 } while (0)

 /* Ugly hack for backwards-compatibility (compatible with gcc) */
----------------------- end of 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  Mon Jan 25 12:27:36 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Jan 2010 12:27:36 -0600
Subject: [LLVMbugs] [Bug 6126] SROA assertion: argument of incompatible type!
In-Reply-To: <bug-6126-206@http.llvm.org/bugs/>
Message-ID: <201001251827.o0PIRaju030476@zion.cs.uiuc.edu>

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


Bob Wilson <bob.wilson at apple.com> changed:

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




--- Comment #4 from Bob Wilson <bob.wilson at apple.com>  2010-01-25 12:27:35 ---
The problem here is that Value::getUnderlyingObject was changed to only look
back through 6 instructions:

r69151 | nicholas | 2009-04-14 23:23:41 -0700 (Tue, 14 Apr 2009) | 3 lines
Limit the number of times we're willing to chase pointers. Removes an O(n^2)
problem from instcombine.

SROA::ConvertUsesToScalar is assuming that getUnderlyingObject will always
succeed in getting back to the underlying AllocaInst.  It really needs that
information to decide how to translate the memcpy/memmove.

Fixed in svn r94433.


-- 
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 Jan 25 14:46:13 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Jan 2010 14:46:13 -0600
Subject: [LLVMbugs] [Bug 6140] New: llvm-as followed by llvm-dis turns "nsw"
 flag into "nuw"
Message-ID: <bug-6140-206@http.llvm.org/bugs/>

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

           Summary: llvm-as followed by llvm-dis turns "nsw" flag into "nuw"
           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: baldrick at free.fr
                CC: gohman at apple.com, llvmbugs at cs.uiuc.edu


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

As illustrated by the attached file sgesl.ll, applying llvm-as
followed by llvm-dis can turn nsw into nuw:

$ cat sgesl.ll | grep nuw
$ llvm-as sgesl.ll -o - | llvm-dis -o - | grep nuw
  %k_93 = sub nuw i32 %k_16, 1                    ; <i32> [#uses=1]
  %k_167 = sub nuw i32 %k_18, 1                   ; <i32> [#uses=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 Jan 25 15:55:56 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Mon, 25 Jan 2010 15:55:56 -0600
Subject: [LLVMbugs] [Bug 6140] llvm-as followed by llvm-dis turns "nsw" flag
	into "nuw"
In-Reply-To: <bug-6140-206@http.llvm.org/bugs/>
Message-ID: <201001252155.o0PLtuJK006626@zion.cs.uiuc.edu>

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


Dan Gohman <gohman at apple.com> changed:

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




--- Comment #1 from Dan Gohman <gohman at apple.com>  2010-01-25 15:55:55 ---
The bitcode reader wasn't reading the flags properly in the case of forward
references.  Fixed in r94454.


-- 
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 Jan 26 00:40:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 00:40:09 -0600
Subject: [LLVMbugs] [Bug 6108] Broken __mode__ (__DI__) on 64bit platforms
In-Reply-To: <bug-6108-206@http.llvm.org/bugs/>
Message-ID: <201001260640.o0Q6e9cW026665@zion.cs.uiuc.edu>

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


Chandler Carruth <chandlerc at gmail.com> changed:

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




--- Comment #7 from Chandler Carruth <chandlerc at gmail.com>  2010-01-26 00:40:08 ---
Fixed in r94527.


-- 
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 Jan 26 02:25:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 02:25:09 -0600
Subject: [LLVMbugs] [Bug 6144] New: GP is used before restored after a
	library call
Message-ID: <bug-6144-206@http.llvm.org/bugs/>

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

           Summary: GP is used before restored after a library call
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: ASSIGNED
          Keywords: ABI
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: bruno.cardoso at gmail.com
        ReportedBy: joe_shuchang_zhou at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


; ModuleID = 'gp.c'
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"

@.str = private constant [3 x i8] c"hi\00", align 1 ; <[3 x i8]*> [#uses=1]
@i = common global i32 0                          ; <i32*> [#uses=1]

define i32 @main() nounwind {
entry:
  %0 = tail call i32 @puts(i8* getelementptr inbounds ([3 x i8]* @.str, i32 0,
i32 0)) nounwind ; <i32> [#uses=0]
  store i32 3, i32* @i, align 4
  ret i32 0
}

declare i32 @puts(i8* nocapture) nounwind

-------------------
Code above segfaults after following commands.
llc -O0 -mcpu=r6000 -march=mips -mattr=+o32 gp.ll -o gp.s
mipsel-unknown-linux-gnu-gcc -mips3 gp.s -o gp
./gp

By GDB, it is because in assembly we have
        lw      $25, %call16(puts)($gp)
        nop
        jalr    $25
        nop
        lw      $2, %got(i)($gp)
                           ~~~~~$gp is used before restored
        nop
        lw      $3, 16($sp)
        nop
        addiu   $4, $zero, 3
        addu    $gp, $zero, $3
        sw      $4, 0($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  Tue Jan 26 03:29:38 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 03:29:38 -0600
Subject: [LLVMbugs] [Bug 6145] New: jit fails on ClamAV with an assert:
 ADT/SmallVector.h:152: T&
 llvm::SmallVectorTemplateCommon<T>::operator[](unsigned int) [with T =
 llvm::Instruction*]: Assertion `begin() + idx < end()'
Message-ID: <bug-6145-206@http.llvm.org/bugs/>

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

           Summary: jit fails on ClamAV with an assert:
                    ADT/SmallVector.h:152: T&
                    llvm::SmallVectorTemplateCommon<T>::operator[](unsigned
                    int) [with T = llvm::Instruction*]: Assertion `begin() +
                    idx < end()'
           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


Running the jit test in MultiSource/Applications/ClamAV crashes.


~/llvm-git/obj/Release/bin/lli -load ./bugpoint.safe.bc-VthxOi.llc.s.so
bugpoint.test.bc-WkE2B9                                                         
LibClamAV Warning: ***********************************************************  
LibClamAV Warning: ***  This version of the ClamAV engine is outdated.     ***  
LibClamAV Warning: *** DON'T PANIC! Read http://www.clamav.net/support/faq ***  
LibClamAV Warning: ***********************************************************  
lli: /home/edwin/llvm-git/llvm/include/llvm/ADT/SmallVector.h:152: T&
llvm::SmallVectorTemplateCommon<T>::operator[](unsigned int) [with T =
llvm::Instruction*]: Assertion `begin() + idx < end()' failed.                  
0  lli                              0x0000000000b302df                          
1  lli                              0x0000000000b30aed                          
2  libpthread.so.0                  0x0000003283c0e990                          
3  libc.so.6                        0x0000003283031f55 gsignal + 53             
4  libc.so.6                        0x0000003283034d90 abort + 384              
5  libc.so.6                        0x000000328302b07a __assert_fail + 234      
6  lli                              0x00000000004ee9f9                          
7  lli                              0x00000000004f594a
llvm::BitcodeReader::ParseFunctionBody(llvm::Function*) + 970       
8  lli                              0x00000000004fa1e4
llvm::BitcodeReader::materializeFunction(llvm::Function*, std::string*) + 324   
9  lli                              0x000000000082d3ad
llvm::JIT::getPointerToFunction(llvm::Function*) + 157              
10 lli                              0x000000000082fe95
getPointerToNamedFunction + 53                                      
11 bugpoint.safe.bc-VthxOi.llc.s.so 0x00007f9c283ce4af
12 bugpoint.safe.bc-VthxOi.llc.s.so 0x00007f9c283ce111 logg + 513
Stack dump:
0.      Program arguments: /home/edwin/llvm-git/obj/Release/bin/lli -load
./bugpoint.safe.bc-VthxOi.llc.s.so bugpoint.test.bc-WkE2B9
Aborted



*** The following functions are being miscompiled:  logg_bb37 logg_bb39
<llc><gcc>You can reproduce the problem with the command line:         
  lli -load ./bugpoint.safe.bc-VthxOi.llc.s.so bugpoint.test.bc-WkE2B9 --debug
--exclude-dir .svn --verbose
-d/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/dbdir
-r
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/clam.cab
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/clamdoc.tar.gz
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/clam.exe
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/clam.exe.bz2
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/clam-v2.rar
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/clam-v3.rar
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/clam.zip
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/README
/home/edwin/llvm-svn/llvm-commit/projects/llvm-test/MultiSource/Applications/ClamAV/inputs/rtf-test 
The shared object was created with:                                             
  llc -march=c bugpoint.safe.bc-VthxOi -o temporary.c                           
  gcc -xc temporary.c -O2 -o ./bugpoint.safe.bc-VthxOi.llc.s.so -fPIC -shared
-fno-strict-aliasing


-- 
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 Jan 26 04:50:24 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 04:50:24 -0600
Subject: [LLVMbugs] [Bug 6146] New: Assertion failed:
 ((!From->hasAnyUseOfValue(i) || From-> getValueType(i) ==
 To->getValueType(i)) && " Cannot use this version of ReplaceAllUsesWith!"),
 function ReplaceAllUsesWith, file SelectionDAG.cpp, line 4952.
Message-ID: <bug-6146-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: ((!From->hasAnyUseOfValue(i) || From-
                    >getValueType(i) == To->getValueType(i)) && "Cannot use
                    this version of ReplaceAllUsesWith!"), function
                    ReplaceAllUsesWith, file SelectionDAG.cpp, line 4952.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


this is a pretty recent regression at most 1 week old

pes delta$ cat dmu_traverse.c 
typedef struct vm_page *vm_page_t;
vm_page_sleep_if_busy(vm_page_t m, int also_m_busy, const char *msg)
{
} blkptr_t;
typedef struct zbookmark {
 unsigned long zb_objset;
 long zb_level;
} zbookmark_t;
typedef struct zstream {
} dnode_phys_t;
typedef struct traverse_blk_cache {
} traverse_blk_cache_t;
struct traverse_handle {
};
compare_bookmark(zbookmark_t *szb, zbookmark_t *ezb, dnode_phys_t *dnp,
    int advance)
{
 int bias = (advance & 0x01) ? 0 : -1;
 int slevel, elevel, wshift;
 if (szb->zb_objset + bias < ezb->zb_objset + bias)
 slevel = szb->zb_level;
 elevel = ezb->zb_level;
  return ((slevel ^ bias) - (elevel ^ bias));
}

pes delta$ clang -O2 dmu_traverse.c
dmu_traverse.c:2:1: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
vm_page_sleep_if_busy(vm_page_t m, int also_m_busy, const char *msg)
^
dmu_traverse.c:4:1: warning: control reaches end of non-void function
[-Wreturn-type]
} blkptr_t;
^
dmu_traverse.c:4:3: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
} blkptr_t;
  ^
dmu_traverse.c:15:1: warning: type specifier missing, defaults to 'int'
[-Wimplicit-int]
compare_bookmark(zbookmark_t *szb, zbookmark_t *ezb, dnode_phys_t *dnp,
^
Assertion failed: ((!From->hasAnyUseOfValue(i) || From->getValueType(i) ==
To->getValueType(i)) && "Cannot use this version of ReplaceAllUsesWith!"),
function ReplaceAllUsesWith, file SelectionDAG.cpp, line 4952.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.0 -S -disable-free -main-file-name dmu_traverse.c
-mrelocation-model static -mdisable-fp-elim -munwind-tables -target-cpu x86-64
-resource-dir /usr/local/lib/clang/1.1 -O2 -fmessage-length 115 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-2sPbT9.s -x c
dmu_traverse.c 
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'X86 DAG->DAG Instruction Selection' on function
'@compare_bookmark'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)


-- 
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 Jan 26 05:26:50 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 05:26:50 -0600
Subject: [LLVMbugs] [Bug 6148] New: Some LLVM tests fail,
 when build with cmake, if clang isn'  t built
Message-ID: <bug-6148-206@http.llvm.org/bugs/>

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

           Summary: Some LLVM tests fail, when build with cmake, if clang
                    isn't built
           Product: Build scripts
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ingmar at exherbo.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4116)
 --> (http://llvm.org/bugs/attachment.cgi?id=4116)
Output of 'make test'

See attachment for the output of 'make test'.

I'm building with cmake, tools/clang isn't present, so clang isn't built.

This bug occurs because %cxx_config is unset (in test/site.exp) when clang
isn't built. These tests should be skipped in this case, I think.


-- 
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 Jan 26 10:20:54 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 10:20:54 -0600
Subject: [LLVMbugs] [Bug 6151] New: llc -O3: invalid assembler: Error: can't
 encode register ' %dh' in an instruction requiring REX prefix.
Message-ID: <bug-6151-206@http.llvm.org/bugs/>

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

           Summary: llc -O3: invalid assembler: Error: can't encode register
                    '%dh' in an instruction requiring REX prefix.
           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: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


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

$ llc -O3 gs.bc && as gs.s
gs.s: Assembler messages:
gs.s:35: Error: can't encode register '%dh' in an instruction requiring REX
prefix.

The line in question is:
        movb    %dh, %dil  # NOREX


-- 
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 Jan 26 12:31:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 12:31:18 -0600
Subject: [LLVMbugs] [Bug 6151] llc -O3: invalid assembler: Error: can't
 encode register '%dh' in an instruction requiring REX prefix.
In-Reply-To: <bug-6151-206@http.llvm.org/bugs/>
Message-ID: <201001261831.o0QIVIeg007924@zion.cs.uiuc.edu>

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


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>  2010-01-26 12:31:18 ---
Fixed in r94558 and r94560.


-- 
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 Jan 26 15:35:58 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 15:35:58 -0600
Subject: [LLVMbugs] [Bug 6153] New: Bitcasts between arrays are incorrectly
 accepted, causing llc to crash
Message-ID: <bug-6153-206@http.llvm.org/bugs/>

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

           Summary: Bitcasts between arrays are incorrectly accepted,
                    causing llc to crash
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: crash-on-invalid
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu


LLVM like the following is happily accepted by both the verifier and the
parser:

@x = constant [1 x i32] bitcast ([4 x i8] c"abcd" to [1 x i32])

However, this is invalid, as the reference says: "[t]he 'bitcast' instruction
takes a value to cast, which must be a **non-aggregate** first class value, and
a type to cast it to, which must also be a **non-aggregate** first class type."
(emphasis added).

On both 2.6 and trunk, accepting this nonsense eventually leads to llc
executing unreachable, at least on x86 and x86-64: (thanks to Dan Gohman for
confirming that trunk is affected)

x:                                                          # @x
        .byte   UNREACHABLE executed!
0   llc             0x0000000000d2d0bf
1   llc             0x0000000000d2d70d
2   libpthread.so.0 0x00007ffde0664e80
3   libc.so.6       0x00007ffddf986035 gsignal + 53
4   libc.so.6       0x00007ffddf987460 abort + 384
5   llc             0x0000000000d13d94 llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 356
...

Snipped the stack trace as it's not really relevant, the program shouldn't even
get that far.


-- 
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 Jan 26 15:51:56 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 15:51:56 -0600
Subject: [LLVMbugs] [Bug 6153] Bitcasts between arrays are incorrectly
 accepted, causing llc to crash
In-Reply-To: <bug-6153-206@http.llvm.org/bugs/>
Message-ID: <201001262151.o0QLpuX8016301@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-26 15:51:56 ---
Fixed in r94595:
llvm-as: t.ll:1:25: error: invalid cast opcode for cast from '[4 x i8]' to '[1
x i32]'
@x = constant [1 x i32] bitcast ([4 x i8] c"abcd" to [1 x i32])
                        ^


-- 
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 Jan 26 22:45:28 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Tue, 26 Jan 2010 22:45:28 -0600
Subject: [LLVMbugs] [Bug 6155] New: Unneeded load not eliminated
Message-ID: <bug-6155-206@http.llvm.org/bugs/>

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

           Summary: Unneeded load not eliminated
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: code-quality, regression
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: abbeyj at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4125)
 --> (http://llvm.org/bugs/attachment.cgi?id=4125)
Example input

Take the following input:
define i32 @foo(i32* %stack) {
  %stack1 = getelementptr i32* %stack, i32 1  ; &stack[1]
  store i32 10, i32* %stack                   ; stack[0] = 10
  store i32 20, i32* %stack1                  ; stack[1] = 20
  %retval = load i32* %stack                  ; return stack[0] (i.e. 10)
  ret i32 %retval
}

Running this through `opt -O3` from LLVM 2.6, the load will be eliminated:
define i32 @foo(i32* nocapture %stack) nounwind {
  %stack1 = getelementptr i32* %stack, i64 1
  store i32 10, i32* %stack
  store i32 20, i32* %stack1
  ret i32 10
}

But with current trunk the load is not eliminated:
define i32 @foo(i32* nocapture %stack) nounwind {
  %stack1 = getelementptr i32* %stack, i32 1
  store i32 10, i32* %stack
  store i32 20, i32* %stack1
  %retval = load i32* %stack
  ret i32 %retval
}

Note that this happens with or without inbounds on the GEP.


-- 
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 Jan 27 01:23:01 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 01:23:01 -0600
Subject: [LLVMbugs] [Bug 6157] New: opt -O1 segfault
Message-ID: <bug-6157-206@http.llvm.org/bugs/>

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

           Summary: opt -O1 segfault
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: viridia at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4126)
 --> (http://llvm.org/bugs/attachment.cgi?id=4126)
One of my compiler unit tests (bitcode file)

With the attached .bc file, opt will run fine with no passes specified, but
will segfault if -O1 is specified.

/home/talin/Projects/llvm-inst/bin/opt -O1 test/stdlib/SwitchStmtTest.bc >
/dev/null
Stack dump:
0.      Program arguments: /home/talin/Projects/llvm-inst/bin/opt -O1
test/stdlib/SwitchStmtTest.bc 
1.      Running pass 'Function Pass Manager' on module
'test/stdlib/SwitchStmtTest.bc'.
2.      Running pass 'Module Verifier' on function
'@"main(tart.core.String[])->int32"'
Segmentation fault


-- 
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 Jan 27 01:43:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 01:43:46 -0600
Subject: [LLVMbugs] [Bug 6155] Unneeded load not eliminated
In-Reply-To: <bug-6155-206@http.llvm.org/bugs/>
Message-ID: <201001270743.o0R7hkVN012821@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |clattner at apple.com
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID




--- Comment #1 from Chris Lattner <clattner at apple.com>  2010-01-27 01:43:46 ---
You can see what is happening with:

$ opt -count-aa -gvn t.ll -S
May alias:      [4294967295B] i32* %stack1, [4294967295B] i32* %stack
May alias:      [4294967295B] i32* %stack1, [4294967295B] i32* %stack
...

Note that gvn is asking for an "unknown" size access.  This is because you
aren't specifying a target data, so it doesn't know how far apart stack1 is
from stack.  If you slap on a targetdata string, it is optimized 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  Wed Jan 27 03:03:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 03:03:09 -0600
Subject: [LLVMbugs] [Bug 6157] opt -O1 segfault
In-Reply-To: <bug-6157-206@http.llvm.org/bugs/>
Message-ID: <201001270903.o0R939Qm027985@zion.cs.uiuc.edu>

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


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |baldrick at free.fr
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #4 from Duncan Sands <baldrick at free.fr>  2010-01-27 03:03:08 ---
It works fine here too and valgrind doesn't show anything.


-- 
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 Jan 27 03:36:40 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 03:36:40 -0600
Subject: [LLVMbugs] [Bug 6158] New: clang crash on C++ file
Message-ID: <bug-6158-206@http.llvm.org/bugs/>

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

           Summary: clang crash on C++ file
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: parser
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: epajarre at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4130)
 --> (http://llvm.org/bugs/attachment.cgi?id=4130)
preprocessed source (from on open source library)

I am a new user of clang, and I am seeing it crash on several of my C++ files.
I am including the preprocessed files and the error message. Several of the
failing C++ files seem to give sort of similar crash results.

I tried this on the latest svn sources (94664), compiled on Ubuntu 9.10

(Adding the stderr.txt here because cannot find how to do multiple attachments)
ANALYZE: pui-src/puButtonBox.cxx puButtonBox
Cast kind 9 not handled.
clang++: GRExprEngine.cpp:2246: void
clang::GRExprEngine::VisitCast(clang::CastExpr*, clang::Expr*,
clang::ExplodedNode*, clang::ExplodedNodeSet&, bool): Assertion `0' failed.
0  clang++   0x092e998a
1  clang++   0x092e97ff
2            0x4001d400 __kernel_sigreturn + 0
3  libc.so.6 0x401c2932 abort + 386
4  libc.so.6 0x401b8648 __assert_fail + 248
5  clang++   0x08316e49
6  clang++   0x08310176
7  clang++   0x0831ad93
8  clang++   0x0830fe70
9  clang++   0x0830f968
10 clang++   0x083087a6
11 clang++   0x08308e82
12 clang++   0x08308acb
13 clang++   0x0813b944
14 clang++   0x081390af
15 clang++   0x081391a6
16 clang++   0x0813922c
17 clang++   0x08138ddb
18 clang++   0x08138892
19 clang++   0x081385c9
20 clang++   0x083a480e
21 clang++   0x0806cd1e
22 clang++   0x0806c9b1
23 clang++   0x08057f33
24 clang++   0x0804e6e8
25 clang++   0x08052e66 main + 267
26 libc.so.6 0x401abb56 __libc_start_main + 230
27 clang++   0x0804d371
Stack dump:
0.      Program arguments: clang++ -cc1 -DIBOutlet=__attribute__((iboutlet))
-cc1 -triple i386-pc-linux-gnu -fsyntax-only -disable-free -main-file-name
puButtonBox.cxx -mrelocation-model static -mdisable-fp-elim -target-cpu
pentium4 -resource-dir /usr/local/lib/clang/1.1 -DLUA_USE_POSIX -DLINUX
-D__SSE__ -DT_EXE=1 -DdDOUBLE -DNDEBUG -DEP_USE_STDIO=1 -DBUS_SIM=0 -Ipui-src
-Ilua-src/include -Ilpng120 -Izpp/zlib -I/usr/include -fmessage-length 0
-fexceptions -fgnu-runtime -fdiagnostics-show-option -x c++
pui-src/puButtonBox.cxx -analyze -analyzer-display-progress
-analyzer-eagerly-assume -analyzer-opt-analyze-nested-blocks
-warn-objc-unused-ivars -warn-security-syntactic -warn-objc-methodsigs
-checker-cfref -warn-dead-stores -analyzer-store=region
-analyzer-constraints=range -analyzer-output=html -o
/tmp/scan-build-2010-01-27-2 
1.      pui-src/puButtonBox.cxx:18:1: current parser token 'int'
2.      pui-src/puButtonBox.cxx:13:24: Error evaluating statement
3.      pui-src/puButtonBox.cxx:13:24: Error evaluating statement
4.      pui-src/puButtonBox.cxx:13:54
<Spelling=/usr/local/lib/clang/1.1/include/stddef.h:36:14>: Error evaluating
statement


-- 
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 Jan 27 13:13:17 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 13:13:17 -0600
Subject: [LLVMbugs] [Bug 6155] load elimination depends on targetdata
In-Reply-To: <bug-6155-206@http.llvm.org/bugs/>
Message-ID: <201001271913.o0RJDHCC020373@zion.cs.uiuc.edu>

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


Dan Gohman <gohman at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |gohman at apple.com
             Status|RESOLVED                    |REOPENED
          Component|new bugs                    |Scalar Optimizations
           Keywords|regression                  |
            Product|new-bugs                    |libraries
         Resolution|INVALID                     |
            Summary|Unneeded load not eliminated|load elimination depends on
                   |                            |targetdata




--- Comment #2 from Dan Gohman <gohman at apple.com>  2010-01-27 13:13:16 ---
This optimization could be done without targetdata 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  Wed Jan 27 14:25:46 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 14:25:46 -0600
Subject: [LLVMbugs] [Bug 6162] New: thumb2 mode generates illegal
	instructions
Message-ID: <bug-6162-206@http.llvm.org/bugs/>

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

           Summary: thumb2 mode generates illegal instructions
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bagel99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The instructions SXTAB, SXTAH, UXTAB, UXTAH are not THUMB-2 instructions and
yet they have patterns in ARMInstrThumb2.td.

The instruction UXTB16 also has a pattern but is not a THUMB-2 instruction.


-- 
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 Jan 27 14:47:33 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 14:47:33 -0600
Subject: [LLVMbugs] [Bug 5737] lazy loading from bitcode shouldn't abuse
	linkage
In-Reply-To: <bug-5737-206@http.llvm.org/bugs/>
Message-ID: <201001272047.o0RKlXOO024283@zion.cs.uiuc.edu>

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


Jeffrey Yasskin <jyasskin at google.com> changed:

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




--- Comment #5 from Jeffrey Yasskin <jyasskin at google.com>  2010-01-27 14:47:33 ---
Fixed in r94686.


-- 
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 Jan 27 15:02:25 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 15:02:25 -0600
Subject: [LLVMbugs] [Bug 6155] load elimination depends on targetdata
In-Reply-To: <bug-6155-206@http.llvm.org/bugs/>
Message-ID: <201001272102.o0RL2Pnf024810@zion.cs.uiuc.edu>

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


Chris Lattner <clattner at apple.com> changed:

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




--- Comment #3 from Chris Lattner <clattner at apple.com>  2010-01-27 15:02:24 ---
Getting this would require a substantial redesign of the alias analysis
interfaces, and I don't think it is worth it.  If you really want to keep this
idea around, plz move it to a README file.


-- 
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 Jan 27 15:50:41 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 15:50:41 -0600
Subject: [LLVMbugs] [Bug 5735] JIT should not codegen available_externally
	functions.
In-Reply-To: <bug-5735-206@http.llvm.org/bugs/>
Message-ID: <201001272150.o0RLofsQ026811@zion.cs.uiuc.edu>

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


Jeffrey Yasskin <jyasskin at google.com> changed:

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




--- Comment #5 from Jeffrey Yasskin <jyasskin at google.com>  2010-01-27 15:50:41 ---
Fixed in r94686.


-- 
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 Jan 27 17:00:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 17:00:18 -0600
Subject: [LLVMbugs] [Bug 6162] thumb2 mode generates illegal instructions
In-Reply-To: <bug-6162-206@http.llvm.org/bugs/>
Message-ID: <201001272300.o0RN0Igc029528@zion.cs.uiuc.edu>

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


Jim Grosbach <grosbach at apple.com> changed:

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




--- Comment #1 from Jim Grosbach <grosbach at apple.com>  2010-01-27 17:00:17 ---
According to the ARM Architecture Reference Manual (ARM DDI 0406A), these are
valid Thumb2 instructions.

Perhaps there is a binutils bug on Linux that these instructions aren't
recognized when assembling Thumb2 code?


-- 
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 Jan 27 17:36:52 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 17:36:52 -0600
Subject: [LLVMbugs] [Bug 6162] thumb2 mode generates illegal instructions
In-Reply-To: <bug-6162-206@http.llvm.org/bugs/>
Message-ID: <201001272336.o0RNaqof030768@zion.cs.uiuc.edu>

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


Brian G. Lucas <bagel99 at gmail.com> changed:

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




--- Comment #2 from Brian G. Lucas <bagel99 at gmail.com>  2010-01-27 17:36:51 ---
I don't think that is the case for V7-M architecture chips such as the
cortex-m3.  My V7-m manual (ARM DDI 0405B) does not have these instructions.  I
do not think it is a binutils bug.  This is an issue that the V7-M chips have a
different implementation of thumb2.  For example, they have udiv and sdiv,
which are in V7-R and V7-M only.


-- 
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 Jan 27 18:00:23 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 18:00:23 -0600
Subject: [LLVMbugs] [Bug 6163] New: Warn when comparing two arrays
Message-ID: <bug-6163-206@http.llvm.org/bugs/>

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

           Summary: Warn when comparing two arrays
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: quality-of-implementation
          Severity: normal
          Priority: P2
         Component: Semantic Analyzer
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu


Clang should warn about code that compares two arrays directly:

  int array1[2];
  int array2[2];

  int foo() {
    return array1 == array2;
  }

because we always know what the answer will be.


-- 
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 Jan 27 18:39:39 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 18:39:39 -0600
Subject: [LLVMbugs] [Bug 6164] New: Assertion failed: ((D->field_begin() ==
 D->field_end()) && "LayoutUnion - Align 0")
Message-ID: <bug-6164-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: ((D->field_begin() == D->field_end())
                    && "LayoutUnion - Align 0")
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu


ddunbar at giles:tmp$ cat t.c
// ../../ABITestGen.py --no-unsigned --no-vector --no-complex --max-args 0 -o
inputs/test.7.a.c -T inputs/test.7.b.c -D inputs/test.7.driver.c --min=7
--count=1
// Generated: 2010-01-27 16:37
// Cardinality of function generator: inf
// Cardinality of type generator: inf

#include <stdio.h>
#include <string.h>
#include <assert.h>

typedef union T0 { char : 0; } T0;
extern T0 T0_retval;
T0 fn7(void);
static T0 T0_values[] = {
        { },
};
void test_fn7(void) {
  printf("fn7: testing return.\n");
  for (int i=0; i<1; ++i) {
    T0 RV;
    T0_retval = T0_values[i];
    RV = fn7();
  }
}
ddunbar at giles:tmp$ clang -c t.c
Assertion failed: ((D->field_begin() == D->field_end()) && "LayoutUnion - Align
0"), function LayoutUnion, file
/Volumes/Data/Users/ddunbar/llvm/tools/clang/lib/CodeGen/CGRecordLayoutBuilder.cpp,
line 210.
0  clang             0x0000000101299d37 PrintStackTrace(void*) + 38
1  clang             0x000000010129a2c5 SignalHandler(int) + 336
2  libSystem.B.dylib 0x00007fff819aeeaa _sigtramp + 26
3  libSystem.B.dylib 0x00007fff81953bea tiny_malloc_from_free_list + 1196
4  libSystem.B.dylib 0x00007fff81a2ae74 __pthread_markcancel + 0
5  clang             0x00000001001d62c2
clang::CodeGen::CGRecordLayoutBuilder::LayoutUnion(clang::RecordDecl const*) +
864
6  clang             0x00000001001d6abe
clang::CodeGen::CGRecordLayoutBuilder::Layout(clang::RecordDecl const*) + 104
7  clang             0x00000001001d6b7a
clang::CodeGen::CGRecordLayoutBuilder::ComputeLayout(clang::CodeGen::CodeGenTypes&,
clang::RecordDecl const*) + 80
8  clang             0x0000000100208236
clang::CodeGen::CodeGenTypes::ConvertTagDeclType(clang::TagDecl const*) + 748
9  clang             0x0000000100207ae0
clang::CodeGen::CodeGenTypes::ConvertNewType(clang::QualType) + 2316
10 clang             0x0000000100207edf
clang::CodeGen::CodeGenTypes::ConvertTypeRecursive(clang::QualType) + 179
11 clang             0x0000000100207180
clang::CodeGen::CodeGenTypes::ConvertTypeForMemRecursive(clang::QualType) + 30
12 clang             0x00000001002077dc
clang::CodeGen::CodeGenTypes::ConvertNewType(clang::QualType) + 1544
13 clang             0x0000000100207edf
clang::CodeGen::CodeGenTypes::ConvertTypeRecursive(clang::QualType) + 179
14 clang             0x00000001002085cc
clang::CodeGen::CodeGenTypes::ConvertType(clang::QualType) + 30
15 clang             0x0000000100191b46 (anonymous
namespace)::ConstExprEmitter::ConvertType(clang::QualType) + 40
16 clang             0x0000000100195ed5 (anonymous
namespace)::ConstExprEmitter::EmitArrayInitialization(clang::InitListExpr*) +
87
17 clang             0x0000000100193a99 (anonymous
namespace)::ConstExprEmitter::VisitInitListExpr(clang::InitListExpr*) + 215
18 clang             0x0000000100194860 clang::StmtVisitor<(anonymous
namespace)::ConstExprEmitter, llvm::Constant*>::Visit(clang::Stmt*) + 3322
19 clang             0x0000000100192955
clang::CodeGen::CodeGenModule::EmitConstantExpr(clang::Expr const*,
clang::QualType, clang::CodeGen::CodeGenFunction*) + 1723
20 clang             0x00000001001fcebf
clang::CodeGen::CodeGenModule::EmitGlobalVarDefinition(clang::VarDecl const*) +
229
21 clang             0x00000001001fd750
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 576
22 clang             0x00000001001fd99a
clang::CodeGen::CodeGenModule::EmitGlobal(clang::CodeGen::GlobalDecl) + 530
23 clang             0x00000001001fdbbf
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 547
24 clang             0x0000000100214470 (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 76
25 clang             0x000000010003dd72 (anonymous
namespace)::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 144
26 clang             0x00000001003173ec clang::ParseAST(clang::Preprocessor&,
clang::ASTConsumer*, clang::ASTContext&, bool, bool,
clang::CodeCompleteConsumer*) + 504
27 clang             0x0000000100060b7e
clang::ASTFrontendAction::ExecuteAction() + 256
28 clang             0x0000000100060c6e clang::FrontendAction::Execute() + 226
29 clang             0x000000010004611a
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 726
30 clang             0x0000000100025da5 cc1_main(char const**, char const**,
char const*, void*) + 1273
31 clang             0x0000000100029706 main + 252
32 clang             0x0000000100024e70 start + 52
Stack dump:
0.      Program arguments:
/Volumes/Data/Users/ddunbar/llvm.obj.64/Debug/bin/clang -cc1 -triple
x86_64-apple-darwin10.0.0 -S -disable-free -main-file-name t.c -pic-level 1
-mdisable-fp-elim -munwind-tables -target-cpu core2 -resource-dir
/Volumes/Data/Users/ddunbar/llvm.obj.64/Debug/lib/clang/1.1 -fmessage-length 88
-stack-protector 1 -fblocks -fdiagnostics-show-option -o
/var/folders/DQ/DQ8GT3++HESEzT1obWBynE+++TI/-Tmp-/cc-0ENDoH.s -x c t.c 
1.      t.c:16:1: current parser token 'void'
2.      t.c:13:11: LLVM IR generation of declaration 'T0_values'
3.      t.c:13:11: Generating code for declaration 'T0_values'
clang: error: compiler command failed due to signal 6 (use -v to see
invocation)
ddunbar at giles: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  Wed Jan 27 19:57:32 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 19:57:32 -0600
Subject: [LLVMbugs] [Bug 6146] Assertion failed:
 ((!From->hasAnyUseOfValue(i) || From-> getValueType(i) ==
 To->getValueType(i)) && " Cannot use this version of ReplaceAllUsesWith!"),
 function ReplaceAllUsesWith, file SelectionDAG.cpp, line 4952.
In-Reply-To: <bug-6146-206@http.llvm.org/bugs/>
Message-ID: <201001280157.o0S1vW3N004142@zion.cs.uiuc.edu>

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


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

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




--- Comment #4 from Evan Cheng <evan.cheng at apple.com>  2010-01-27 19:57:32 ---
Fixed: r94731.


-- 
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 Jan 27 21:32:18 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Wed, 27 Jan 2010 21:32:18 -0600
Subject: [LLVMbugs] [Bug 6165] New: optimization problem with srem on
	negative values
Message-ID: <bug-6165-206@http.llvm.org/bugs/>

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

           Summary: optimization problem with srem on negative values
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vargaz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


To reproduce:

llvm-as bug.ll
llc bug.bc -o bug.s && gcc bug.s && ./a.out
opt -O1 bug.bc -o bug2.bc && llc bug2.bc -o bug.s && gcc bug.s && ./a.out

The first run prints '0' while the second one prints '5'.

The ll code is mostly equal to the following C code:

int foo ()
{
        int i, j;

        i = 0;
        for (j = 0; j < 29; ++j)
                i --;
        if ((i % 2) != -1)
                return 5;
        if ((i % 4) != -1)
                return 6;

        return 0;
}

void main ()
{
        printf ("%d\n", foo ());
}


-- 
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 Jan 28 11:23:49 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Jan 2010 11:23:49 -0600
Subject: [LLVMbugs] [Bug 6165] optimization problem with srem on negative
	values
In-Reply-To: <bug-6165-206@http.llvm.org/bugs/>
Message-ID: <201001281723.o0SHNncd021888@zion.cs.uiuc.edu>

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


Duncan Sands <baldrick at free.fr> changed:

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




--- Comment #6 from Duncan Sands <baldrick at free.fr>  2010-01-28 11:23:48 ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20100125/095249.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 Jan 28 12:22:16 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Jan 2010 12:22:16 -0600
Subject: [LLVMbugs] [Bug 6164] Assertion failed: ((D->field_begin() ==
 D->field_end()) && " LayoutUnion - Align 0")
In-Reply-To: <bug-6164-206@http.llvm.org/bugs/>
Message-ID: <201001281822.o0SIMGP8025395@zion.cs.uiuc.edu>

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


Anders Carlsson <andersca at mac.com> changed:

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




--- Comment #2 from Anders Carlsson <andersca at mac.com>  2010-01-28 12:22:16 ---
Committed revision 94754.


-- 
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 Jan 28 17:26:31 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Jan 2010 17:26:31 -0600
Subject: [LLVMbugs] [Bug 6167] New: Segmentation fault due to type mismatch
 for build_struct_gep in OCaml bindings
Message-ID: <bug-6167-206@http.llvm.org/bugs/>

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

           Summary: Segmentation fault due to type mismatch for
                    build_struct_gep in OCaml bindings
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hawkinsp at cs.stanford.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4135)
 --> (http://llvm.org/bugs/attachment.cgi?id=4135)
Proposed bug fix

Calling the build_struct_gep function in the OCaml bindings always leads to a
segmentation fault in the binding C stub code. There is a type mismatch between
the C stub (bindings/ocaml/llvm/llvm_ocaml.c:llvm_build_struct_gep), which
expects an array of indices, and the ocaml type signature
(bindings/ocaml/llvm/llvm.mli:build_struct_gep), which takes a single integer
argument. The binding as it stands attempts to use the index argument as the
address of an array, leading to a crash.

I've attached a patch that changes the C stub to match the OCaml signature.
This fixes the seg fault.


-- 
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 Jan 28 19:02:35 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Jan 2010 19:02:35 -0600
Subject: [LLVMbugs] [Bug 6168] New: clang emits missing fields as undef
	instead of 0
Message-ID: <bug-6168-206@http.llvm.org/bugs/>

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

           Summary: clang emits missing fields as undef instead of 0
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu


C99 6.7.8 p21 says, "If there are fewer initializers in a brace-enclosed list
than there are elements or members of an aggregate, ... the remainder of the
aggregate shall be initialized implicitly the same as objects that have static
storage duration."  p10 says static objects are initialized to null or zero.

Clang, instead, initializes the remainder of the aggregate to "undef". In many
cases, this will produce the right result because lots of optimizers treat
undef as 0, but that's certainly not guaranteed.

For example:

$ cat test.c
struct ManyFields {
  int a;
  int b;
  int c;
  char d;
  int e;
  int f;
};

extern struct ManyFields FewInits;
struct ManyFields FewInits = {1, 2};

$ clang -std=c99 -femit-all-decls -emit-llvm -S test.c -o -
; ModuleID = 'test.c'
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-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

%0 = type { i32, i32, [16 x i8] }

@FewInits = global %0 { i32 1, i32 2, [16 x i8] undef }, align 4 ; <%0*>
[#uses=0]

$


-- 
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 Jan 28 22:21:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Thu, 28 Jan 2010 22:21:48 -0600
Subject: [LLVMbugs] [Bug 6170] New: Assertion failure in getTargetVersion
 while PCH is being processed on PPC
Message-ID: <bug-6170-206@http.llvm.org/bugs/>

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

           Summary: Assertion failure in getTargetVersion while PCH is being
                    processed on PPC
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm at gentlyusedunderwear.com
                CC: llvmbugs at cs.uiuc.edu


I'm getting an assertion when clang is processing a PowerPC PCH.

The command:

ProcessPCH
/var/folders/xH/xHa+qh4xEf8ICLyAHxy-YE+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/Precompiled-eipxzojdpfplejcepifxqvflztqb/Precompiled.pch.gch
Sources/Precompiled.pch normal ppc objective-c com.apple.compilers.llvmgcc42
cd /Volumes/Consecrated/source/Dev/Perforce/FruitMenu
setenv LANG en_US.US-ASCII
/Volumes/Consecrated/source/Dev/llvm/Release/bin/clang -x objective-c-header
-arch ppc -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks
-O0 -Wmissing-field-initializers -Wreturn-type -Wmissing-braces -Wparentheses
-Wswitch -Wunused-variable -Wsign-compare -Wshorten-64-to-32
-Wstrict-selector-match -Wundeclared-selector -isysroot
/Developer/SDKs/MacOSX10.6.sdk -fobjc-gc -mtune=G4 -mmacosx-version-min=10.5
-gdwarf-2
-I/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/FruitMenu.build/Debug/ape.build/FruitMenu.hmap
-Wmost -Wno-four-char-constants -Wno-unknown-pragmas
-F/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/Debug
-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks
-F/Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks
-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks
-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/PrivateFrameworks
-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/PrivateFrameworks
-I/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/Debug/include
-I../_common
-I/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/FruitMenu.build/Debug/ape.build/DerivedSources/ppc
-I/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/FruitMenu.build/Debug/ape.build/DerivedSources
-v -fconstant-cfstrings -isysroot /Developer/SDKs/MacOSX10.6.sdk -c
/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/Sources/Precompiled.pch -o
/var/folders/xH/xHa+qh4xEf8ICLyAHxy-YE+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/Precompiled-eipxzojdpfplejcepifxqvflztqb/Precompiled.pch.gch

The output with -v:

clang version 1.1 (trunk 94787)
Target: powerpc-apple-darwin10
Thread model: posix
Assertion failed: (TargetInitialized && "Target not initialized!"), function
getTargetVersion, file ToolChains.h, line 100.
0  clang             0x00000001012d0562 PrintStackTrace(void*) + 34
1  clang             0x00000001012d0dec SignalHandler(int) + 652
2  libSystem.B.dylib 0x00007fff83a9982a _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2086037488
4  libSystem.B.dylib 0x00007fff83b14ef0 __pthread_markcancel + 0
5  clang             0x0000000100152a2f
clang::driver::tools::Clang::ConstructJob(clang::driver::Compilation&,
clang::driver::JobAction const&, clang::driver::Job&, clang::driver::InputInfo
const&, llvm::SmallVector<clang::driver::InputInfo, 4u> const&,
clang::driver::ArgList const&, char const*) const + 15935
6  clang             0x000000010012d968
clang::driver::Driver::BuildJobsForAction(clang::driver::Compilation&,
clang::driver::Action const*, clang::driver::ToolChain const*, char const*,
bool, bool, char const*, clang::driver::InputInfo&) const + 2600
7  clang             0x000000010012d70a
clang::driver::Driver::BuildJobsForAction(clang::driver::Compilation&,
clang::driver::Action const*, clang::driver::ToolChain const*, char const*,
bool, bool, char const*, clang::driver::InputInfo&) const + 1994
8  clang             0x000000010012e057
clang::driver::Driver::BuildJobs(clang::driver::Compilation&) const + 407
9  clang             0x000000010012ecdf
clang::driver::Driver::BuildCompilation(int, char const**) + 2223
10 clang             0x00000001000399fa main + 1578
11 clang             0x0000000100034fa8 start + 52
12 clang             0x0000000000000031 start + 4294750397
Stack dump:
0.      Program arguments:
/Volumes/Consecrated/source/Dev/llvm/Release/bin/clang -x objective-c-header
-arch ppc -fmessage-length=0 -pipe -Wno-trigraphs -fpascal-strings -fasm-blocks
-O0 -Wmissing-field-initializers -Wreturn-type -Wmissing-braces -Wparentheses
-Wswitch -Wunused-variable -Wsign-compare -Wshorten-64-to-32
-Wstrict-selector-match -Wundeclared-selector -isysroot
/Developer/SDKs/MacOSX10.6.sdk -fobjc-gc -mtune=G4 -mmacosx-version-min=10.5
-gdwarf-2
-I/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/FruitMenu.build/Debug/ape.build/FruitMenu.hmap
-Wmost -Wno-four-char-constants -Wno-unknown-pragmas
-F/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/Debug
-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/ApplicationServices.framework/Versions/A/Frameworks
-F/Developer/SDKs/MacOSX10.6.sdk/Library/Frameworks
-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/Frameworks/CoreServices.framework/Versions/A/Frameworks
-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/PrivateFrameworks
-F/Developer/SDKs/MacOSX10.6.sdk/System/Library/PrivateFrameworks
-I/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/Debug/include
-I../_common
-I/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/FruitMenu.build/Debug/ape.build/DerivedSources/ppc
-I/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/build/FruitMenu.build/Debug/ape.build/DerivedSources
-v -fconstant-cfstrings -isysroot /Developer/SDKs/MacOSX10.6.sdk -c
/Volumes/Consecrated/source/Dev/Perforce/FruitMenu/Sources/Precompiled.pch -o
/var/folders/xH/xHa+qh4xEf8ICLyAHxy-YE+++TI/-Caches-/com.apple.Xcode.501/SharedPrecompiledHeaders/Precompiled-eipxzojdpfplejcepifxqvflztqb/Precompiled.pch.gch 
1.      Compilation construction
2.      Building compilation jobs
3.      Building compilation jobs
4.      Building compilation jobs
Command /Volumes/Consecrated/source/Dev/llvm/Release/bin/clang failed with exit
code 6


-- 
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 Jan 29 12:04:06 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 29 Jan 2010 12:04:06 -0600
Subject: [LLVMbugs] [Bug 6172] New: can't build klee on Ubuntu 9.10 on x86
Message-ID: <bug-6172-206@http.llvm.org/bugs/>

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

           Summary: can't build klee on Ubuntu 9.10 on x86
           Product: new-bugs
           Version: trunk
          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


I'm pretty sure I've followed all instructions at the Klee page.  Unless I'm
doing something stupid, this is a problem caused by the latest Ubuntu using g++
4.4 which is stricter about some c++ stuff than previous versions.


regehr at john-home:~/z/klee$ make ENABLE_OPTIMIZED=1 
make[1]: Entering directory `/home/regehr/z/klee/stp'
make[2]: Entering directory `/home/regehr/z/klee/stp/AST'
g++ -g -O2 -O2 -Wall -DEXT_HASH_MAP   -c -o AST.o AST.cpp
In file included from /usr/include/c++/4.4/ext/hash_set:59,
                 from AST.h:14,
                 from AST.cpp:10:
/usr/include/c++/4.4/backward/backward_warning.h:28:2: warning: #warning This
file includes at least one deprecated or antiquated header which may be removed
without further notice at a future date. Please use a non-deprecated interface
with equivalent functionality instead. For a listing of replacement headers and
interfaces, consult the file backward_warning.h. To disable this warning use
-Wno-deprecated.
AST.cpp: In member function ???BEEV::ASTNode
BEEV::BeevMgr::CreateBVConst(unsigned int, long long unsigned int)???:
AST.cpp:759: error: ???uint32_t??? does not name a type
AST.cpp:761: error: ???uint32_t??? was not declared in this scope
AST.cpp:761: error: expected ???;??? before ???numbits???
AST.cpp:762: error: expected ???;??? before ???mask???
AST.cpp:763: error: ???numbits??? was not declared in this scope
AST.cpp:764: error: ???mask??? was not declared in this scope
make[2]: *** [AST.o] Error 1
make[2]: Leaving directory `/home/regehr/z/klee/stp/AST'
make[1]: *** [AST/libast.a] Error 2
make[1]: Leaving directory `/home/regehr/z/klee/stp'
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  Fri Jan 29 12:32:48 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 29 Jan 2010 12:32:48 -0600
Subject: [LLVMbugs] [Bug 6173] New: SIMD code causes segfault in LLI,
 runs fine native on linux  /x86
Message-ID: <bug-6173-206@http.llvm.org/bugs/>

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

           Summary: SIMD code causes segfault in LLI, runs fine native on
                    linux/x86
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: maililistaalterego at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4139)
 --> (http://llvm.org/bugs/attachment.cgi?id=4139)
Test case .ll

I was experimenting with LLVM by hand writing .ll files. I was hacking with
arrays of SIMD vectors when I stumbled into a bug that causes LLI to segfault
but the code runs fine when I make a native executable.

$ llvm-as testcase.ll
$ lli testcase.bc 
Stack dump:
0.      Program arguments: ../oss/llvm/build/bin/lli testcase.bc 
Segmentation fault
$ llvm-ld -native -o testcase testcase.bc
$??./testcase # runs fine

I also tried an older version of LLI, which did not segfault like the one from
LLVM trunk (r94421). The old, working lli version is:
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.5 (Debian 2.5-0ubuntu1)
  Optimized build with assertions.
  Built Mar  6 2009(17:11:47).


-- 
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 Jan 29 15:26:17 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 29 Jan 2010 15:26:17 -0600
Subject: [LLVMbugs] [Bug 3128] assertion with bitfields
In-Reply-To: <bug-3128-206@http.llvm.org/bugs/>
Message-ID: <201001292126.o0TLQHZ8012741@zion.cs.uiuc.edu>

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


Daniel Dunbar <daniel at zuster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |daniel at zuster.org
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME




--- Comment #1 from Daniel Dunbar <daniel at zuster.org>  2010-01-29 15:26:16 ---
I cannot reproduce 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 bugzilla-daemon at cs.uiuc.edu  Fri Jan 29 15:57:56 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Fri, 29 Jan 2010 15:57:56 -0600
Subject: [LLVMbugs] [Bug 6176] New: clang generates wrong code for load from
 bitfield in packed struct
Message-ID: <bug-6176-206@http.llvm.org/bugs/>

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

           Summary: clang generates wrong code for load from bitfield in
                    packed struct
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: baldrick at free.fr, llvmbugs at cs.uiuc.edu


+++ This bug was initially created as a clone of Bug #2394 +++

struct __attribute((packed)) x {int a : 24;};
int a(struct x* g) {return g->a;}

Code generated with llvm-gcc:
a:
        movl    4(%esp), %eax
        movl    (%eax), %eax
        shll    $8, %eax
        sarl    $8, %eax
        ret

This is broken because the last byte might not be legal to load.


-- 
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 Jan 30 00:20:15 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 30 Jan 2010 00:20:15 -0600
Subject: [LLVMbugs] [Bug 2626] 2006-01-23-InitializedBitField.c uses
	over-width bools
In-Reply-To: <bug-2626-206@http.llvm.org/bugs/>
Message-ID: <201001300620.o0U6KFTC031780@zion.cs.uiuc.edu>

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


Nick Lewycky <nicholas at mxc.ca> changed:

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




--- Comment #3 from Nick Lewycky <nicholas at mxc.ca>  2010-01-30 00:20:14 ---
It appears that 2006-01-23-InitializedBitField.c has been removed from the
repo.


-- 
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 Jan 30 07:21:14 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 30 Jan 2010 07:21:14 -0600
Subject: [LLVMbugs] [Bug 6178] New: Unaligned loads are created for packed
	structs
Message-ID: <bug-6178-206@http.llvm.org/bugs/>

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

           Summary: Unaligned loads are created for packed structs
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Consider the following code:

struct foo
{  char a;
   char b;
   char c;
   int  d;
} __attribute__((packed));

extern struct foo bar;
extern int baz;

void y(void)
{
    baz = bar.d;
}

Access to "d" results in unaligned load. However, no extra alignment specifier
is attached to load:

x86-64:
  %tmp = load i32* getelementptr inbounds (%struct.foo* @bar, i64 0, i32 3) ;
<i32> [#uses=1]

msp430:
  %tmp = load i16* getelementptr inbounds (%struct.foo* @bar, i16 0, i32 3) ;
<i16> [#uses=1]

This results to unaligned access on targets where unaligned memops are
prohibited (e.g. arm, ppc, msp430, ...).

The correct one (for msp430) should be:
  %tmp = load i16* getelementptr inbounds (%struct.foo* @bar, i16 0, i32 3),
align 1

In fact, there is no single setAlignment() call inside CGExpr.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  Sat Jan 30 08:11:09 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 30 Jan 2010 08:11:09 -0600
Subject: [LLVMbugs] [Bug 6180] New: Weird error for ommitted semicolon
Message-ID: <bug-6180-206@http.llvm.org/bugs/>

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

           Summary: Weird error for ommitted semicolon
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: parser
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: c.r1 at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Hi,
in the attached testcase, one semicolon is missing. The parser now complains on
the last line in the file, which consists of whitespace, producing a weird,
not-so-helping diagnostic. Maybe it should point to the line with the }, or the
last line which has source code, or it could even recover+fixit from that
(seemingly) easy error.


-- 
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 Jan 30 08:46:55 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 30 Jan 2010 08:46:55 -0600
Subject: [LLVMbugs] [Bug 6182] New: Cascaded and non-specific errors for
 ommitted semicolon after a class {}
Message-ID: <bug-6182-206@http.llvm.org/bugs/>

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

           Summary: Cascaded and non-specific errors for ommitted semicolon
                    after a class {}
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: parser
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: c.r1 at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4145)
 --> (http://llvm.org/bugs/attachment.cgi?id=4145)
test

Hi,
in the attached testcase, there is the semicolon missing after the class a{},
though all reported errors mention other stuff (neither semicolon missing, nor
is class a{} printed), which makes it hard to find+fix the actual error.


-- 
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 Jan 30 10:15:49 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 30 Jan 2010 10:15:49 -0600
Subject: [LLVMbugs] [Bug 4172] false positive: Branch condition evaluates to
 an uninitialized value
In-Reply-To: <bug-4172-206@http.llvm.org/bugs/>
Message-ID: <201001301615.o0UGFnRM003684@zion.cs.uiuc.edu>

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


Dmitry G. Dyachenko <dimhen at gmail.com> changed:

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




--- Comment #3 from Dmitry G. Dyachenko <dimhen at gmail.com>  2010-01-30 10:15:48 ---
clang rev.94876 PASS all 3 testcases.


-- 
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 Jan 30 12:36:10 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 30 Jan 2010 12:36:10 -0600
Subject: [LLVMbugs] [Bug 6144] [mips] GP is used before restored after a
	library call
In-Reply-To: <bug-6144-206@http.llvm.org/bugs/>
Message-ID: <201001301836.o0UIaAiK008913@zion.cs.uiuc.edu>

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


Bruno Cardoso Lopes <bruno.cardoso at gmail.com> changed:

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




--- Comment #3 from Bruno Cardoso Lopes <bruno.cardoso at gmail.com>  2010-01-30 12:36:09 ---
Hi Zhou,

Fixed now in r94915:
http://llvm.org/viewvc/llvm-project?view=rev&revision=94915

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 Jan 30 17:19:49 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 30 Jan 2010 17:19:49 -0600
Subject: [LLVMbugs] [Bug 6105] AsmStmt should not use SmallVector
In-Reply-To: <bug-6105-206@http.llvm.org/bugs/>
Message-ID: <201001302319.o0UNJnv6018420@zion.cs.uiuc.edu>

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


Anders Carlsson <andersca at mac.com> changed:

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




--- Comment #2 from Anders Carlsson <andersca at mac.com>  2010-01-30 17:19:48 ---
Committed revision 94926.


-- 
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 Jan 30 22:23:40 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sat, 30 Jan 2010 22:23:40 -0600
Subject: [LLVMbugs] [Bug 6185] New: llvm-gcc assumes no alignment for
	bitfield loads
Message-ID: <bug-6185-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc assumes no alignment for bitfield loads
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P2
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lessen42 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Consider the following C code:

struct bf1_31 {
    unsigned a:1;
    unsigned b:31;
};

void func(struct bf1_31 *p, int n, int a)
{
    int i = 0;
    do {
        if (p[i].a)
            p[i].b += a;
    } while (++i < n);
}

llvm-gcc emits the following llvm ir for 32-bit targets:

; ModuleID = 'bitfield.c'
target datalayout =
"e-p:32:32:32-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-n32"
target triple = "armv5e-none-linux-gnueabi"

%struct.bf1_31 = type <{ i32 }>

define arm_aapcscc void @func(%struct.bf1_31* nocapture %p, i32 %n, i32 %a)
nounwind {
entry:
  %0 = shl i32 %a, 1                              ; <i32> [#uses=1]
  %tmp4 = icmp sgt i32 %n, 1                      ; <i1> [#uses=1]
  %smax = select i1 %tmp4, i32 %n, i32 1          ; <i32> [#uses=1]
  br label %bb

bb:                                               ; preds = %bb2, %entry
  %i.0 = phi i32 [ 0, %entry ], [ %4, %bb2 ]      ; <i32> [#uses=2]
  %scevgep5 = getelementptr inbounds %struct.bf1_31* %p, i32 %i.0, i32 0 ;
<i32*> [#uses=2]
  %1 = load i32* %scevgep5, align 1               ; <i32> [#uses=2]
  %tmp = and i32 %1, 1                            ; <i32> [#uses=1]
  %2 = icmp eq i32 %tmp, 0                        ; <i1> [#uses=1]
  br i1 %2, label %bb2, label %bb1

bb1:                                              ; preds = %bb
  %3 = add i32 %1, %0                             ; <i32> [#uses=1]
  store i32 %3, i32* %scevgep5, align 1
  br label %bb2

bb2:                                              ; preds = %bb, %bb1
  %4 = add nsw i32 %i.0, 1                        ; <i32> [#uses=2]
  %exitcond = icmp eq i32 %4, %smax               ; <i1> [#uses=1]
  br i1 %exitcond, label %return, label %bb

return:                                           ; preds = %bb2
  ret void
}

The problem is line
  %1 = load i32* %scevgep5, align 1               ; <i32> [#uses=2]

ARM ABI at least requires that bitfield types be contained within one naturally
aligned instance of its declared type. In this case, this means unsigned int
and 32-bit alignment. I'd be surprised if other ABIs allowed less alignment.

This leads to rather inefficient code on this sample on at least armv5 targets
since they don't support unaligned loads.

clang doesn't specify alignment for this load and generates better code for
armv5.


-- 
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 Jan 31 02:17:11 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 31 Jan 2010 02:17:11 -0600
Subject: [LLVMbugs] [Bug 6186] New: hang in tail duplication compiling
 js_Interpret from Firefox
Message-ID: <bug-6186-206@http.llvm.org/bugs/>

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

           Summary: hang in tail duplication compiling js_Interpret from
                    Firefox
           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: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 5511


Created an attachment (id=4148)
 --> (http://llvm.org/bugs/attachment.cgi?id=4148)
Testcase

Testcase attached; to reproduce, run "llc xx.bc".  A few quick backtraces seem
to pin the issue on UpdateSuccessorsPHIs in TailDuplication.cpp, but I haven't
looked closely.

This might actually be a performance issue rather than a hang, but the file
takes 2.5 seconds to compile at -O0 and at least 4 minutes to compile with
optimization.


-- 
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 Jan 31 08:36:57 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 31 Jan 2010 08:36:57 -0600
Subject: [LLVMbugs] [Bug 6189] New: llc: Assertion `InReg && "Value not in
	map!"' failed
Message-ID: <bug-6189-206@http.llvm.org/bugs/>

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

           Summary: llc: Assertion `InReg && "Value not in map!"' failed
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sorokin at rain.ifmo.ru
                CC: llvmbugs at cs.uiuc.edu


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

ivan at ivan-desktop:~/d/llvm-build/Debug/bin$ ./llc 11.nopt.opt.s
llc: /home/ivan/d/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:735:
llvm::SDValue llvm::SelectionDAGBuilder::getValue(const llvm::Value*):
Assertion `InReg && "Value not in map!"' failed.
0  llc             0x000000000162c6ee
1  llc             0x000000000162c567
2  libpthread.so.0 0x00007f58e9042190
3  libc.so.6       0x00007f58e83484b5 gsignal + 53
4  libc.so.6       0x00007f58e834bf50 abort + 384
5  libc.so.6       0x00007f58e8341481 __assert_fail + 241
6  llc             0x000000000114afeb
llvm::SelectionDAGBuilder::getValue(llvm::Value const*) + 4765
7  llc             0x000000000115a5c3
llvm::SelectionDAGBuilder::visitTargetIntrinsic(llvm::CallInst&, unsigned int)
+ 637
8  llc             0x0000000001166740
llvm::SelectionDAGBuilder::visitIntrinsicCall(llvm::CallInst&, unsigned int) +
156
9  llc             0x000000000116db9c
llvm::SelectionDAGBuilder::visitCall(llvm::CallInst&) + 276
10 llc             0x0000000001149bb2 llvm::SelectionDAGBuilder::visit(unsigned
int, llvm::User&) + 1260
11 llc             0x00000000011496be
llvm::SelectionDAGBuilder::visit(llvm::Instruction&) + 52
12 llc             0x000000000118a93b
llvm::SelectionDAGISel::SelectBasicBlock(llvm::BasicBlock*,
llvm::ilist_iterator<llvm::Instruction>,
llvm::ilist_iterator<llvm::Instruction>, bool&) + 243
13 llc             0x000000000118d7d2
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function&,
llvm::MachineFunction&, llvm::MachineModuleInfo*, llvm::DwarfWriter*,
llvm::TargetInstrInfo const&) + 2646
14 llc             0x000000000118a5d7
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 983
15 llc             0x00000000012a4d97
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 95
16 llc             0x00000000015a128b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 387
17 llc             0x00000000015a0f67
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 89
18 llc             0x00000000015a0c02
llvm::FunctionPassManager::run(llvm::Function&) + 110
19 llc             0x0000000000966728 main + 3478
20 libc.so.6       0x00007f58e8333abd __libc_start_main + 253
21 llc             0x0000000000965089
Stack dump:
0.      Program arguments: ./llc 11.nopt.opt.s 
1.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@main'
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 Jan 31 09:01:54 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 31 Jan 2010 09:01:54 -0600
Subject: [LLVMbugs] [Bug 6157] opt -O1 segfault
In-Reply-To: <bug-6157-206@http.llvm.org/bugs/>
Message-ID: <201001311501.o0VF1sBe022666@zion.cs.uiuc.edu>

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


Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |dpatel at apple.com
             Status|RESOLVED                    |REOPENED
         Resolution|WORKSFORME                  |




--- Comment #7 from Duncan Sands <baldrick at free.fr>  2010-01-31 09:01:54 ---
This seems to be due to metadata:

735       assert(InReg && "Value not in map!");
Current language:  auto
The current source language is "auto; currently c++".
(gdb) call V->dump()
!{{ { { { { { \5, i32, \2, i8*, ...


-- 
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 Jan 31 10:38:05 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 31 Jan 2010 10:38:05 -0600
Subject: [LLVMbugs] [Bug 6189] llc: Assertion `InReg && "Value not in map!"'
	failed
In-Reply-To: <bug-6189-206@http.llvm.org/bugs/>
Message-ID: <201001311638.o0VGc5sh025848@zion.cs.uiuc.edu>

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


Anton Korobeynikov <asl at math.spbu.ru> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |asl at math.spbu.ru
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE




--- Comment #4 from Anton Korobeynikov <asl at math.spbu.ru>  2010-01-31 10:38:05 ---


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


-- 
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 Jan 31 19:54:57 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 31 Jan 2010 19:54:57 -0600
Subject: [LLVMbugs] [Bug 6190] New: [mips] insufficient stack space reserved
Message-ID: <bug-6190-206@http.llvm.org/bugs/>

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

           Summary: [mips] insufficient stack space reserved
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: ASSIGNED
          Keywords: ABI
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: bruno.cardoso at gmail.com
        ReportedBy: zhou_shuchang at sina.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4154)
 --> (http://llvm.org/bugs/attachment.cgi?id=4154)
will report "Illegal instruction"

The file below will report "Illegal instruction", the ll file is attached.

#include<stdio.h>
void f(){
        printf("Hi in f\n");
}
int main()
{
        f();
        printf("Hi\n");
}

Examine the assembly, we see 

f:
        .frame  $fp,8,$ra
                    ~~ O32 ABI requires at least 16 bytes reserved for outgoing
arguments
        .mask   0xC0000000,-4
        .fmask  0x00000000,0
        .set    noreorder
        .cpload $25
        .set    nomacro
        addiu   $sp, $sp, -8
        sw      $ra, 4($sp)
        sw      $fp, 0($sp)
        addu    $fp, $sp, $zero
        .cprestore      16
         ~~~~~~~~~~~~~~~~~~ this accesses 16($sp), which is out of range.
...


-- 
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 Jan 31 20:05:19 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 31 Jan 2010 20:05:19 -0600
Subject: [LLVMbugs] [Bug 6190] [mips] insufficient stack space reserved
In-Reply-To: <bug-6190-206@http.llvm.org/bugs/>
Message-ID: <201002010205.o1125J7O013586@zion.cs.uiuc.edu>

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


Bruno Cardoso Lopes <bruno.cardoso at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
                 CC|                            |bruno.cardoso at gmail.com
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED




--- Comment #1 from Bruno Cardoso Lopes <bruno.cardoso at gmail.com>  2010-01-31 20:05:18 ---
Hey, I had just fixed that together with the other bug and forgot to commit,
fixed in r94969:
http://llvm.org/viewvc/llvm-project?rev=94969&view=rev


-- 
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 Jan 31 20:45:03 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 31 Jan 2010 20:45:03 -0600
Subject: [LLVMbugs] [Bug 6192] New: [mips] wrong instruction selection for
 multiplication
Message-ID: <bug-6192-206@http.llvm.org/bugs/>

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

           Summary: [mips] wrong instruction selection for multiplication
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: ASSIGNED
          Keywords: miscompilation
          Severity: normal
          Priority: P2
         Component: new bugs
        AssignedTo: bruno.cardoso at gmail.com
        ReportedBy: zhou_shuchang at sina.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=4155)
 --> (http://llvm.org/bugs/attachment.cgi?id=4155)
wrong instruction selection for multiplication

In assembly generated for following file
#include<stdio.h>
int main(){
        int i;
        scanf("%d",&i);
        printf("i*i=%d\n",i*i);
        return 0;       
}

we see instruction sequence below generated
        mult    $2, $2
        mfhi    $2
        ~~~~ should be mflo


-- 
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 Jan 31 23:03:44 2010
From: bugzilla-daemon at cs.uiuc.edu (bugzilla-daemon at cs.uiuc.edu)
Date: Sun, 31 Jan 2010 23:03:44 -0600
Subject: [LLVMbugs] [Bug 5185] C99 [*] VLA notation should be disallowed in
 function definitions
In-Reply-To: <bug-5185-206@http.llvm.org/bugs/>
Message-ID: <201002010503.o1153ihV019431@zion.cs.uiuc.edu>

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


Sam Weinig <weinig at apple.com> changed:

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




--- Comment #1 from Sam Weinig <weinig at apple.com>  2010-01-31 23:03:38 ---
Fixed in r94972.


-- 
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.