From bugzilla-daemon at llvm.org  Sat Oct  1 01:37:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  1 Oct 2011 01:37:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10616] Crash in static analyzer
In-Reply-To: <bug-10616-206@http.llvm.org/bugs/>
References: <bug-10616-206@http.llvm.org/bugs/>
Message-ID: <20111001063703.A72CD2A6C12C@llvm.org>

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

Anna Zaks <ganna at apple.com> changed:

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

--- Comment #1 from Anna Zaks <ganna at apple.com> 2011-10-01 01:36:52 CDT ---
Fixed in r140725 + test case in r140932.

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

From bugzilla-daemon at llvm.org  Sat Oct  1 03:10:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  1 Oct 2011 03:10:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11046] New: Loop unrolling should be driven by
 optimization opportunities
Message-ID: <bug-11046-206@http.llvm.org/bugs/>

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

           Summary: Loop unrolling should be driven by optimization
                    opportunities
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This bug is split off from PR11034 to track a more general issue that can be
observed in the examples there. Consider:

% cat arr1.good.ll 
; ModuleID = 'arr1.cc'
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"

%struct.X = type { [25 x i8], [2 x i8] }

@_ZL2gx = internal unnamed_addr constant %struct.X { [25 x i8]
c"abcd\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00\00", [2 x
i8] c"a\00" }, align 1

define i32 @_Z5testXiiPc() nounwind uwtable readnone {
entry:
  br label %for.body

for.body:                                         ; preds = %for.body, %entry
  %indvars.iv = phi i64 [ 0, %entry ], [ %indvars.iv.next, %for.body ]
  %sum.02 = phi i32 [ 0, %entry ], [ %add, %for.body ]
  %arrayidx = getelementptr inbounds %struct.X* @_ZL2gx, i64 0, i32 0, i64
%indvars.iv
  %0 = load i8* %arrayidx, align 1, !tbaa !0
  %conv = sext i8 %0 to i32
  %add = add nsw i32 %conv, %sum.02
  %indvars.iv.next = add i64 %indvars.iv, 1
  %lftr.wideiv = trunc i64 %indvars.iv.next to i32
  %exitcond = icmp eq i32 %lftr.wideiv, 21
  br i1 %exitcond, label %for.end, label %for.body

for.end:                                          ; preds = %for.body
  ret i32 %add
}

!0 = metadata !{metadata !"omnipotent char", metadata !1}
!1 = metadata !{metadata !"Simple C/C++ TBAA", null}

LLVM optimizes this with ease:
% ./bin/opt -S -O3 <arr1.good.ll
; ModuleID = '<stdin>'
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"

define i32 @_Z5testXiiPc() nounwind uwtable readnone {
entry:
  ret i32 394
}

But with a tiny diff:
% diff -u arr1.good.ll arr1.bad.ll 
--- arr1.good.ll        2011-09-30 23:22:45.795562851 -0700
+++ arr1.bad.ll 2011-09-30 23:22:52.846028642 -0700
@@ -19,7 +19,7 @@
   %add = add nsw i32 %conv, %sum.02
   %indvars.iv.next = add i64 %indvars.iv, 1
   %lftr.wideiv = trunc i64 %indvars.iv.next to i32
-  %exitcond = icmp eq i32 %lftr.wideiv, 21
+  %exitcond = icmp eq i32 %lftr.wideiv, 22
   br i1 %exitcond, label %for.end, label %for.body

 for.end:% diff -u arr1.good.ll arr1.bad.ll 

LLVM can't touch it, and it stays exactly the same.

>From PR11034, Andy said:
> Unrolling should be driven by identification of opportunities,
> not a context independent size threshold. I suggest you file another bug on
> that. I plan to close this one after making a minor fix to the hueristics.

So filed. =]

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

From bugzilla-daemon at llvm.org  Sat Oct  1 03:38:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  1 Oct 2011 03:38:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11047] New: test-suite execution broken
Message-ID: <bug-11047-206@http.llvm.org/bugs/>

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

           Summary: test-suite execution broken
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Somewhere between 140000 and 140468 the test-suite does not work anymore at
all.

It is configured like:
../../src-test-suite/configure \
  --with-llvmsrc=/data/buildslave/clang-amd64-freebsd-fnt/src-llvm \
  --with-llvmobj=/data/buildslave/clang-amd64-freebsd-fnt/obj/llvm.1

gmake -j2 ENABLE_PARALLEL_REPORT=1 DISABLE_CBE=1 DISABLE_JIT=1 TEST=nightly
report

... build output ...
I/data/buildslave/clang-amd64-freebsd-fnt/obj/test-suite.1/SingleSource/UnitTests/Vector/SSE
-I/data/buildslave/clang-amd64-freebsd-fnt/src-test-suite/SingleSource/UnitTests/Vector/SSE
-I/data/buildslave/clang-amd64-freebsd-fnt/obj/test-suite.1/../../src-test-suite/include
-I../../../../include
-I/data/buildslave/clang-amd64-freebsd-fnt/obj/llvm.1/include
-I/data/buildslave/clang-amd64-freebsd-fnt/src-llvm/include -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS -DNDEBUG  -O3 -mllvm -disable-llvm-optzns -msse2 -m64
-fomit-frame-pointer -S
/data/buildslave/clang-amd64-freebsd-fnt/src-test-suite/SingleSource/UnitTests/Vector/SSE/sse.expandfft.c
-o Output/sse.expandfft.ll -emit-llvm
gmake[5]:
I/data/buildslave/clang-amd64-freebsd-fnt/obj/test-suite.1/SingleSource/UnitTests/Vector/SSE:
Command not found
gmake[5]: [Output/sse.expandfft.ll] Error 127 (ignored)

Other command it tries to execute are also incomplete:

gcc -DDEBUG ... -o Output/zalloc.o
DDEBUG ... -o Output/be.ll -emit-llvm
gmake[4]: DDEBUG: Command not found
gmake[4]: [Output/be.ll] Error 127 (ignored)

So it looks like the commands are missing the compiler. It could be related to
the autoconf/configure changes by echristo.

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

From bugzilla-daemon at llvm.org  Sat Oct  1 04:42:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  1 Oct 2011 04:42:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11048] New: Crash when initializing array of
	typedef-ed arrays
Message-ID: <bug-11048-206@http.llvm.org/bugs/>

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

           Summary: Crash when initializing array of typedef-ed arrays
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ori at avtalion.name
                CC: llvmbugs at cs.uiuc.edu


Using r140938.

Compiling the following code with "clang -c" causes a crash:

typedef char foo[10];
foo bar[] = { "hello" };

This used to work, so it's a regression.

I only have a release build, so I can't provide useful debug symbols.

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

From bugzilla-daemon at llvm.org  Sat Oct  1 14:58:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  1 Oct 2011 14:58:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10702] [x86 disassembler] crc32 not disassembled
	correctly
In-Reply-To: <bug-10702-206@http.llvm.org/bugs/>
References: <bug-10702-206@http.llvm.org/bugs/>
Message-ID: <20111001195817.DDB1F2A6C12C@llvm.org>

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

Craig Topper <craig.topper at gmail.com> changed:

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

--- Comment #6 from Craig Topper <craig.topper at gmail.com> 2011-10-01 14:58:09 CDT ---
Fixed in r140954.

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

From bugzilla-daemon at llvm.org  Sat Oct  1 15:36:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  1 Oct 2011 15:36:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11049] New: undefined reference to
 '__builtin_eh_copy_values' on mutiple c++ programs with
 -fplugin-arg-dragonegg-enable-gcc-optzns
Message-ID: <bug-11049-206@http.llvm.org/bugs/>

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

           Summary: undefined reference to '__builtin_eh_copy_values' on
                    mutiple c++ programs with
                    -fplugin-arg-dragonegg-enable-gcc-optzns
           Product: dragonegg
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: jkillius at arcor.de
                CC: llvmbugs at cs.uiuc.edu


Hi,
if I use -fplugin-arg-dragonegg-enable-gcc-optzns on c++ programs I get this
error message:
undefined reference to '__builtin_eh_copy_values'

Here is an example:
.obj/mediapanel.o:mediapanel.cpp:function MediaPanel::~MediaPanel(): error:
undefined reference to '__builtin_eh_copy_values'                               
.obj/mediapanel.o:mediapanel.cpp:function MediaPanel::~MediaPanel(): error:
undefined reference to '__builtin_eh_copy_values'                               
.obj/mediapanel.o:mediapanel.cpp:function MediaPanel::~MediaPanel(): error:
undefined reference to '__builtin_eh_copy_values'                               
.obj/mediapanel.o:mediapanel.cpp:function MediaPanel::~MediaPanel(): error:
undefined reference to '__builtin_eh_copy_values'


code:
MediaPanel::~MediaPanel()                                                       
{                                                                               

}

I'm using the trunk versions of gcc 4.6,llvm,dragonegg

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

From bugzilla-daemon at llvm.org  Sun Oct  2 11:56:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  2 Oct 2011 11:56:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10344] Incorrect disassembly for "0x49 0x90" on
 x86-64 ("xchg %r8, %rax")
In-Reply-To: <bug-10344-206@http.llvm.org/bugs/>
References: <bug-10344-206@http.llvm.org/bugs/>
Message-ID: <20111002165628.CE1E22A6C12C@llvm.org>

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

Craig Topper <craig.topper at gmail.com> changed:

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

--- Comment #1 from Craig Topper <craig.topper at gmail.com> 2011-10-02 11:56:24 CDT ---
Fixed in r140971.

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

From bugzilla-daemon at llvm.org  Sun Oct  2 13:47:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  2 Oct 2011 13:47:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11050] New: make fails on MinGW+MSYS
Message-ID: <bug-11050-206@http.llvm.org/bugs/>

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

           Summary: make fails on MinGW+MSYS
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gyorokpeter at freemail.hu
                CC: llvmbugs at cs.uiuc.edu


When I try to run make from msys it fails at opt.exe with about 7000 "undefined
reference" errors in AnalysisWrappers.o. This happens with 2.8, 2.9 and the SVN
versions.

Operating system: Windows 7 (64-bit)

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

From bugzilla-daemon at llvm.org  Sun Oct  2 14:23:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  2 Oct 2011 14:23:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11037] PATCH: Ubuntu 11.04 64Bit
In-Reply-To: <bug-11037-206@http.llvm.org/bugs/>
References: <bug-11037-206@http.llvm.org/bugs/>
Message-ID: <20111002192344.DC107312800A@llvm.org>

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

Peter K?mmel <syntheticpp at gmx.net> changed:

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

--- Comment #5 from Peter K?mmel <syntheticpp at gmx.net> 2011-10-02 14:23:42 CDT ---
Did an update to r140972, and linking works now without the 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 llvm.org  Sun Oct  2 17:51:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  2 Oct 2011 17:51:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11051] New: c++0x typeinfo header dies
Message-ID: <bug-11051-206@http.llvm.org/bugs/>

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

           Summary: c++0x typeinfo header dies
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: tim.dawborn at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7388)
 --> (http://llvm.org/bugs/attachment.cgi?id=7388)
described test.cc

Inclusion of the <typeinfo> header when using c++0x causes a fatal error:

$ uname -a
Linux pc-4e43-0 2.6.32-34-generic-pae #77-Ubuntu SMP Tue Sep 13 21:16:18 UTC
2011 i686 GNU/Linux

$ clang++ --version
clang version 3.0 (trunk 140931)
Target: i386-pc-linux-gnu
Thread model: posix

$ cat test.cc
#include <typeinfo>
int
main(void) {
  return 0;
}

$ clang++ -std=c++0x test.cc -o test
In file included from test.cc:1:
In file included from /usr/include/c++/4.4/typeinfo:34:
In file included from /usr/include/c++/4.4/exception:148:
/usr/include/c++/4.4/exception_ptr.h:143:13: error: unknown type name
'type_info'
      const type_info*
            ^
1 error 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 llvm.org  Sun Oct  2 18:04:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  2 Oct 2011 18:04:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11052] New: SCEV produces two objects for identical
	inputs
Message-ID: <bug-11052-206@http.llvm.org/bugs/>

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

           Summary: SCEV produces two objects for identical inputs
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


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

A unittest is attached, but the short story is that this:

  SmallVector<const SCEV *, 4> Sum;
  Sum.push_back(SE.getMulExpr(Arg1, Arg2));
  Sum.push_back(SE.getMulExpr(Arg3, Arg2));
  Sum.push_back(SE.getMulExpr(Arg1, Arg4));
  const SCEV *LHS = SE.getAddExpr(Sum);

  const SCEV *RHS = SE.getMulExpr(Arg1, Arg2);
  RHS = SE.getAddExpr(RHS, SE.getMulExpr(Arg3, Arg2));
  RHS = SE.getAddExpr(RHS, SE.getMulExpr(Arg1, Arg4));

produces two different SCEVs:

  LHS: (((%1 + %3) * %0) + (%1 * %2))
  RHS: (((%0 + %2) * %1) + (%0 * %3))

In particular note how everything is in the same order, all 3 MulExpr's are the
same inputs, and they're used in the same order.

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

From bugzilla-daemon at llvm.org  Mon Oct  3 01:37:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  3 Oct 2011 01:37:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11051] c++0x typeinfo header dies
In-Reply-To: <bug-11051-206@http.llvm.org/bugs/>
References: <bug-11051-206@http.llvm.org/bugs/>
Message-ID: <20111003063740.845892A6C130@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-03 01:37:39 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon Oct  3 05:37:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  3 Oct 2011 05:37:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10978] dllexport/dllimport attributes not known for
	x86_64
In-Reply-To: <bug-10978-206@http.llvm.org/bugs/>
References: <bug-10978-206@http.llvm.org/bugs/>
Message-ID: <20111003103730.EEB782A6C12E@llvm.org>

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

vanboxem.ruben at gmail.com changed:

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

--- Comment #4 from vanboxem.ruben at gmail.com 2011-10-03 05:37:25 CDT ---
r140871

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

From bugzilla-daemon at llvm.org  Mon Oct  3 07:24:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  3 Oct 2011 07:24:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11053] New: Checker should warn against any use of
	vfork()
Message-ID: <bug-11053-206@http.llvm.org/bugs/>

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

           Summary: Checker should warn against any use of vfork()
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: graham at fuzzyaliens.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7391)
 --> (http://llvm.org/bugs/attachment.cgi?id=7391)
Patch adds use of vfork() as a security issue.

According to SEI CERT guideline POS33-C[*], vfork(2) should not be used due to
potential denial of service issues and undefined behaviour across different
implementations. The attached patch adds a check to
experimental.security.SecuritySyntactic to detect and report an issue on use of
vfork().

[*]
https://www.securecoding.cert.org/confluence/display/seccode/POS33-C.+Do+not+use+vfork%28%29

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

From bugzilla-daemon at llvm.org  Mon Oct  3 15:34:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  3 Oct 2011 15:34:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11048] Crash when initializing array of typedef-ed
	arrays
In-Reply-To: <bug-11048-206@http.llvm.org/bugs/>
References: <bug-11048-206@http.llvm.org/bugs/>
Message-ID: <20111003203443.F2C1D2A6C124@llvm.org>

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

Ori Avtalion <ori at avtalion.name> changed:

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

--- Comment #4 from Ori Avtalion <ori at avtalion.name> 2011-10-03 15:34:39 CDT ---
Oops. You are correct. My repetitive builds did not even succeed.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 01:03:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 01:03:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10832] "movbe" is not recognized as an x86 mnemonic
In-Reply-To: <bug-10832-206@http.llvm.org/bugs/>
References: <bug-10832-206@http.llvm.org/bugs/>
Message-ID: <20111004060352.52A012A6C12D@llvm.org>

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

Craig Topper <craig.topper at gmail.com> changed:

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

--- Comment #2 from Craig Topper <craig.topper at gmail.com> 2011-10-04 01:03:44 CDT ---
Fixed in r141007.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 01:03:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 01:03:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11026] [x86 assembler] rdrand not recognized?
In-Reply-To: <bug-11026-206@http.llvm.org/bugs/>
References: <bug-11026-206@http.llvm.org/bugs/>
Message-ID: <20111004060359.B0C582A6C12C@llvm.org>

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

Craig Topper <craig.topper at gmail.com> changed:

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

--- Comment #6 from Craig Topper <craig.topper at gmail.com> 2011-10-04 01:03:54 CDT ---
Fixed in r141007.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 01:05:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 01:05:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11027] [x86 disassembler] rdrand not recognized
In-Reply-To: <bug-11027-206@http.llvm.org/bugs/>
References: <bug-11027-206@http.llvm.org/bugs/>
Message-ID: <20111004060524.8455F2A6C12C@llvm.org>

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

Craig Topper <craig.topper at gmail.com> changed:

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

--- Comment #5 from Craig Topper <craig.topper at gmail.com> 2011-10-04 01:05:24 CDT ---
Fixed in r141007.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 01:31:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 01:31:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10676] [x86 disassembler] L bit in VEX prefix is
 not ignored properly
In-Reply-To: <bug-10676-206@http.llvm.org/bugs/>
References: <bug-10676-206@http.llvm.org/bugs/>
Message-ID: <20111004063127.5BCB92A6C12C@llvm.org>

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

Craig Topper <craig.topper at gmail.com> changed:

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

--- Comment #8 from Craig Topper <craig.topper at gmail.com> 2011-10-04 01:31:24 CDT ---
Fixed in 141065.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 09:10:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 09:10:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11054] New: avoid substituting -clang in lit
Message-ID: <bug-11054-206@http.llvm.org/bugs/>

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

           Summary: avoid substituting -clang in lit
           Product: Test Suite
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: lit
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: patrik.h.hagglund at ericsson.com
                CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org


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

I tried to build in a subdirectory 'build-clang'. That made 'make check' fail:

/local/scratch/uabpath/master/build-clang/test/BugPoint/Output/metadata.ll.script:
line 2:
/local/scratch/uabpath/master/build-/local/scratch/uabpath/master/build-clang/Debug+Asserts/bin/clang/Debug+Asserts/bin/bugpoint:
No such file or directory

Here is a patch:

diff --git a/test/lit.cfg b/test/lit.cfg
index c588efa..85f54d8 100644
--- a/test/lit.cfg
+++ b/test/lit.cfg
@@ -177,12 +177,12 @@ for sub in ['llvmgcc', 'llvmgxx', 'emitir',
'compile_cxx', 'compile_c',
 # includes every tool placed in $(LLVM_OBJ_ROOT)/$(BuildMode)/bin
 # (llvm_tools_dir in lit parlance).
                 # Don't match 'bugpoint-' or 'clang-'.
-                                        # Don't match '/clang'.
+                                        # Don't match '/clang' or '-clang'.
 if os.pathsep == ';':
     pathext = os.environ.get('PATHEXT', '').split(';')
 else:
     pathext = ['']
-for pattern in [r"\bbugpoint\b(?!-)",   r"(?<!/)\bclang\b(?!-)",
+for pattern in [r"\bbugpoint\b(?!-)",   r"(?<!/|-)\bclang\b(?!-)",
                 r"\bgold\b",
                 r"\bllc\b",             r"\blli\b",
                 r"\bllvm-ar\b",         r"\bllvm-as\b",

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

From bugzilla-daemon at llvm.org  Tue Oct  4 11:12:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 11:12:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11054] avoid substituting -clang in lit
In-Reply-To: <bug-11054-206@http.llvm.org/bugs/>
References: <bug-11054-206@http.llvm.org/bugs/>
Message-ID: <20111004161300.86DCA3128018@llvm.org>

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

David Dean <david_dean at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE
         AssignedTo|unassignedbugs at nondot.org   |david_dean at apple.com

--- Comment #2 from David Dean <david_dean at apple.com> 2011-10-04 11:12:58 CDT ---
LGTM.

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

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

From bugzilla-daemon at llvm.org  Tue Oct  4 11:27:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 11:27:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9833] broken lit substitutions
In-Reply-To: <bug-9833-206@http.llvm.org/bugs/>
References: <bug-9833-206@http.llvm.org/bugs/>
Message-ID: <20111004162731.E5E592A6C12C@llvm.org>

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

David Dean <david_dean at apple.com> changed:

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

--- Comment #5 from David Dean <david_dean at apple.com> 2011-10-04 11:27:31 CDT ---
Committed revision 141092.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 12:02:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 12:02:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11049] undefined reference to
 '__builtin_eh_copy_values' on mutiple c++ programs with
 -fplugin-arg-dragonegg-enable-gcc-optzns
In-Reply-To: <bug-11049-206@http.llvm.org/bugs/>
References: <bug-11049-206@http.llvm.org/bugs/>
Message-ID: <20111004170209.9D3CE2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #4 from Duncan Sands <baldrick at free.fr> 2011-10-04 12:02:04 CDT ---
Thanks for the testcases.  Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111003/129111.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 llvm.org  Tue Oct  4 12:46:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 12:46:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11056] New: very large array initialization(s)
 gives a segmentation fault
Message-ID: <bug-11056-206@http.llvm.org/bugs/>

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

           Summary: very large array initialization(s) gives a
                    segmentation fault
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dotsojourner at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7398)
 --> (http://llvm.org/bugs/attachment.cgi?id=7398)
bzip2 compressed attachment. Trimmed version is inlined in the report.

# The command issued:

clang -c t.c -Wall

# output:

0  clang 0x09728db8
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple i386-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name t.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -target-linker-version 2.18.0.20080103
-momit-leaf-frame-pointer -resource-dir /usr/bin/../lib/clang/2.9 -Wall
-ferror-limit 19 -fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o t.o -x c t.c 
1.    t.c:29767:2: current parser token ';'
clang: error: unable to execute command: Segmentation fault (core dumped)
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)



# clang --version

clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-linux-gnu
Thread model: posix

the test case (trimmed to fit. see the attachment is a complete test case):
    1 int X[29942][2]={
    2 {0},
    3 {0},
    4 {0},
    5 {0},
    6 {0},
    7 {0},
..
..
..

29764 {0},
29765 {0},
29766 {0}
29767 };



# Note:

I was not able to simulate the segmentation fault with any less number of
initializing values or dimensions. The original array was [65536][16] ... on
running that, the output is:


# output 2:

0  clang 0x09728db8
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple i386-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
dst_common.i -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -target-cpu pentium4 -target-linker-version
2.18.0.20080103 -momit-leaf-frame-pointer -resource-dir
/usr/bin/../lib/clang/2.9 -Wall -ferror-limit 19 -fmessage-length 80
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o dst_common.o -x
cpp-output dst_common.i 
1.    terminate called after throwing an instance of 'std::bad_alloc'
  what():  std::bad_alloc
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal 1 (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 llvm.org  Tue Oct  4 13:38:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 13:38:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11057] New: Provide API migration guide for
 exception handling in LLVM 3.0
Message-ID: <bug-11057-206@http.llvm.org/bugs/>

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

           Summary: Provide API migration guide for exception handling in
                    LLVM 3.0
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: wendling at apple.com
        ReportedBy: dgregor at apple.com
                CC: llvmbugs at cs.uiuc.edu


Exception handling was overhauled for LLVM 3.0. We should have a guide
available as part of LLVM 3.0 that describes how to migrate from the old EH
APIs to the new EH APIs.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 14:13:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 14:13:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8882] Need an "isexact" bit for shift left
In-Reply-To: <bug-8882-206@http.llvm.org/bugs/>
References: <bug-8882-206@http.llvm.org/bugs/>
Message-ID: <20111004191316.DBA292A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #8 from Chris Lattner <clattner at apple.com> 2011-10-04 14:13:01 CDT ---
This looks resolved to me, thanks Andy.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 14:42:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 14:42:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10607] JIT No Longer Registers EH Information
In-Reply-To: <bug-10607-206@http.llvm.org/bugs/>
References: <bug-10607-206@http.llvm.org/bugs/>
Message-ID: <20111004194238.6586A2A6C12C@llvm.org>

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

David Chisnall <csdavec at swan.ac.uk> changed:

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

--- Comment #1 from David Chisnall <csdavec at swan.ac.uk> 2011-10-04 14:42:33 CDT ---
Not sure when, but this has been fixed by someone 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 llvm.org  Tue Oct  4 15:14:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 15:14:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11058] New: dragon segfault with gcc 4.6 trunk and
 -fexpensive-optimizations and enabled gcc optimizer
Message-ID: <bug-11058-206@http.llvm.org/bugs/>

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

           Summary: dragon segfault with gcc 4.6 trunk and
                    -fexpensive-optimizations and enabled gcc optimizer
           Product: dragonegg
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: jkillius at arcor.de
                CC: llvmbugs at cs.uiuc.edu


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

g++ -march=native -O1 -fexpensive-optimizations -fplugin=dragonegg.so
-fplugin-arg-dragonegg-enable-gcc-optzns test.cpp -o test

*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_FINISH_UNIT               | dragonegg
PLUGIN_FINISH                    | dragonegg
PLUGIN_START_UNIT                | dragonegg
PLUGIN_ALL_IPA_PASSES_END        | dragonegg
test.cpp: In function ?test(SelectiveAck const*)?:
test.cpp:23:8: internal compiler error: Segmentation fault
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 15:16:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 15:16:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7656] Clang generates incorrect IR for
	__attribute__((cleanup))
In-Reply-To: <bug-7656-206@http.llvm.org/bugs/>
References: <bug-7656-206@http.llvm.org/bugs/>
Message-ID: <20111004201632.EB4F52A6C124@llvm.org>

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

David Chisnall <csdavec at swan.ac.uk> changed:

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

--- Comment #8 from David Chisnall <csdavec at swan.ac.uk> 2011-10-04 15:16:18 CDT ---
I'm pretty sure the EH rewrite fixed 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 llvm.org  Tue Oct  4 15:32:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 15:32:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11056] very large array initialization(s) gives a
 segmentation fault
In-Reply-To: <bug-11056-206@http.llvm.org/bugs/>
References: <bug-11056-206@http.llvm.org/bugs/>
Message-ID: <20111004203209.29F052A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-04 15:32:06 CDT ---
r141106.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 15:34:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 15:34:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11059] New: Warn for use of array types with va_arg
Message-ID: <bug-11059-206@http.llvm.org/bugs/>

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

           Summary: Warn for use of array types with va_arg
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


Using arrays with va_arg seems to be undefined behavior. It would be useful if
clang actually warned about that, possibly even error by default.

See http://gnats.netbsd.org/45138 for a longer discussion and test cases.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 16:15:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 16:15:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11060] New: configure --target does not work
Message-ID: <bug-11060-206@http.llvm.org/bugs/>

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

           Summary: configure --target does not work
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: autoconf
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: spop at codeaurora.org
                CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org


I tried to build a cross compiler configuring llvm with --host=x86
--target=arm.  The clang driver outputs x86 assembly and the only way
to output arm assembly is by specifying a -ccc-host-triple option.

It seems like clang decides to target the host machine by default, and
not the machine that has been specified on the configure line using
the --target option.  There are several places in clang that call
llvm::sys::getHostTriple() to initialize the *target* driver:

- lib/Frontend/CompilerInvocation.cpp: in ParseTargetArgs
- lib/Frontend/CreateInvocationFromCommandLine.cpp: in
clang::createInvocationFromCommandLine
- tools/driver/cc1as_main.cpp: in AssemblerInvocation::CreateFromArgs
- tools/driver/driver.cpp: in main
- examples/clang-interpreter/main.cpp: in main

In all these places I would suggest to replace the call to
llvm::sys::getHostTriple() with a call to a yet to be written function
llvm::sys::getDefaultTargetTriple() that would return the default
triple that we get from configure --target.

Comments are welcome on how to better fix this.

Thanks,
Sebastian Pop
--
Qualcomm Innovation Center, Inc is a member of Code Aurora Forum

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

From bugzilla-daemon at llvm.org  Tue Oct  4 18:04:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 18:04:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11061] New: High optimization produces incorrect
	result
Message-ID: <bug-11061-206@http.llvm.org/bugs/>

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

           Summary: High optimization produces incorrect result
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: steven at ngls.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The attached code produces incorrect results
when compiled with -O2 or -O3:


bluishred:~ 556 ? /usr/local/dev/Linux_x86_64/clang-trunk/bin/clang++ -O3
tclc.cpp -DWORKAROUND
bluishred:~ 557 ? ./a.out
nameMap.count( "" ): 0   should be zero!
nameMap.count( "" ): 0   should be zero!
nameMap.count( "" ): 0   should be zero!
bluishred:~ 558 ? /usr/local/dev/Linux_x86_64/clang-trunk/bin/clang++ -O3
tclc.cpp
bluishred:~ 559 ? ./a.out
nameMap.count( "" ): 0   should be zero!
nameMap.count( "" ): 1   should be zero!
nameMap.count( "" ): 1   should be zero!
bluishred:~ 560 ? /usr/local/dev/Linux_x86_64/clang-trunk/bin/clang++ -O2
tclc.cpp
bluishred:~ 561 ? ./a.out
nameMap.count( "" ): 0   should be zero!
nameMap.count( "" ): 1   should be zero!
nameMap.count( "" ): 1   should be zero!
bluishred:~ 562 ? /usr/local/dev/Linux_x86_64/clang-trunk/bin/clang++ -O1
tclc.cpp
bluishred:~ 563 ? ./a.out
nameMap.count( "" ): 0   should be zero!
nameMap.count( "" ): 0   should be zero!
nameMap.count( "" ): 0   should be zero!
bluishred:~ 564 ? /usr/local/dev/Linux_x86_64/clang-trunk/bin/clang++ -v
clang version 3.0 (trunk 140700)
Target: x86_64-unknown-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 llvm.org  Tue Oct  4 19:08:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 19:08:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9553] [JIT] calls to @llvm.memset end up trying to
	jump to zero
In-Reply-To: <bug-9553-206@http.llvm.org/bugs/>
References: <bug-9553-206@http.llvm.org/bugs/>
Message-ID: <20111005000846.3DD402A6C12D@llvm.org>

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

Matt Pharr <matt at pharr.org> changed:

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

--- Comment #2 from Matt Pharr <matt at pharr.org> 2011-10-04 19:08:44 CDT ---
I've spent a bit of time trying to put together a full test case that
reproduces this, with no success.  A lesson for me to submit the test case when
I've got it.  Marking resolved/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 llvm.org  Tue Oct  4 19:18:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 19:18:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11003] clang cannot find a conversion in c++0x mode
In-Reply-To: <bug-11003-206@http.llvm.org/bugs/>
References: <bug-11003-206@http.llvm.org/bugs/>
Message-ID: <20111005001852.679CB2A6C12F@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-10-04 19:18:50 CDT ---
(In reply to comment #3)
> Hmm... I think clang is messing up here: it's somehow picking the
> Value(Value&&) constructor, but realizes it isn't viable when it actually tries
> to perform the conversion in question.

Eli is correct. We shouldn't have allowed the binding to the rvalue reference
in the first place. Fixed in Clang r141137.

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

From bugzilla-daemon at llvm.org  Tue Oct  4 19:22:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 19:22:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11062] New: inline keyword ignored for function
	called strlcpy
Message-ID: <bug-11062-206@http.llvm.org/bugs/>

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

           Summary: inline keyword ignored for function called strlcpy
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: crigler at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

clang in -std=c99 mode ignores the inline keyword when used on a function
called strlcpy, causing the code to always be emitted. It works if the function
is renamed to my_strlcpy. gcc -std=c99 works either 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 llvm.org  Tue Oct  4 20:40:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 20:40:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11063] New: Inliner incorrectly removes non-dead
 code w/ lazy bitcode
Message-ID: <bug-11063-206@http.llvm.org/bugs/>

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

           Summary: Inliner incorrectly removes non-dead code w/ lazy
                    bitcode
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: boulos at cs.stanford.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7402)
 --> (http://llvm.org/bugs/attachment.cgi?id=7402)
bitcode loading app

This is a simpler test case from the one I posted in July
(http://lists.cs.uiuc.edu/pipermail/llvmdev/2011-July/041187.html).

The setup is that I've got some simple bitcode with a template in it, which
causes a function to be marked linkonce_odr. If I load the bitcode via
getLazyBitcodeModule() though and then optimize the module with the Inliner, it
incorrectly treats the templated code as dead because it sees no callsites (and
it's linkonce_odr).

The original input (bitcode_input.cc) was:

template<typename T>
class SomeContainer {
public:
   T* getPtr() { return data; }
   T* data;
};

extern "C"
float* RunStuff(void) {
   SomeContainer<float> emptyContainer;
   return emptyContainer.getPtr();
}


To reproduce:

clang++ -emit-llvm -c bitcode_input.cc -o test.bc
clang++ `llvm-config --cxxflags --ldflags --libs` load_bitcode.cc
./a.out

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

From bugzilla-daemon at llvm.org  Tue Oct  4 23:47:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  4 Oct 2011 23:47:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11064] New: Duplicate store instructions
Message-ID: <bug-11064-206@http.llvm.org/bugs/>

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

           Summary: Duplicate store instructions
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7403)
 --> (http://llvm.org/bugs/attachment.cgi?id=7403)
The LLVM file.

The current trunk version of LLVM generates duplicate store instructions for
the attached LLVM code. This code was generated by clang for the following
function:

double _Complex maybe_an_fma(double _Complex a, double _Complex b, double
_Complex c)
{
        return a*b + c;
}


Running Debug+Asserts/bin/llc -O3 -o - t.ll yields an assembly sequence which
ends with:
    addsd    40(%esp), %xmm0
    movl    4(%esp), %eax
    movsd    %xmm0, (%eax)
    movsd    %xmm1, 8(%eax)
    movsd    %xmm1, 8(%eax)
    ret    $4

Running Debug+Asserts/bin/llc -O3 -mtriple=powerpc-unknown-linux-gnu -o - t.ll
yields an assembly sequence which ends with:
    fadd 0, 0, 4
    stfd 1, 0(3)
    stfd 0, 8(3)
    stfd 0, 8(3)
    blr 

In both cases, the final store instructions are identical. The LLVM ends with:
  %real1 = getelementptr inbounds %0* %agg.result, i32 0, i32 0
  %imag2 = getelementptr inbounds %0* %agg.result, i32 0, i32 1
  store double %agg.result.real, double* %real1
  store double %agg.result.imag, double* %imag2
  ret void
(full LLVM file attached). Something seems amiss.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 03:14:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 03:14:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11060] configure --target does not work
In-Reply-To: <bug-11060-206@http.llvm.org/bugs/>
References: <bug-11060-206@http.llvm.org/bugs/>
Message-ID: <20111005081406.075D62A6C12F@llvm.org>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2011-10-05 03:14:01 CDT ---
Yeah, noone was brave enough to "fix" cross-compilation to work properly w/o
additional knobs and options.

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

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

From bugzilla-daemon at llvm.org  Wed Oct  5 03:36:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 03:36:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11064] Duplicate store instructions
In-Reply-To: <bug-11064-206@http.llvm.org/bugs/>
References: <bug-11064-206@http.llvm.org/bugs/>
Message-ID: <20111005083649.3DB922A6C12C@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |baldrick at free.fr
         Resolution|                            |INVALID

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-10-05 03:36:44 CDT ---
llc expects the IR level optimizers to have been run first.  It doesn't do IR
level optimization itself, it only does codegen level optimizations.  If you
run "opt -std-compile-opts" on your LLVM IR and run llc on the result then the
problematic code is no longer there, because the IR level optimizations that
opt runs eliminate the duplicate getelementptr instructions and stores.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 05:17:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 05:17:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11065] New: 'Archaic' protocol use crashes clang
Message-ID: <bug-11065-206@http.llvm.org/bugs/>

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

           Summary: 'Archaic' protocol use crashes clang
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu


This program now crashes clang, even with -fsyntax-only:

@protocol Broken @end
@interface Crash @end
@implementation Crash
- (void)crashWith:(<Broken>)a {
}
@end

This appears to be a recent regression - Clang from last week works fine...

The back trace is:


#0  0x000000080423f93c in thr_kill () from /lib/libc.so.7
#1  0x00000008042dddfb in abort () from /lib/libc.so.7
#2  0x00000008042c7265 in __assert () from /lib/libc.so.7
#3  0x00000000010f42f7 in clang::SourceLocation::getLocWithOffset
(this=0x7fffffff9598, Offset=-1)
    at SourceLocation.h:131
#4  0x0000000001e98446 in getArgLoc (Arg=0x804c56390)
    at /home/theraven/llvm/tools/clang/lib/AST/SelectorLocationsKind.cpp:58
#5  0x0000000001e983f7 in getArgLoc (Index=0, Args={Data = 0x7fffffff9e50,
Length = 1})
    at /home/theraven/llvm/tools/clang/lib/AST/SelectorLocationsKind.cpp:63
#6  0x0000000001e9837b in clang::getStandardSelectorLoc (Index=0, Sel={InfoPtr
= 34439774850}, 
    WithArgSpace=false, Args={Data = 0x7fffffff9e50, Length = 1}, EndLoc={ID =
98})
    at /home/theraven/llvm/tools/clang/lib/AST/SelectorLocationsKind.cpp:124
#7  0x0000000001e981eb in hasStandardSelLocs (Sel={InfoPtr = 34439774850},
SelLocs=
      {Data = 0x7fffffffaca0, Length = 1}, Args={Data = 0x7fffffff9e50, Length
= 1}, EndLoc={ID = 98})
    at /home/theraven/llvm/tools/clang/lib/AST/SelectorLocationsKind.cpp:74
#8  0x0000000001e9813d in clang::hasStandardSelectorLocs (Sel={InfoPtr =
34439774850}, SelLocs=
      {Data = 0x7fffffffaca0, Length = 1}, Args={Data = 0x7fffffff9e50, Length
= 1}, EndLoc={ID = 98})
    at /home/theraven/llvm/tools/clang/lib/AST/SelectorLocationsKind.cpp:115
#9  0x0000000001e0bc49 in clang::ObjCMethodDecl::setMethodParams
(this=0x804c56300, C=@0x804d05800, Params=
      {Data = 0x7fffffff9e50, Length = 1}, SelLocs={Data = 0x7fffffffaca0,
Length = 1})
    at /home/theraven/llvm/tools/clang/lib/AST/DeclObjC.cpp:383
#10 0x0000000001608ced in clang::Sema::ActOnMethodDeclaration
(this=0x804d49500, S=0x804dbb380, MethodLoc=
      {ID = 68}, EndLoc={ID = 98}, MethodType=clang::tok::minus,
ReturnQT=@0x7fffffffaf20, ReturnType=
      {Ptr = 0x7fffffff98a0}, SelectorLocs={Data = 0x7fffffff98a0, Length =
18446744071575798464}, Sel=
      {InfoPtr = 140737488328864}, ArgInfo=0x7fffffffa9e0,
CParamInfo=0x7fffffffadb0, CNumArgs=0, 
    AttrList=0x0, MethodDeclKind=clang::tok::objc_not_keyword,
isVariadic=false, MethodDefinition=true)
    at /home/theraven/llvm/tools/clang/lib/Sema/SemaDeclObjC.cpp:2614
#11 0x000000000146ba30 in clang::Parser::ParseObjCMethodDecl (this=0x804c23100,
mLoc={ID = 68}, 
    mType=clang::tok::minus, MethodImplKind=clang::tok::objc_not_keyword,
MethodDefinition=true)
    at /home/theraven/llvm/tools/clang/lib/Parse/ParseObjc.cpp:1094
#12 0x000000000146aa26 in clang::Parser::ParseObjCMethodPrototype
(this=0x804c23100, 
    MethodImplKind=clang::tok::objc_not_keyword, MethodDefinition=true)
    at /home/theraven/llvm/tools/clang/lib/Parse/ParseObjc.cpp:610
#13 0x000000000146e379 in clang::Parser::ParseObjCMethodDefinition
(this=0x804c23100)
    at /home/theraven/llvm/tools/clang/lib/Parse/ParseObjc.cpp:1840
#14 0x000000000148f7d2 in clang::Parser::ParseExternalDeclaration
(this=0x804c23100, attrs=@0x7fffffffb810, 
    DS=0x0) at /home/theraven/llvm/tools/clang/lib/Parse/Parser.cpp:611
#15 0x000000000148f0d9 in clang::Parser::ParseTopLevelDecl (this=0x804c23100,
Result=@0x7fffffffb908)
    at /home/theraven/llvm/tools/clang/lib/Parse/Parser.cpp:511
#16 0x0000000001465f7e in clang::ParseAST (S=@0x804d49500, PrintStats=false)
    at /home/theraven/llvm/tools/clang/lib/Parse/ParseAST.cpp:84
#17 0x0000000001137d28 in clang::ASTFrontendAction::ExecuteAction
(this=0x804c72b50)
    at /home/theraven/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:379
#18 0x0000000001137973 in clang::FrontendAction::Execute (this=0x804c72b50)
    at /home/theraven/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:299
#19 0x00000000011166cd in clang::CompilerInstance::ExecuteAction
(this=0x804c1c100, Act=@0x804c72b50)
    at /home/theraven/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:618
#20 0x00000000010e04bf in clang::ExecuteCompilerInvocation (Clang=0x804c1c100)
    at
/home/theraven/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:172
#21 0x00000000010ce2be in cc1_main (ArgBegin=0x7fffffffcab0,
ArgEnd=0x7fffffffcbc8, 
    Argv0=0x804c18488 "/home/theraven/llvm/Debug+Asserts/bin/clang",
MainAddr=0x10da4a0)
    at /home/theraven/llvm/tools/clang/tools/driver/cc1_main.cpp:159
#22 0x00000000010da6ed in main (argc_=37, argv_=0x7fffffffd350)
    at /home/theraven/llvm/tools/clang/tools/driver/driver.cpp:353

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

From bugzilla-daemon at llvm.org  Wed Oct  5 05:33:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 05:33:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11066] New: Applying address-of operator twice on
 overloaded member function crashes clang
Message-ID: <bug-11066-206@http.llvm.org/bugs/>

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

           Summary: Applying address-of operator twice on overloaded
                    member function crashes clang
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pichet2000 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This ill formed program crashes clang:

  struct A {
    static int foo(short);
    static int foo(float);
    void test();
  };

  void A::test() {
    int (A::*ptr)(int) = & &A::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 llvm.org  Wed Oct  5 05:38:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 05:38:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11067] New: constexpr and initialization of static
 data members in templates
Message-ID: <bug-11067-206@http.llvm.org/bugs/>

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

           Summary: constexpr and initialization of static data members in
                    templates
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: davidhunter22 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This may relate this bug report http://llvm.org/bugs/show_bug.cgi?id=4503

The C++11 standard seems to have had a few modification late in the process
related to the initialization of static data members of template classes. Some
discussion of this topic
http://stackoverflow.com/questions/4999241/mixing-use-of-constexpr-and-const,
http://patchwork.ozlabs.org/patch/113305/,
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3308.pdf

Anyway I was trying to build using a clang++ built from the trunk as of 140970
on a Linux box "2.6.31-23-server #75-Ubuntu SMP Fri Mar 18 19:23:09 UTC 2011
x86_64 GNU/Linux" in conjunction with trunk GCC 4.7.0 ( although the same issue
appears with 4.6.0 ). This led to errors from the GCC header files because of
constructs like this

template<typename T, T v> struct bar
{
    static constexpr T value = v;
};

template<typename T, T v> constexpr T bar<T,v>::value;

which compiles fine with GCC itself but clang gives 

constexpr.cpp:6:49: error: definition of initialized static data member 'value'
cannot be marked constexpr
template<typename T, T v> constexpr T bar<T,v>::value;

After reading about this for a while I still can't tell if this should be an
error or not. Anyway I believe someone out there is working on constexpr
related stuff and I wanted to make sure this issue was captured. It may be
clang is correct but that makes using clang with a recent GCC standard C++
library pretty impossible.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 05:46:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 05:46:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11068] New: lib/tablegen/TGPreprocessor.h requires
 NULL, but does not include a header for it
Message-ID: <bug-11068-206@http.llvm.org/bugs/>

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

           Summary: lib/tablegen/TGPreprocessor.h requires NULL, but does
                    not include a header for it
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu


As in summary, lib/tablegen/TGPreprocessor.h uses NULL, but does not include a
header for it.

At the moment it includes <vector>, which picks up <cstdlib> on many
implementations. In g++, starting with g++4.6, it no longer does, therefore the
following patch (or something similar) is required:


Index: lib/TableGen/TGPreprocessor.h
===================================================================
--- lib/TableGen/TGPreprocessor.h    (revision 141174)
+++ lib/TableGen/TGPreprocessor.h    (working copy)
@@ -15,6 +15,7 @@
 #define TGPREPROCESSOR_H

 #include <vector>
+#include <cstdlib>

 namespace llvm {

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

From bugzilla-daemon at llvm.org  Wed Oct  5 15:51:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 15:51:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11069] New: infinite loop in
 clang::runUninitializedVariablesAnalysis (?)
Message-ID: <bug-11069-206@http.llvm.org/bugs/>

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

           Summary: infinite loop in
                    clang::runUninitializedVariablesAnalysis (?)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pageexec at freemail.hu
                CC: llvmbugs at cs.uiuc.edu


while compiling linux-3.0.4/kernel/mutex.c clang (r141199 but it's been
happening for many weeks now) seemingly enters an infinite loop with the
following backtrace when interrupted in gdb:

(gdb) bt
#0  0x0000000000c9d5a7 in (anonymous namespace)::CFGBlockValues::getValueVector
(this=0x3a36bde8290, block=0x24514a0, dstBlock=0x0) at
/mnt/root32/root/src/devel/llvm/llvm.svn/tools/clang/lib/Analysis/UninitializedValues.cpp:192
#1  0x0000000000c9e03f in updateValueVectorWithScratch (this=0x3a36bde8290,
block=0x24514a0) at
/mnt/root32/root/src/devel/llvm/llvm.svn/tools/clang/lib/Analysis/UninitializedValues.cpp:235
#2  runOnBlock (block=<optimized out>, cfg=..., ac=..., vals=<optimized out>,
wasAnalyzed=<optimized out>, handler=0x0) at
llvm.svn/tools/clang/lib/Analysis/UninitializedValues.cpp:656
#3  0x0000000000c9f136 in clang::runUninitializedVariablesAnalysis (dc=...,
cfg=..., ac=..., handler=..., stats=...) at
llvm.svn/tools/clang/lib/Analysis/UninitializedValues.cpp:694
#4  0x0000000000b1c73c in clang::sema::AnalysisBasedWarnings::IssueWarnings
(this=0x163d870, P=<optimized out>, fscope=<optimized out>, D=<optimized out>,
blkExpr=0x244e820) at
llvm.svn/tools/clang/lib/Sema/AnalysisBasedWarnings.cpp:881
#5  0x00000000008a989c in clang::Sema::PopFunctionOrBlockScope (this=0x163cb50,
WP=<optimized out>, D=<optimized out>, blkExpr=<optimized out>) at
llvm.svn/tools/clang/lib/Sema/Sema.cpp:804
#6  0x000000000091f713 in clang::Sema::ActOnFinishFunctionBody (this=0x163cb50,
dcl=0x2437970, Body=0x243c5a0, IsInstantiation=false) at
llvm.svn/tools/clang/lib/Sema/SemaDecl.cpp:6980
#7  0x000000000083d755 in clang::Parser::ParseFunctionStatementBody
(this=0x163e1e0, Decl=0x2437970, BodyScope=...) at
llvm.svn/tools/clang/lib/Parse/ParseStmt.cpp:1925
#8  0x0000000000856bd0 in clang::Parser::ParseFunctionDefinition
(this=0x163e1e0, D=..., TemplateInfo=...) at
llvm.svn/tools/clang/lib/Parse/Parser.cpp:994
#9  0x0000000000865b9b in clang::Parser::ParseDeclGroup (this=0x163e1e0,
DS=..., Context=0, AllowFunctionDefinitions=true, DeclEnd=0x0, FRI=0x0) at
llvm.svn/tools/clang/lib/Parse/ParseDecl.cpp:1023
#10 0x00000000008521c5 in clang::Parser::ParseDeclarationOrFunctionDefinition
(this=0x163e1e0, DS=..., AS=clang::AS_none) at
llvm.svn/tools/clang/lib/Parse/Parser.cpp:812
#11 0x00000000008526de in clang::Parser::ParseDeclarationOrFunctionDefinition
(this=0x163e1e0, attrs=<optimized out>, AS=clang::AS_none) at
llvm.svn/tools/clang/lib/Parse/Parser.cpp:825
#12 0x00000000008546bf in clang::Parser::ParseExternalDeclaration
(this=0x163e1e0, attrs=..., DS=0x0) at
llvm.svn/tools/clang/lib/Parse/Parser.cpp:695
#13 0x0000000000854abf in clang::Parser::ParseTopLevelDecl (this=0x163e1e0,
Result=...) at llvm.svn/tools/clang/lib/Parse/Parser.cpp:511
#14 0x000000000082d49d in clang::ParseAST (S=..., PrintStats=false) at
llvm.svn/tools/clang/lib/Parse/ParseAST.cpp:84
#15 0x00000000006fe354 in clang::CodeGenAction::ExecuteAction (this=0x1619d60)
at llvm.svn/tools/clang/lib/CodeGen/CodeGenAction.cpp:346
#16 0x00000000005ee4d5 in clang::CompilerInstance::ExecuteAction
(this=0x1615c20, Act=...) at
llvm.svn/tools/clang/lib/Frontend/CompilerInstance.cpp:631
#17 0x00000000005d573e in clang::ExecuteCompilerInvocation (Clang=0x1615c20) at
llvm.svn/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:172
#18 0x00000000005cc1e1 in cc1_main (ArgBegin=0x3a36bdead10,
ArgEnd=0x3a36bdeb068, Argv0=0x1613438 "build.amd64/image/bin/clang",
MainAddr=0x5d29d0) at llvm.svn/tools/clang/tools/driver/cc1_main.cpp:159
#19 0x00000000005ca784 in main (argc_=109, argv_=0x3a36bdebe68) at
llvm.svn/tools/clang/tools/driver/driver.cpp:354

i tried to isolate a minimal example but it didn't work out, so i guess some
non-trivial context is also needed. the linux code in question is in

    kernel/mutex.c: static inline int __sched __mutex_lock_common(struct mutex
*lock, long state, unsigned int subclass, struct lockdep_map *nest_lock,
unsigned long ip)

and CONFIG_MUTEX_SPIN_ON_OWNER must be enabled in .config to enable the
following code (comments removed):

143 #ifdef CONFIG_MUTEX_SPIN_ON_OWNER
162 ????????for (;;) {
163 ????????????????struct task_struct *owner;
164
169 ????????????????owner = ACCESS_ONCE(lock->owner);
170 ????????????????if (owner && !mutex_spin_on_owner(lock, owner))
171 ????????????????????????break;
172
173 ????????????????if (atomic_cmpxchg(&lock->count, 1, 0) == 1) {
174 ????????????????????????lock_acquired(&lock->dep_map, ip);
175 ????????????????????????mutex_set_owner(lock);
176 ????????????????????????preempt_enable();
177 ????????????????????????return 0;
178 ????????????????}
179
186 ????????????????if (!owner && (need_resched() || rt_task(task)))
187 ????????????????????????break;
188
195 ????????????????arch_mutex_cpu_relax();
196 ????????}
197 #endif

if i remove this infinite loop, the file compiles fine.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 16:05:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 16:05:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11070] New: assert in
	lib/Analysis/ScalarEvolution.cpp:4717
Message-ID: <bug-11070-206@http.llvm.org/bugs/>

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

           Summary: assert in lib/Analysis/ScalarEvolution.cpp:4717
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pageexec at freemail.hu
                CC: llvmbugs at cs.uiuc.edu


while compiling linux-3.0.4/kernel/events/core.c with clang r141199 i get the
following assert:

clang: llvm.svn/lib/Analysis/ScalarEvolution.cpp:4717: llvm::PHINode*
getConstantEvolvingPHIOperands(llvm::Instruction*, const llvm::Loop*,
llvm::DenseMap<llvm::Instruction*, llvm::PHINode*>&): Assertion `(!PHI || P ==
PHI) && "inconsistent data flow"' 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 llvm.org  Wed Oct  5 16:05:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 16:05:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9631] clang misses "-fpack-struct" GCC command line
	option
In-Reply-To: <bug-9631-206@http.llvm.org/bugs/>
References: <bug-9631-206@http.llvm.org/bugs/>
Message-ID: <20111005210508.DCE032A6C124@llvm.org>

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

Daniel Dunbar <daniel at zuster.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |daniel at zuster.org
         Resolution|                            |FIXED

--- Comment #1 from Daniel Dunbar <daniel at zuster.org> 2011-10-05 16:05:07 CDT ---
Fixed here:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=141211

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

From bugzilla-daemon at llvm.org  Wed Oct  5 16:12:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 16:12:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11071] New: compiler error parsing 'aligned'
	attribute in cast
Message-ID: <bug-11071-206@http.llvm.org/bugs/>

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

           Summary: compiler error parsing 'aligned' attribute in cast
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pageexec at freemail.hu
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


when compiling linux-3.0.4/crypto/shash.c i get the following error:

crypto/shash.c:68:56: error: 'aligned' attribute ignored when parsing type
        return len + (mask & ~(__alignof__(u8 __attribute__ ((aligned))) - 1));
                                                              ^~~~~~~
1 error generated.

gcc accepts this code but i don't know if it's correct or not.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 16:24:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 16:24:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11072] New: Clang mishandles extern inline functions
Message-ID: <bug-11072-206@http.llvm.org/bugs/>

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

           Summary: Clang mishandles extern inline functions
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: criswell at illinois.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7406)
 --> (http://llvm.org/bugs/attachment.cgi?id=7406)
Test file to help reproduce the problem

As far as I know, when a function is marked with extern inline, it should
either be treated as an external function (which means that the function body
should not be added to the generated object file) or its body should be inlined
into the caller.

Clang appears to include the function body as an externally visible function. 
This prevents two files that include a header with an extern inline function
from linking because the extern inline function is defined multiple times (once
in each compiled object file).

The function body should either be marked internal when converted to LLVM IR,
or the function body should not be added to the compilation unit at all.

To reproduce:

clang -o test test1.c test2.c

/tmp/test2-ALwjs1.o: In function `foo':
test2.c:(.text+0x0): multiple definition of `foo'
/tmp/test1-7iCfuk.o:test1.c:(.text+0x0): first defined here
clang: error: linker command failed with exit code 1 (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 llvm.org  Wed Oct  5 16:24:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 16:24:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11073] New: Debug info not correctly generated for
 function arguments.
Message-ID: <bug-11073-206@http.llvm.org/bugs/>

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

           Summary: Debug info not correctly generated for function
                    arguments.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: anders at 0x63.nu
                CC: llvmbugs at cs.uiuc.edu


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

Documentation
(http://llvm.org/docs/SourceLevelDebugging.html#format_composite_type) says:
"The first member of subroutine (tag = DW_TAG_subroutine_type) type elements is
the return type for the subroutine. The remaining elements are the formal
arguments to the subroutine."

But for example compiling this function:

int somefunc(char *x, int y, double z) {
    return y;
}

compiles into the following debuginfo:

!llvm.dbg.sp = !{!0}

!0 = metadata !{i32 589870, i32 0, metadata !1, metadata !"somefunc", metadata
!"somefunc", metadata !"", metadata !1, i32 4, metadata !3, i1 false, i1 true,
i32 0, i32 0, i32 0, i32 256, i1 false, i32 (i8*, i32, double)* @somefunc} ; [
DW_TAG_subprogram ]
...
!3 = metadata !{i32 589845, metadata !1, metadata !"", metadata !1, i32 0, i64
0, i64 0, i32 0, i32 0, i32 0, metadata !4, i32 0, i32 0} ; [
DW_TAG_subroutine_type ]
!4 = metadata !{metadata !5}
!5 = metadata !{i32 589860, metadata !2, metadata !"int", null, i32 0, i64 32,
i64 32, i64 0, i32 0, i32 5} ; [ DW_TAG_base_type ]


See how !4 only contains the return type and not the arguments as the
documentation specifies.

With the attached patch applied the behaviuor is as documented.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 16:30:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 16:30:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11074] New: Error generated when enumeration
 constant used in templatized wrapper of NEON intrinsic
Message-ID: <bug-11074-206@http.llvm.org/bugs/>

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

           Summary: Error generated when enumeration constant used in
                    templatized wrapper of NEON intrinsic
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mburke at ea.com
                CC: llvmbugs at cs.uiuc.edu


Given this code:

#include <arm_neon.h>
#include <stdio.h>

enum Axis
{
    X = 0,
    Y = 1,
    Z = 2,
    W = 3
};

template<Axis PARAM>
float32_t foo(float32x4_t a)
{
    float32_t value = vgetq_lane_f32(a, PARAM);
    return value;
}

int main()
{
    float32x4_t a = (float32x4_t){0.f, 1.f, 2.f, 3.f};
    printf("%f", foo<W>(a));
}

clang generates an error that the argument to vgetq_lane_f32 should be between
0 and 3. Is it possible to check the template parameter is in the range before
generating an error?

This was encountered with clang-2.9 (iOS SDK 4.3) and verified in trunk as of
revision 141208 with builds targeting iOS 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 llvm.org  Wed Oct  5 16:58:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 16:58:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11072] Clang mishandles extern inline functions
In-Reply-To: <bug-11072-206@http.llvm.org/bugs/>
References: <bug-11072-206@http.llvm.org/bugs/>
Message-ID: <20111005215803.550732A6C12E@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-05 16:58:00 CDT ---
http://clang.llvm.org/compatibility.html#inline

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

From bugzilla-daemon at llvm.org  Wed Oct  5 17:07:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 17:07:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11070] PR11070 - assert in SCEV
	getConstantEvolvingPHIOperands.
In-Reply-To: <bug-11070-206@http.llvm.org/bugs/>
References: <bug-11070-206@http.llvm.org/bugs/>
Message-ID: <20111005220711.2CC192A6C124@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
            Summary|assert in                   |PR11070 - assert in SCEV
                   |lib/Analysis/ScalarEvolutio |getConstantEvolvingPHIOpera
                   |n.cpp:4717                  |nds.

--- Comment #4 from Andrew Trick <atrick at apple.com> 2011-10-05 17:07:09 CDT ---
Fixed in r141219.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 17:27:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 17:27:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11061] High optimization produces incorrect result
In-Reply-To: <bug-11061-206@http.llvm.org/bugs/>
References: <bug-11061-206@http.llvm.org/bugs/>
Message-ID: <20111005222741.15F1A2A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #5 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-05 17:27:39 CDT ---
r141227.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 17:36:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 17:36:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11065] 'Archaic' protocol use crashes clang
In-Reply-To: <bug-11065-206@http.llvm.org/bugs/>
References: <bug-11065-206@http.llvm.org/bugs/>
Message-ID: <20111005223652.DC2182A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-05 17:36:38 CDT ---
r141215.

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

From bugzilla-daemon at llvm.org  Wed Oct  5 17:56:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 17:56:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11077] New: llvm 'GV doesn't have initializer'
 assert with using LTO
Message-ID: <bug-11077-206@http.llvm.org/bugs/>

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

           Summary: llvm 'GV doesn't have initializer' assert with using
                    LTO
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dane at dbsgeo.com
                CC: llvmbugs at cs.uiuc.edu


Getting this within a build that works great for the remainder of the source
code, but one small so fails when linking. This is on ubuntu 11.04 with
binutils built from cvs head with the gold linker enabled and clang/llvm trunk
from today.

$ clang++ -O4 -use-gold-plugin -save-temps -o plugins/input/ogr.input -shared
plugins/input/ogr/ogr_converter.os plugins/input/ogr/ogr_datasource.os
plugins/input/ogr/ogr_featureset.os plugins/input/ogr/ogr_index_featureset.os
-Lagg -Lsrc -L/usr/local/lib -L/usr/lib
-L/home/mapnik/projects/mapnik-static-build/sources/lib
-L/home/mapnik/projects/mapnik-static-build/sources -lgdal -lmapnik2 -licuuc
-lboost_system -lboost_filesystem -lproj -lexpat -ljpeg -ltiff -lpng -lz
-lpthread -lm -lrt -ldl
ld: /home/mapnik/src/llvm/include/llvm/GlobalVariable.h:122: llvm::Constant*
llvm::GlobalVariable::getInitializer(): Assertion `hasInitializer() && "GV
doesn't have initializer!"' failed.
clang: error: unable to execute command: Aborted
clang: error: linker command failed due to signal 2 (use -v to see invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: warning: treating 'c' input as 'c++' when in C++ mode, this behavior is
deprecated
clang: note: diagnostic msg: Error generating preprocessed source(s).

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

From bugzilla-daemon at llvm.org  Wed Oct  5 18:40:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  5 Oct 2011 18:40:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11078] New: error: ran out of registers during
 register allocation
Message-ID: <bug-11078-206@http.llvm.org/bugs/>

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

           Summary: error: ran out of registers during register allocation
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pageexec at freemail.hu
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


Created an attachment (id=7411)
 --> (http://llvm.org/bugs/attachment.cgi?id=7411)
preprocessed source

when compiling linux-3.0.4/arch/x86/kernel/machine_kexec_32.c i get the
following error on i386:

linux-3.0.4-pax-clang/arch/x86/include/asm/cmpxchg_32.h:79:15: error: ran out
of registers during register allocation
 asm volatile("\n1:\t"
              ^
with the following inline asm:

 79 ????????asm volatile("\n1:\t"
 80 ????????????????     LOCK_PREFIX "cmpxchg8b %0\n\t"
 81 ????????????????     "jnz 1b"
 82 ????????????????     : "=m" (*ptr), "+A" (prev)
 83 ????????????????     : "b" (low), "c" (high)
 84 ????????????????     : "memory");

this code used to compile fine some months ago. preprocessed source attached,
the command line needed to compile it:

clang -Wp,-MD,arch/x86/kernel/.machine_kexec_32.o.d  -nostdinc
-Iarch/x86/include/generated -Iinclude  -include include/generated/autoconf.h
-D__KERNEL__ -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs
-Qunused-arguments -W -Wno-unused-parameter -Wno-missing-field-initializers
-Wno-self-assign -Wno-unused-value -Wno-format -mno-sse
-Wno-unknown-warning-option -fcatch-undefined-behavior -fno-strict-aliasing
-fno-common -Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Wno-empty-body -O2 -m32 -msoft-float
-mregparm=3 -freg-struct-return -mpreferred-stack-boundary=2 -march=i686
-mtune=core2 -maccumulate-outgoing-args -ffreestanding -DCONFIG_AS_CFI=1
-DCONFIG_AS_CFI_SIGNAL_FRAME=1 -DCONFIG_AS_CFI_SECTIONS=1 -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2
-mno-3dnow -Wframe-larger-than=1024 -fno-stack-protector
-Wno-unused-but-set-variable -fno-omit-frame-pointer
-fno-optimize-sibling-calls -g -femit-struct-debug-baseonly -pg
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -D"KBUILD_STR(s)=#s"
-D"KBUILD_BASENAME=KBUILD_STR(machine_kexec_32)" 
-D"KBUILD_MODNAME=KBUILD_STR(machine_kexec_32)" -c -o machine_kexec_32.o
machine_kexec_32.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 llvm.org  Thu Oct  6 00:01:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 00:01:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10538] Assertion failed:
 (ParmVarDeclBits.ParameterIndex == parameterIndex && "truncation!"),
 function setScopeInfo
In-Reply-To: <bug-10538-206@http.llvm.org/bugs/>
References: <bug-10538-206@http.llvm.org/bugs/>
Message-ID: <20111006050143.DC0E82A6C124@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #7 from Ted Kremenek <kremenek at apple.com> 2011-10-06 00:01:29 CDT ---
Fixed: r141273

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

From bugzilla-daemon at llvm.org  Thu Oct  6 04:22:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 04:22:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11067] constexpr and initialization of static data
 members in templates
In-Reply-To: <bug-11067-206@http.llvm.org/bugs/>
References: <bug-11067-206@http.llvm.org/bugs/>
Message-ID: <20111006092235.57EB72A6C12D@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

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

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-10-06 04:22:23 CDT ---
Fixed in r141279.

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

From bugzilla-daemon at llvm.org  Thu Oct  6 10:18:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 10:18:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10345] Incorrect assembly of "xchg %eax,
	%eax" on x86-64
In-Reply-To: <bug-10345-206@http.llvm.org/bugs/>
References: <bug-10345-206@http.llvm.org/bugs/>
Message-ID: <20111006151817.E633B2A6C12D@llvm.org>

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

Craig Topper <craig.topper at gmail.com> changed:

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

--- Comment #1 from Craig Topper <craig.topper at gmail.com> 2011-10-06 10:17:59 CDT ---
Fixed in r141274.

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

From bugzilla-daemon at llvm.org  Thu Oct  6 12:34:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 12:34:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11079] New: missing warning for unqualified
 dependent base lookup
Message-ID: <bug-11079-206@http.llvm.org/bugs/>

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

           Summary: missing warning for unqualified dependent base lookup
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: alexr at leftfield.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7412)
 --> (http://llvm.org/bugs/attachment.cgi?id=7412)
example of missed errors

The attached example doesn't trigger this error for all the cases shown.
Notably, lines 63 and 76 do not complain at all. With -DNO_THIS, line 36
produces the correct error and fixit, but line 37 doesn't offer the fixit.

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

From bugzilla-daemon at llvm.org  Thu Oct  6 13:23:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 13:23:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11080] New: Jump to incorrect address (off by 4
 bytes) is being generated [x86, OSX]
Message-ID: <bug-11080-206@http.llvm.org/bugs/>

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

           Summary: Jump to incorrect address (off by 4 bytes) is being
                    generated [x86, OSX]
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


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

If the attached test case is compiled and run, it generates a seg fault.  From
the debugging I've done, it seems to be due to a call instruction being emitted
with an incorrect offset.  (Further details in the following.)

I've only been able to reproduce this on OSX (and not Linux, for example), but
don't know if this means that it's an OSX-specific issue, or if it's just
happenstance that it doesn't happen on Linux.

% llc x.ll -filetype=obj -o x.o && clang -g x.cpp x.o && ./a.out
[1]    70823 segmentation fault  ./a.out

However, if 'private' qualifier from the @__do_print() function at the top of
x.ll is removed, it produces the correct output (basically, printing the two
values passed to it via the %args array parameter.)

% llc x.ll -filetype=obj -o x.o && clang -g x.cpp x.o && ./a.out
yep 2.000000 2.000000

In the case where it's crashing, if I disassemble the _p function in gdb (which
calls __do_print), I get the following:

Dump of assembler code for function p:
0x0000000100000e50 <p+0>:    sub    $0x28,%rsp
0x0000000100000e54 <p+4>:    movss  %xmm1,0x4(%rsp)
0x0000000100000e5a <p+10>:    movss  %xmm0,0xc(%rsp)
0x0000000100000e60 <p+16>:    lea    0xc(%rsp),%rax
0x0000000100000e65 <p+21>:    mov    %rax,0x10(%rsp)
0x0000000100000e6a <p+26>:    movss  %xmm1,0x8(%rsp)
0x0000000100000e70 <p+32>:    lea    0x8(%rsp),%rax
0x0000000100000e75 <p+37>:    mov    %rax,0x18(%rsp)
0x0000000100000e7a <p+42>:    lea    0x7a(%rip),%rdi        # 0x100000efb
<__str2>
0x0000000100000e81 <p+49>:    lea    0x7c(%rip),%rsi        # 0x100000f04
<__str3>
0x0000000100000e88 <p+56>:    lea    0x10(%rsp),%r8
0x0000000100000e8d <p+61>:    mov    $0x4,%edx
0x0000000100000e92 <p+66>:    mov    $0xf,%ecx
0x0000000100000e97 <p+71>:    callq  0x100000d8c <main+252>
0x0000000100000e9c <p+76>:    movss  0x4(%rsp),%xmm0
0x0000000100000ea2 <p+82>:    add    $0x28,%rsp
0x0000000100000ea6 <p+86>:    retq   
End of assembler dump.

(This in general looks like the code I'd expect for this function.)  If I
single-step through these instructions, the problem comes immediately after the
callq.  Disassembling at where it ends up, it turns out that it's jumping to
the pop instruction at the end of the main function, instead of the start of
the __do_print function, which happens to start at 0x0000000100000d90.  It
seems to have jumped 4 bytes too early.

... assembly for main() ... ending with ...
0x0000000100000d8c <main+252>:    pop    %rbp
0x0000000100000d8d <main+253>:    retq   
0x0000000100000d8e <main+254>:    xchg   %ax,%ax
0x0000000100000d90 <main+256>:    push   %rbp
0x0000000100000d91 <main+257>:    push   %r15
... assembly for the rest of __do_print ...

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

From bugzilla-daemon at llvm.org  Thu Oct  6 15:05:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 15:05:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10981] __builtin_object_size codegens infinite loop
 at -01 and greater
In-Reply-To: <bug-10981-206@http.llvm.org/bugs/>
References: <bug-10981-206@http.llvm.org/bugs/>
Message-ID: <20111006200535.5E3472A6C12E@llvm.org>

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

Benjamin Kramer <benny.kra at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |DUPLICATE

--- Comment #7 from Benjamin Kramer <benny.kra at gmail.com> 2011-10-06 15:05:35 CDT ---


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

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

From bugzilla-daemon at llvm.org  Thu Oct  6 15:13:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 15:13:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11079] missing warning for unqualified dependent
	base lookup
In-Reply-To: <bug-11079-206@http.llvm.org/bugs/>
References: <bug-11079-206@http.llvm.org/bugs/>
Message-ID: <20111006201308.A9BC22A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-06 15:13:08 CDT ---
This is working exactly how the C++ rules say it should... try looking up the
rules for argument-dependent lookup.

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

From bugzilla-daemon at llvm.org  Thu Oct  6 16:24:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 16:24:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11081] New: alias is miscompiled with -fPIC
Message-ID: <bug-11081-206@http.llvm.org/bugs/>

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

           Summary: alias is miscompiled with -fPIC
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kcc at google.com
                CC: llvmbugs at cs.uiuc.edu


I think that aliases are miscompiled when -fPIC is used. 
Here is the minimized example (llvm r140360): 

----------------
; ModuleID = 'a.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"
@GLOBAL = global { i32, [60 x i8] } zeroinitializer, align 32
@ALIAS = alias internal getelementptr inbounds ({ i32, [60 x i8] }* @GLOBAL,
i32 0, i32 0)
define i32* @foo() nounwind uwtable readnone {
entry:
  ret i32* @ALIAS
}
----------------
$ llc -relocation-model=pic a.ll && grep ALIAS a.s

    leaq    ALIAS(%rip), %rax

The generated code should look more like 
    movq    ALIAS at GOTPCREL(%rip), %rax

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

From bugzilla-daemon at llvm.org  Thu Oct  6 19:22:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 19:22:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11082] New: Support may_alias in processTypeAttrs()
Message-ID: <bug-11082-206@http.llvm.org/bugs/>

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

           Summary: Support may_alias in processTypeAttrs()
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


clang now complains about unsupported attributes on types. As a consequence, it
complains about may_alias in cast expressions such as here:

void g(int p __attribute__((may_alias))) {}

void f() {
  int a = 0;
  g((int __attribute__((may_alias)))a);
}

hummer:clang thakis$ ../../Release+Asserts/bin/clang -Wall test.c -c
test.c:5:25: error: 'may_alias' attribute ignored when parsing type
  g((int __attribute__((may_alias)))a);
                        ^~~~~~~~~
1 error generated.


This is used in glib, see e.g. here:
http://codesearch.google.com/#cZwlSNS7aEw/external/bluetooth/glib/glib/gatomic.h&q=%5C(g_atomic_pointer_set%5C)%5C%20%5C(%5C(volatile%5C%20gpointer%5C%20G_GNUC_MAY_ALIAS%5C%20%5C*%5C)%5C%20%5C(void%5C%20%5C*%5C)%5C%20%5C(atomic%5C),%5C%20%5C(newval%5C)%5C)%5C)&type=cs&l=76

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

From bugzilla-daemon at llvm.org  Thu Oct  6 19:43:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 19:43:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11069] infinite loop in
 clang::runUninitializedVariablesAnalysis (?)
In-Reply-To: <bug-11069-206@http.llvm.org/bugs/>
References: <bug-11069-206@http.llvm.org/bugs/>
Message-ID: <20111007004321.ACB432A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #7 from Ted Kremenek <kremenek at apple.com> 2011-10-06 19:43:20 CDT ---
Fixed: r141345

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

From bugzilla-daemon at llvm.org  Thu Oct  6 21:39:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  6 Oct 2011 21:39:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10912] Assertion `FieldNo < FieldCount && "Invalid
	Field No"'
In-Reply-To: <bug-10912-206@http.llvm.org/bugs/>
References: <bug-10912-206@http.llvm.org/bugs/>
Message-ID: <20111007023940.A20DD2A6C12E@llvm.org>

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

John McCall <rjmccall at apple.com> changed:

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

--- Comment #4 from John McCall <rjmccall at apple.com> 2011-10-06 21:39:40 CDT ---
Fixed in r141350.

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

From bugzilla-daemon at llvm.org  Fri Oct  7 01:53:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  7 Oct 2011 01:53:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11083] New: clang doesn't support
	-fno-inline-functions
Message-ID: <bug-11083-206@http.llvm.org/bugs/>

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

           Summary: clang doesn't support -fno-inline-functions
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jongsok.choi at gmail.com
                CC: llvmbugs at cs.uiuc.edu


llvm-gcc supported -fno-inline-functions which forced it not to inline any
functions. It doesn't seem to be working well with clang since it is inlining
functions with even this option. Clang doesn't give a warning that
-fno-inline-functions is not supported.

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

From bugzilla-daemon at llvm.org  Fri Oct  7 04:45:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  7 Oct 2011 04:45:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11084] New: compiler assertion on strange templated
 code, probably noexcept related
Message-ID: <bug-11084-206@http.llvm.org/bugs/>

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

           Summary: compiler assertion on strange templated code, probably
                    noexcept related
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: davidhunter22 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I was trying out the trunk of llvm/clang at revision 141361. This was build on
a Linux box "2.6.31-23-server #75-Ubuntu SMP Fri Mar 18 19:23:09 UTC 2011
x86_64 GNU/Linux" using gcc 4.6.0 which all went fine and seems to work.

However when I try to use the compiler using GCC 4.6.0 ( or 4.7.0 trunk )
standard C++ library header files I was getting a compiler assert

clang: /home/david/tools/llvm/3.0/llvm/tools/clang/lib/AST/Type.cpp:1616:
clang::FunctionProtoType::NoexceptResult
clang::FunctionProtoType::getNoexceptSpec(clang::ASTContext&) const: Assertion
`isICE && "AST should not contain bad noexcept expressions."' failed.

I was able to reduce the test case that causes this to the following still
quite complex code

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
template<typename T> struct Foo1
{
    static constexpr bool foo( );
};

template<typename T> struct Foo2
{
    typedef Foo2<T> Foo2_T;
};

template<typename T> struct Bar
{
    typedef typename Foo2<int>::Foo2_T Foo2_T;
};

template<typename T> class Bar2
{
    typedef Foo2<T> Foo2_T;

    typedef Foo1<typename Bar<Foo2_T>::Foo2_T> Y;

    Bar2& operator=(Bar2&&) noexcept(Y::foo());
};

template<typename T> T mod(T);

class Bar3
{
    template<typename T> void generate( )
    {
        typename T::value_type  r1;

        r1 = mod<int>(1);
    }

    Bar2<int> v;
};
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

The full compiler output was 

clang: /home/david/tools/llvm/3.0/llvm/tools/clang/lib/AST/Type.cpp:1616:
clang::FunctionProtoType::NoexceptResult
clang::FunctionProtoType::getNoexceptSpec(clang::ASTContext&) const: Assertion
`isICE && "AST should not contain bad noexcept expressions."' failed.
0  clang           0x0000000001bd655f
1  clang           0x0000000001bd6a61
2  libpthread.so.0 0x00007fe7c2a52190
3  libc.so.6       0x00007fe7c1d364b5 gsignal + 53
4  libc.so.6       0x00007fe7c1d39f50 abort + 384
5  libc.so.6       0x00007fe7c1d2f481 __assert_fail + 241
6  clang           0x0000000000fedfb2
7  clang           0x0000000000ab385b
clang::Sema::ImplicitExceptionSpecification::CalledDecl(clang::CXXMethodDecl*)
+ 187
8  clang           0x0000000000ac5559
clang::Sema::ComputeDefaultedMoveAssignmentExceptionSpec(clang::CXXRecordDecl*)
+ 601
9  clang           0x0000000000ac55b3
clang::Sema::DeclareImplicitMoveAssignment(clang::CXXRecordDecl*) + 35
10 clang           0x0000000000b6cff0
11 clang           0x0000000000b729f7
clang::Sema::CppLookupName(clang::LookupResult&, clang::Scope*) + 135
12 clang           0x0000000000b73768
clang::Sema::LookupName(clang::LookupResult&, clang::Scope*, bool) + 936
13 clang           0x0000000000b739a5
clang::Sema::LookupOverloadedOperatorName(clang::OverloadedOperatorKind,
clang::Scope*, clang::QualType, clang::QualType, clang::UnresolvedSetImpl&) +
245
14 clang           0x0000000000b1a243 clang::Sema::BuildBinOp(clang::Scope*,
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) +
531
15 clang           0x0000000000b1a315 clang::Sema::ActOnBinOp(clang::Scope*,
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 197
16 clang           0x00000000009e02f8
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*,
true>, clang::prec::Level) + 520
17 clang           0x00000000009e0a7f
clang::Parser::ParseAssignmentExpression() + 47
18 clang           0x00000000009e17a9 clang::Parser::ParseExpression() + 9
19 clang           0x00000000009a47b2
clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 50
20 clang           0x00000000009a1378
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 2168
21 clang           0x000000000099e2b9
clang::Parser::ParseCompoundStatementBody(bool) + 489
22 clang           0x000000000099f035
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 149
23 clang           0x00000000009baefe
clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 398
24 clang           0x00000000009bacf1
clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 145
25 clang           0x00000000009d8f34
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 157
26 clang           0x00000000009da201
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 3953
27 clang           0x00000000009c8aa3
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 1971
28 clang           0x00000000009b4679
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 89
29 clang           0x00000000009b4bc6
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 678
30 clang           0x00000000009b6c0f
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2639
31 clang           0x00000000009b7037
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 167
32 clang           0x000000000098ed3d clang::ParseAST(clang::Sema&, bool) + 269
33 clang           0x000000000085ae04 clang::CodeGenAction::ExecuteAction() +
68
34 clang           0x0000000000745e85
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 373
35 clang           0x000000000072c88e
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1182
36 clang           0x00000000007218c8 cc1_main(char const**, char const**, char
const*, void*) + 840
37 clang           0x000000000072b024 main + 708
38 libc.so.6       0x00007fe7c1d21abd __libc_start_main + 253
39 clang           0x00000000007213f9
Stack dump:
0.      Program arguments: /home/david/tools/llvm/3.0/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
bug.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20 -momit-leaf-frame-pointer -resource-dir
/home/david/tools/llvm/3.0/bin/../lib/clang/3.0 -I
/home/david/tools/gcc/4.7.0/include/c++/4.7.0/x86_64-unknown-linux-gnu -I
/home/david/tools/gcc/4.7.0/include/c++/4.7.0 -fmodule-cache-path
/var/tmp/clang-module-cache -std=gnu++0x -fdeprecated-macro -ferror-limit 19
-fmessage-length 120 -fgnu-runtime -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-fragile-abi -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/bug-XE12MK.o -x c++
bug.cpp 
1.      bug.cpp:33:25: current parser token ';'
2.      bug.cpp:27:1: parsing struct/union/class body 'Bar3'
3.      bug.cpp:30:5: parsing function body 'generate'
4.      bug.cpp:30:5: in compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/bug-6Xz0CW.ii

The command line options I passed to clang were

-I/home/david/tools/gcc/4.7.0/include/c++/4.7.0/x86_64-unknown-linux-gnu
-I/home/david/tools/gcc/4.7.0/include/c++/4.7.0 -std=gnu++0

So really just telling it where the GCC stuff is.

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

From bugzilla-daemon at llvm.org  Fri Oct  7 05:56:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  7 Oct 2011 05:56:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9920] Another case of unnecessary "shift count is
 negative" warning
In-Reply-To: <bug-9920-206@http.llvm.org/bugs/>
References: <bug-9920-206@http.llvm.org/bugs/>
Message-ID: <20111007105613.C1D2D2A6C12D@llvm.org>

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

Dimitry Andric <dimitry at andric.com> changed:

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

--- Comment #4 from Dimitry Andric <dimitry at andric.com> 2011-10-07 05:56:12 CDT ---
Setting this as a duplicate of bug 10030. The problem only manifests itself
with global initializations, so that PR has a much better description.

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

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

From bugzilla-daemon at llvm.org  Fri Oct  7 06:23:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  7 Oct 2011 06:23:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11085] New: error in backend: expected relocatable
 expression when compiling objective-c header file
Message-ID: <bug-11085-206@http.llvm.org/bugs/>

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

           Summary: error in backend: expected relocatable expression when
                    compiling objective-c header file
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sebastia at l00-bugdead-prods.de
                CC: llvmbugs at cs.uiuc.edu


compiling opengroupware with llvm/clang from svn (checkout from Thursday
2011-01-06) the compilation stops the following way:

$ clang LSWSchedulerPreferences.m -c -v -integrated-as -MMD -MP -Wall -DGNUSTEP
-DGNUSTEP_BASE_LIBRARY=1 -DGNU_GUI_LIBRARY=1 -DGNU_RUNTIME=1
-DGNUSTEP_BASE_LIBRARY=1 -fno-strict-aliasing -fexceptions -fobjc-exceptions
-D_NATIVE_OBJC_EXCEPTIONS -fPIC -DDEBUG -fno-om>
clang version 3.0 (trunk 141278)
Target: i386-unknown-openbsd5.0
Thread model: posix
 "/usr/local/bin/clang" -cc1 -triple i386-unknown-openbsd5.0 -emit-obj
-mrelax-all -disable-free -main-file-name LSWSchedulerPreferences.m -pic-level
2 -mdisable-fp-elim -relaxed-aliasing -masm-verbose -mconstructor-aliases
-target-cpu i486 -target-linker-version 2.15 -momit-leaf-frame-pointer -v -g
-coverage-file obj/LSWScheduler.obj/LSWSchedulerPreferences.m.o -resource-dir
/usr/local/bin/../lib/clang/3.0 -dependency-file
obj/LSWScheduler.obj/LSWSchedulerPreferences.m.d -MT
obj/LSWScheduler.obj/LSWSchedulerPreferences.m.o -MP -D GNUSTEP -D
GNUSTEP_BASE_LIBRARY=1 -D GNU_GUI_LIBRARY=1 -D GNU_RUNTIME=1 -D
GNUSTEP_BASE_LIBRARY=1 -D _NATIVE_OBJC_EXCEPTIONS -D DEBUG -D GSWARN -D
GSDIAGNOSE -I .. -I ../.. -I ../../../Logic -I ../../../DocumentAPI -I
../../../SOPE/sope-ical -I . -I /usr/local/include -I
/opengroupware-5.5_writes_to_HOME/GNUstep/Library/Headers -I /usr/local/include
-fmodule-cache-path /var/tmp/clang-module-cache -O0 -Wall -Wall -Wno-import
-fconstant-string-class NSConstantString -ferror-limit 19 -fmessage-length 267
-fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fobjc-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
obj/LSWScheduler.obj/LSWSchedulerPreferences.m.o -x objective-c
LSWSchedulerPreferences.m
clang -cc1 version 3.0 based upon llvm 3.0svn hosted on i386-unknown-openbsd5.0
ignoring nonexistent directory
"/opengroupware-5.5_writes_to_HOME/GNUstep/Library/Headers"
ignoring duplicate directory "/usr/local/include"
ignoring duplicate directory "/usr/local/include"
  as it is a non-system directory that duplicates a system directory
#include "..." search starts here:
#include <...> search starts here:
 ..
 ../..
 ../../../Logic
 ../../../DocumentAPI
 ../../../SOPE/sope-ical
 .
 /usr/local/include
 /usr/local/bin/../lib/clang/3.0/include
 /usr/include
End of search list.
LSWSchedulerPreferences.m:1146:3: warning: incompatible pointer types assigning
to 'NSMutableArray *' from 'NSArray *' [-Wincompatible-pointer-types]
  ASSIGN(self->participants, _p);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/GNUstepBase/GNUstep.h:125:10: note: expanded from:           
  object = [(value) retain]; \
         ^ ~~~~~~~~~~~~~~~~
/usr/local/include/Foundation/NSObject.h:173:1: note: instance method 'retain'
is assumed to return an instance of its receiver type ('NSArray *')             
- (id) retain NS_AUTOMATED_REFCOUNT_UNAVAILABLE;
^
LSWSchedulerPreferences.m:1162:3: warning: incompatible pointer types assigning
to 'NSMutableArray *' from 'NSArray *' [-Wincompatible-pointer-types]           
  ASSIGN(self->writeAccess, _p);
  ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/local/include/GNUstepBase/GNUstep.h:125:10: note: expanded from:           
  object = [(value) retain]; \
         ^ ~~~~~~~~~~~~~~~~
/usr/local/include/Foundation/NSObject.h:173:1: note: instance method 'retain'
is assumed to return an instance of its receiver type ('NSArray *')             
- (id) retain NS_AUTOMATED_REFCOUNT_UNAVAILABLE;
^
In file included from LSWSchedulerPreferences.m:125:                            
In file included from ./common.h:40:
In file included from ../../../Logic/LSFoundation/LSFoundation.h:31:
In file included from ../../../Logic/LSFoundation/LSSortCommand.h:25:
../../../Logic/LSFoundation/LSBaseCommand.h:165:13: warning: unused function
'LSCommandSet' [-Wunused-function]
static void LSCommandSet(LSBaseCommand *_cmd, NSString *_argument, id _value) {
            ^
../../../Logic/LSFoundation/LSBaseCommand.h:168:11: warning: unused function
'LSCommandGet' [-Wunused-function]                                              
static id LSCommandGet(LSBaseCommand *_cmd, NSString *_argument) {
          ^
../../../Logic/LSFoundation/LSBaseCommand.h:172:11: warning: unused function
'LSCommandLookup' [-Wunused-function]                                           
static id LSCommandLookup(id _factory, NSString *_domain, NSString *_command) {
          ^
fatal error: error in backend: expected relocatable expression 

also without the -integrated-as, the same problem.

the file I want to compile is this:

http://opengroupware.hg.sourceforge.net/hgweb/opengroupware/opengroupware/file/a1b46fe89065/opengroupware/Logic/LSFoundation/LSBaseCommand.h

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

From bugzilla-daemon at llvm.org  Fri Oct  7 07:45:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  7 Oct 2011 07:45:52 -0500 (CDT)
Subject: [LLVMbugs] =?utf-8?q?=5BBug_10890=5D__unsupported_target_builtin_?=
 =?utf-8?b?4oCYX19idWlsdGluX2lhMzJfdmVjX3Blcm1fdjJkZuKAmSB1c2VkIGluIHJu?=
 =?utf-8?q?flow_with_vector-select?=
In-Reply-To: <bug-10890-206@http.llvm.org/bugs/>
References: <bug-10890-206@http.llvm.org/bugs/>
Message-ID: <20111007124552.41B9C2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #10 from Duncan Sands <baldrick at free.fr> 2011-10-07 07:45:51 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111003/129347.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 llvm.org  Fri Oct  7 15:20:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  7 Oct 2011 15:20:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11086] New: APFloat::toString is wrong in specific
	cases
Message-ID: <bug-11086-206@http.llvm.org/bugs/>

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

           Summary: APFloat::toString is wrong in specific cases
           Product: libraries
           Version: 2.9
          Platform: PC
        OS/Version: other
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jerome_123 at hotmail.com
                CC: llvmbugs at cs.uiuc.edu


Repro:

    llvm::SmallVectorImpl<char> buffer(0);
    llvm::APFloat apFloat( 29.999998 );
    apFloat.toString( buffer, 6 );

Output:
    0.485211

I fixed it by replacing, in APFloat.cpp,
    unsigned precision = semantics->precision + 137 * texp / 59;
by
    unsigned precision = semantics->precision + 137 * texp / 59 + 1;

I think that the current formula didn't take into account the fact that ints
are rounding down, which led to too small precisions in exceptional cases like
this.

(OS = Windows 7; you don't have that in your OS list??)

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

From bugzilla-daemon at llvm.org  Fri Oct  7 18:41:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  7 Oct 2011 18:41:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11086] APFloat::toString is wrong in specific cases
In-Reply-To: <bug-11086-206@http.llvm.org/bugs/>
References: <bug-11086-206@http.llvm.org/bugs/>
Message-ID: <20111007234124.6A3212A6C12F@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-07 18:41:24 CDT ---
r141441.

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

From bugzilla-daemon at llvm.org  Fri Oct  7 19:10:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  7 Oct 2011 19:10:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11087] New: Save code space on ARM Thumb with
	PC-relative LDR
Message-ID: <bug-11087-206@http.llvm.org/bugs/>

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

           Summary: Save code space on ARM Thumb with PC-relative LDR
           Product: libraries
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


It would be nice if LLVM was able to save space on ARM Thumb/Thumb2 by using
PC-relative LDR, at least when set to optimize for size. The Keil compiler does
this.

For example, instead of 8-byte MOVW/MOVT, what the Keil compiler will do is
intersperse the 8-byte relocation with the code, and use a PC-relative LDR.
This takes 6 bytes instead of 8. Trivial example from a boot loader (objdump
output):

00001000 <__main-0x8>:
    1000:    4800          ldr    r0, [pc, #0]    (1004
<BuildAttributes$$gibberish+0x1004>)
    1002:    4700          bx    r0
    1004:    0000100d     .word    0x0000100d

The other nice effect of this is that it seems to search through your
already-existing constants before introducing new 4-byte addresses. So often
the 8-byte MOVW/MOVT becomes 2 bytes. Once, for example, I had a table of
function pointers, and it just pulled the address from there as it was only a
few hundred bytes away.

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

From bugzilla-daemon at llvm.org  Sat Oct  8 06:12:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  8 Oct 2011 06:12:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11088] New: Assertion failed:
 (X86::GR8_NOREXRegClass.contains(SrcReg,
 DestReg) && "8-bit H register can not be copied outside GR8_NOREX")
Message-ID: <bug-11088-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed:
                    (X86::GR8_NOREXRegClass.contains(SrcReg, DestReg) &&
                    "8-bit H register can not be copied outside
                    GR8_NOREX")
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7420)
 --> (http://llvm.org/bugs/attachment.cgi?id=7420)
bugpoint-reduced-simplified.bc

clang version 3.0 (trunk 141482)
Target: x86_64-unknown-freebsd9.0

Crash when compiling ARMAsmParser.cpp from llvm r135360. This was introduced
between r141373 and r141415.

% llc bugpoint-reduced-simplified.bc
Assertion failed: (X86::GR8_NOREXRegClass.contains(SrcReg, DestReg) && "8-bit H
register can not be copied outside GR8_NOREX"), function copyPhysReg, file
/data/buildslave/freebsd-clang-amd64/src-llvm/lib/Target/X86/X86InstrInfo.cpp,
line 2196.
Stack dump:
0.    Program arguments:
/data/buildslave/freebsd-clang-amd64/obj/llvm.2/Release+Asserts/bin/llc
bugpoint-reduced-simplified.bc 
1.    Running pass 'Function Pass Manager' on module
'bugpoint-reduced-simplified.bc'.
2.    Running pass 'Post-RA pseudo instruction expansion pass' on function
'@_ZNK12_GLOBAL__N_112ARMAsmParser24ComputeAvailableFeaturesEm'
Abort (core dumped)

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

From bugzilla-daemon at llvm.org  Sat Oct  8 07:13:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  8 Oct 2011 07:13:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11089] New: sspreq broken with JIT
Message-ID: <bug-11089-206@http.llvm.org/bugs/>

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

           Summary: sspreq broken with JIT
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7421)
 --> (http://llvm.org/bugs/attachment.cgi?id=7421)
x.bc

With ToT the stackprotect attribute is still broken when using the JIT.
(it works when using static compilation).

It was broken in 2.9 too, last time it worked was in 2.8.


When adding the sspreq required attribute to a function and running it with the
JIT it generates code like this:
   0x00007ffff7f41010 <+0>:     sub    $0x18,%rsp
=> 0x00007ffff7f41014 <+4>:     mov    0x28,%rax
   0x00007ffff7f4101c <+12>:    mov    %rax,0x10(%rsp)
   0x00007ffff7f41021 <+17>:    movl   $0x0,0xc(%rsp)

Obviously that mov crashes because it tries to read from address 0x28.

When compiling to a static .s file everything seems fine though, but the code
in question looks like this:
    movq    %fs:40, %rax
    movq    %rax, 16(%rsp)

So it looks like the %fs: segment register is lost when JITing.

To reproduce:
$ lli --debug-only=jit x.bc
JIT: Binary code:
JIT: 0: 2423613172 37413972 00040 366813772 
JIT: 16: 366819916 00012 4139720 004037 
JIT: 32: 6859720 133151636 00010 004184 
JIT: 48: 196131720 1847219524 13346154144 00053 
JIT: 64: 208255
0  lli             0x0000000000c7b03f
1  lli             0x0000000000c7b529
2  libpthread.so.0 0x0000003585e0f020
3  libpthread.so.0 0x00007f52cac86014
Stack dump:
0.    Program arguments:
/home/edwin/HDD/edwin/llvm-git/build/Release+Asserts/bin/lli --debug-only=jit
x.bc 
Segmentation fault (core dumped)

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

From bugzilla-daemon at llvm.org  Sat Oct  8 13:28:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  8 Oct 2011 13:28:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11088] Assertion failed:
 (X86::GR8_NOREXRegClass.contains(SrcReg,
 DestReg) && "8-bit H register can not be copied outside GR8_NOREX")
In-Reply-To: <bug-11088-206@http.llvm.org/bugs/>
References: <bug-11088-206@http.llvm.org/bugs/>
Message-ID: <20111008182849.236942A6C12C@llvm.org>

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

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> 2011-10-08 13:28:48 CDT ---
r141499

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

From bugzilla-daemon at llvm.org  Sun Oct  9 06:56:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 06:56:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11090] New: Extremely slow compilation + high
 memory usage in "Loop Strength Reduction"
Message-ID: <bug-11090-206@http.llvm.org/bugs/>

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

           Summary: Extremely slow compilation + high memory usage in
                    "Loop Strength Reduction"
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


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

Compile the attached file, it will require > 1GB memory and crash at some point
if it doesn't get that.

1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'crypt_sha512-23056a.i'.
4.    Running pass 'Loop Pass Manager' on function '@php_sha512_crypt_r'
5.    Running pass 'Loop Strength Reduction' on basic block '%while.body877'

Source is from current PHP, so it is high-profile.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 07:52:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 07:52:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11091] New: incorrect warning for printf and
 printing std::runtime_error::what()
Message-ID: <bug-11091-206@http.llvm.org/bugs/>

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

           Summary: incorrect warning for printf and printing
                    std::runtime_error::what()
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: vanboxem.ruben at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This test program:

#include <stdexcept>
#include <cstdio>
using namespace std;

int main()
{
    runtime_error e( "bla" );
    printf( e.what() );
}

Produces this warning:
main.cpp:8:13: warning: format string is not a string literal (potentially
insecure) [-Wformat-security]
    printf( err.what() );
            ^~~~~~~~~~
1 warning generated.

This seems very misleading and warns on correct code like the above, ie when
the format string doesn't contain any format specifiers at all, and is just a
plain const char*.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 09:02:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 09:02:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11092] New: error in backend: Cannot select:
 0x99e5db0: v8f32 = bit_convert 0x92b0b70
Message-ID: <bug-11092-206@http.llvm.org/bugs/>

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

           Summary: error in backend: Cannot select: 0x99e5db0: v8f32 =
                    bit_convert 0x92b0b70
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tim at klingt.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7424)
 --> (http://llvm.org/bugs/attachment.cgi?id=7424)
preprocessed source

compiling attached code with -mavx -msse4.2 -O3 -DNDEBUG and clang++ from
svn/trunk, i get the following error:


fatal error: error in backend: Cannot select: 0xcdf71a0: v8f32 = bit_convert
0xc888c10 [ID=98]
  0xc888c10: v4f32 = X86ISD::PSHUFD 0xb132060, 0xcfdc950 [ID=97]
    0xb132060: v4f32,ch = load 0xc4ca880, 0xcfdca50,
0xc4cab80<LD16[FixedStack4](align=32)> [ID=96]
      0xcfdca50: i64 = FrameIndex<4> [ID=27]
      0xc4cab80: i64 = undef [ORD=28462] [ID=6]
    0xcfdc950: i8 = Constant<0> [ID=35]

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

From bugzilla-daemon at llvm.org  Sun Oct  9 09:52:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 09:52:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11093] New: compiling PCL (www.pointclouds.org)
 fails with strange error
Message-ID: <bug-11093-206@http.llvm.org/bugs/>

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

           Summary: compiling PCL (www.pointclouds.org) fails with strange
                    error
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nsallem at willowgarage.com
                CC: llvmbugs at cs.uiuc.edu


Hi,

Compiling PCL with clang (trunk version) fails with error asking for bug report
so here it is.
1.      <eof> parser at end of file
2.      .../eigen3/Eigen/src/SVD/JacobiSVD.h:412:5: instantiating function
definition 'JacobiSVD'
3.      .../include/eigen3/Eigen/src/SVD/JacobiSVD.h:431:16: instantiating
function definition 'compute'
4.      .../include/eigen3/Eigen/src/SVD/JacobiSVD.h:262:6: instantiating
function definition 'real_2x2_ja
cobi_svd'
5.      .../include/eigen3/Eigen/src/Core/MatrixBase.h:455:10: instantiating
function definition 'applyOnT
heLeft'
6.      ../include/eigen3/Eigen/src/Jacobi/Jacobi.h:271:6: instantiating
function definition 'apply_rotat
ion_in_the_plane'
clang-3: error: unable to execute command: Aborted

To report the error simply download PCL sources and try a fresh build. ALthough
not worth mentioning but just in case, code compiles and runs with gcc-4.4.3
ubuntu falvour.

I would appreciate your help.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 13:32:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 13:32:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11084] compiler assertion on strange templated code,
 probably noexcept related
In-Reply-To: <bug-11084-206@http.llvm.org/bugs/>
References: <bug-11084-206@http.llvm.org/bugs/>
Message-ID: <20111009183211.5491E2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-09 13:32:10 CDT ---
Fixed in Clang r141511.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 13:56:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 13:56:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10839] Weird accepts-invalid with operator as field
	(?)
In-Reply-To: <bug-10839-206@http.llvm.org/bugs/>
References: <bug-10839-206@http.llvm.org/bugs/>
Message-ID: <20111009185614.60B3C2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 13:56:14 CDT ---
Fixed in Clang r141513.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 14:10:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 14:10:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11066] Applying address-of operator twice on
 overloaded member function crashes clang
In-Reply-To: <bug-11066-206@http.llvm.org/bugs/>
References: <bug-11066-206@http.llvm.org/bugs/>
Message-ID: <20111009191057.4F4852A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |crash-on-invalid
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 14:10:56 CDT ---
Fixed in Clang r141514.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 14:13:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 14:13:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10984] clang++ incorrectly handles addresses of
 temporaries created during optimization
In-Reply-To: <bug-10984-206@http.llvm.org/bugs/>
References: <bug-10984-206@http.llvm.org/bugs/>
Message-ID: <20111009191346.14E502A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #8 from Douglas Gregor <dgregor at apple.com> 2011-10-09 14:13:44 CDT ---
I'm closing this bug, since the issue was not in fact a miscompile.

If you can provide us with a self-contained test case that shows the code that
returning a reference to a temporary on the stack, which Clang does not warn
about, please re-open this bug.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 14:22:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 14:22:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10929] inconsistent warning for implicit truncation
	to bitfield
In-Reply-To: <bug-10929-206@http.llvm.org/bugs/>
References: <bug-10929-206@http.llvm.org/bugs/>
Message-ID: <20111009192225.BDF3C2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 14:22:25 CDT ---
The compiler can't warn about implicit truncation for FLAG2 because FLAG2 is
not a constant. The warning would end up being a false positive if, for
example, FLAG2 were assigned to a smaller value somewhere else in the program.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 14:41:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 14:41:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10944] Rejects-valid/potential miscompile in edge
 case with templates and initializer-list
In-Reply-To: <bug-10944-206@http.llvm.org/bugs/>
References: <bug-10944-206@http.llvm.org/bugs/>
Message-ID: <20111009194133.1BF012A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-09 14:41:32 CDT ---
I have no clue what I was thinking... I'll go back and take a look.  In the
meantime, yes, this is 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 llvm.org  Sun Oct  9 15:27:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 15:27:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11094] New: FAIL: Clang :: Driver/linux-ld.c
Message-ID: <bug-11094-206@http.llvm.org/bugs/>

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

           Summary: FAIL: Clang :: Driver/linux-ld.c
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu


The aforementioned test fails on Exherbo Linux in the following way:

FAIL: Clang :: Driver/linux-ld.c (1938 of 3910)
******************** TEST 'Clang :: Driver/linux-ld.c' FAILED
********************
Script:
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple i386-unknown-linux     
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree
   | FileCheck --check-prefix=CHECK-LD-32
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple x86_64-unknown-linux     
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree
   | FileCheck --check-prefix=CHECK-LD-64
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple i386-unknown-linux -m32     
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/multilib_32bit_linux_tree
   | FileCheck --check-prefix=CHECK-32-TO-32
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple i386-unknown-linux -m64     
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/multilib_32bit_linux_tree
   | FileCheck --check-prefix=CHECK-32-TO-64
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple x86_64-unknown-linux -m64     
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/multilib_64bit_linux_tree
   | FileCheck --check-prefix=CHECK-64-TO-64
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple x86_64-unknown-linux -m32     
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/multilib_64bit_linux_tree
   | FileCheck --check-prefix=CHECK-64-TO-32
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple i386-unknown-linux -m32      -ccc-install-dir
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/fake_install_tree/bin
    
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree
   | FileCheck --check-prefix=CHECK-INSTALL-DIR-32
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple x86_64-unknown-linux -m64      -ccc-install-dir
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/fake_install_tree/bin
    
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree
   | FileCheck --check-prefix=CHECK-INSTALL-DIR-64
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple i386-unknown-linux -m32      -ccc-install-dir
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/gcc_version_parsing1/bin
    
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree
   | FileCheck --check-prefix=CHECK-GCC-VERSION1
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple i386-unknown-linux -m32      -ccc-install-dir
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/gcc_version_parsing2/bin
    
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree
   | FileCheck --check-prefix=CHECK-GCC-VERSION2
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/Release+Asserts/bin/clang
 -no-canonical-prefixes
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
-### -o
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o
2>&1      -ccc-host-triple i386-unknown-linux -m32      -ccc-install-dir
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/gcc_version_parsing3/bin
    
--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree
   | FileCheck --check-prefix=CHECK-GCC-VERSION3
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c
--
Exit Code: 1
Command Output (stderr):
--
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/linux-ld.c:9:17:
error: expected string not found in input
// CHECK-LD-32: "{{.*}}/usr/lib/gcc/i386-unknown-linux/4.6.0/crtbegin.o"
                ^
<stdin>:5:131: note: scanning from here
 "/usr/bin/ld"
"--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree"
"--eh-frame-hdr" "-m" "elf_i386" "-dynamic-linker" "/lib/ld-linux.so.2" "-o"
"/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o"
"crt1.o" "crti.o" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/crtbegin.o"
"-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3"
"-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../.."
"-L/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree/lib"
"-L/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree/usr/lib"
"/tmp/linux-ld-O3RNV7.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc"
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/crtend.o" "crtn.o"
                                                                               
                                                  ^
<stdin>:5:325: note: possible intended match here
 "/usr/bin/ld"
"--sysroot=/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree"
"--eh-frame-hdr" "-m" "elf_i386" "-dynamic-linker" "/lib/ld-linux.so.2" "-o"
"/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Output/linux-ld.c.tmp.o"
"crt1.o" "crti.o" "/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/crtbegin.o"
"-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3"
"-L/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/../../../.."
"-L/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree/lib"
"-L/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/test/Driver/Inputs/basic_linux_tree/usr/lib"
"/tmp/linux-ld-O3RNV7.o" "-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed" "-lc"
"-lgcc" "--as-needed" "-lgcc_s" "--no-as-needed"
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.5.3/crtend.o" "crtn.o"


The recent changes to lib/Driver/ToolChain* are probably to blame.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 15:46:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 15:46:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10785] crash on invalid use of variable of type
 "const T&" where T = an unbound method
In-Reply-To: <bug-10785-206@http.llvm.org/bugs/>
References: <bug-10785-206@http.llvm.org/bugs/>
Message-ID: <20111009204615.A2D2C2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 15:46:15 CDT ---
This no longer crashes with mainline Clang:


t2.cpp:17:5: error: no matching function for call to object of type
      'FunctionLike'
    fl(cls.method);
    ^~
t2.cpp:10:31: note: candidate template ignored: couldn't infer template
argument
      'T'
    template<typename T> void operator()(const 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 llvm.org  Sun Oct  9 15:59:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 15:59:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10913] friend function with cast is'nt working for
	templates
In-Reply-To: <bug-10913-206@http.llvm.org/bugs/>
References: <bug-10913-206@http.llvm.org/bugs/>
Message-ID: <20111009205927.32B5F2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-09 15:59:26 CDT ---
Fixed in Clang r141515.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 16:22:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 16:22:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8101] __has_nothrow_constructor failures
In-Reply-To: <bug-8101-206@http.llvm.org/bugs/>
References: <bug-8101-206@http.llvm.org/bugs/>
Message-ID: <20111009212207.1EF212A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 16:22:06 CDT ---
The only place where Clang currently differs from the requested semantics is
for int[]. Since this is a POD type, the GCC definition of
__has_nothrow_constructor(int[]) is documented to evaluate true, per

  http://gcc.gnu.org/onlinedocs/gcc/Type-Traits.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 llvm.org  Sun Oct  9 16:24:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 16:24:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8105] __has_trivial_copy does not work with void,
 arrays with incomplete or complete bounds
In-Reply-To: <bug-8105-206@http.llvm.org/bugs/>
References: <bug-8105-206@http.llvm.org/bugs/>
Message-ID: <20111009212409.9C02B2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-10-09 16:24:08 CDT ---
(In reply to comment #3)
> (In reply to comment #2)
> > Again, if there is some reason we do not want _has_trivial_copy(T) to model the
> > behavior intended for std::has_copy_constructor<T>, then I can work around it
> > in the library (libc++).  Just it would be simpler to drop straight through.
> 
> I'd prefer to have __has_trivial_copy(T) model the behavior of
> std::has_copy_constructor<T>. It's a better specification than "what GCC does",
> and more useful besides.

Older and wiser, I now think that it's better to follow GCC's specification to
improve compatibility, even though it's suboptimal for libc++. Clang is already
following GCC's specification, documented here:

  http://gcc.gnu.org/onlinedocs/gcc/Type-Traits.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 llvm.org  Sun Oct  9 16:26:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 16:26:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8107] __has_nothrow_copy not working for some types
In-Reply-To: <bug-8107-206@http.llvm.org/bugs/>
References: <bug-8107-206@http.llvm.org/bugs/>
Message-ID: <20111009212631.158872A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-09 16:26:30 CDT ---
Clang is behaving correctly now, per GCC's specification of this type trait.
int[3] and int[] have no throw "copy" operations (because they are POD types).
And under C++0x, NotEmpty implicitly has a 'noexcept' specification.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 16:27:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 16:27:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8136] clang doesn't detect invalid redeclarations
 after a using directive brings in something with the same name
In-Reply-To: <bug-8136-206@http.llvm.org/bugs/>
References: <bug-8136-206@http.llvm.org/bugs/>
Message-ID: <20111009212749.107482A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 16:27:48 CDT ---
We properly detect this error now:


t.cpp:5:7: error: redefinition of 'A' as different kind of symbol
class A {};
      ^
t.cpp:1:11: note: previous definition is here
namespace 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 llvm.org  Sun Oct  9 16:30:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 16:30:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8146] Clang incorrectly emitting 'is a private
 member of' error for templated friend class
In-Reply-To: <bug-8146-206@http.llvm.org/bugs/>
References: <bug-8146-206@http.llvm.org/bugs/>
Message-ID: <20111009213019.2F8B1312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-10-09 16:30:18 CDT ---
This is the same as http://llvm.org/PR10913, which was fixed in Clang r 141515.

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

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

From bugzilla-daemon at llvm.org  Sun Oct  9 16:40:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 16:40:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8173] clang++ (rev. 114175) fails inference of
 struct type template param from pointer to overloaded member function
In-Reply-To: <bug-8173-206@http.llvm.org/bugs/>
References: <bug-8173-206@http.llvm.org/bugs/>
Message-ID: <20111009214015.089B52A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-09 16:40:14 CDT ---
Clang is correct here, per C++0x [temp.deduct.call]p6, which states that

  - If the argument is an overload set (not containing function templates),
trial argument deduction is attempted using each of the members of the set. If
deduction succeeds for only one of the overload set members, that member is
used as the argument value for the deduction. If deduction succeeds for more
than one member of the overload set the parameter is treated as a non-deduced
context.

For the call to the "connect" function, this matters for the parameter

  ReturnType (MemberObj:: *fn) (Arg1)

which is matched against the argument

  &B::slot

Note that deduction succeeds for both "slot" overloads, so this parameter is
considered a non-deduced context. Hence, there is nothing left to deduce
MemberObj.

Note that EDG agrees with Clang's interpretation here. I don't know what GCC is
doing to accept this 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 llvm.org  Sun Oct  9 16:46:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 16:46:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8509] clang should support compiling drizzle
In-Reply-To: <bug-8509-206@http.llvm.org/bugs/>
References: <bug-8509-206@http.llvm.org/bugs/>
Message-ID: <20111009214619.7BDBB2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-09 16:46:18 CDT ---
It's been 10 months since I asked for something reproducible. Closing due to
insufficient information.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 17:05:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:05:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11095] New: Assertion in instruction selector
Message-ID: <bug-11095-206@http.llvm.org/bugs/>

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

           Summary: Assertion in instruction selector
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         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=7425)
 --> (http://llvm.org/bugs/attachment.cgi?id=7425)
Testcase

Consider the attached testcase. Running llc yields:

$ ./llc 2.ll
Assertion failed: (InChain.getValueType() == MVT::Other && "Not a chain"),
function HandleMergeInputChains, file
/Users/asl/Projects/llvm/src/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp,
line 1749.
0  llc               0x000000010ca61d12 _ZL15PrintStackTracePv + 34
1  llc               0x000000010ca622f9 _ZL13SignalHandleri + 745
2  libsystem_c.dylib 0x00007fff91639cfa _sigtramp + 26
3  libsystem_c.dylib 000000000000000000 _sigtramp + 18446603338076939040
4  llc               0x000000010ca61f66 abort + 22
5  llc               0x000000010ca61f28 __assert_rtn + 56
6  llc               0x000000010c6061fb
_ZL22HandleMergeInputChainsRN4llvm15SmallVectorImplIPNS_6SDNodeEEEPNS_12SelectionDAGE
+ 1035
7  llc               0x000000010c604303
llvm::SelectionDAGISel::SelectCodeCommon(llvm::SDNode*, unsigned char const*,
unsigned int) + 11715
8  llc               0x000000010c42c6d9 (anonymous
namespace)::ARMDAGToDAGISel::Select(llvm::SDNode*) + 9001
9  llc               0x000000010c5fe34b
llvm::SelectionDAGISel::DoInstructionSelection() + 699
10 llc               0x000000010c5fd62c
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 4188
11 llc               0x000000010c5fb819
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 265
12 llc               0x000000010c5fac8a
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 970
13 llc               0x000000010c6f2cac
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 60
14 llc               0x000000010c97445d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 349
15 llc               0x000000010c97473b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
16 llc               0x000000010c974879
llvm::MPPassManager::runOnModule(llvm::Module&) + 265
17 llc               0x000000010c974e82
llvm::PassManagerImpl::run(llvm::Module&) + 290
18 llc               0x000000010c9753dd llvm::PassManager::run(llvm::Module&) +
13
19 llc               0x000000010c2476b5 main + 4725
20 llc               0x000000010c246434 start + 52
Stack dump:
0.    Program arguments: ./llc 2.ll 
1.    Running pass 'Function Pass Manager' on module '2.ll'.
2.    Running pass 'ARM Instruction Selection' on function '@baz'
Illegal instruction: 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 llvm.org  Sun Oct  9 17:06:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:06:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8598] Failed template argument deduction involving
 member function pointers
In-Reply-To: <bug-8598-206@http.llvm.org/bugs/>
References: <bug-8598-206@http.llvm.org/bugs/>
Message-ID: <20111009220659.183972A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 17:06:58 CDT ---
Fixed in Clang r141517.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 17:08:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:08:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8653] ObjC++ synthesized property setter uses
	GetCopyStructFn
In-Reply-To: <bug-8653-206@http.llvm.org/bugs/>
References: <bug-8653-206@http.llvm.org/bugs/>
Message-ID: <20111009220828.934CD2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-09 17:08:26 CDT ---
Fariborz recently fixed this on top-of-tree.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 17:10:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:10:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8675] protected member access check should only
 apply to functions or data members
In-Reply-To: <bug-8675-206@http.llvm.org/bugs/>
References: <bug-8675-206@http.llvm.org/bugs/>
Message-ID: <20111009221016.596922A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-10-09 17:10:15 CDT ---
Dup'ing to the general bug about searching for subclasses that are friends.

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

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

From bugzilla-daemon at llvm.org  Sun Oct  9 17:17:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:17:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8829] bad interaction bt attribute noreturn and
 throw specification
In-Reply-To: <bug-8829-206@http.llvm.org/bugs/>
References: <bug-8829-206@http.llvm.org/bugs/>
Message-ID: <20111009221749.15395312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-09 17:17:48 CDT ---
This is fixed in top-of-tree 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 llvm.org  Sun Oct  9 17:21:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:21:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8952] extern "C" function returning pointer to
 class in namespace{} silently drops symbol
In-Reply-To: <bug-8952-206@http.llvm.org/bugs/>
References: <bug-8952-206@http.llvm.org/bugs/>
Message-ID: <20111009222158.EBCAD312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 17:21:58 CDT ---
With top-of-tree Clang, I see both bar() and baz(), as expected:


0000000000000000 T _bar
0000000000000038 S _bar.eh
0000000000000010 T _baz
0000000000000060 S _baz.eh

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

From bugzilla-daemon at llvm.org  Sun Oct  9 17:27:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:27:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9049] type-dependent attribute evaluated during
 template definition
In-Reply-To: <bug-9049-206@http.llvm.org/bugs/>
References: <bug-9049-206@http.llvm.org/bugs/>
Message-ID: <20111009222702.90CFD2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 17:27:01 CDT ---
Fixed in Clang r141518.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 17:38:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:38:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9103] encapsulation and friend functions
In-Reply-To: <bug-9103-206@http.llvm.org/bugs/>
References: <bug-9103-206@http.llvm.org/bugs/>
Message-ID: <20111009223849.536492A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 17:38:49 CDT ---
Fixed in Clang r141520.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 17:42:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:42:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11096] New: __builtin_expect-based machine basic
 block reordering not working in simple cases
Message-ID: <bug-11096-206@http.llvm.org/bugs/>

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

           Summary: __builtin_expect-based machine basic block reordering
                    not working in simple cases
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Transformation Utilities
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Consider the following code:

void f(int n);
void g();
extern bool b;
extern int n;
void h() {
  if (__builtin_expect(b,E))
    f(n * n * n * n);
  g();
}

With g++ -DE=0 -O3 (on x86_64), we get this:

_Z1hv:
        subq    $8, %rsp
        cmpb    $0, b(%rip)
        jne     .L4
.L2:
        addq    $8, %rsp
        jmp     _Z1gv
.L4:
        movl    n(%rip), %edi
        imull   %edi, %edi
        imull   %edi, %edi
        call    _Z1fi
        jmp     .L2

With g++ -DE=1 -O3, we get this:

_Z1hv:
        subq    $8, %rsp
        cmpb    $0, b(%rip)
        je      .L2
        movl    n(%rip), %edi
        imull   %edi, %edi
        imull   %edi, %edi
        call    _Z1fi
.L2:
        addq    $8, %rsp
        jmp     _Z1gv

However, LLVM doesn't do anywhere near as well. clang++ -DE=0 -O3 produces
this:

_Z1hv:
        pushq   %rax
        movq    b at GOTPCREL(%rip), %rax
        movb    (%rax), %cl
        andb    $1, %cl
        movzbl  %cl, %eax
        cmpq    $0, %rax
        je      .LBB0_2
        movq    n at GOTPCREL(%rip), %rax
        movl    (%rax), %ecx
        imull   (%rax), %ecx
        imull   (%rax), %ecx
        imull   (%rax), %ecx
        movl    %ecx, %edi
        callq   _Z1fi at PLT
.LBB0_2:
        callq   _Z1gv at PLT
        popq    %rax
        ret

clang++ -DE=1 -O3 produces this:

_Z1hv:
        pushq   %rax
        movq    b at GOTPCREL(%rip), %rax
        testb   $1, (%rax)
        je      .LBB0_2
        movq    n at GOTPCREL(%rip), %rax
        movl    (%rax), %eax
        movl    %eax, %edi
        imull   %edi, %edi
        imull   %eax, %edi
        imull   %eax, %edi
        callq   _Z1fi at PLT
.LBB0_2:
        popq    %rax
        jmp     _Z1gv at PLT

There are lots of things which llvm has done badly here, but in particular the
__builtin_expect(b, 0) has not caused the unexpected code to be moved to the
end of the function (though it has made the test of 'b' bizarrely inefficient,
so it's not being entirely ignored).

The problem seems to be in llvm rather than in clang: the __builtin_expect is
converted to an llvm.expect.i64 (which is converted to !prof metadata).

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

From bugzilla-daemon at llvm.org  Sun Oct  9 17:58:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 17:58:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9162] Namespace and extern "C" gives problems with
 forward struct declarations
In-Reply-To: <bug-9162-206@http.llvm.org/bugs/>
References: <bug-9162-206@http.llvm.org/bugs/>
Message-ID: <20111009225820.1C53F2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 17:58:19 CDT ---
Fixed in Clang r141521.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 18:00:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 18:00:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9382] Incorrect "'noreturn' should not return" when
 there's code after a nested call to a noreturn member function
In-Reply-To: <bug-9382-206@http.llvm.org/bugs/>
References: <bug-9382-206@http.llvm.org/bugs/>
Message-ID: <20111009230037.AE03F312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 18:00:37 CDT ---
Clang correctly models this now. There is no -Winvalid-noreturn diagnostic, but
there is a warning under -Wunreachable-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 llvm.org  Sun Oct  9 18:02:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 18:02:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9476] clang++ asserts while parsing broken/strange
 top level declaration
In-Reply-To: <bug-9476-206@http.llvm.org/bugs/>
References: <bug-9476-206@http.llvm.org/bugs/>
Message-ID: <20111009230207.9DC7F2A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 18:02:07 CDT ---
Clang now complains without crashing.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 18:05:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 18:05:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9545] Don't cause deduction failure for mismatch
 against function parameter not having deducible template parameters
In-Reply-To: <bug-9545-206@http.llvm.org/bugs/>
References: <bug-9545-206@http.llvm.org/bugs/>
Message-ID: <20111009230506.2B8AA2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-09 18:05:05 CDT ---
This is the same as PR8598, which I fixed today.

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

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

From bugzilla-daemon at llvm.org  Sun Oct  9 18:08:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 18:08:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9599] Conditional expression + noreturn destructor
 confuses -Wreturn-type
In-Reply-To: <bug-9599-206@http.llvm.org/bugs/>
References: <bug-9599-206@http.llvm.org/bugs/>
Message-ID: <20111009230812.CB8D9312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-09 18:08:12 CDT ---
This is fixed in top-of-tree.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 18:23:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 18:23:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9759] clang accepts qualified property access in
	objective-c++
In-Reply-To: <bug-9759-206@http.llvm.org/bugs/>
References: <bug-9759-206@http.llvm.org/bugs/>
Message-ID: <20111009232302.405302A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 18:23:01 CDT ---
Fixed in Clang r141522.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 18:30:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 18:30:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9785] Template friend in namespace doesn't work
	correctly.
In-Reply-To: <bug-9785-206@http.llvm.org/bugs/>
References: <bug-9785-206@http.llvm.org/bugs/>
Message-ID: <20111009233007.635852A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 18:30:06 CDT ---
Clang is actually behaving correctly here. The friend struct template
declaration here:

namespace detail {
    template <class T>
    struct Info {
        template <class X> friend struct Test;    
    protected:
        Info(int) {}
    };
}

actually makes the struct template "detail::Test" a friend, because friend
declarations refer to the innermost enclosing namespace. 

The right way to do this would be:


template <class T> struct Test;

namespace detail {
    template <class T>
    struct Info {
        template <class X> friend struct ::Test;    
    protected:
        Info(int) {}
    };
}

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

From bugzilla-daemon at llvm.org  Sun Oct  9 20:12:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 20:12:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9853] Friends allowed to define member functions
In-Reply-To: <bug-9853-206@http.llvm.org/bugs/>
References: <bug-9853-206@http.llvm.org/bugs/>
Message-ID: <20111010011210.4EC182A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-09 20:12:10 CDT ---
Fixed in Clang r141524.

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

From bugzilla-daemon at llvm.org  Sun Oct  9 22:00:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 22:00:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11097] New: NumQuoted wrong after
 RemoveDuplicates(SearchList, NumQuoted, Verbose); 
Message-ID: <bug-11097-206@http.llvm.org/bugs/>

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

           Summary: NumQuoted wrong after RemoveDuplicates(SearchList,
                    NumQuoted, Verbose);
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Headers
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: emmanuel.christophe at gmail.com
                CC: llvmbugs at cs.uiuc.edu


In InitHeaderSearch.cpp in the Realize() method during the third call
to RemoveDuplicates:

01092   // Remove duplicates across both the Angled and System
directories.  GCC does
01093   // this and failing to remove duplicates across these two groups breaks
01094   // #include_next.
01095   RemoveDuplicates(SearchList, NumQuoted, Verbose);

The RemoveDuplicates method can remove non system directories (when
they are also system directories) showing the information message:

01039       if (DirToRemove != i)
01040         llvm::errs() << "  as it is a non-system directory that
duplicates "
01041                      << "a system directory\n";

When this happens, the NumQuoted variable is wrong, the header
initialization is incorrect:
01098   Headers.SetSearchPaths(SearchList, NumQuoted, NumAngled,
DontSearchCurDir);

and the use of  search_dir_iterator system_dir_begin() is unreliable,
missing some system directories.

This bug manifested itself using include-what-you-use, misinterpreting some
system path as user path:
http://code.google.com/p/include-what-you-use/issues/detail?id=60

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

From bugzilla-daemon at llvm.org  Sun Oct  9 23:20:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  9 Oct 2011 23:20:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9893] "Invalid GetElementPtrInst indices for type!"
 on valid structure
In-Reply-To: <bug-9893-206@http.llvm.org/bugs/>
References: <bug-9893-206@http.llvm.org/bugs/>
Message-ID: <20111010042044.C7881312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-09 23:20:43 CDT ---
This is fixed in top-of-tree.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 02:43:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 02:43:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11098] New: valgrind errors in
 PCHGenerator::HandleTranslationUnit
Message-ID: <bug-11098-206@http.llvm.org/bugs/>

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

           Summary: valgrind errors in PCHGenerator::HandleTranslationUnit
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pawel.worach at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This is with trunk r141528.

******************** TEST 'Clang :: ASTMerge/exprs.c' FAILED
********************
Script:
--
/data/tmp/obj.1/Debug+Asserts/bin/clang -cc1 -emit-pch -o
/data/tmp/obj.1/tools/clang/test/ASTMerge/Output/exprs.c.tmp.1.ast
/data/tmp/llvm/tools/clang/test/ASTMerge/Inputs/exprs1.c
/data/tmp/obj.1/Debug+Asserts/bin/clang -cc1 -emit-pch -o
/data/tmp/obj.1/tools/clang/test/ASTMerge/Output/exprs.c.tmp.2.ast
/data/tmp/llvm/tools/clang/test/ASTMerge/Inputs/exprs2.c
/data/tmp/obj.1/Debug+Asserts/bin/clang -cc1 -ast-merge
/data/tmp/obj.1/tools/clang/test/ASTMerge/Output/exprs.c.tmp.1.ast -ast-merge
/data/tmp/obj.1/tools/clang/test/ASTMerge/Output/exprs.c.tmp.2.ast
-fsyntax-only -verify /data/tmp/llvm/tools/clang/test/ASTMerge/exprs.c
--
Exit Code: 123
Command Output (stderr):
--
==35607== Syscall param write(buf) points to uninitialised byte(s)
==35607==    at 0x4DD015C: __sys_write (in /lib/libc.so.7)
==35607==    by 0x28E88C1: llvm::raw_ostream::write(char const*, unsigned long)
(raw_ostream.cpp:305)
==35607==    by 0x28E8846: llvm::raw_ostream::write(char const*, unsigned long)
(raw_ostream.cpp:295)
==35607==    by 0x115AAF4:
clang::PCHGenerator::HandleTranslationUnit(clang::ASTContext&)
(GeneratePCH.cpp:55)
==35607==    by 0x12BB978: clang::ParseAST(clang::Sema&, bool)
(ParseAST.cpp:101)
==35607==    by 0x100119A: clang::ASTFrontendAction::ExecuteAction()
(FrontendAction.cpp:379)
==35607==    by 0x10012B5: clang::FrontendAction::Execute()
(FrontendAction.cpp:299)
==35607==    by 0xFE4561:
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
(CompilerInstance.cpp:631)
==35607==    by 0xFB71B5:
clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
(ExecuteCompilerInvocation.cpp:173)
==35607==    by 0xFA80D6: cc1_main(char const**, char const**, char const*,
void*) (cc1_main.cpp:159)
==35607==    by 0xFB2BC1: main (driver.cpp:354)
==35607==  Address 0x5321a5d is 14,349 bytes inside a block of size 131,072
alloc'd
==35607==    at 0x4172F79: operator new(unsigned long) (in
/usr/local/lib/valgrind/vgpreload_memcheck-amd64-freebsd.so)
==35607==    by 0x113650E: __gnu_cxx::new_allocator<unsigned
char>::allocate(unsigned long, void const*) (new_allocator.h:91)
==35607==    by 0x1136544: std::_Vector_base<unsigned char,
std::allocator<unsigned char> >::_M_allocate(unsigned long) (stl_vector.h:128)
==35607==    by 0x1136678: std::vector<unsigned char, std::allocator<unsigned
char> >::_M_insert_aux(__gnu_cxx::__normal_iterator<unsigned char*,
std::vector<unsigned char, std::allocator<unsigned char> > >, unsigned char
const&) (vector.tcc:271)
==35607==    by 0x113682B: std::vector<unsigned char, std::allocator<unsigned
char> >::push_back(unsigned char const&) (stl_vector.h:605)
==35607==    by 0x11371F0: void
llvm::BitstreamWriter::EmitRecordWithAbbrevImpl<unsigned long>(unsigned int,
llvm::SmallVectorImpl<unsigned long>&, llvm::StringRef) (BitstreamWriter.h:363)
==35607==    by 0x1137508: void
llvm::BitstreamWriter::EmitRecordWithBlob<unsigned long>(unsigned int,
llvm::SmallVectorImpl<unsigned long>&, llvm::StringRef) (BitstreamWriter.h:428)
==35607==    by 0x110DF0D:
clang::ASTWriter::WriteIdentifierTable(clang::Preprocessor&, bool)
(ASTWriter.cpp:2359)
==35607==    by 0x1118357: clang::ASTWriter::WriteASTCore(clang::Sema&,
clang::MemorizeStatCalls*, llvm::StringRef, std::string const&, bool)
(ASTWriter.cpp:3020)
==35607==    by 0x1118A8D: clang::ASTWriter::WriteAST(clang::Sema&,
clang::MemorizeStatCalls*, std::string const&, bool, llvm::StringRef)
(ASTWriter.cpp:2741)
==35607==    by 0x115AAC4:
clang::PCHGenerator::HandleTranslationUnit(clang::ASTContext&)
(GeneratePCH.cpp:52)
==35607==    by 0x12BB978: clang::ParseAST(clang::Sema&, bool)
(ParseAST.cpp:101)
==35607== 
--

********************

Another valgrind error is this which looks related:
******************** TEST 'Clang :: PCH/chain-cxx.cpp' FAILED
********************Script:
--
/data/buildslave/clang-i386-freebsd-vg_leak/obj/llvm.1/Release+Asserts/bin/clang
-cc1 -fsyntax-only -verify -include
/data/buildslave/clang-i386-freebsd-vg_leak/src-llvm/tools/clang/test/PCH/chain-cxx.cpp
-include
/data/buildslave/clang-i386-freebsd-vg_leak/src-llvm/tools/clang/test/PCH/chain-cxx.cpp
/data/buildslave/clang-i386-freebsd-vg_leak/src-llvm/tools/clang/test/PCH/chain-cxx.cpp
/data/buildslave/clang-i386-freebsd-vg_leak/obj/llvm.1/Release+Asserts/bin/clang
-cc1 -fsyntax-only -verify
/data/buildslave/clang-i386-freebsd-vg_leak/src-llvm/tools/clang/test/PCH/chain-cxx.cpp
-chain-include
/data/buildslave/clang-i386-freebsd-vg_leak/src-llvm/tools/clang/test/PCH/chain-cxx.cpp
-chain-include
/data/buildslave/clang-i386-freebsd-vg_leak/src-llvm/tools/clang/test/PCH/chain-cxx.cpp
--
Exit Code: 123
Command Output (stderr):
--
==53519== Conditional jump or move depends on uninitialised value(s)
==53519==    at 0x1136A7D: llvm::BitstreamWriter::EmitVBR64(unsigned long,
unsigned int) (BitstreamWriter.h:147)
==53519==    by 0x1137435: void llvm::BitstreamWriter::EmitRecord<unsigned
long>(unsigned int, llvm::SmallVectorImpl<unsigned long>&, unsigned int)
(BitstreamWriter.h:402)
==53519==    by 0x114F316: clang::ASTWriter::WriteSubStmt(clang::Stmt*)
(ASTWriterStmt.cpp:1468)
==53519==    by 0x114F2E4: clang::ASTWriter::WriteSubStmt(clang::Stmt*)
(ASTWriterStmt.cpp:1466)
==53519==    by 0x114F3A5: clang::ASTWriter::FlushStmts()
(ASTWriterStmt.cpp:1477)
==53519==    by 0x11419B7: clang::ASTWriter::WriteDecl(clang::ASTContext&,
clang::Decl*) (ASTWriterDecl.cpp:1671)
==53519==    by 0x11182B2: clang::ASTWriter::WriteASTCore(clang::Sema&,
clang::MemorizeStatCalls*, llvm::StringRef, std::string const&, bool)
(ASTWriter.cpp:3012)
==53519==    by 0x1118A8D: clang::ASTWriter::WriteAST(clang::Sema&,
clang::MemorizeStatCalls*, std::string const&, bool, llvm::StringRef)
(ASTWriter.cpp:2741)
==53519==    by 0x115AAC4:
clang::PCHGenerator::HandleTranslationUnit(clang::ASTContext&)
(GeneratePCH.cpp:52)
==53519==    by 0x12BB978: clang::ParseAST(clang::Sema&, bool)
(ParseAST.cpp:101)
==53519==    by 0x11591F1:
clang::ChainedIncludesSource::create(clang::CompilerInstance&)
(ChainedIncludesSource.cpp:146)
==53519==    by 0x100237B:
clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&,
llvm::StringRef, clang::InputKind) (FrontendAction.cpp:220)
==53519== 
==53519== Conditional jump or move depends on uninitialised value(s)
==53519==    at 0x1136A4D: llvm::BitstreamWriter::EmitVBR(unsigned int,
unsigned int) (BitstreamWriter.h:138)
==53519==    by 0x1136A90: llvm::BitstreamWriter::EmitVBR64(unsigned long,
unsigned int) (BitstreamWriter.h:148)
==53519==    by 0x1137435: void llvm::BitstreamWriter::EmitRecord<unsigned
long>(unsigned int, llvm::SmallVectorImpl<unsigned long>&, unsigned int)
(BitstreamWriter.h:402)
==53519==    by 0x114F316: clang::ASTWriter::WriteSubStmt(clang::Stmt*)
(ASTWriterStmt.cpp:1468)
==53519==    by 0x114F2E4: clang::ASTWriter::WriteSubStmt(clang::Stmt*)
(ASTWriterStmt.cpp:1466)
==53519==    by 0x114F3A5: clang::ASTWriter::FlushStmts()
(ASTWriterStmt.cpp:1477)
==53519==    by 0x11419B7: clang::ASTWriter::WriteDecl(clang::ASTContext&,
clang::Decl*) (ASTWriterDecl.cpp:1671)
==53519==    by 0x11182B2: clang::ASTWriter::WriteASTCore(clang::Sema&,
clang::MemorizeStatCalls*, llvm::StringRef, std::string const&, bool)
(ASTWriter.cpp:3012)
==53519==    by 0x1118A8D: clang::ASTWriter::WriteAST(clang::Sema&,
clang::MemorizeStatCalls*, std::string const&, bool, llvm::StringRef)
(ASTWriter.cpp:2741)
==53519==    by 0x115AAC4:
clang::PCHGenerator::HandleTranslationUnit(clang::ASTContext&)
(GeneratePCH.cpp:52)
==53519==    by 0x12BB978: clang::ParseAST(clang::Sema&, bool)
(ParseAST.cpp:101)
==53519==    by 0x11591F1:
clang::ChainedIncludesSource::create(clang::CompilerInstance&)
(ChainedIncludesSource.cpp:146)
==53519==

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

From bugzilla-daemon at llvm.org  Mon Oct 10 03:25:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 03:25:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7880] llc with frame pointer elimination disabled
 generates incorrect epilogue code for the ARM target
In-Reply-To: <bug-7880-206@http.llvm.org/bugs/>
References: <bug-7880-206@http.llvm.org/bugs/>
Message-ID: <20111010082535.3A7363128018@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #13 from Bill Wendling <wendling at apple.com> 2011-10-10 03:25:34 CDT ---
2.7 and 2.8 are ancient. ToT llc and llvm-dis (etc.) are unable to read the .bc
file.

Please regenerate the file with ToT. If it still has the problem, then please
reopen this bug.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 03:27:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 03:27:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7877] "Dwarf Error: bad offset" when compiling with
 debugging symbols (-g)
In-Reply-To: <bug-7877-206@http.llvm.org/bugs/>
References: <bug-7877-206@http.llvm.org/bugs/>
Message-ID: <20111010082703.5B60D3128018@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #3 from Bill Wendling <wendling at apple.com> 2011-10-10 03:27:02 CDT ---
There hasn't been any movement on this bug for quite a while. If this is still
a problem in mainline, please reopen this bug.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 03:30:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 03:30:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4457] Array size error when building with LLVM
In-Reply-To: <bug-4457-206@http.llvm.org/bugs/>
References: <bug-4457-206@http.llvm.org/bugs/>
Message-ID: <20111010083009.44767312800A@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #6 from Bill Wendling <wendling at apple.com> 2011-10-10 03:30:08 CDT ---
llvm-gcc is no more. Please use clang instead. Chris's example works as does
the original test case.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 03:30:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 03:30:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11099] New: Error compiling zlib
Message-ID: <bug-11099-206@http.llvm.org/bugs/>

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

           Summary: Error compiling zlib
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dontbugme at mailinator.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7427)
 --> (http://llvm.org/bugs/attachment.cgi?id=7427)
Files causing troubles

When trying to compile zlib 1.2.5 with clang:

E:\projects\benchmark04\tst\tmp>c:\clang\bin\clang.exe -o deflate.c.obj -c
deflate.c -v
clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-mingw32
Thread model: posix
 "c:/clang/bin/clang.exe" -cc1 -triple i386-pc-mingw32 -S -disable-free
-disable
-llvm-verifier -main-file-name deflate.c -mrelocation-model static
-mdisable-fp-
elim -mconstructor-aliases -target-cpu pentium4 -target-linker-version 97.14
-mo
mit-leaf-frame-pointer -v -resource-dir c:/clang/bin\..\lib\clang\2.9
-ferror-li
mit 19 -fmessage-length 80 -fno-use-cxa-atexit -fgnu-runtime
-fdiagnostics-show-
option -fcolor-diagnostics -o C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s -x
c E:\projects\benchmark04\src\zlib\deflate.c
clang -cc1 version 2.9 based upon llvm 2.9 hosted on i386-pc-mingw32
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "/mingw/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 c:/clang/bin/../lib/clang/2.9/include
 c:/mingw/include
End of search list.
 "c:/MinGW/bin/gcc.exe" -v -c -m32 -o deflate.c.obj -x assembler
C:/DOCUME~1/ADM
INI~1/LOCALS~1/Temp/cc-270455.s
Using built-in specs.
COLLECT_GCC=c:/MinGW/bin/gcc.exe
COLLECT_LTO_WRAPPER=c:/mingw/bin/../libexec/gcc/mingw32/4.5.2/lto-wrapper.exe
Target: mingw32
Configured with: ../gcc-4.5.2/configure
--enable-languages=c,c++,ada,fortran,obj
c,obj-c++ --disable-sjlj-exceptions --with-dwarf2 --enable-shared
--enable-libgo
mp --disable-win32-registry --enable-libstdcxx-debug
--enable-version-specific-r
untime-libs --disable-werror --build=mingw32 --prefix=/mingw
Thread model: win32
gcc version 4.5.2 (GCC)
COLLECT_GCC_OPTIONS='-v' '-c' '-m32' '-o' 'deflate.c.obj' '-mtune=i386'
'-march=
i386'
 c:/mingw/bin/../lib/gcc/mingw32/4.5.2/../../../../mingw32/bin/as.exe -o
deflate
.c.obj C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s
C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s: Assembler messages:
C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s:5971: Error: unknown pseudo-op:
`
.hidden'
C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s:5972: Error: unknown pseudo-op:
`
.hidden'
C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s:5973: Error: unknown pseudo-op:
`
.hidden'
C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s:5974: Error: unknown pseudo-op:
`
.hidden'
C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s:5975: Error: unknown pseudo-op:
`
.hidden'
C:/DOCUME~1/ADMINI~1/LOCALS~1/Temp/cc-270455.s:5976: Error: unknown pseudo-op:
`
.hidden'
clang: error:
      assembler
      (via
      gcc)
      command
      failed
      with
      exit
      code
      1
      (use
      -v
      to
      see
      invocation)

clang version:
clang version 2.9 (tags/RELEASE_29/final)
Target: i386-pc-mingw32
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 llvm.org  Mon Oct 10 04:08:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 04:08:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11100] New: conditional noexcept using constexpr
 template function produces an error when it should compile
Message-ID: <bug-11100-206@http.llvm.org/bugs/>

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

           Summary: conditional noexcept using constexpr template function
                    produces an error when it should compile
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: davidhunter22 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Trunk code at revision 141529

This is sort of a follow on to http://llvm.org/bugs/show_bug.cgi?id=11084 which
related to a compiler assertion for similar code. That assertion is now fixed
however I believe the compiler is still in error ( at least according to my
newbie understanding of conditional noexcept )

Note that I am actually trying to use the GCC 4.6.0 standard C++ library on
Linux and these errors are distilled cases where the GCC compiler has no
problem with its headers while clang throws up. So it may be that clang is
right and GCC wrong.

Anyway the code in question is

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
template<typename T> struct Foo
{
    static constexpr bool foo( ) { return( true ); }
};

class Bar 
{
    void bar( ) noexcept(Foo<int>::foo());
};

int main( int, char** )
{
    Bar v;

    return( 0 );
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

Which produces an error 

bug.cpp:8:26: error: argument to noexcept specifier must be a constant
expression
    void bar( ) noexcept(Foo<int>::foo());


It would seem to me that Foo<X>::foo is always a constexpr function returning a
bool for any X so you should be able to use it in a conditional noexcept
specifier.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 07:32:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 07:32:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11101] New: constructor taking an rvalue reference
 causes error with normal copy constructor
Message-ID: <bug-11101-206@http.llvm.org/bugs/>

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

           Summary: constructor taking an rvalue reference causes error
                    with normal copy constructor
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: davidhunter22 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Trunk code as of revision 141531 on a unmolested Ubuntu Linux desktop.

The following code

>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>>
template<typename T> struct Foo
{   
    explicit Foo(T* );

    Foo(Foo&&) noexcept;
};  

struct Bar
{ 
    virtual ~Bar( ) { }
};

int main( int, char** )
{
    static Foo<Bar> f = Foo<Bar>( new Bar ); 

    Foo<Bar> g = f;
}
<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<<

gives the following error 

bug.cpp:19:14: error: call to deleted constructor of 'Foo<Bar>'
    Foo<Bar> g = f;
             ^   ~
bug.cpp:2:29: note: function has been explicitly marked deleted here
template<typename T> struct Foo 
                            ^
1 error generated.


which seems odd to me. I don't see any function being explicitly marked as
deleted. I assume it means the new " = delete" syntax. I also assume is means
the normal copy constructor Foo(Foo&) which I think should be compiler
generated here although maybe the presence of a "move" constructor is meant to
stop the copy constructor being created.

Anyway this code is a cut down test case from the GCC 4.6.0 header files which
don't seem to have a problem with constructs like 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 llvm.org  Mon Oct 10 07:56:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 07:56:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11098] valgrind errors in
	PCHGenerator::HandleTranslationUnit
In-Reply-To: <bug-11098-206@http.llvm.org/bugs/>
References: <bug-11098-206@http.llvm.org/bugs/>
Message-ID: <20111010125635.E34302A6C124@llvm.org>

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

Benjamin Kramer <benny.kra at gmail.com> changed:

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2011-10-10 07:56:35 CDT ---
Fixed in r141532.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 09:05:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 09:05:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9865] Assertion `Result.isInvalid() && "C++ binary
 operator overloading is missing candidates!"' failed.
In-Reply-To: <bug-9865-206@http.llvm.org/bugs/>
References: <bug-9865-206@http.llvm.org/bugs/>
Message-ID: <20111010140541.C046B312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-10 09:05:41 CDT ---
Fixed in Clang r141537.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 09:49:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 09:49:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9989] Wrong point of declaration for static data
	member
In-Reply-To: <bug-9989-206@http.llvm.org/bugs/>
References: <bug-9989-206@http.llvm.org/bugs/>
Message-ID: <20111010144939.04A782A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-10 09:49:38 CDT ---
Fixed in Clang r141539.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 09:53:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 09:53:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10086] Explicit Template Instantiation without
 Original Template Definition
In-Reply-To: <bug-10086-206@http.llvm.org/bugs/>
References: <bug-10086-206@http.llvm.org/bugs/>
Message-ID: <20111010145340.06BAF312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 09:53:39 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon Oct 10 09:56:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 09:56:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10219] UNREACHABLE: unexpected type in nested name
	specifier!
In-Reply-To: <bug-10219-206@http.llvm.org/bugs/>
References: <bug-10219-206@http.llvm.org/bugs/>
Message-ID: <20111010145607.5B6F72A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 09:56:07 CDT ---
This appears to be fixed with top-of-tree 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 llvm.org  Mon Oct 10 11:01:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 11:01:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11102] New: [AVX] x86 isel hits assert (begin() +
 idx < end()), function operator[], file [...]/ADT/SmallVector.h, line 154
Message-ID: <bug-11102-206@http.llvm.org/bugs/>

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

           Summary: [AVX] x86 isel hits assert (begin() + idx < end()),
                    function operator[], file [...]/ADT/SmallVector.h,
                    line 154
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


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

If I run "llc -mattr=+avx" with the attached test case, the assertion above
hits in the X86 DAG->DAG instruction selection pass.

For reasons unknown, I don't get a reasonable stack trace from llc, but the
following seems to be where it's hitting this:

5  ispc              0x000000010cd0f648 __assert_rtn + 56
6  ispc              0x000000010c5bc7c0
llvm::X86TargetLowering::LowerVECTOR_SHUFFLE(llvm::SDValue,
llvm::SelectionDAG&) const + 31840
7  ispc              0x000000010c5dbcd7
llvm::X86TargetLowering::LowerOperation(llvm::SDValue, llvm::SelectionDAG&)
const + 487
8  ispc              0x000000010c6b1ab0 (anonymous
namespace)::SelectionDAGLegalize::LegalizeOp(llvm::SDValue) + 3696
9  ispc              0x000000010c6b0a9d llvm::SelectionDAG::Legalize() + 173
10 ispc              0x000000010c7bc2c9
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 3161
11 ispc              0x000000010c7ba8b9
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 265
12 ispc              0x000000010c7b9d2a
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 970
13 ispc              0x000000010c8a7dbc
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 60
14 ispc              0x000000010cc6f97d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 349
15 ispc              0x000000010cc6fc5b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
16 ispc              0x000000010cc6fd99
llvm::MPPassManager::runOnModule(llvm::Module&) + 265
17 ispc              0x000000010cc703a2
llvm::PassManagerImpl::run(llvm::Module&) + 290
18 ispc              0x000000010cc708fd llvm::PassManager::run(llvm::Module&) +
13

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

From bugzilla-daemon at llvm.org  Mon Oct 10 11:05:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 11:05:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10288] Clang rejects string literal initializer for
 char array that has no explicit size
In-Reply-To: <bug-10288-206@http.llvm.org/bugs/>
References: <bug-10288-206@http.llvm.org/bugs/>
Message-ID: <20111010160534.DAC7E2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 11:05:34 CDT ---
Fixed in Clang r141543.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 11:12:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 11:12:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11103] New: SetVector documentation needs to be
 updated WRT default data structures used.
Message-ID: <bug-11103-206@http.llvm.org/bugs/>

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

           Summary: SetVector documentation needs to be updated WRT
                    default data structures used.
           Product: Documentation
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: michael at lunarg.com
                CC: llvmbugs at cs.uiuc.edu


(I tried sending an email to llvm-commits with this patch last month, but I
don't know if I was following the right process as I did not hear anything
back)

Since r33854, SetVectors have defaulted to size 16 SmallSets, but the
Programmer's Manual still says it uses an std:set. 

This brings it to a single malloc for the std::vector, so I'm not sure if it
should still be called "quite expensive", but I'll let someone else make 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 llvm.org  Mon Oct 10 11:19:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 11:19:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10684] MPPassManager::addLowerLevelRequiredPass may
	crash
In-Reply-To: <bug-10684-206@http.llvm.org/bugs/>
References: <bug-10684-206@http.llvm.org/bugs/>
Message-ID: <20111010161951.E0AF92A6C124@llvm.org>

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

Devang Patel <dpatel at apple.com> changed:

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

--- Comment #3 from Devang Patel <dpatel at apple.com> 2011-10-10 11:19:51 CDT ---
I believe this was fixed by r139642.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 11:32:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 11:32:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11104] New: Inefficient Code Gen for Boolean
 Expression Evaluation
Message-ID: <bug-11104-206@http.llvm.org/bugs/>

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

           Summary: Inefficient Code Gen for Boolean Expression Evaluation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: justin.holewinski at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7431)
 --> (http://llvm.org/bugs/attachment.cgi?id=7431)
Test Case Source

Clang is currently producing inefficient LLVM IR for expression evaluation
involving short-circuit evaluation. In the attached test case, both an integer
and a boolean expression is computed. However, short-circuit evaluation of the
boolean expression may render the integer computation useless. An additional
basic block is inserted in the LLVM IR to allow short-circuit evaluation, but
the possibly-unnecessary integer computation is not placed in this basic block.
Instead, the computation is *always* performed.

Please see the attached short-circuit.cpp test case, as well as the
short-circuit.clang.ll LLVM IR file which shows the inefficiency. Additionally,
the short-circuit.dragonegg.ll shows the LLVM IR output from DragonEgg, which
shows GCC moving the integer computation into a basic block which will only be
executed if the result of the integer expression is actually needed.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 11:59:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 11:59:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11106] New: SROA pass hit assert with simple program
Message-ID: <bug-11106-206@http.llvm.org/bugs/>

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

           Summary: SROA pass hit assert with simple program
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


With top of tree and the following program:

define void @"f_v___REFUf[]"() nounwind {
allocas:
  %a156286 = alloca [4 x <4 x float>], align 16
  br i1 undef, label %cif_done, label %for_test158.preheader

for_test158.preheader:                            ; preds = %allocas
  %a156286305 = bitcast [4 x <4 x float>]* %a156286 to i8*
  call void @llvm.memset.p0i8.i64(i8* %a156286305, i8 -1, i64 64, i32 16, i1
false)
  unreachable

cif_done:                                         ; preds = %allocas
  ret void
}

If I run opt as follows:

% opt -scalarrepl bugpoint-reduced-simplified.ll > /dev/null

This assertion hits:
Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"),
function cast, file /Users/mmp/llvm-dev-src/include/llvm/Support/Casting.h,
line 194.

opt doesn't give me a good stack trace, but this seems to be the relevant bits:
[...]
6  ispc              0x00000001044cb8b2 (anonymous
namespace)::SROA::RewriteForScalarRepl(llvm::Instruction*, llvm::AllocaInst*,
unsigned long long, llvm::SmallVector<llvm::AllocaInst*, 32u>&) + 11890
7  ispc              0x00000001044c8c05 (anonymous
namespace)::SROA::RewriteForScalarRepl(llvm::Instruction*, llvm::AllocaInst*,
unsigned long long, llvm::SmallVector<llvm::AllocaInst*, 32u>&) + 453
8  ispc              0x00000001044c4ca0 (anonymous
namespace)::SROA::runOnFunction(llvm::Function&) + 3792
9  ispc              0x0000000104732ecd
llvm::FPPassManager::runOnFunction(llvm::Function&) + 349
10 ispc              0x000000010458856e (anonymous
namespace)::CGPassManager::runOnModule(llvm::Module&) + 2078
11 ispc              0x00000001047332e9
llvm::MPPassManager::runOnModule(llvm::Module&) + 265
12 ispc              0x00000001047338f2
llvm::PassManagerImpl::run(llvm::Module&) + 290
[...]
0.    Program arguments: opt -scalarrepl bugpoint-reduced-simplified.ll 
1.    Running pass 'Function Pass Manager' on module
'bugpoint-reduced-simplified.ll'.
2.    Running pass 'Scalar Replacement of Aggregates (DT)' on function
'@"f_v___REFUf[]"'

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

From bugzilla-daemon at llvm.org  Mon Oct 10 12:09:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 12:09:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11106] SROA pass hit assert with simple program
In-Reply-To: <bug-11106-206@http.llvm.org/bugs/>
References: <bug-11106-206@http.llvm.org/bugs/>
Message-ID: <20111010170935.CE1C62A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |baldrick at free.fr
         Resolution|                            |DUPLICATE

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-10-10 12:09:35 CDT ---
This is probably a duplicate of PR10565.

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

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

From bugzilla-daemon at llvm.org  Mon Oct 10 12:19:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 12:19:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11101] poor diagnostic with implicitly deleted copy
	constructor
In-Reply-To: <bug-11101-206@http.llvm.org/bugs/>
References: <bug-11101-206@http.llvm.org/bugs/>
Message-ID: <20111010171934.05FB02A6C124@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |DUPLICATE

--- Comment #4 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-10-10 12:19:33 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon Oct 10 12:21:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 12:21:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11096] __builtin_expect-based machine basic block
 reordering not working in simple cases
In-Reply-To: <bug-11096-206@http.llvm.org/bugs/>
References: <bug-11096-206@http.llvm.org/bugs/>
Message-ID: <20111010172142.796D02A6C12C@llvm.org>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bob.wilson at apple.com
         Resolution|                            |LATER

--- Comment #3 from Bob Wilson <bob.wilson at apple.com> 2011-10-10 12:21:42 CDT ---
Support for builtin_expect is a work in progress.  The basic infrastructure is
in place but there aren't many optimizations using it yet.  Block reordering
will be added soon.

Since this is a missing optimization, not a bug, I'm closing this.  (We don't
generally use bug report to keep track of opportunities for better
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 llvm.org  Mon Oct 10 12:22:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 12:22:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10289] Clang incorrectly takes an unnamed bitfield
	as a member
In-Reply-To: <bug-10289-206@http.llvm.org/bugs/>
References: <bug-10289-206@http.llvm.org/bugs/>
Message-ID: <20111010172232.3789A2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-10 12:22:31 CDT ---
Fixed in Clang r141549.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 12:38:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 12:38:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10291] clang asserts when comparing different types
 inside a throw inside a class template
In-Reply-To: <bug-10291-206@http.llvm.org/bugs/>
References: <bug-10291-206@http.llvm.org/bugs/>
Message-ID: <20111010173830.DCA1D2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 12:38:29 CDT ---
Fixed in Clang r141552.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 12:54:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 12:54:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10505] Assertion failed: (FieldNo < FieldCount &&
 "Invalid Field No"), function getFieldOffset, file
 /usr/home/rdivacky/llvm/tools/clang/lib/AST/../../include/clang/AST/RecordLayout.h,
 line 121.
In-Reply-To: <bug-10505-206@http.llvm.org/bugs/>
References: <bug-10505-206@http.llvm.org/bugs/>
Message-ID: <20111010175400.8C4892A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-10-10 12:53:59 CDT ---
This is no longer failing with top-of-tree 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 llvm.org  Mon Oct 10 12:56:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 12:56:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10595] Friend with templated function parameter
	ignored
In-Reply-To: <bug-10595-206@http.llvm.org/bugs/>
References: <bug-10595-206@http.llvm.org/bugs/>
Message-ID: <20111010175612.537A22A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-10 12:56:11 CDT ---
Yes, this is the same as PR9440.

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

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

From bugzilla-daemon at llvm.org  Mon Oct 10 12:58:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 12:58:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10784] accepts invalid templated operator() call
In-Reply-To: <bug-10784-206@http.llvm.org/bugs/>
References: <bug-10784-206@http.llvm.org/bugs/>
Message-ID: <20111010175809.066D5312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-10-10 12:58:08 CDT ---
Clang properly rejects these cases now.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 13:16:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 13:16:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10801] clang++ incorrectly reports function could
 be attribute 'noreturn' in template function
In-Reply-To: <bug-10801-206@http.llvm.org/bugs/>
References: <bug-10801-206@http.llvm.org/bugs/>
Message-ID: <20111010181616.89A0A2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 13:16:16 CDT ---
Fixed in Clang r141559.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 13:27:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 13:27:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9586] = default support needed for libstdc++-4.6 in
	C++0x mode
In-Reply-To: <bug-9586-206@http.llvm.org/bugs/>
References: <bug-9586-206@http.llvm.org/bugs/>
Message-ID: <20111010182706.C06713128018@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 13:27:06 CDT ---
"= default" is implemented in top-of-tree 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 llvm.org  Mon Oct 10 13:29:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 13:29:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9916] link-time undefined copy constructor when
	defaulting
In-Reply-To: <bug-9916-206@http.llvm.org/bugs/>
References: <bug-9916-206@http.llvm.org/bugs/>
Message-ID: <20111010182915.3C2A62A6C12C@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-10 13:29:14 CDT ---
This is fixed with top-of-tree 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 llvm.org  Mon Oct 10 13:32:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 13:32:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10035] noexcept can't reference function arguments
In-Reply-To: <bug-10035-206@http.llvm.org/bugs/>
References: <bug-10035-206@http.llvm.org/bugs/>
Message-ID: <20111010183259.C20AF2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 13:32:59 CDT ---
This is fixed in top-of-tree.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 13:35:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 13:35:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10173] Clang asserts/crashes when compiling static
 member function with late-specified return type
In-Reply-To: <bug-10173-206@http.llvm.org/bugs/>
References: <bug-10173-206@http.llvm.org/bugs/>
Message-ID: <20111010183522.D86CA312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 13:35:22 CDT ---
Clang top-of-tree handles this 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 llvm.org  Mon Oct 10 13:36:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 13:36:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9916] link-time undefined copy constructor when
 defaulting missing testcases
In-Reply-To: <bug-9916-206@http.llvm.org/bugs/>
References: <bug-9916-206@http.llvm.org/bugs/>
Message-ID: <20111010183620.714552A6C12C@llvm.org>

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

Sean Hunt <scshunt at csclub.uwaterloo.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |
            Summary|link-time undefined copy    |link-time undefined copy
                   |constructor when defaulting |constructor when defaulting
                   |                            |missing testcases

--- Comment #3 from Sean Hunt <scshunt at csclub.uwaterloo.ca> 2011-10-10 13:36:20 CDT ---
This is still missing testcases; leaving open as a reminder.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 13:43:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 13:43:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11107] New: r141365 causes infinite loop in
 consumer-lame and 464_h264ref
Message-ID: <bug-11107-206@http.llvm.org/bugs/>

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

           Summary: r141365 causes infinite loop in consumer-lame and
                    464_h264ref
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: wendling at apple.com
                CC: llvmbugs at cs.uiuc.edu


The title says it all. There's an infinite loop in these two tests:

External/SPEC/CINT2006/464_h264ref/464_h264ref.exec
MultiSource/Benchmarks/MiBench/consumer-lame/consumer-lame.exec

Here's my setup:

make -k -j 1 report "TARGET_LLCFLAGS=" "USE_REFERENCE_OUTPUT=1" \
"DISABLE_CBE=1" "ENABLE_OPTIMIZED=1" "ARCH=ARM" "DISABLE_JIT=1" \
"TARGET_CXX=None" "REMOTE_PORT=30022" "TARGET_CC=None" \
TARGET_LLVMGXX=/Volumes/Sandbox/llvm/llvm-clean.obj/Release+Asserts/bin/clang++
\
"TARGET_FLAGS=-miphoneos-version-min=5.0 -Wl,--no-demangle -ccc-install-dir
/Developer/Platforms/iPhoneOS.platform/Developer/usr/bin -arch armv7 -isysroot
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS6.0.sdk" \
"SMALL_PROBLEM_SIZE=1" "ENABLE_HASHED_PROGRAM_OUTPUT=1" \
"REMOTE_USER=root" "OPTFLAGS=-O3" \
TARGET_LLVMGCC=/Volumes/Sandbox/llvm/llvm-clean.obj/Release+Asserts/bin/clang \
"LLI_OPTFLAGS=-O3" "CC_UNDER_TEST_TARGET_IS_ARMV7=1" \
"CC_UNDER_TEST_IS_CLANG=1" "TEST=simple" "REMOTE_CLIENT=ssh" \
"LLC_OPTFLAGS=-O3" "REMOTE_HOST=localhost" "PROGRAMS_TO_TEST=consumer-lame"

Similar for 464_h264ref.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 14:00:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 14:00:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10230] UNREACHABLE: non-canonical or dependent type
 in IR-generation
In-Reply-To: <bug-10230-206@http.llvm.org/bugs/>
References: <bug-10230-206@http.llvm.org/bugs/>
Message-ID: <20111010190001.8C3B9312800A@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-10 14:00:01 CDT ---
Fixed in Clang r141568.

Note that Clang can't handle the original example because it doesn't yet
implement initializer lists.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 14:02:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 14:02:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10329] assertion failure on invalid combination of
 late-specified return type and 'new'.
In-Reply-To: <bug-10329-206@http.llvm.org/bugs/>
References: <bug-10329-206@http.llvm.org/bugs/>
Message-ID: <20111010190208.666202A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 14:02:07 CDT ---
We no longer assert here:


t.cpp:1:25: error: cannot allocate function type 'int ()' with new
void f() { new (auto()->int); }
                        ^~~

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

From bugzilla-daemon at llvm.org  Mon Oct 10 14:03:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 14:03:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10396] clang crashes during name mangling with
 <nullptr> as non-type template parameter
In-Reply-To: <bug-10396-206@http.llvm.org/bugs/>
References: <bug-10396-206@http.llvm.org/bugs/>
Message-ID: <20111010190346.F30552A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 14:03:46 CDT ---
Clang doesn't properly handle NULL non-type template arguments, per

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

This is one aspect of that (larger) problem.

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

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

From bugzilla-daemon at llvm.org  Mon Oct 10 14:15:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 14:15:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10945] can't compile boost::thread with -std=c++0x
In-Reply-To: <bug-10945-206@http.llvm.org/bugs/>
References: <bug-10945-206@http.llvm.org/bugs/>
Message-ID: <20111010191551.4FD3D3128018@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #9 from Douglas Gregor <dgregor at apple.com> 2011-10-10 14:15:50 CDT ---
(In reply to comment #6)
> From the cfe-dev thread, I think this is by design. 
> 
> shared_ptr defines a move constructor (t.cc:22083) but relies on a constructor
> template (immediately above, t.cc:22079) for copy construction. The letter of
> the law (12.8p7) says:
> 
> "If the class definition declares a move constructor or move assignment
> operator, the implicitly declared copy constructor is defined as deleted;
> otherwise, it is defined as defaulted"
> 
> Without this clause I'm not entirely sure what should've happened - I suppose
> the default copy ctor should've been implicitly provided (from my cursory
> glance of the code it seems like the default would've been correct/sufficient)
> and the constructor template that looks like it could do copy would've been
> ignored.
> 
> With this clause that no longer works, the copy ctor is marked as deleted and
> fails to compile.
> 
> A simpler example is this:
> 
> struct foo {
>   void operator=(foo&&);
> } g((foo()));
> 
> Which compiles without error in g++ but fails in clang++. So far as I'm reading
> the spec, clang is correct and GCC is incorrect.

Yes, this is correct. GCC 4.6.1 doesn't implement this clause yet, because it
came into C++11 relatively late. Closing this as "invalid": it's a GCC and
Boost bug, not a Clang bug. There is a little more information here

  http://clang.llvm.org/compatibility.html#deleted-special-func

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

From bugzilla-daemon at llvm.org  Mon Oct 10 14:16:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 14:16:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11000] Segmentation fault on invalid code
In-Reply-To: <bug-11000-206@http.llvm.org/bugs/>
References: <bug-11000-206@http.llvm.org/bugs/>
Message-ID: <20111010191642.D8C7B2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-10 14:16:42 CDT ---
This no longer crashes with top-of-tree 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 llvm.org  Mon Oct 10 14:24:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 14:24:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10811] Terrible error on implicitly deleted default
 constructor in C++0x mode
In-Reply-To: <bug-10811-206@http.llvm.org/bugs/>
References: <bug-10811-206@http.llvm.org/bugs/>
Message-ID: <20111010192401.14A6E2A6C12D@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |DUPLICATE

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-10-10 14:24:00 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon Oct 10 14:27:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 14:27:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11097] NumQuoted wrong after
 RemoveDuplicates(SearchList, NumQuoted, Verbose); 
In-Reply-To: <bug-11097-206@http.llvm.org/bugs/>
References: <bug-11097-206@http.llvm.org/bugs/>
Message-ID: <20111010192709.0F8062A6C124@llvm.org>

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

Chad Rosier <chad.rosier at gmail.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 llvm.org  Mon Oct 10 15:08:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 15:08:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8950] Crypto++ validation test crashes in IDEA code
In-Reply-To: <bug-8950-206@http.llvm.org/bugs/>
References: <bug-8950-206@http.llvm.org/bugs/>
Message-ID: <20111010200840.0885C2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.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 llvm.org  Mon Oct 10 15:41:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 15:41:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11091] incorrect warning for printf and printing
 std::runtime_error::what()
In-Reply-To: <bug-11091-206@http.llvm.org/bugs/>
References: <bug-11091-206@http.llvm.org/bugs/>
Message-ID: <20111010204127.A2F9B2A6C12F@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-10 15:41:27 CDT ---
This is by design: -Wformat-security doesn't do any flow analysis.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 15:42:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 15:42:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11068] lib/tablegen/TGPreprocessor.h requires NULL,
 but does not include a header for it
In-Reply-To: <bug-11068-206@http.llvm.org/bugs/>
References: <bug-11068-206@http.llvm.org/bugs/>
Message-ID: <20111010204259.D35822A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-10 15:42:59 CDT ---
TGPreprocessor.h is now gone.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 16:17:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 16:17:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11108] New: Code-Completion crashes
Message-ID: <bug-11108-206@http.llvm.org/bugs/>

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

           Summary: Code-Completion crashes
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthias_kleine at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


On clang-revision 14520, code completion can be crashed by running the attached
test. The problem seems to be caused by Sema::IsSimplyAccessible trying to
build an AccessTarget for a NamedDecl that is not a CXXRecordDecl.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 17:30:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 17:30:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11102] [AVX] x86 isel hits assert (begin() + idx <
 end()), function operator[], file [...]/ADT/SmallVector.h, line 154
In-Reply-To: <bug-11102-206@http.llvm.org/bugs/>
References: <bug-11102-206@http.llvm.org/bugs/>
Message-ID: <20111010223008.ABF752A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-10 17:30:08 CDT ---
r141585.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 17:55:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 17:55:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11107] r141365 causes infinite loop in
 consumer-lame and 464_h264ref
In-Reply-To: <bug-11107-206@http.llvm.org/bugs/>
References: <bug-11107-206@http.llvm.org/bugs/>
Message-ID: <20111010225522.E93242A6C12C@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #8 from Bill Wendling <wendling at apple.com> 2011-10-10 17:55:22 CDT ---
Fixed:

Sending        lib/Target/ARM/Thumb2ITBlockPass.cpp
Transmitting file data .
Committed revision 141589.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 17:59:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 17:59:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11100] conditional noexcept using constexpr
 template function produces an error when it should compile
In-Reply-To: <bug-11100-206@http.llvm.org/bugs/>
References: <bug-11100-206@http.llvm.org/bugs/>
Message-ID: <20111010225930.9D90A2A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |LATER

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-10 17:59:30 CDT ---
This is just an instance of "we don't support evaluating constexpr functions
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 llvm.org  Mon Oct 10 18:44:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 18:44:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11108] Code-Completion crashes
In-Reply-To: <bug-11108-206@http.llvm.org/bugs/>
References: <bug-11108-206@http.llvm.org/bugs/>
Message-ID: <20111010234447.421802A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-10 18:44:46 CDT ---
Fixed in Clang r141600.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 18:56:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 18:56:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10685] "pragma comment" followed by a comment while
 clang is started with -C
In-Reply-To: <bug-10685-206@http.llvm.org/bugs/>
References: <bug-10685-206@http.llvm.org/bugs/>
Message-ID: <20111010235618.4C5162A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-10 18:56:18 CDT ---
This appears to be working with trunk.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 19:13:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 19:13:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8836] Microsoft's offsetof not recognized as
 constant expression
In-Reply-To: <bug-8836-206@http.llvm.org/bugs/>
References: <bug-8836-206@http.llvm.org/bugs/>
Message-ID: <20111011001337.3E2582A6C12E@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-10 19:13:36 CDT ---
r141604.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 19:25:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 19:25:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8818] -E produces code that clang can't parse
In-Reply-To: <bug-8818-206@http.llvm.org/bugs/>
References: <bug-8818-206@http.llvm.org/bugs/>
Message-ID: <20111011002513.A26DC2A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-10 19:25:13 CDT ---
If you try to compile a preprocessed file for the wrong architecture, yes,
you'll run into issues... and we're not about to mess with the output format of
-E for a marginally useful feature.

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

From bugzilla-daemon at llvm.org  Mon Oct 10 19:27:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 19:27:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9548] "no known conversion from 'vector<string>' to
 'vector<string>'"
In-Reply-To: <bug-9548-206@http.llvm.org/bugs/>
References: <bug-9548-206@http.llvm.org/bugs/>
Message-ID: <20111011002701.60BAA2A6C12F@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-10 19:27:00 CDT ---
Trunk gives:

<stdin>:15:3: error: no matching function for call to 'f'
  f(v);
  ^
<stdin>:7:6: note: candidate function not viable: no known conversion from
'vector<string>'
      (aka 'std::vector<std::basic_string>') to 'vector<string>' (aka
'std::vector<versa_string>') for 1st argument;
void f(vector<string> v);
     ^
1 error 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 llvm.org  Mon Oct 10 23:36:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 10 Oct 2011 23:36:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11053] Checker should warn against any use of
	vfork()
In-Reply-To: <bug-11053-206@http.llvm.org/bugs/>
References: <bug-11053-206@http.llvm.org/bugs/>
Message-ID: <20111011043645.D9D5E312800A@llvm.org>

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

Anna Zaks <ganna at apple.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 llvm.org  Tue Oct 11 01:11:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 01:11:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10565] scalarrepl assertion failure: Invalid cast!
In-Reply-To: <bug-10565-206@http.llvm.org/bugs/>
References: <bug-10565-206@http.llvm.org/bugs/>
Message-ID: <20111011061108.A2D19312800A@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #3 from Cameron Zwarich <zwarich at apple.com> 2011-10-11 01:11:08 CDT ---
Fixed in r141646, with a test in r141647.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 01:34:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 01:34:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11103] SetVector documentation needs to be updated
 WRT default data structures used.
In-Reply-To: <bug-11103-206@http.llvm.org/bugs/>
References: <bug-11103-206@http.llvm.org/bugs/>
Message-ID: <20111011063415.F13792A6C12D@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #2 from Bill Wendling <wendling at apple.com> 2011-10-11 01:34:15 CDT ---
Applied with some formatting changes here: r141648

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 llvm.org  Tue Oct 11 01:42:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 01:42:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10636] list of linkage types
In-Reply-To: <bug-10636-206@http.llvm.org/bugs/>
References: <bug-10636-206@http.llvm.org/bugs/>
Message-ID: <20111011064201.393832A6C12D@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #1 from Bill Wendling <wendling at apple.com> 2011-10-11 01:42:00 CDT ---
It actually was, but was called "externally visible". That was inconsistent
with the other linkage types.

Changed here: r141649

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

From bugzilla-daemon at llvm.org  Tue Oct 11 01:44:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 01:44:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9935] insertvalue syntax in Language Reference
 Manual does not show it being vararg.
In-Reply-To: <bug-9935-206@http.llvm.org/bugs/>
References: <bug-9935-206@http.llvm.org/bugs/>
Message-ID: <20111011064429.913D82A6C124@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |wendling at apple.com
         Resolution|                            |FIXED

--- Comment #3 from Bill Wendling <wendling at apple.com> 2011-10-11 01:44:29 CDT ---
This looks like it got fixed along the 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 llvm.org  Tue Oct 11 02:04:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 02:04:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9413] out-of-date code in WritingAnLLVMPass
In-Reply-To: <bug-9413-206@http.llvm.org/bugs/>
References: <bug-9413-206@http.llvm.org/bugs/>
Message-ID: <20111011070416.51D7C2A6C12D@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #2 from Bill Wendling <wendling at apple.com> 2011-10-11 02:04:15 CDT ---
Updated to the Hello World example in ToT:  r141655.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 02:06:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 02:06:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2712] Hello,
	World in `Writing an LLVM Pass' does not work
In-Reply-To: <bug-2712-206@http.llvm.org/bugs/>
References: <bug-2712-206@http.llvm.org/bugs/>
Message-ID: <20111011070659.A006A2A6C124@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |wendling at apple.com
         Resolution|                            |WORKSFORME

--- Comment #3 from Bill Wendling <wendling at apple.com> 2011-10-11 02:06:58 CDT ---
This has been updated and should work now.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 02:25:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 02:25:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8214] llvm release_28 branch fails to build
 documentation with latest doxygen (1.7.1)
In-Reply-To: <bug-8214-206@http.llvm.org/bugs/>
References: <bug-8214-206@http.llvm.org/bugs/>
Message-ID: <20111011072551.64BBE2A6C12C@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |wendling at apple.com
         Resolution|                            |WONTFIX

--- Comment #2 from Bill Wendling <wendling at apple.com> 2011-10-11 02:25:50 CDT ---
Patch applied: r141657

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

From bugzilla-daemon at llvm.org  Tue Oct 11 02:25:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 02:25:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8214] llvm release_28 branch fails to build
 documentation with latest doxygen (1.7.1)
In-Reply-To: <bug-8214-206@http.llvm.org/bugs/>
References: <bug-8214-206@http.llvm.org/bugs/>
Message-ID: <20111011072558.04E1C2A6C12C@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WONTFIX                     |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 llvm.org  Tue Oct 11 04:26:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 04:26:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11109] New: Clang crashes when trying to compile
 incomplete source file
Message-ID: <bug-11109-206@http.llvm.org/bugs/>

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

           Summary: Clang crashes when trying to compile incomplete source
                    file
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthias_kleine at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7438)
 --> (http://llvm.org/bugs/attachment.cgi?id=7438)
Source file that causes the crash

Clang crashes when trying to compile the attached source 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 llvm.org  Tue Oct 11 07:39:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 07:39:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9583] Support building against libstd++-4.6
In-Reply-To: <bug-9583-206@http.llvm.org/bugs/>
References: <bug-9583-206@http.llvm.org/bugs/>
Message-ID: <20111011123932.92127312800A@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

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

--- Comment #2 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-10-11 07:39:32 CDT ---
I have been able to build firefox with libstdc++ 4.6 in gnu++0x mode, so I
think we can close this and open individual bugs if any remaining issue is
found.

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 llvm.org  Tue Oct 11 10:24:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 10:24:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9924] Programs compiled with clang++ cause GDB to
	segfault
In-Reply-To: <bug-9924-206@http.llvm.org/bugs/>
References: <bug-9924-206@http.llvm.org/bugs/>
Message-ID: <20111011152440.294BF2A6C12E@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

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

--- Comment #7 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-10-11 10:24:39 CDT ---
> Has our exceptions rewrite addressed the problem?

Yes, the reduced testcases are working :-)

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

From bugzilla-daemon at llvm.org  Tue Oct 11 10:25:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 10:25:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11110] New: clang segfaults on valid code from boost
Message-ID: <bug-11110-206@http.llvm.org/bugs/>

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

           Summary: clang segfaults on valid code from boost
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang ToT segfaults on the following code, extracted from a boost unique_ptr
test (when compiling with libc++)


struct unique_ptr
{
template <int> int operator=( int );
int operator=(unique_ptr );
};

const int i = __has_nothrow_assign(unique_ptr);

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

From bugzilla-daemon at llvm.org  Tue Oct 11 10:31:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 10:31:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11058] dragon segfault with gcc 4.6 trunk and
 -fexpensive-optimizations and enabled gcc optimizer
In-Reply-To: <bug-11058-206@http.llvm.org/bugs/>
References: <bug-11058-206@http.llvm.org/bugs/>
Message-ID: <20111011153109.A51032A6C12D@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-10-11 10:31:09 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111010/129617.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 llvm.org  Tue Oct 11 11:00:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 11:00:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11111] New: clang 2.9 and svn miscompiles MPFR 3.1.0
Message-ID: <bug-11111-206@http.llvm.org/bugs/>

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

           Summary: clang 2.9 and svn miscompiles MPFR 3.1.0
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The clang compilers from both the 2.9 release and current svn both miscompile
the MPFR 3.1.0 library. The resulting binaries on x86_64-apple-darwin11 fail
their testsuite with...

[tversion] GMP: header 5.0.2, library 5.0.2
[tversion] MPFR tuning parameters from src/x86_64/core2/mparam.h
PASS: tversion
PASS: tinternals
PASS: tinits
PASS: tisqrt
PASS: tsgn
PASS: tcheck
PASS: tisnan
Error: emin >= emax
FAIL: texceptions
../../tests/tset_exp.c:44: MPFR assertion failed: ret == 0 &&
(__builtin_constant_p (2) && (mpfr_ulong) (2) == 0 ? (mpfr_sgn) (x) :
mpfr_cmp_ui_2exp ((x), (2), 0)) == 0
/bin/sh: line 1: 68248 Abort trap: 6           MPFR_QUIET=1 ${dir}$tst
FAIL: tset_exp
/bin/sh: line 1: 68267 Segmentation fault: 11  MPFR_QUIET=1 ${dir}$tst
FAIL: tset
PASS: mpf_compat
Error in conversion to/from mpz
expected 17, got 0.0000000000000000e+00
FAIL: mpfr_compat
../../src/set_str_raw.c:54: MPFR assertion failed: res == 0
/bin/sh: line 1: 68319 Abort trap: 6           MPFR_QUIET=1 ${dir}$tst
FAIL: reuse
/bin/sh: line 1: 68337 Segmentation fault: 11  MPFR_QUIET=1 ${dir}$tst
FAIL: tabs

This problem doesn't exist in Apple's Xcode 4.1.1 release but apparently exists
in Xcode 4.2 now.
These failures are suppressed if MPFR is passed --disable-thread-safe.
Comparing the config.log generated against Apple's clang from Xcode 4.1 and
llvm.org's 2.9 clang, I see...

-checking for TLS support... no
+checking for TLS support... yes

suggesting that the TLS support in clang svn is buggy.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 11:37:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 11:37:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10565] scalarrepl assertion failure: Invalid cast!
In-Reply-To: <bug-10565-206@http.llvm.org/bugs/>
References: <bug-10565-206@http.llvm.org/bugs/>
Message-ID: <20111011163739.2143E312800A@llvm.org>

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

Matt Pharr <matt at pharr.org> changed:

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

--- Comment #4 from Matt Pharr <matt at pharr.org> 2011-10-11 11:37:38 CDT ---
With top-of-tree, I'm still seeing that assertion hit with the test case from
11106:

define void @"f_v___REFUf[]"() nounwind {
allocas:
  %a156286 = alloca [4 x <4 x float>], align 16
  br i1 undef, label %cif_done, label %for_test158.preheader

for_test158.preheader:                            ; preds = %allocas
  %a156286305 = bitcast [4 x <4 x float>]* %a156286 to i8*
  call void @llvm.memset.p0i8.i64(i8* %a156286305, i8 -1, i64 64, i32 16, i1
false)
  unreachable

cif_done:                                         ; preds = %allocas
  ret void
}

declare void @llvm.memset.p0i8.i64(i8* nocapture, i8, i64, i32, 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 llvm.org  Tue Oct 11 12:07:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 12:07:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9548] "no known conversion from 'vector<string>' to
 'vector<string>'"
In-Reply-To: <bug-9548-206@http.llvm.org/bugs/>
References: <bug-9548-206@http.llvm.org/bugs/>
Message-ID: <20111011170700.8526A312800A@llvm.org>

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

Matt Beaumont-Gay <matthewbg at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #2 from Matt Beaumont-Gay <matthewbg at google.com> 2011-10-11 12:07:00 CDT ---
For the record, this was fixed by a patch from rtrieu in r134904.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 13:02:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 13:02:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11112] New: llvm-ld corrupts debugging information
 of local variables.
Message-ID: <bug-11112-206@http.llvm.org/bugs/>

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

           Summary: llvm-ld corrupts debugging information of local
                    variables.
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Linker
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: haohui.mai at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

I'm using clang+llvm to compile my project, and I found out llvm-ld somehow
made the debugging information of local variables unavailable in debugger.

Here is a simple C program:

extern int putchar(int c);

int main() {
        for (int debug_var = 0; debug_var < 26; ++debug_var)
                putchar(debug_var + 'A');
        return 0;
}

I compiled it with clang in mainline:

$clang -march=armv7 -mfloat-abi=soft -ccc-host-triple arm-elf -Wall -Werror
-emit-llvm t.c -c -o t.bc -O0 -g

The debugging information for "debug_var" is available after llc:

$llc -disable-fp-elim -march=arm -mcpu=cortex-a9 -mattr=+vfp3,+neon
-float-abi=soft -O=0 t.bc -o -|grep "debug_var" -a3
    .long    .Ltmp0                  @ DW_AT_low_pc
    .long    .Ltmp1                  @ DW_AT_high_pc
    .byte    4                       @ Abbrev [4] 0x7f:0x14 DW_TAG_variable
    .ascii     "debug_var"            @ DW_AT_name
    .byte    0
    .byte    1                       @ DW_AT_decl_file
    .byte    4                       @ DW_AT_decl_line

However, if I pass the bitcode file through llvm-ld, the information is no
longer available:

$llvm-ld -disable-opt -link-as-library t.bc -o -|/opt/local/ibos/bin/llc
-disable-fp-elim -march=arm -mcpu=cortex-a9 -mattr=+vfp3,+neon -float-abi=soft
-O=0|grep "debug_var" -a3

The diff of bitcode before and after llvm-ld shows slight difference:

$ diff -u before-llvm-ld.ll after-llvm-ld.ll
...
-  call void @llvm.dbg.declare(metadata !{i32* %debug_var}, metadata !12), !dbg
!15
-  store i32 0, i32* %debug_var, align 4, !dbg !16
-  br label %for.cond, !dbg !16
+  call void @llvm.dbg.declare(metadata !12, metadata !13), !dbg !16
+  store i32 0, i32* %debug_var, align 4, !dbg !17
+  br label %for.cond, !dbg !17
...
-!12 = metadata !{i32 721152, metadata !13, metadata !"debug_var", metadata !6,
i32 4, metadata !9, i32 0, i32 0} ; [ DW_TAG_auto_variable ]
-!13 = metadata !{i32 720907, metadata !14, i32 4, i32 2, metadata !6, i32 1} ;
[ DW_TAG_lexical_block ]
+!12 = metadata !{null}
+!13 = metadata !{i32 721152, metadata !14, metadata !"debug_var", metadata !6,
i32 4, metadata !9, i32 0, i32 0} ; [ DW_TAG_auto_variable ]

You can see the first argument of @llvm.dbg.declare is nullified for some
reason.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 13:21:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 13:21:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10565] scalarrepl assertion failure: Invalid cast!
In-Reply-To: <bug-10565-206@http.llvm.org/bugs/>
References: <bug-10565-206@http.llvm.org/bugs/>
Message-ID: <20111011182135.A2831312800A@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #5 from Cameron Zwarich <zwarich at apple.com> 2011-10-11 13:21:34 CDT ---
Then that bug isn't a dupe. I'll still take a look 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 llvm.org  Tue Oct 11 13:22:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 13:22:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11106] SROA pass hit assert with simple program
In-Reply-To: <bug-11106-206@http.llvm.org/bugs/>
References: <bug-11106-206@http.llvm.org/bugs/>
Message-ID: <20111011182220.842C02A6C124@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |zwarich at apple.com
         Resolution|DUPLICATE                   |
         AssignedTo|unassignedbugs at nondot.org   |zwarich at apple.com

--- Comment #2 from Cameron Zwarich <zwarich at apple.com> 2011-10-11 13:22:20 CDT ---
Matt, the test case you pasted doesn't work out of the box. Can you give me a
full test case, including the target string?

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

From bugzilla-daemon at llvm.org  Tue Oct 11 14:54:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 14:54:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10160] Problem with autoconf's mmap check
In-Reply-To: <bug-10160-206@http.llvm.org/bugs/>
References: <bug-10160-206@http.llvm.org/bugs/>
Message-ID: <20111011195452.E92123128018@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

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

--- Comment #17 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-10-11 14:54:52 CDT ---


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

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

From bugzilla-daemon at llvm.org  Tue Oct 11 15:35:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 15:35:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11113] New: vector::iterator operator+ fails to
	compile
Message-ID: <bug-11113-206@http.llvm.org/bugs/>

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

           Summary: vector::iterator operator+ fails to compile
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7442)
 --> (http://llvm.org/bugs/attachment.cgi?id=7442)
patch to iterator

The following code doesn't compile with ToT libc++

#include <vector>

int main(void)
{
  std::vector<int> v;
  1 + v.begin();
}

The problem is that the definitions of operator+ have got out of sync. This
patch fixes it:

Note this is syncing up with the actual definition on line 1296.

This fixes a problem in boost (and probably other things too).

I couldn't see any other similar issues at a quick glance.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 16:28:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 16:28:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11113] vector::iterator operator+ fails to compile
In-Reply-To: <bug-11113-206@http.llvm.org/bugs/>
References: <bug-11113-206@http.llvm.org/bugs/>
Message-ID: <20111011212853.746162A6C12C@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2011-10-11 16:28:53 CDT ---
Committed revision 141714.

Thanks Chris.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 16:29:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 16:29:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11106] SROA pass hit assert with simple program
In-Reply-To: <bug-11106-206@http.llvm.org/bugs/>
References: <bug-11106-206@http.llvm.org/bugs/>
Message-ID: <20111011212957.E0BC52A6C124@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #4 from Cameron Zwarich <zwarich at apple.com> 2011-10-11 16:29:57 CDT ---
Fixed in r141713.

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

From bugzilla-daemon at llvm.org  Tue Oct 11 17:10:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 17:10:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11114] New: Clang buffer overflow checks fail to
 detect simple case.
Message-ID: <bug-11114-206@http.llvm.org/bugs/>

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

           Summary: Clang buffer overflow checks fail to detect simple
                    case.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: william.metcalf at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Tested with version of clang/scan-build in trunk. The static analyzer fails to
detect a simple buffer overflow in program found here.  I guess more of an FYI
than anything else..

http://www.debian-administration.org/articles/408

clang -v
clang version 3.0 (trunk 141707)
Target: x86_64-unknown-linux-gnu
Thread model: posix

scan-build gcc -o buggy buggy.c
scan-build: 'clang' executable not found in '/opt/clang/scan-build/bin'.
scan-build: Using 'clang' from path: /opt/clang/bin/clang
scan-build: Removing directory '/tmp/scan-build-2011-10-11-1' because it
contains no reports.

clang --analyze -Xclang -analyzer-checker -Xclang security.experimental buggy.c
clang --analyze -Xclang -analyzer-checker -Xclang
security.experimental.ArrayBound buggy.c
clang --analyze -Xclang -analyzer-checker -Xclang
security.experimental.ArrayBound2 buggy.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 llvm.org  Tue Oct 11 17:10:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 11 Oct 2011 17:10:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11062] inline keyword ignored for function called
	strlcpy
In-Reply-To: <bug-11062-206@http.llvm.org/bugs/>
References: <bug-11062-206@http.llvm.org/bugs/>
Message-ID: <20111011221003.71A203128018@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-11 17:10:03 CDT ---
r141723.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 04:12:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 04:12:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11115] New: Many warnings when building with
	-Weffc++
Message-ID: <bug-11115-206@http.llvm.org/bugs/>

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

           Summary: Many warnings when building with -Weffc++
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


The g++ option -Weffc++ turns on warnings derived from the guidelines in the
?Effective C++? and ?More Effective C++? books.  Building LLVM with this option
produces a gazillion warnings.  I have no idea if these indicate real problems
or not.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 04:15:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 04:15:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11116] New: Weak aliases are not supported on MacOS
	X
Message-ID: <bug-11116-206@http.llvm.org/bugs/>

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

           Summary: Weak aliases are not supported on MacOS X
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: llvm at martin-whitaker.me.uk
                CC: llvmbugs at cs.uiuc.edu


When compiling the following (simplified) code fragment:

  int get_value(int *value)
  {
    return *value;
  }

  int get_value_alias(int *high) __attribute__ ((weak, alias ("get_value")));

for MacOS X, clang reports the following error:

  % clang -ccc-host-triple i386-apple-darwin -c -o bug.o bug.c
  bug.c:6:54: error: only weak aliases are supported on darwin
  int get_value_alias(int *high) __attribute__ ((weak, alias ("get_value"))); 

It would appear that clang does not support weak aliases on MacOS X (I asked on
the cfe-dev list, but nobody suggested a solution). If it is not possible to
support weak aliases for this target, I suggest changing the error message to
indicate this fact.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 06:29:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 06:29:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11117] New: Link error when using libc++'s std::bind
Message-ID: <bug-11117-206@http.llvm.org/bugs/>

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

           Summary: Link error when using libc++'s std::bind
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following program compiles, but fails to link with clang r141771 and libc++
r141771:

#include <functional>

using namespace std::placeholders;

struct Foo {
    void doItB()
    {
    }
};

template <typename F>
static void bar(F f)
{
    Foo    foo;
    f(foo);
}

int main(int, char**)
{
    bar(std::bind(&Foo::doItB, _1));
}


This results in:

$ ~/LLVM/build/Release+Asserts/bin/clang++ -std=c++0x -stdlib=libc++ -v
clang.cpp 
clang version 3.0 (trunk 141771)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
[...]
Undefined symbols:
 
"__ZNSt3__18__invokeIRM3FooFvvERS1_EEDTdsclsr3std3__1E7forwardIT0_Efp0_Efp_EOT_OS6_",
referenced from:
      __ZL3barINSt3__16__bindIM3FooFvvEJRNS0_12placeholders4__phILi1EEEEEEEvT_
in clang-whLOw0.o
ld: symbol(s) not found
clang: error: linker command failed with exit code 1 (use -v to see invocation)


This error does not occur with clang r140992 (which is why I'm filing this as a
clang bug).

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

From bugzilla-daemon at llvm.org  Wed Oct 12 06:48:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 06:48:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11118] New: regex does not handle (?=^|[\n\r])
	correctly
Message-ID: <bug-11118-206@http.llvm.org/bugs/>

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

           Summary: regex does not handle (?=^|[\n\r]) correctly
           Product: libc++
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu


The following program, intended to search for #include directives in a string,
compiles using clang r141771 and libc++ r141771, but does not produce the
intended result:

#include <regex>

static const std::regex   
INCLUDE_REGEXP(R"((?=^|[\n\r])#include\s*<([^>]+)>)");

static const std::string    s = 
    "#include <A.glsl>\n"
    "attribute vec3    vertexTex0;\n"
    "//#include <DontFindThisOne.glsl>\n"
    "uniform mat4    mvp;\n"
    "#include <shaders/include/B.glsl>";


int main(int, char**)
{
    std::sregex_iterator        it(s.begin(), s.end(), INCLUDE_REGEXP);
    std::sregex_iterator const    end;
    if (it == end)
    {
        std::printf("Not found\n");
    }
    else
    {
        while (it != end)
        {
            std::printf("Found '%s [%s]'\n", it->str().c_str(),
it->str(1).c_str());
            ++it;
        }
    }
}


When run, this produces:

Found '#include <A.glsl> [A.glsl]'
Found '#include <DontFindThisOne.glsl> [DontFindThisOne.glsl]'
Found '#include <shaders/include/B.glsl> [shaders/include/B.glsl]'

"DontFindThisOne" is found, even though there are "//" between the beginning of
the line and the "#include".

Turning the predicate into a normal capture (full regexp:
"(^|[\n\r])#include\s*<([^>]+)>") results in the desired result (modulo one
additional capture and thus slightly incorrect output).

Removing the begin-of-line atom (full regexp: "(?=[\n\r])#include\s*<([^>]+)>")
results in no finding at all, even though the last line of <s> should be found.

C.f. the thread starting at
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-March/014221.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 llvm.org  Wed Oct 12 08:52:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 08:52:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11119] New: -fstack-protector-all isn't working
	correctly
Message-ID: <bug-11119-206@http.llvm.org/bugs/>

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

           Summary: -fstack-protector-all isn't working correctly
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


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

Compile the attached test program for x86-64 with -fstack-protector-all and run
it like "./a.out 10". This is expected to fail due to the buffer overflow, but
it will only start crashing with 14, when compiled with clang. Tested on Linux
and NetBSD.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 10:10:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 10:10:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11120] New: Assert in
 llvm\tools\clang\lib\Lex\PreprocessingRecord.cpp
Message-ID: <bug-11120-206@http.llvm.org/bugs/>

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

           Summary: Assert in
                    llvm\tools\clang\lib\Lex\PreprocessingRecord.cpp
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hans.walheim at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Running
> c-index-test -test-load-source all test\file.cpp -std=c++0x -I .\test

with file.cpp containing:

#define FILE_HEADER_NAME "fileheader.h"

#if defined(FILE_HEADER_NAME)
#include FILE_HEADER_NAME
#endif

gives following assert:
Assertion failed: (PreprocessedEntities.empty() ||
!SourceMgr.isBeforeInTranslationUnit(Entity->getSourceRange().getBegin(),
PreprocessedEntities.back()->getSourceRange().getBegin())) && "Adding a
preprocessed entity that is before the previous one in TU", file
..\..\..\..\..llvm\tools\clang\lib\Lex\PreprocessingRecord.cpp, line 176

I guess the checkin that introduced this was
Author: akirtzidis
Date: Mon Sep 19 15:40:25 2011
New Revision: 140058

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

From bugzilla-daemon at llvm.org  Wed Oct 12 10:41:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 10:41:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11110] clang segfaults on valid code from boost
In-Reply-To: <bug-11110-206@http.llvm.org/bugs/>
References: <bug-11110-206@http.llvm.org/bugs/>
Message-ID: <20111012154100.E946F2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-12 10:41:00 CDT ---
Fixed in Clang r141777.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 11:59:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 11:59:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11121] New: configure fails if clang is installed
Message-ID: <bug-11121-206@http.llvm.org/bugs/>

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

           Summary: configure fails if clang is installed
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: autoconf
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: contact at philipashmore.com
                CC: llvmbugs at cs.uiuc.edu


I tried to build the doxygen documentation, but that option isn't available for
cmake builds, the one I use to build the debian llvm package.

So I created an am-release directory in the same directory as llvm and did
   $ ../llvm/configure --enable-doxygen

It fails one of the tests "compiler cannot create executables" as the linker
cannot find crt1.o

Uninstalling the llvm debian package causes configure to succeed.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 12:37:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 12:37:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11120] Assert in
 llvm\tools\clang\lib\Lex\PreprocessingRecord.cpp
In-Reply-To: <bug-11120-206@http.llvm.org/bugs/>
References: <bug-11120-206@http.llvm.org/bugs/>
Message-ID: <20111012173735.212202A6C12C@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #2 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-10-12 12:37:34 CDT ---
Fixed in r141788, thanks for the report!

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

From bugzilla-daemon at llvm.org  Wed Oct 12 12:53:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 12:53:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11119] -fstack-protector-all isn't working correctly
In-Reply-To: <bug-11119-206@http.llvm.org/bugs/>
References: <bug-11119-206@http.llvm.org/bugs/>
Message-ID: <20111012175330.479E42A6C12C@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #1 from Bill Wendling <wendling at apple.com> 2011-10-12 12:53:29 CDT ---
This is because the array is an array of 'i32' and not an array of 'i8'. At the
moment, we support stack protectors only on arrays of characters.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 12:54:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 12:54:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10892] Polyhedron 2005 fatigue.f90 benchmark
 miscompiled with -msse4 -ffast-math -funroll-loops -O3
 -fplugin-arg-dragonegg-enable-gcc-optzns
In-Reply-To: <bug-10892-206@http.llvm.org/bugs/>
References: <bug-10892-206@http.llvm.org/bugs/>
Message-ID: <20111012175431.AF7FC2A6C124@llvm.org>

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

Jack Howarth <howarth at nitro.med.uc.edu> changed:

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

--- Comment #22 from Jack Howarth <howarth at nitro.med.uc.edu> 2011-10-12 12:54:30 CDT ---
Fixed in current svn.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 13:17:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 13:17:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11122] New: doxygen CREATE_SUBDIRS should be YES
Message-ID: <bug-11122-206@http.llvm.org/bugs/>

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

           Summary: doxygen CREATE_SUBDIRS should be YES
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Doxygen
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: contact at philipashmore.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7446)
 --> (http://llvm.org/bugs/attachment.cgi?id=7446)
CREATE_SUBDIRS=YES for llvm

Steps to reproduce
1. mkdir am-build
2. cd am-build
3. ../llvm/configure --enable-doxygen
4. cd docs
5. doxygen doxygen.cfg

Result: doxygen generates 25613 files under docs/doxygen/html.

1. (from am-build) cd tools/clang/docs
2. doxygen doxygen.cfg
Result: doxygen generates 17137 files under tools/clang/docs/doxygen/html.

The LLVM doxygen run should also generate a TAG file that's reused by the clang
doxygen run.

Then there's integration with the libstdc++.tag if you have one.

Take a look at http://sourceforge.net/projects/v3c/
It creates doxygen documentation tag chains for related projects with automake.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 15:36:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 15:36:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11117] Link error when using libc++'s std::bind
In-Reply-To: <bug-11117-206@http.llvm.org/bugs/>
References: <bug-11117-206@http.llvm.org/bugs/>
Message-ID: <20111012203603.C94832A6C12C@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-10-12 15:36:03 CDT ---
Fixed in Clang r141809.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 16:03:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 16:03:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11123] New: Add John Regehr and Peng Li's Integer
 Overflow Checker (IOC) to CLang
Message-ID: <bug-11123-206@http.llvm.org/bugs/>

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

           Summary: Add John Regehr and Peng Li's Integer Overflow Checker
                    (IOC) to CLang
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: noloader at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hi All,

John Regehr and Peng Li have a nice extension for Clang called Integer Overflow
Checker (IOC). The IOC page is http://embed.cs.utah.edu/ioc/.

Its a handy utility, and pinpointed the cause of a self test failure in the
Crypto++ library.

Please consider adding IOC to Clang.

Jeffrey Walton
Baltimore, MD, US

(My apologies for mis-classification of the component if its not frontend)

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

From bugzilla-daemon at llvm.org  Wed Oct 12 16:21:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 16:21:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11112] llvm-ld corrupts debugging information of
 local variables.
In-Reply-To: <bug-11112-206@http.llvm.org/bugs/>
References: <bug-11112-206@http.llvm.org/bugs/>
Message-ID: <20111012212107.55E91312800A@llvm.org>

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

Devang Patel <dpatel at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dpatel at apple.com
         Resolution|                            |DUPLICATE

--- Comment #4 from Devang Patel <dpatel at apple.com> 2011-10-12 16:21:07 CDT ---


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

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

From bugzilla-daemon at llvm.org  Wed Oct 12 16:25:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 16:25:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10252] -strong-phi-elim crash
In-Reply-To: <bug-10252-206@http.llvm.org/bugs/>
References: <bug-10252-206@http.llvm.org/bugs/>
Message-ID: <20111012212543.D9DB82A6C12D@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|unassignedbugs at nondot.org   |zwarich at apple.com

--- Comment #3 from Cameron Zwarich <zwarich at apple.com> 2011-10-12 16:25:43 CDT ---
Fixed in r141812.

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

From bugzilla-daemon at llvm.org  Wed Oct 12 18:38:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 12 Oct 2011 18:38:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11078] error: ran out of registers during register
	allocation
In-Reply-To: <bug-11078-206@http.llvm.org/bugs/>
References: <bug-11078-206@http.llvm.org/bugs/>
Message-ID: <20111012233818.DCC4D2A6C12D@llvm.org>

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

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

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

--- Comment #3 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-10-12 18:38:17 CDT ---
r141836

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

From bugzilla-daemon at llvm.org  Thu Oct 13 01:11:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 01:11:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11109] Clang crashes when trying to compile
 incomplete source file
In-Reply-To: <bug-11109-206@http.llvm.org/bugs/>
References: <bug-11109-206@http.llvm.org/bugs/>
Message-ID: <20111013061100.240A22A6C12D@llvm.org>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #3 from David Blaikie <dblaikie at gmail.com> 2011-10-13 01:10:59 CDT ---
Fixed by r141852.

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

From bugzilla-daemon at llvm.org  Thu Oct 13 07:39:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 07:39:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10332] Compiler crashes when parser overflows the
 stack, instead of providing a nice report
In-Reply-To: <bug-10332-206@http.llvm.org/bugs/>
References: <bug-10332-206@http.llvm.org/bugs/>
Message-ID: <20111013123952.A0659312800A@llvm.org>

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

Aaron Ballman <aaron at aaronballman.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |aaron at aaronballman.com
         Resolution|                            |FIXED

--- Comment #1 from Aaron Ballman <aaron at aaronballman.com> 2011-10-13 07:39:52 CDT ---
Fixed in r141782

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

From bugzilla-daemon at llvm.org  Thu Oct 13 12:35:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 12:35:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11090] Extremely slow compilation + high memory
 usage in "Loop Strength Reduction"
In-Reply-To: <bug-11090-206@http.llvm.org/bugs/>
References: <bug-11090-206@http.llvm.org/bugs/>
Message-ID: <20111013173511.37CBC2A6C12C@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #6 from Andrew Trick <atrick at apple.com> 2011-10-13 12:35:10 CDT ---
Fixed in r141868 and r141870.

SCEV had problems with expression DAGs in two places, postinc transformation
and posting expansion of expressions, that would lead to exponential recursion.

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

From bugzilla-daemon at llvm.org  Thu Oct 13 12:57:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 12:57:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11119] -fstack-protector-all isn't working correctly
In-Reply-To: <bug-11119-206@http.llvm.org/bugs/>
References: <bug-11119-206@http.llvm.org/bugs/>
Message-ID: <20111013175736.960D0312800A@llvm.org>

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

J?rg Sonnenberger <joerg at NetBSD.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         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 llvm.org  Thu Oct 13 13:03:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 13:03:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11090] Extremely slow compilation + high memory
 usage in "Loop Strength Reduction"
In-Reply-To: <bug-11090-206@http.llvm.org/bugs/>
References: <bug-11090-206@http.llvm.org/bugs/>
Message-ID: <20111013180321.710F62A6C12C@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #7 from Andrew Trick <atrick at apple.com> 2011-10-13 13:03:20 CDT ---
I reverted r141870 because it exposed some other problem that seems to cause
data corruption. So this bug is only partially fixed. I still need to reproduce
the problem reported by a buildbot.

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

From bugzilla-daemon at llvm.org  Thu Oct 13 13:30:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 13:30:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11124] New: Virtual inheritance segfault
Message-ID: <bug-11124-206@http.llvm.org/bugs/>

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

           Summary: Virtual inheritance segfault
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tomboshoven at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following C++ code gives a segfault when executed.

struct Base
{
    const int text;
    Base():text(1) {}
    Base(int aText)
    : text(aText) {}
};
struct SubA : public virtual Base
{
protected:
  int x;
public:
  SubA(int aX)
  : x(aX) {}
};
class SubB : public virtual Base
{};
struct Diamond : public SubA, public SubB
{
    Diamond(int text)
    : Base(text), SubA(5), SubB() {}

    void printText()
    {
        if(text != 2)
          __builtin_abort();
        if(x!=5)
          __builtin_abort();
    }
};

int main(int, char**)
{
    Diamond x(2);
    x.printText();
}

Incidentally, the same problem existed as a regression in gcc:
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=50618

Compilation was done on clang version 2.9 (tags/RELEASE_29/final).
Target: x86_64-unknown-linux-gnu.
Default Arch Linux distribution.

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

From bugzilla-daemon at llvm.org  Thu Oct 13 15:10:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 15:10:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11125] New: [AVX] incorrect code generated with AVX
 target (vxorps related?)
Message-ID: <bug-11125-206@http.llvm.org/bugs/>

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

           Summary: [AVX] incorrect code generated with AVX target (vxorps
                    related?)
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


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

Attached is a test case that shows an AVX code generation regression. 
Unfortunately the test case is reasonably complex; attempts to simplify it down
further have led to the bug not manifesting itself any more.  (The good news is
that I have identified the checkin that introduced the regression--see below.)

To run the test case, do:

% llc -mattr=+avx noise.ll -filetype=obj -o noise.o && clang -m64 -O3 -Wall -o
noise noise.cpp noise.o && ./noise 
Mismatch on result 1: got 0.131250, should be 0.081250
Mismatch on result 2: got -0.075000, should be -0.175000
Mismatch on result 3: got -0.218750, should be -0.368750
Mismatch on result 4: got -0.300000, should be -0.500000
Mismatch on result 5: got -0.318750, should be -0.568750
Mismatch on result 6: got -0.275000, should be -0.575000
Mismatch on result 7: got -0.168750, should be -0.518750
%

If one compiles using the default SSE target, it runs without error:
% llc noise.ll -filetype=obj -o noise.o && clang -m64 -O3 -Wall -o noise
noise.cpp noise.o && ./noise
%             

I have done archeology in recent changes, and this checkin seems to have
introduced the regression.  I've also attached the assembly generated by the
version of LLVM immediately before that checkin (good.s) and the assembly
generated with that checkin (bad.s).  The changes are relatively minimal,
mostly some new vxorps instructions.  (I presume that these are part of the
problem, but I haven't worked through that yet.)

Author: Jakob Stoklund Olesen <stoklund at 2pi.dk>
Date:   Thu Sep 29 05:10:54 2011 +0000

    Expand the x86 V_SET0* pseudos right after register allocation.

    This also makes it possible to reduce the number of pseudo instructions
    and get rid of the encoding information.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 140776
91177308-0d34-0410-b5e6-96231b3b80d8

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

From bugzilla-daemon at llvm.org  Thu Oct 13 15:21:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 15:21:08 -0500 (CDT)
Subject: [LLVMbugs] =?utf-8?b?W0J1ZyAxMTEyNl0gTmV3OiBNYWMgT1MgWCAoTGlvbik6?=
 =?utf-8?q?__=E2=80=9Cerror_=3A_unknown_type_name_=27BOOL=27=3B_did_you_me?=
 =?utf-8?b?YW4gJ0JPT0wnPyDigJ0gd2hlbiB1c2luZyBMTFZNIDMgLjAgKFhjb2RlIDQu?=
 =?utf-8?q?2=29?=
Message-ID: <bug-11126-206@http.llvm.org/bugs/>

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

           Summary: Mac OS X (Lion): ?error: unknown type name 'BOOL'; did
                    you mean 'BOOL'?? when using LLVM 3.0 (Xcode 4.2)
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: noloader at gmail.com
                CC: llvmbugs at cs.uiuc.edu


My apologies if this is not a front end issue.

When compiling the following code fragment using LLVM 3.0 on Lion with Intel
x64 hardware (MacBook):

// AppConstants.h
typedef enum { ThreadPriorityLow = NSOperationQueuePriorityLow,
ThreadPriorityNormal = NSOperationQueuePriorityNormal, ThreadPriorityHigh =
NSOperationQueuePriorityHigh, ThreadPriorityDefault = ThreadPriorityNormal }
ThreadPriority;

static inline BOOL IsValidThreadPriority(ThreadPriority priority)
{
    return priority == ThreadPriorityLow || priority == ThreadPriorityNormal ||
priority == ThreadPriorityHigh;
}

The compiler spits out an error:

    ?error: unknown type name 'BOOL'; did you mean 'BOOL'??

I can right click on the offending BOOL in Xcode, and Xcode will happily jump
to the definition in <objc/objc.h>. Though I'm using precompiled headers (so
the declaration should be available), including <objc/objc.h> directly did
*not* resolve the issue.

Switching to GCC 4.2 resolved the issue.

Also filed as an Apple Bug: Radar 10278815. Reported to LLVM since Apple can
move very slowly at times. My apologies if Apple has pushed it upstream
already.

$ uname -a
Darwin newton 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 20:54:00 PDT
2011; root:xnu-1699.24.8~1/RELEASE_X86_64 x86_64

$ clang --version
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
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 llvm.org  Thu Oct 13 15:56:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 15:56:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9798] Linker flags fail / can't find crtbegin.o
In-Reply-To: <bug-9798-206@http.llvm.org/bugs/>
References: <bug-9798-206@http.llvm.org/bugs/>
Message-ID: <20111013205629.F30AE3128018@llvm.org>

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

julian <mayer.julian at googlemail.com> changed:

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

--- Comment #17 from julian <mayer.julian at googlemail.com> 2011-10-13 15:56:29 CDT ---
gone with trunk on ubuntu 11.04 too. 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 llvm.org  Thu Oct 13 15:57:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 15:57:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11127] New: Failed assertion: `Result.isInvalid()
 && "C++ binary operator overloading is missing candidates!"'
Message-ID: <bug-11127-206@http.llvm.org/bugs/>

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

           Summary: Failed assertion: `Result.isInvalid() && "C++ binary
                    operator overloading is missing candidates!"'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7452)
 --> (http://llvm.org/bugs/attachment.cgi?id=7452)
delta-reduced input (not valid code but manages to make clang++ crash)

Based on attachment 6824 from bug #10270 (different error, different
reduction):

% clang++ -c input.ii
[..]

clang:
/var/tmp/paludis/build/dev-lang-llvm-scm/work/llvm-scm/tools/clang/lib/Sema/../../include/clang/AST/DeclTemplate.h:1477:
void
clang::ClassTemplateSpecializationDecl::setInstantiationOf(clang::ClassTemplatePartialSpecializationDecl
*, clang::TemplateArgumentList *): Assertion
`!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already set
to a class template partial specialization!"' failed.
0  libLLVM-3.0svn.so 0x00007ffff73fc64f
1  libLLVM-3.0svn.so 0x00007ffff73fcb69
2  libpthread.so.0   0x00007ffff6490f70
3  libc.so.6         0x00007ffff57ae5c5 gsignal + 53
4  libc.so.6         0x00007ffff57af8c5 abort + 389
5  libc.so.6         0x00007ffff57a7235 __assert_fail + 245
6  clang             0x00000000009c2628
clang::ClassTemplateSpecializationDecl::setInstantiationOf(clang::ClassTemplatePartialSpecializationDecl*,
clang::TemplateArgumentList*) + 152
7  clang             0x00000000009afd16
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 1718
8  clang             0x00000000009e720d
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&, std::pair<clang::SourceLocation,
clang::PartialDiagnostic>) + 221
9  clang             0x00000000009e758d
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&) + 77
10 clang             0x00000000007bdc85
clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&,
clang::DeclContext*) + 309
11 clang             0x000000000081831f
clang::Sema::getTypeName(clang::IdentifierInfo&, clang::SourceLocation,
clang::Scope*, clang::CXXScopeSpec*, bool, bool,
clang::OpaquePtr<clang::QualType>, bool, clang::IdentifierInfo**) + 383
12 clang             0x0000000000774f11
clang::Parser::TryAnnotateTypeOrScopeToken(bool, bool) + 1457
13 clang             0x000000000076d8a3
clang::Parser::isCXXDeclarationSpecifier() + 67
14 clang             0x000000000076e6cf
clang::Parser::isCXXTypeId(clang::Parser::TentativeCXXTypeIdContext, bool&) +
31
15 clang             0x0000000000795e4e
clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool,
bool, clang::OpaquePtr<clang::QualType>&, clang::SourceLocation&) + 1134

16 clang             0x0000000000793bd3
clang::Parser::ParseCastExpression(bool, bool, bool&, bool) + 195
17 clang             0x00000000007921a9
clang::Parser::ParseAssignmentExpression() + 121
18 clang             0x000000000077fb3d
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 941
19 clang             0x000000000077f356
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1366
20 clang             0x0000000000772f74
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 676
21 clang             0x000000000077314a
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 394
22 clang             0x000000000077248c
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 2700
23 clang             0x0000000000789295
clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&,
clang::ParsedAttributes&, clang::Parser::BalancedDelimiterTracker&) + 181
24 clang             0x0000000000788de9 clang::Parser::ParseNamespace(unsigned
int, clang::SourceLocation&, clang::SourceLocation) + 3337
25 clang             0x000000000077cbec
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 508
26 clang             0x0000000000772077
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1655
27 clang             0x000000000077198e
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 254
28 clang             0x0000000000758f1e clang::ParseAST(clang::Sema&, bool) +
318
29 clang             0x000000000066de91 clang::CodeGenAction::ExecuteAction() +
769
30 clang             0x0000000000567167
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 983
31 clang             0x0000000000551cd0
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2848
32 clang             0x000000000054992b cc1_main(char const**, char const**,
char const*, void*) + 5787
33 clang             0x000000000054e29a main + 634
34 libc.so.6         0x00007ffff579ac7d __libc_start_main + 253
35 clang             0x00000000005481c9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name input.ii -mrelocation-model
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21.1 -momit-leaf-frame-pointer
-coverage-file input.o -resource-dir /usr/bin/../lib/clang/3.0
-fdeprecated-macro -ferror-limit 19 -fmessage-length 118 -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
input.o -x c++-cpp-output input.ii 
1.      input.ii:29:133: current parser token 'run'
2.      input.ii:5:1: parsing namespace 'internal'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.
%

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

From bugzilla-daemon at llvm.org  Thu Oct 13 18:24:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 18:24:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11128] New: Failed assertion: `Result.isInvalid()
 && "C++ binary operator overloading is missing candidates!"'
Message-ID: <bug-11128-206@http.llvm.org/bugs/>

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

           Summary: Failed assertion: `Result.isInvalid() && "C++ binary
                    operator overloading is missing candidates!"'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7454)
 --> (http://llvm.org/bugs/attachment.cgi?id=7454)
delta-reduced input (not valid code but manages to make clang++ crash)

Yet another reduction of attachment 6824 from bug #10270 (for another reduction
with another error, see e.g. bug #11127).


% clang++ -c input.ii 
[..]
clang: SemaOverload.cpp:9038: ExprResult
clang::Sema::CreateOverloadedBinOp(clang::SourceLocation, unsigned int, const
clang::UnresolvedSetImpl &, clang::Expr *, clang::Expr *): Assertion
`Result.isInvalid() && "C++ binary operator overloading is missing
candidates!"' failed.

0  libLLVM-3.0svn.so 0x00007ffff73fc64f
1  libLLVM-3.0svn.so 0x00007ffff73fcb69
2  libpthread.so.0   0x00007ffff6490f70
3  libc.so.6         0x00007ffff57ae5c5 gsignal + 53
4  libc.so.6         0x00007ffff57af8c5 abort + 389
5  libc.so.6         0x00007ffff57a7235 __assert_fail + 245
6  clang             0x00000000009378cd
7  clang             0x00000000008b42b2 clang::Sema::BuildBinOp(clang::Scope*,
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) +
450
8  clang             0x00000000009b26d3
9  clang             0x00000000009b1e46
10 clang             0x00000000009c0735
11 clang             0x00000000009b0e09
12 clang             0x00000000009b03a7 clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 87
13 clang             0x00000000009cc370
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 2176
14 clang             0x00000000009cd372
clang::Sema::PerformPendingInstantiations(bool) + 466
15 clang             0x00000000007b2189
clang::Sema::ActOnEndOfTranslationUnit() + 393
16 clang             0x0000000000771900
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 112
17 clang             0x0000000000758f1e clang::ParseAST(clang::Sema&, bool) +
318
18 clang             0x000000000066de91 clang::CodeGenAction::ExecuteAction() +
769
19 clang             0x0000000000567167
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 983
20 clang             0x0000000000551cd0
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2848
21 clang             0x000000000054992b cc1_main(char const**, char const**,
char const*, void*) + 5787
22 clang             0x000000000054e29a main + 634
23 libc.so.6         0x00007ffff579ac7d __libc_start_main + 253
24 clang             0x00000000005481c9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name input.ii -mrelocation-model
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21.1 -momit-leaf-frame-pointer
-coverage-file input.o -resource-dir /usr/bin/../lib/clang/3.0
-fdeprecated-macro -ferror-limit 19 -fmessage-length 118 -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
input.o -x c++-cpp-output input.ii 
1.      <eof> parser at end of file
2.      input.ii:25:6: instantiating function definition
'apply_rotation_in_the_plane'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.
%

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

From bugzilla-daemon at llvm.org  Thu Oct 13 19:40:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 19:40:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11125] [AVX] incorrect code generated with AVX
 target (vxorps related?)
In-Reply-To: <bug-11125-206@http.llvm.org/bugs/>
References: <bug-11125-206@http.llvm.org/bugs/>
Message-ID: <20111014004057.98A6A2A6C12C@llvm.org>

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

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

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

--- Comment #5 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-10-13 19:40:57 CDT ---
r141923 and r141924. Matt, 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 llvm.org  Thu Oct 13 21:30:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 13 Oct 2011 21:30:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11124] Virtual inheritance segfault
In-Reply-To: <bug-11124-206@http.llvm.org/bugs/>
References: <bug-11124-206@http.llvm.org/bugs/>
Message-ID: <20111014023009.2AC6A3128018@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-13 21:30:08 CDT ---
r141933.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 09:13:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 09:13:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11129] New: llc 2.9 is failing failing to compile
 following example for ARM Cortex-A9
Message-ID: <bug-11129-206@http.llvm.org/bugs/>

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

           Summary: llc 2.9 is failing failing to compile following
                    example for ARM Cortex-A9
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: babslachem at gmail.com
                CC: llvmbugs at cs.uiuc.edu


On following code:

define arm_aapcscc void @test_convert_ushort2_ulong2(<2 x i64>* nocapture %src,
<2 x i16>* nocapture %dest) nounwind {
L.entry:
  %0 = load <2 x i64>* %src, align 16
  %1 = trunc <2 x i64> %0 to <2 x i16>
  store <2 x i16> %1, <2 x i16>* %dest, align 4
  ret void
}

When compiling for arm cortex-a9 target using following command line:

llc -march=arm -mcpu=cortex-a9 conv.ll -s conv.s 

I've got following internal error message:

LLVM ERROR: Cannot select: 0x812dab0: v4i16 = extract_subvector 0x812de68,
0x812d780 [ID=10]
  0x812de68: v4i32 = bit_convert 0x812d9a0 [ID=9]
    0x812d9a0: v2f64,ch = load 0x811a404, 0x812d5e8, 0x812d808<LD16[%src]>
[ID=8]
      0x812d5e8: i32,ch = CopyFromReg 0x811a404, 0x812d560 [ORD=1] [ID=6]
        0x812d560: i32 = Register %vreg0 [ORD=1] [ID=1]
      0x812d808: i32 = undef [ORD=1] [ID=3]
  0x812d780: i32 = Constant<0> [ID=4]

If I remove -mcpu=cortex-a9 from command line, it compiles successfully

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

From bugzilla-daemon at llvm.org  Fri Oct 14 12:08:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 12:08:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11131] New: decltype crash breaks is_constructable
Message-ID: <bug-11131-206@http.llvm.org/bugs/>

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

           Summary: decltype crash breaks is_constructable
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following test case is reduced libc++'s is_constructable. The case causes
clang to segfault. This bug arose in a boost test case. It's hard to track down
exactly what is going on in boost, because (as always) there are many levels of
code, and clang is crashing.


struct S;

struct __any
{
    __any(...);
};

template<typename T>
T& D();

template <class _Tp, class ..._Args>
decltype(D<_Args>()...)
X(_Tp&&, _Args&& ...);

template <class ..._Args>
int
X(__any, _Args&& ...);

decltype(X(D<S>(), D<int>())) j;

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

From bugzilla-daemon at llvm.org  Fri Oct 14 12:27:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 12:27:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10814] MachineSink creates zombie defines
In-Reply-To: <bug-10814-206@http.llvm.org/bugs/>
References: <bug-10814-206@http.llvm.org/bugs/>
Message-ID: <20111014172708.B3F542A6C124@llvm.org>

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

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

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

--- Comment #6 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-10-14 12:27:08 CDT ---
Jan's patch applied in r141960.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 12:33:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 12:33:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11132] New: Missing %EFLAGS<kill> flag on CMOV
 causes suboptimal code
Message-ID: <bug-11132-206@http.llvm.org/bugs/>

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

           Summary: Missing %EFLAGS<kill> flag on CMOV causes suboptimal
                    code
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


The unit test test/CodeGen/X86/uint64-to-float.ll generates this code:


# After Instruction Selection:
# Machine code for function test:
Function Live Ins: %RDI in %vreg0
Function Live Outs: %XMM0

BB#0: derived from LLVM BB %entry
    Live Ins: %RDI
    %vreg0<def> = COPY %RDI; GR64:%vreg0
    %vreg1<def> = SHR64r1 %vreg0, %EFLAGS<imp-def,dead>; GR64:%vreg1,%vreg0
    %vreg2<def> = AND64ri8 %vreg0, 1, %EFLAGS<imp-def,dead>; GR64:%vreg2,%vreg0
    %vreg3<def> = OR64rr %vreg2, %vreg1<kill>, %EFLAGS<imp-def,dead>;
GR64:%vreg3,%vreg2,%vreg1
    %vreg4<def> = CVTSI2SS64rr %vreg3<kill>; FR32:%vreg4 GR64:%vreg3
    %vreg5<def> = ADDSSrr %vreg4, %vreg4; FR32:%vreg5,%vreg4,%vreg4
    %vreg6<def> = CVTSI2SS64rr %vreg0; FR32:%vreg6 GR64:%vreg0
    TEST64rr %vreg0, %vreg0, %EFLAGS<imp-def>; GR64:%vreg0
    %vreg7<def> = CMOV_FR32 %vreg6<kill>, %vreg5<kill>, 15, %EFLAGS<imp-use>;
FR32:%vreg7,%vreg6,%vreg5
    %XMM0<def> = COPY %vreg7; FR32:%vreg7
    RET

Note the missing %EFLAGS<kill> flag on CMOV_FR32. When this instruction is
expanded by the custom inserter pass, the new blocks have %EFLAGS live-in
because of the missing kill flag:

# After Pre-RegAlloc TailDuplicate:
# Machine code for function test:
Function Live Ins: %RDI in %vreg0
Function Live Outs: %XMM0

BB#0: derived from LLVM BB %entry
    Live Ins: %RDI
    %vreg0<def> = COPY %RDI; GR64:%vreg0
    %vreg1<def> = SHR64r1 %vreg0, %EFLAGS<imp-def,dead>; GR64:%vreg1,%vreg0
    %vreg2<def> = AND64ri8 %vreg0, 1, %EFLAGS<imp-def,dead>; GR64:%vreg2,%vreg0
    %vreg3<def> = OR64rr %vreg2, %vreg1<kill>, %EFLAGS<imp-def,dead>;
GR64:%vreg3,%vreg2,%vreg1
    %vreg4<def> = CVTSI2SS64rr %vreg3<kill>; FR32:%vreg4 GR64:%vreg3
    %vreg5<def> = ADDSSrr %vreg4, %vreg4; FR32:%vreg5,%vreg4,%vreg4
    %vreg6<def> = CVTSI2SS64rr %vreg0; FR32:%vreg6 GR64:%vreg0
    TEST64rr %vreg0, %vreg0, %EFLAGS<imp-def>; GR64:%vreg0
    JS_4 <BB#2>, %EFLAGS<imp-use>
    Successors according to CFG: BB#1 BB#2

BB#1: derived from LLVM BB %entry
    Live Ins: %EFLAGS
    Predecessors according to CFG: BB#0
    Successors according to CFG: BB#2

BB#2: derived from LLVM BB %entry
    Live Ins: %EFLAGS
    Predecessors according to CFG: BB#0 BB#1
    %vreg7<def> = PHI %vreg6, <BB#1>, %vreg5, <BB#0>; FR32:%vreg7,%vreg6,%vreg5
    %XMM0<def> = COPY %vreg7; FR32:%vreg7
    RET

MachineSinking can split the critical edge, but it cannot sink the instructions
clobbering %EFLAGS into a block with %EFLAGS live-in.

All of this happens before the proper liveness analysis in LiveVariables, but
InstrEmitter could add a kill flag to %EFLAGS.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 12:55:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 12:55:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11133] New: llvm-gcc self host .o mismatch after
 enable-iv-rewrite=false
Message-ID: <bug-11133-206@http.llvm.org/bugs/>

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

           Summary: llvm-gcc self host .o mismatch after
                    enable-iv-rewrite=false
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: atrick at apple.com
        ReportedBy: atrick at apple.com
                CC: llvmbugs at cs.uiuc.edu


http://lab.llvm.org:8011/builders/llvm-x86_64-linux-checks

The self-host reports stage 2/3 differences in pt.o and gcc.o, and occasionally
others.

I have only been able to reproduce with a parallel make of the entire tree but
not as an individual build step.

I manually inspected the .o file differences and don't see any functional
difference.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 15:09:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 15:09:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11134] New: Failed assertion: `(Previous.empty() ||
 Previous.isOverloadedResult() || Previous.isSingleResult()) && "Lookup of
 member name should be either overloaded, single or null"'
Message-ID: <bug-11134-206@http.llvm.org/bugs/>

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

           Summary: Failed assertion: `(Previous.empty() ||
                    Previous.isOverloadedResult() ||
                    Previous.isSingleResult()) && "Lookup of member name
                    should be either overloaded, single or null"'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7456)
 --> (http://llvm.org/bugs/attachment.cgi?id=7456)
delta-reduced input (not valid code but manages to make clang++ crash)

% clang++ -c -x c++ output-minimal
[..]
clang: SemaDecl.cpp:8384: clang::FieldDecl
*clang::Sema::HandleField(clang::Scope *, clang::RecordDecl *,
clang::SourceLocation, clang::Declarator &, clang::Expr *, bool,
clang::AccessSpecifier): Assertion `(Previous.empty() ||
Previous.isOverloadedResult() || Previous.isSingleResult()) && "Lookup of
member name should be either overloaded, single or null"' failed.
0  libLLVM-3.0svn.so 0x00007ffff73fc64f
1  libLLVM-3.0svn.so 0x00007ffff73fcb69
2  libpthread.so.0   0x00007ffff6490f70
3  libc.so.6         0x00007ffff57ae5c5 gsignal + 53
4  libc.so.6         0x00007ffff57af8c5 abort + 389
5  libc.so.6         0x00007ffff57a7235 __assert_fail + 245
6  clang             0x000000000083aa81 clang::Sema::HandleField(clang::Scope*,
clang::RecordDecl*, clang::SourceLocation, clang::Declarator&, clang::Expr*,
bool, clang::AccessSpecifier) + 1249
7  clang             0x000000000085d608
clang::Sema::ActOnCXXMemberDeclarator(clang::Scope*, clang::AccessSpecifier,
clang::Declarator&, clang::ASTMultiPtr<clang::TemplateParameterList*>,
clang::Expr*, clang::VirtSpecifiers const&, bool) + 1656
8  clang             0x000000000078f652
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 4930
9  clang             0x000000000078d659
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 2249
10 clang             0x000000000078c79c
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 4796
11 clang             0x000000000077db2c
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 2844
12 clang             0x000000000078eaf2
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 2018
13 clang             0x0000000000769b4d
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier, clang::AttributeList*) + 77
14 clang             0x0000000000769934
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 740
15 clang             0x000000000076957f
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 351
16 clang             0x000000000078e8ba
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 1450
17 clang             0x000000000078d659
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 2249
18 clang             0x000000000078c79c
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 4796
19 clang             0x000000000077db2c
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 2844
20 clang             0x0000000000769dc8
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier, clang::AttributeList*) + 712
21 clang             0x0000000000769934
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 740
22 clang             0x000000000076957f
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 351
23 clang             0x000000000077cb70
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 384
24 clang             0x0000000000772077
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1655
25 clang             0x0000000000789295
clang::Parser::ParseInnerNamespace(std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, std::vector<clang::IdentifierInfo*,
std::allocator<clang::IdentifierInfo*> >&, std::vector<clang::SourceLocation,
std::allocator<clang::SourceLocation> >&, unsigned int, clang::SourceLocation&,
clang::ParsedAttributes&, clang::Parser::BalancedDelimiterTracker&) + 181
26 clang             0x0000000000788de9 clang::Parser::ParseNamespace(unsigned
int, clang::SourceLocation&, clang::SourceLocation) + 3337
27 clang             0x000000000077cbec
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 508
28 clang             0x0000000000772077
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1655
29 clang             0x000000000077198e
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 254
30 clang             0x0000000000758f1e clang::ParseAST(clang::Sema&, bool) +
318
31 clang             0x000000000066de91 clang::CodeGenAction::ExecuteAction() +
769
32 clang             0x0000000000567167
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 983
33 clang             0x0000000000551cd0
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2848
34 clang             0x000000000054992b cc1_main(char const**, char const**,
char const*, void*) + 5787
35 clang             0x000000000054e29a main + 634
36 libc.so.6         0x00007ffff579ac7d __libc_start_main + 253
37 clang             0x00000000005481c9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name output-minimal
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1
-momit-leaf-frame-pointer -coverage-file output-minimal.o -resource-dir
/usr/bin/../lib/clang/3.0 -fmodule-cache-path /var/tmp/clang-module-cache
-fdeprecated-macro -ferror-limit 19 -fmessage-length 238 -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
output-minimal.o -x c++ output-minimal 
1.      output-minimal:15:11: current parser token '='
2.      output-minimal:1:1: parsing namespace 'internal'
3.      output-minimal:9:1: parsing struct/union/class body 'dense_xpr_base'
4.      output-minimal:11:28: parsing struct/union/class body 'MapBase'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/output-minimal-3baqMR.ii
%

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

From bugzilla-daemon at llvm.org  Fri Oct 14 15:34:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 15:34:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11131] decltype crash breaks is_constructable
In-Reply-To: <bug-11131-206@http.llvm.org/bugs/>
References: <bug-11131-206@http.llvm.org/bugs/>
Message-ID: <20111014203439.B6E222A6C12C@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-10-14 15:34:39 CDT ---
Fixed in Clang r141986.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 15:46:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 15:46:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11135] New: LLVMDebugVersion 11 is not supported
Message-ID: <bug-11135-206@http.llvm.org/bugs/>

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

           Summary: LLVMDebugVersion 11 is not supported
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwintorok at gmail.com
                CC: llvmbugs at cs.uiuc.edu


clang now generates debug version 11 because LLVM's Support/Dwarf.h defaults to
that.
However LLVM's include/Analysis/DebugInfo.h has various asserts that trigger
unless the debug info version is <= LLVMDebugVersion10.

For example opt -print-dbginfo would trip asserts on clang 3.0 -g generated
code.

include/Analysis/DebugInfo.h should be updated to deal with version 11 debug
info
for 3.0 release.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 17:21:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 17:21:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11136] New: Bad diagnostic when passing address of
 overloaded function to template
Message-ID: <bug-11136-206@http.llvm.org/bugs/>

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

           Summary: Bad diagnostic when passing address of overloaded
                    function to template
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jyasskin at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


C++11 adds an overload to vector::push_back, leading to code that breaks with
the following error. The bad error happens in C++98 mode too.


$ cat test.cc
struct vector {
  void push_back(const int&);
  void push_back(int*);
};

template<typename T, typename R>
void NewCallback(T*, R (T::*)());

template<typename T, typename R, typename A1>
void NewCallback(T*, R (T::*)(A1));

void foo() {
  vector v;
  NewCallback(&v, &vector::push_back);
}
$ clang -c test.cc
test.cc:14:3: error: no matching function for call to 'NewCallback'
  NewCallback(&v, &vector::push_back);
  ^~~~~~~~~~~
test.cc:7:6: note: candidate template ignored: couldn't infer template argument
'R'
void NewCallback(T*, R (T::*)());
     ^
test.cc:10:6: note: candidate template ignored: couldn't infer template
argument 'R'
void NewCallback(T*, R (T::*)(A1));
     ^
1 error generated.


----------

The error should refer to the function whose address doesn't have a unique
type, in addition to the template that failed to constrain the type.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 18:59:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 18:59:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11129] llc 2.9 is failing failing to compile
 following example for ARM Cortex-A9
In-Reply-To: <bug-11129-206@http.llvm.org/bugs/>
References: <bug-11129-206@http.llvm.org/bugs/>
Message-ID: <20111014235901.360F82A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 18:59:00 CDT ---
r142022.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 20:42:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 20:42:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11133] llvm-gcc self host .o mismatch after
 enable-iv-rewrite=false
In-Reply-To: <bug-11133-206@http.llvm.org/bugs/>
References: <bug-11133-206@http.llvm.org/bugs/>
Message-ID: <20111015014215.074EB312800A@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |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 llvm.org  Fri Oct 14 20:57:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 20:57:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8674] bewildering error message: cannot initialize
 a parameter of type 'struct stat *' with an rvalue of type 'struct stat *'
In-Reply-To: <bug-8674-206@http.llvm.org/bugs/>
References: <bug-8674-206@http.llvm.org/bugs/>
Message-ID: <20111015015727.6EC163128018@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 20:57:26 CDT ---
<stdin>:12:16: error: cannot initialize a parameter of type 'struct stat *'
(aka 'stat *') with an rvalue of type
      'struct stat *' (aka 'clang::stat *')
  ::baz("foo", &X);
               ^~
<stdin>:8:36: note: passing argument to parameter here
void baz(const char*, struct stat *);
                                   ^

Seems good enough 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 llvm.org  Fri Oct 14 21:00:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:00:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8543] Wrong cast kind for a const char* -> char*
	cast.
In-Reply-To: <bug-8543-206@http.llvm.org/bugs/>
References: <bug-8543-206@http.llvm.org/bugs/>
Message-ID: <20111015020009.7857C312800A@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #4 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:00:08 CDT ---
It looks like we get this right on trunk.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:01:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:01:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7410] Bad return type causes extra "abstract class"
	error
In-Reply-To: <bug-7410-206@http.llvm.org/bugs/>
References: <bug-7410-206@http.llvm.org/bugs/>
Message-ID: <20111015020150.D11422A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:01:50 CDT ---
This works correctly on trunk.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:10:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:10:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10582] ICE on int main(){int a=0?0:throw 0;}
In-Reply-To: <bug-10582-206@http.llvm.org/bugs/>
References: <bug-10582-206@http.llvm.org/bugs/>
Message-ID: <20111015021052.A790F2A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:10:51 CDT ---
r142047.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:22:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:22:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 1913] EH: Should turn invoke+resume into call
In-Reply-To: <bug-1913-206@http.llvm.org/bugs/>
References: <bug-1913-206@http.llvm.org/bugs/>
Message-ID: <20111015022250.533382A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:22:49 CDT ---
This works correctly now.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:23:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:23:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11137] New: Cleanup iteration over pointer-keyed
 maps and other nondeterminism
Message-ID: <bug-11137-206@http.llvm.org/bugs/>

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

           Summary: Cleanup iteration over pointer-keyed maps and other
                    nondeterminism
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: atrick at apple.com
                CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu


Based on an IRC discussion, it seems to be about time for someone to sweep over
the code removing obvious sources of nondeterminism like iterating over a map
with pointer keys.

I haven't looked carefully to see if any of these cases cause noticeable
nondeterminism. It may be worth cleaning them up just to be rigorous about this
sort of thing.

In SimplifyCFG:
  for (std::map<BasicBlock*, std::pair<unsigned, unsigned> >::iterator
             I = Popularity.begin(), E = Popularity.end(); I != E; ++I) {


In DeadStoreElimination:
  for (SmallPtrSet<Value*, 16>::iterator I = DeadStackObjects.begin(),

If anyone sees other suspects, please add them to this list if you don't intend
to fix it yourself!

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:26:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:26:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2084] Regalloc should deal with running out of
 registers more gracefully
In-Reply-To: <bug-2084-206@http.llvm.org/bugs/>
References: <bug-2084-206@http.llvm.org/bugs/>
Message-ID: <20111015022643.CDF67312800A@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:26:43 CDT ---
The situation here is improved a lot on trunk:

<stdin>:1:50: error: ran out of registers during register allocation
int a() {int a,b,c,d,di,si,bp,sp;; asm volatile ("%0 %1 %2 %3 %4 %5 %6 %7" :
                                                 ^

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:29:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:29:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2584] Suboptimal codegen for <2 x i32>
	extractelement
In-Reply-To: <bug-2584-206@http.llvm.org/bugs/>
References: <bug-2584-206@http.llvm.org/bugs/>
Message-ID: <20111015022944.D894A2A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #4 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:29:44 CDT ---
We're generating completely different code for the given testcase; please file
a new bug if there are still issues here.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:36:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:36:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2829] llvm.memory.barrier fails to produce
 write-before-read fence (mfence)
In-Reply-To: <bug-2829-206@http.llvm.org/bugs/>
References: <bug-2829-206@http.llvm.org/bugs/>
Message-ID: <20111015023639.03B6B3128018@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:36:37 CDT ---
llvm.memory.barrier is gone; the new fence instruction has reasonable
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 llvm.org  Fri Oct 14 21:38:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:38:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2897] Miscompilation when SSE2 is disabled
In-Reply-To: <bug-2897-206@http.llvm.org/bugs/>
References: <bug-2897-206@http.llvm.org/bugs/>
Message-ID: <20111015023821.30E90312800A@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #5 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:38:20 CDT ---
As far as I know, everything is working here... please reopen if there are
still issues.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:39:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:39:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3091] FunctionType::get should take an iterator pair
In-Reply-To: <bug-3091-206@http.llvm.org/bugs/>
References: <bug-3091-206@http.llvm.org/bugs/>
Message-ID: <20111015023932.23844312800A@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:39:31 CDT ---
FunctionType::get now takes an ArrayRef.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:41:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:41:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3346] Possible bug in linear scan allocator
In-Reply-To: <bug-3346-206@http.llvm.org/bugs/>
References: <bug-3346-206@http.llvm.org/bugs/>
Message-ID: <20111015024157.B56C63128018@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         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 llvm.org  Fri Oct 14 21:52:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:52:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5164] Warning when passing multiple -O* arguments
In-Reply-To: <bug-5164-206@http.llvm.org/bugs/>
References: <bug-5164-206@http.llvm.org/bugs/>
Message-ID: <20111015025215.8003F2A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:52:14 CDT ---
This works correctly now.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:53:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:53:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5366] Assertion in DAG combiner
In-Reply-To: <bug-5366-206@http.llvm.org/bugs/>
References: <bug-5366-206@http.llvm.org/bugs/>
Message-ID: <20111015025320.B87BB312800A@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #5 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:53:20 CDT ---
I'll assume this is working now, given the lack of response; please reopen if
there are still issues.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 21:58:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 21:58:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5950] instantiate C99 extern inline functions
In-Reply-To: <bug-5950-206@http.llvm.org/bugs/>
References: <bug-5950-206@http.llvm.org/bugs/>
Message-ID: <20111015025849.DF4DF3128018@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 21:58:49 CDT ---
This has been working correctly for a while now.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 22:00:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 22:00:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5964] improve diagnostics for failed overload
 resolution during initialization
In-Reply-To: <bug-5964-206@http.llvm.org/bugs/>
References: <bug-5964-206@http.llvm.org/bugs/>
Message-ID: <20111015030059.907063128018@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 22:00:59 CDT ---
On trunk:

<stdin>:9:16: error: address of overloaded function 'test' does not match
required type 'foo *()'
foo *(*X)() = &test<foo>;
               ^~~~~~~~~
<stdin>:7:7: note: candidate function
Pass *test() { return new PassName(); }
      ^
1 error generated.

This seems to be 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 llvm.org  Fri Oct 14 22:02:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 22:02:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6051] not marking const global 'constant' and not
	eliding it
In-Reply-To: <bug-6051-206@http.llvm.org/bugs/>
References: <bug-6051-206@http.llvm.org/bugs/>
Message-ID: <20111015030259.5DA723128018@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 22:02:58 CDT ---
This is working on trunk.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 22:20:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 22:20:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10378] ASTContext.cpp assertion failure
In-Reply-To: <bug-10378-206@http.llvm.org/bugs/>
References: <bug-10378-206@http.llvm.org/bugs/>
Message-ID: <20111015032031.B14BA312800A@llvm.org>

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

Ethan Tira-Thompson <ejtttje at gmail.com> changed:

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

--- Comment #3 from Ethan Tira-Thompson <ejtttje at gmail.com> 2011-10-14 22:20:29 CDT ---
I just tried again with rev 142047 and things look happy now, so I guess this
got fixed, 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 llvm.org  Fri Oct 14 22:21:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 22:21:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9615] Missing destructor call on objects returned
 from operator->
In-Reply-To: <bug-9615-206@http.llvm.org/bugs/>
References: <bug-9615-206@http.llvm.org/bugs/>
Message-ID: <20111015032112.848BB312800A@llvm.org>

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

Ethan Tira-Thompson <ejtttje at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |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 llvm.org  Fri Oct 14 22:21:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 22:21:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8307] Cannot compile mmx-builtins.c on MSVC
In-Reply-To: <bug-8307-206@http.llvm.org/bugs/>
References: <bug-8307-206@http.llvm.org/bugs/>
Message-ID: <20111015032113.9F6803128026@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 22:21:12 CDT ---
I believe this test is working now; please reopen if it isn'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 llvm.org  Fri Oct 14 22:22:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 22:22:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9615] Missing destructor call on objects returned
 from operator->
In-Reply-To: <bug-9615-206@http.llvm.org/bugs/>
References: <bug-9615-206@http.llvm.org/bugs/>
Message-ID: <20111015032258.300B72A6C12C@llvm.org>

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

Ethan Tira-Thompson <ejtttje at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|WORKSFORME                  |FIXED

--- Comment #5 from Ethan Tira-Thompson <ejtttje at gmail.com> 2011-10-14 22:22:57 CDT ---
(undoing accidental status change)

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

From bugzilla-daemon at llvm.org  Fri Oct 14 22:24:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 22:24:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8936] [MC x86] does not know xcryptecb instruction
In-Reply-To: <bug-8936-206@http.llvm.org/bugs/>
References: <bug-8936-206@http.llvm.org/bugs/>
Message-ID: <20111015032439.1B24A2A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-14 22:24:38 CDT ---
This was added in r128826.

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

From bugzilla-daemon at llvm.org  Fri Oct 14 22:56:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 14 Oct 2011 22:56:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11138] New: Regression(141895?): clang crashes when
 compiling webkit
Message-ID: <bug-11138-206@http.llvm.org/bugs/>

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

           Summary: Regression(141895?): clang crashes when compiling
                    webkit
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


I'm using clang r142009 from earlier today.

____Distributed-CompileC
../../../../../xcodebuild/WebCore.build/Release/webcore_platform.build/Objects-normal/i386/ShadowBlur.o
    cd
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp
    setenv DISTCC_HOSTS goma,cpp,lzo
    setenv INCLUDE_SERVER_DIR /tmp/distcc-pump.tZs2MN
    setenv INCLUDE_SERVER_PID 1370
    setenv INCLUDE_SERVER_PORT /tmp/distcc-pump.tZs2MN/socket
    setenv LANG en_US.US-ASCII
    setenv PATH
"/usr/bin:/Developer/usr/bin:/b/build/../depot_tools:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin"
    /b/build/goma/gomacc
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../third_party/llvm-build/Release+Asserts/bin/clang
-x c++ -arch i386 -fmessage-length=0 -pipe -Wno-trigraphs -fno-exceptions
-fno-rtti -O3 -Werror -Wnewline-eof -DCHROMIUM_BUILD -DENABLE_REMOTING=1
-DENABLE_P2P_APIS=1 -DENABLE_CONFIGURATION_POLICY -DENABLE_INPUT_SPEECH
-DDCHECK_ALWAYS_ON=1 -DENABLE_GPU=1 -DENABLE_EGLIMAGE=1
-DENABLE_REGISTER_PROTOCOL_HANDLER=1 "-DWEBCORE_NAVIGATOR_VENDOR=\"Google
Inc.\"" -DWEBCORE_NAVIGATOR_PLATFORM="MacIntel"
-DWebCascadeList=ChromiumWebCoreObjCWebCascadeList
-DScrollbarPrefsObserver=ChromiumWebCoreObjCScrollbarPrefsObserver
-DWebCoreRenderThemeNotificationObserver=ChromiumWebCoreObjCWebCoreRenderThemeNotificationObserver
-DWebFontCache=ChromiumWebCoreObjCWebFontCache
-DScrollAnimationHelperDelegate=ChromiumWebCoreObjCScrollAnimationHelperDelegate
-DScrollbarPainterControllerDelegate=ChromiumWebCoreObjCScrollbarPainterControllerDelegate
-DScrollbarPainterDelegate=ChromiumWebCoreObjCScrollbarPainterDelegate
-DScrollbarPartAnimation=ChromiumWebCoreObjCScrollbarPartAnimation
-DENABLE_3D_PLUGIN=1 -DENABLE_BLOB=1 -DENABLE_BLOB_SLICE=1
-DENABLE_CHANNEL_MESSAGING=1 -DENABLE_CLIENT_BASED_GEOLOCATION=1
-DENABLE_DASHBOARD_SUPPORT=0 -DENABLE_DATA_TRANSFER_ITEMS=1 -DENABLE_DETAILS=1
-DENABLE_DEVICE_ORIENTATION=1 -DENABLE_DIRECTORY_UPLOAD=1
-DENABLE_DOM_STORAGE=1 -DENABLE_DOWNLOAD_ATTRIBUTE=1 -DENABLE_FILE_SYSTEM=1
-DENABLE_FILTERS=1 -DENABLE_FULLSCREEN_API=1 -DENABLE_GAMEPAD=1
-DENABLE_GEOLOCATION=1 -DENABLE_GESTURE_EVENTS=1 -DENABLE_GESTURE_RECOGNIZER=1
-DENABLE_ICONDATABASE=0 -DENABLE_INDEXED_DATABASE=1 -DENABLE_INPUT_SPEECH=1
-DENABLE_INPUT_TYPE_COLOR=0 -DENABLE_INPUT_TYPE_DATE=0
-DENABLE_INPUT_TYPE_DATETIME=0 -DENABLE_INPUT_TYPE_DATETIMELOCAL=0
-DENABLE_INPUT_TYPE_MONTH=0 -DENABLE_INPUT_TYPE_TIME=0
-DENABLE_INPUT_TYPE_WEEK=0 -DENABLE_JAVASCRIPT_DEBUGGER=1
-DENABLE_JAVASCRIPT_I18N_API=1 -DENABLE_LINK_PREFETCH=1
-DENABLE_MEDIA_STATISTICS=1 -DENABLE_MEDIA_STREAM=1 -DENABLE_METER_TAG=1
-DENABLE_MHTML=1 -DENABLE_MICRODATA=0 -DENABLE_MUTATION_OBSERVERS=0
-DENABLE_NOTIFICATIONS=1 -DENABLE_ORIENTATION_EVENTS=0
-DENABLE_PAGE_VISIBILITY_API=1 -DENABLE_PROGRESS_TAG=1 -DENABLE_QUOTA=1
-DENABLE_REQUEST_ANIMATION_FRAME=1 -DENABLE_RUBY=1 -DENABLE_SANDBOX=1
-DENABLE_SHARED_WORKERS=1 -DENABLE_SKIA_GPU=0 -DENABLE_SKIA_TEXT=0
-DENABLE_SMOOTH_SCROLLING=1 -DENABLE_SQL_DATABASE=1 -DENABLE_SVG=0
-DENABLE_SVG_FONTS=0 -DENABLE_TOUCH_EVENTS=1 -DENABLE_TOUCH_ICON_LOADING=0
-DENABLE_V8_SCRIPT_DEBUG_SERVER=1 -DENABLE_VIDEO=1 -DENABLE_VIDEO_TRACK=1
-DENABLE_WEBGL=1 -DENABLE_WEB_SOCKETS=1 -DENABLE_WEB_TIMING=1
-DENABLE_WORKERS=1 -DENABLE_XHR_RESPONSE_BLOB=1 -DENABLE_XPATH=1
-DENABLE_XSLT=1 -DWTF_USE_LEVELDB=1 -DWTF_USE_BUILTIN_UTF8_CODEC=1
-DWTF_USE_OPENTYPE_SANITIZER=1 -DWTF_USE_WEBP=1
-DWTF_USE_WEBKIT_IMAGE_DECODERS=1 -DENABLE_WEB_AUDIO=1
-DWTF_USE_ACCELERATED_COMPOSITING=1 -DENABLE_3D_RENDERING=1
-DENABLE_RUBBER_BANDING=1 -DWTF_USE_SKIA_ON_MAC_CHROMIUM=0
-DBUILDING_CHROMIUM__=1 -DUSE_SYSTEM_MALLOC=1 -DWTF_USE_NEW_THEME=1
-DU_USING_ICU_NAMESPACE=0 -DU_STATIC_IMPLEMENTATION -DSK_BUILD_NO_IMAGE_ENCODE
-DGR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h" -DGR_AGGRESSIVE_SHADER_OPTS=1
-DCHROME_PNG_WRITE_SUPPORT -DPNG_USER_CONFIG -DLIBXML_STATIC -DLIBXSLT_STATIC
-D__STDC_FORMAT_MACROS -DNDEBUG -DNVALGRIND -DDYNAMIC_ANNOTATIONS_ENABLED=0
-isysroot /Developer/SDKs/MacOSX10.5.sdk -fvisibility=hidden
-fvisibility-inlines-hidden -fno-threadsafe-statics -mmacosx-version-min=10.5
-Wall -Wendif-labels -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wheader-hygiene -Wno-char-subscripts
-Wno-unused-function -Wno-unnamed-type-template-args -Wno-c++0x-compat
-fpch-preprocess
-F/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/Release
-F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks
-I/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/Release/include
-I../../../../icu/public/common -I../../../../icu/public/i18n
-I../../../WebKitLibraries -I../../../../../gpu -I../../../../..
-I/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/DerivedSources/Release
-I../platform/graphics/cocoa -I../platform/graphics/cg -I.. -I../..
-I../accessibility -I../accessibility/chromium -I../bindings
-I../bindings/generic -I../bindings/v8 -I../bindings/v8/custom
-I../bindings/v8/specialization -I../bridge -I../bridge/jni -I../bridge/jni/v8
-I../css -I../dom -I../dom/default -I../editing -I../fileapi -I../history
-I../html -I../html/canvas -I../html/parser -I../html/shadow -I../html/track
-I../inspector -I../loader -I../loader/appcache -I../loader/archive
-I../loader/archive/cf -I../loader/archive/mhtml -I../loader/cache
-I../loader/icon -I../mathml -I../notifications -I../p2p -I../page
-I../page/animation -I../page/chromium -I../platform -I../platform/animation
-I../platform/audio -I../platform/audio/chromium -I../platform/chromium
-I../platform/graphics -I../platform/graphics/chromium
-I../platform/graphics/filters -I../platform/graphics/filters/arm
-I../platform/graphics/gpu -I../platform/graphics/opentype
-I../platform/graphics/skia -I../platform/graphics/transforms
-I../platform/image-decoders -I../platform/image-decoders/bmp
-I../platform/image-decoders/gif -I../platform/image-decoders/ico
-I../platform/image-decoders/jpeg -I../platform/image-decoders/png
-I../platform/image-decoders/skia -I../platform/image-decoders/xbm
-I../platform/image-decoders/webp -I../platform/image-encoders/skia
-I../platform/leveldb -I../platform/mediastream -I../platform/mock
-I../platform/network -I../platform/network/chromium -I../platform/sql
-I../platform/text -I../platform/text/transcoder -I../plugins
-I../plugins/chromium -I../rendering -I../rendering/style -I../rendering/svg
-I../storage -I../storage/chromium -I../svg -I../svg/animation
-I../svg/graphics -I../svg/graphics/filters -I../svg/properties
-I../../ThirdParty/glu -I../webaudio -I../websockets -I../workers -I../xml
-I../xml/parser -I../platform/audio/mac -I../platform/cocoa
-I../platform/graphics/mac -I../platform/mac -I../platform/text/mac
-I../../../../../third_party/angle/include/GLSLANG
-I/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/DerivedSources/Release/webkit
-I/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/DerivedSources/Release/webkit/bindings
-I../../JavaScriptCore -I../../JavaScriptCore/wtf -I../../../../../skia/config
-I../../../../../third_party/skia/include/config
-I../../../../../third_party/skia/include/core
-I../../../../../third_party/skia/include/effects
-I../../../../../third_party/skia/include/pdf
-I../../../../../third_party/skia/include/gpu
-I../../../../../third_party/skia/include/ports -I../../../../../skia/ext
-I../../../../../third_party/skia/include/utils/mac -I../../../../iccjpeg
-I../../../../libwebp -I../../../../libpng -I../../../../zlib
-I../../../../libxml/mac/include -I../../../../libxml/src/include
-I../../../../libxslt -I../../../../npapi -I../../../../npapi/bindings
-I../../../../ots/include -I../../../../sqlite -I../../../../../v8/include
-I../../../../libjpeg_turbo -I../../../../leveldatabase/src/include
-I../../../../leveldatabase/src
-I/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/Release/webcore_platform.build/DerivedSources/i386
-I/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/Release/webcore_platform.build/DerivedSources
-fno-strict-aliasing -Xclang -load -Xclang
/b/build/slave/mac/build/src/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib
-Xclang -add-plugin -Xclang find-bad-constructs -include
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../WebCorePrefix.h
-c
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../platform/graphics/ShadowBlur.cpp
-o
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/Release/webcore_platform.build/Objects-normal/i386/ShadowBlur.o
Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"),
function cast, file
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/include/llvm/Support/Casting.h,
line 194.
0  clang             0x00000001013bac82 PrintStackTrace(void*) + 34
1  clang             0x00000001013bb269 SignalHandler(int) + 713
2  libSystem.B.dylib 0x00007fff8831f1ba _sigtramp + 26
3  clang             0x0000000101901a50 vtable for llvm::CallbackVH + 16
4  clang             0x000000010001d726 abort + 22
5  clang             0x000000010001d778 __assert_rtn + 56
6  clang             0x000000010124d8bd
llvm::SCEVExpander::isExpandedAddRecExprPHI(llvm::PHINode*, llvm::Instruction*,
llvm::Loop const*, llvm::Type*) + 569
7  clang             0x0000000101251e9e
llvm::SCEVExpander::getAddRecExprPHILiterally(llvm::SCEVAddRecExpr const*,
llvm::Loop const*, llvm::Type*, llvm::Type*) + 370
8  clang             0x0000000101252a82
llvm::SCEVExpander::expandAddRecExprLiterally(llvm::SCEVAddRecExpr const*) +
618
9  clang             0x0000000101250d2b
llvm::SCEVExpander::visitAddRecExpr(llvm::SCEVAddRecExpr const*) + 47
10 clang             0x0000000101255288 llvm::SCEVVisitor<llvm::SCEVExpander,
llvm::Value*>::visit(llvm::SCEV const*) + 382
11 clang             0x00000001012501be llvm::SCEVExpander::expand(llvm::SCEV
const*) + 554
12 clang             0x000000010124ff19
llvm::SCEVExpander::expandCodeFor(llvm::SCEV const*, llvm::Type*) + 37
13 clang             0x00000001010c9e97 (anonymous
namespace)::LSRInstance::Expand((anonymous namespace)::LSRFixup const&,
(anonymous namespace)::Formula const&, llvm::ilist_iterator<llvm::Instruction>,
llvm::SCEVExpander&, llvm::SmallVectorImpl<llvm::WeakVH>&) const + 1959
14 clang             0x00000001010d222f (anonymous
namespace)::LSRInstance::LSRInstance(llvm::TargetLowering const*, llvm::Loop*,
llvm::Pass*) + 30361
15 clang             0x00000001010d2c01 (anonymous
namespace)::LoopStrengthReduce::runOnLoop(llvm::Loop*, llvm::LPPassManager&) +
45
16 clang             0x0000000101202fb1
llvm::LPPassManager::runOnFunction(llvm::Function&) + 835
17 clang             0x0000000101321d5d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 341
18 clang             0x000000010131d37b
llvm::FPPassManager::runOnModule(llvm::Module&) + 61
19 clang             0x0000000101321a6a
llvm::MPPassManager::runOnModule(llvm::Module&) + 318
20 clang             0x0000000101322e71
llvm::PassManagerImpl::run(llvm::Module&) + 303
21 clang             0x0000000101322ef1 llvm::PassManager::run(llvm::Module&) +
13
22 clang             0x00000001001589d5
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 4661
23 clang             0x000000010022e7e2
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 278
24 clang             0x000000010006a8c4
clang::MultiplexConsumer::HandleTranslationUnit(clang::ASTContext&) + 66
25 clang             0x000000010025074f clang::ParseAST(clang::Sema&, bool) +
431
26 clang             0x000000010022d7ce clang::CodeGenAction::ExecuteAction() +
852
27 clang             0x0000000100039e42
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 958
28 clang             0x00000001000253b1
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2177
29 clang             0x000000010001f47b cc1_main(char const**, char const**,
char const*, void*) + 2923
30 clang             0x0000000100022430 main + 640
31 clang             0x000000010001e904 start + 52
Stack dump:
0.    Program arguments:
/b/build/slave/mac/build/src/third_party/llvm-build/Release+Asserts/bin/clang
-cc1 -triple i386-apple-macosx10.5.0 -emit-obj -disable-free -main-file-name
ShadowBlur.cpp -pic-level 1 -mdisable-fp-elim -relaxed-aliasing -masm-verbose
-target-cpu yonah -target-linker-version 97.17 -coverage-file
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/Release/webcore_platform.build/Objects-normal/i386/ShadowBlur.o
-resource-dir
/b/build/slave/mac/build/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.0
-isysroot /Developer/SDKs/MacOSX10.5.sdk -include
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../WebCorePrefix.h
-D CHROMIUM_BUILD -D ENABLE_REMOTING=1 -D ENABLE_P2P_APIS=1 -D
ENABLE_CONFIGURATION_POLICY -D ENABLE_INPUT_SPEECH -D DCHECK_ALWAYS_ON=1 -D
ENABLE_GPU=1 -D ENABLE_EGLIMAGE=1 -D ENABLE_REGISTER_PROTOCOL_HANDLER=1 -D
WEBCORE_NAVIGATOR_VENDOR="Google Inc." -D WEBCORE_NAVIGATOR_PLATFORM="MacIntel"
-D WebCascadeList=ChromiumWebCoreObjCWebCascadeList -D
ScrollbarPrefsObserver=ChromiumWebCoreObjCScrollbarPrefsObserver -D
WebCoreRenderThemeNotificationObserver=ChromiumWebCoreObjCWebCoreRenderThemeNotificationObserver
-D WebFontCache=ChromiumWebCoreObjCWebFontCache -D
ScrollAnimationHelperDelegate=ChromiumWebCoreObjCScrollAnimationHelperDelegate
-D
ScrollbarPainterControllerDelegate=ChromiumWebCoreObjCScrollbarPainterControllerDelegate
-D ScrollbarPainterDelegate=ChromiumWebCoreObjCScrollbarPainterDelegate -D
ScrollbarPartAnimation=ChromiumWebCoreObjCScrollbarPartAnimation -D
ENABLE_3D_PLUGIN=1 -D ENABLE_BLOB=1 -D ENABLE_BLOB_SLICE=1 -D
ENABLE_CHANNEL_MESSAGING=1 -D ENABLE_CLIENT_BASED_GEOLOCATION=1 -D
ENABLE_DASHBOARD_SUPPORT=0 -D ENABLE_DATA_TRANSFER_ITEMS=1 -D ENABLE_DETAILS=1
-D ENABLE_DEVICE_ORIENTATION=1 -D ENABLE_DIRECTORY_UPLOAD=1 -D
ENABLE_DOM_STORAGE=1 -D ENABLE_DOWNLOAD_ATTRIBUTE=1 -D ENABLE_FILE_SYSTEM=1 -D
ENABLE_FILTERS=1 -D ENABLE_FULLSCREEN_API=1 -D ENABLE_GAMEPAD=1 -D
ENABLE_GEOLOCATION=1 -D ENABLE_GESTURE_EVENTS=1 -D ENABLE_GESTURE_RECOGNIZER=1
-D ENABLE_ICONDATABASE=0 -D ENABLE_INDEXED_DATABASE=1 -D ENABLE_INPUT_SPEECH=1
-D ENABLE_INPUT_TYPE_COLOR=0 -D ENABLE_INPUT_TYPE_DATE=0 -D
ENABLE_INPUT_TYPE_DATETIME=0 -D ENABLE_INPUT_TYPE_DATETIMELOCAL=0 -D
ENABLE_INPUT_TYPE_MONTH=0 -D ENABLE_INPUT_TYPE_TIME=0 -D
ENABLE_INPUT_TYPE_WEEK=0 -D ENABLE_JAVASCRIPT_DEBUGGER=1 -D
ENABLE_JAVASCRIPT_I18N_API=1 -D ENABLE_LINK_PREFETCH=1 -D
ENABLE_MEDIA_STATISTICS=1 -D ENABLE_MEDIA_STREAM=1 -D ENABLE_METER_TAG=1 -D
ENABLE_MHTML=1 -D ENABLE_MICRODATA=0 -D ENABLE_MUTATION_OBSERVERS=0 -D
ENABLE_NOTIFICATIONS=1 -D ENABLE_ORIENTATION_EVENTS=0 -D
ENABLE_PAGE_VISIBILITY_API=1 -D ENABLE_PROGRESS_TAG=1 -D ENABLE_QUOTA=1 -D
ENABLE_REQUEST_ANIMATION_FRAME=1 -D ENABLE_RUBY=1 -D ENABLE_SANDBOX=1 -D
ENABLE_SHARED_WORKERS=1 -D ENABLE_SKIA_GPU=0 -D ENABLE_SKIA_TEXT=0 -D
ENABLE_SMOOTH_SCROLLING=1 -D ENABLE_SQL_DATABASE=1 -D ENABLE_SVG=0 -D
ENABLE_SVG_FONTS=0 -D ENABLE_TOUCH_EVENTS=1 -D ENABLE_TOUCH_ICON_LOADING=0 -D
ENABLE_V8_SCRIPT_DEBUG_SERVER=1 -D ENABLE_VIDEO=1 -D ENABLE_VIDEO_TRACK=1 -D
ENABLE_WEBGL=1 -D ENABLE_WEB_SOCKETS=1 -D ENABLE_WEB_TIMING=1 -D
ENABLE_WORKERS=1 -D ENABLE_XHR_RESPONSE_BLOB=1 -D ENABLE_XPATH=1 -D
ENABLE_XSLT=1 -D WTF_USE_LEVELDB=1 -D WTF_USE_BUILTIN_UTF8_CODEC=1 -D
WTF_USE_OPENTYPE_SANITIZER=1 -D WTF_USE_WEBP=1 -D
WTF_USE_WEBKIT_IMAGE_DECODERS=1 -D ENABLE_WEB_AUDIO=1 -D
WTF_USE_ACCELERATED_COMPOSITING=1 -D ENABLE_3D_RENDERING=1 -D
ENABLE_RUBBER_BANDING=1 -D WTF_USE_SKIA_ON_MAC_CHROMIUM=0 -D
BUILDING_CHROMIUM__=1 -D USE_SYSTEM_MALLOC=1 -D WTF_USE_NEW_THEME=1 -D
U_USING_ICU_NAMESPACE=0 -D U_STATIC_IMPLEMENTATION -D SK_BUILD_NO_IMAGE_ENCODE
-D GR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h" -D
GR_AGGRESSIVE_SHADER_OPTS=1 -D CHROME_PNG_WRITE_SUPPORT -D PNG_USER_CONFIG -D
LIBXML_STATIC -D LIBXSLT_STATIC -D __STDC_FORMAT_MACROS -D NDEBUG -D NVALGRIND
-D DYNAMIC_ANNOTATIONS_ENABLED=0
-F/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/Release
-F/Developer/SDKs/MacOSX10.5.sdk/System/Library/Frameworks/ApplicationServices.framework/Frameworks
-I
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/Release/include
-I ../../../../icu/public/common -I ../../../../icu/public/i18n -I
../../../WebKitLibraries -I ../../../../../gpu -I ../../../../.. -I
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/DerivedSources/Release
-I ../platform/graphics/cocoa -I ../platform/graphics/cg -I .. -I ../.. -I
../accessibility -I ../accessibility/chromium -I ../bindings -I
../bindings/generic -I ../bindings/v8 -I ../bindings/v8/custom -I
../bindings/v8/specialization -I ../bridge -I ../bridge/jni -I ../bridge/jni/v8
-I ../css -I ../dom -I ../dom/default -I ../editing -I ../fileapi -I ../history
-I ../html -I ../html/canvas -I ../html/parser -I ../html/shadow -I
../html/track -I ../inspector -I ../loader -I ../loader/appcache -I
../loader/archive -I ../loader/archive/cf -I ../loader/archive/mhtml -I
../loader/cache -I ../loader/icon -I ../mathml -I ../notifications -I ../p2p -I
../page -I ../page/animation -I ../page/chromium -I ../platform -I
../platform/animation -I ../platform/audio -I ../platform/audio/chromium -I
../platform/chromium -I ../platform/graphics -I ../platform/graphics/chromium
-I ../platform/graphics/filters -I ../platform/graphics/filters/arm -I
../platform/graphics/gpu -I ../platform/graphics/opentype -I
../platform/graphics/skia -I ../platform/graphics/transforms -I
../platform/image-decoders -I ../platform/image-decoders/bmp -I
../platform/image-decoders/gif -I ../platform/image-decoders/ico -I
../platform/image-decoders/jpeg -I ../platform/image-decoders/png -I
../platform/image-decoders/skia -I ../platform/image-decoders/xbm -I
../platform/image-decoders/webp -I ../platform/image-encoders/skia -I
../platform/leveldb -I ../platform/mediastream -I ../platform/mock -I
../platform/network -I ../platform/network/chromium -I ../platform/sql -I
../platform/text -I ../platform/text/transcoder -I ../plugins -I
../plugins/chromium -I ../rendering -I ../rendering/style -I ../rendering/svg
-I ../storage -I ../storage/chromium -I ../svg -I ../svg/animation -I
../svg/graphics -I ../svg/graphics/filters -I ../svg/properties -I
../../ThirdParty/glu -I ../webaudio -I ../websockets -I ../workers -I ../xml -I
../xml/parser -I ../platform/audio/mac -I ../platform/cocoa -I
../platform/graphics/mac -I ../platform/mac -I ../platform/text/mac -I
../../../../../third_party/angle/include/GLSLANG -I
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/DerivedSources/Release/webkit
-I
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/DerivedSources/Release/webkit/bindings
-I ../../JavaScriptCore -I ../../JavaScriptCore/wtf -I
../../../../../skia/config -I ../../../../../third_party/skia/include/config -I
../../../../../third_party/skia/include/core -I
../../../../../third_party/skia/include/effects -I
../../../../../third_party/skia/include/pdf -I
../../../../../third_party/skia/include/gpu -I
../../../../../third_party/skia/include/ports -I ../../../../../skia/ext -I
../../../../../third_party/skia/include/utils/mac -I ../../../../iccjpeg -I
../../../../libwebp -I ../../../../libpng -I ../../../../zlib -I
../../../../libxml/mac/include -I ../../../../libxml/src/include -I
../../../../libxslt -I ../../../../npapi -I ../../../../npapi/bindings -I
../../../../ots/include -I ../../../../sqlite -I ../../../../../v8/include -I
../../../../libjpeg_turbo -I ../../../../leveldatabase/src/include -I
../../../../leveldatabase/src -I
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/Release/webcore_platform.build/DerivedSources/i386
-I
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/Release/webcore_platform.build/DerivedSources
-fmodule-cache-path /var/tmp/clang-module-cache -O3 -Wno-trigraphs -Werror
-Wnewline-eof -Wall -Wendif-labels -Wextra -Wno-unused-parameter
-Wno-missing-field-initializers -Wheader-hygiene -Wno-char-subscripts
-Wno-unused-function -Wno-unnamed-type-template-args -Wno-c++0x-compat
-fdeprecated-macro -ferror-limit 19 -fmessage-length 0 -fvisibility hidden
-fvisibility-inlines-hidden -stack-protector 1 -fblocks
-fblocks-runtime-optional -fno-rtti -fno-threadsafe-statics -fobjc-fragile-abi
-fdiagnostics-show-option -load
/b/build/slave/mac/build/src/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib
-add-plugin find-bad-constructs -o
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../../../../../xcodebuild/WebCore.build/Release/webcore_platform.build/Objects-normal/i386/ShadowBlur.o
-x c++
/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../platform/graphics/ShadowBlur.cpp 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module
'/b/build/slave/mac/build/src/third_party/WebKit/Source/WebCore/WebCore.gyp/../platform/graphics/ShadowBlur.cpp'.
4.    Running pass 'Loop Pass Manager' on function
'@_ZN7WebCore10ShadowBlur14blurLayerImageEPhRKNS_7IntSizeEi'
5.    Running pass 'Loop Strength Reduction' on basic block '%for.body43'
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/ShadowBlur-H2Lxla.ii
Command /b/build/goma/gomacc failed with exit code 254
Command /b/build/goma/gomacc failed with exit code 254

I'll try to come up with a reduced repro.

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

From bugzilla-daemon at llvm.org  Sat Oct 15 01:21:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Oct 2011 01:21:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11138] Regression(141895?): clang crashes when
	compiling webkit
In-Reply-To: <bug-11138-206@http.llvm.org/bugs/>
References: <bug-11138-206@http.llvm.org/bugs/>
Message-ID: <20111015062154.348B02A6C12D@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|unassignedclangbugs at nondot. |atrick at apple.com
                   |org                         |

--- Comment #4 from Andrew Trick <atrick at apple.com> 2011-10-15 01:21:53 CDT ---
Fixed in r142058. Bad assumption about SCEV expression types, which are
currently unreliable.

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

From bugzilla-daemon at llvm.org  Sat Oct 15 04:09:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Oct 2011 04:09:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11139] New: FTBFS unrecognizable insn in
 InitHeaderSearch.cpp:195
Message-ID: <bug-11139-206@http.llvm.org/bugs/>

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

           Summary: FTBFS unrecognizable insn in InitHeaderSearch.cpp:195
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ps at kr.tuwien.ac.at
                CC: llvmbugs at cs.uiuc.edu


I run nightly builds of clang and use it for nightly builds of another project.

Between 141590 and 141720 (about 4 days ago) some change introduced a problem.


Since then my builds fail.

The error message is:

llvm[4]: Compiling InitHeaderSearch.cpp for Release+Asserts build
InitHeaderSearch.cpp: In member function
?void<unnamed>::InitHeaderSearch::AddMinGWCPlusPlusIncludePaths(llvm::StringRef,
llvm::StringRef, llvm::StringRef)?:
InitHeaderSearch.cpp:195:1: error: unrecognizable insn:
(insn 318 317 46 2
/var/lib/buildbot/clang-slave/trunk/build/include/llvm/ADT/Twine.h:180 (set
(reg:DI 23 xmm2)
        (plus:DI (reg:DI 23 xmm2)
            (mem/u/c/i:DI (symbol_ref/u:DI ("*.LC22") [flags 0x2]) [0 S8
A64]))) -1 (expr_list:REG_EQUIV (plus:DI (reg/f:DI 7 sp)
            (mem/u/c/i:DI (symbol_ref/u:DI ("*.LC22") [flags 0x2]) [0 S8 A64]))
        (nil)))
InitHeaderSearch.cpp:195:1: internal compiler error: in extract_insn, at
recog.c:2103
Please submit a full bug report,
with preprocessed source if appropriate.
See <file:///usr/share/doc/gcc-4.5/README.Bugs> for instructions.
/bin/rm: cannot remove
`/var/lib/buildbot/clang-slave/trunk/build/tools/clang/lib/Frontend/Release+Asserts/InitHeaderSearch.d.tmp':
No such file or directory
make[4]: Leaving directory
`/var/lib/buildbot/clang-slave/trunk/build/tools/clang/lib/Frontend'

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

From bugzilla-daemon at llvm.org  Sat Oct 15 07:55:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Oct 2011 07:55:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11140] New: Fast nightly test buildbot failing
Message-ID: <bug-11140-206@http.llvm.org/bugs/>

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

           Summary: Fast nightly test buildbot failing
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Nightly Tester
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


This buildbot
http://lab.llvm.org:8011/builders/clang-x86_64-debian-fnt
is reporting failure, apparently because these failed:
  GCC.MultiSource/Applications/siod/siod
  GCC.MultiSource/Benchmarks/MiBench/consumer-lame/consumer-lame
It's not clear why it thinks GCC (not clang!) is failing, since GCC isn't even
being used for these tests: the reference output is being 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 llvm.org  Sat Oct 15 10:25:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Oct 2011 10:25:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11141] New: Provide a fixit hint for non-const
 format string with no other parameters.
Message-ID: <bug-11141-206@http.llvm.org/bugs/>

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

           Summary: Provide a fixit hint for non-const format string with
                    no other parameters.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu


A relatively common pattern is


char *foo;
?
printf(foo);


clang warns about this because it's a potential security problem if foo is
user-controlled.
That warning should provide a fixit to add "%s".

printf("%s", foo);

The tricky part is to get this right for all flavors of format string functions
(e.g. NSLog(@"%@", nsstring);)

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

From bugzilla-daemon at llvm.org  Sat Oct 15 12:19:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 15 Oct 2011 12:19:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11142] New: Testcase: suboptimal code in memory
	transportation
Message-ID: <bug-11142-206@http.llvm.org/bugs/>

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

           Summary: Testcase: suboptimal code in memory transportation
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


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

I have attached an example file to show you how i'm doing string concatenation.
(This is the result after opt -O3 from llvm3.0)
There are two strings (a and b) allocated and filled with malloc and
llvm.memcpy (from an internal constant). Then, a third string (c) is created.
The new length is correctly constant folded, and llvm.memcpy copies the memory
from the first two strings into the new one.
If LLVM would change the memcpy from a and b to c to a memcpy from the
(internal constant) a to c, it would be much better optimizable:
 - Filling c could be made of one big memcpy
 - The data filled into a and b would not longer be used
 - So dead code elimination could remove two memcpy calls
 - Then no calls are done on a and b, all other store's could be removed by
dead store elimination
 - From a and b, a malloc/free pair would be remain which will be removed then

I hope you can implement some optimization rules to achieve that improvement ;)

Explaination of the example:
 - The interesting part is from line 12-72
 - a is built in line 23
 - b is built in line 34
 - in line 46 and 48, a copy from a->c and b->c is performed
 - target of the optimization should be to have "i8* getelementptr inbounds ([7
x i8]* @label8, i64 0, i64 0)" as src parameter instead of %2 in line 46
 - in line 48, it should be "i8* getelementptr inbounds ([7 x i8]* @label8, i64
0, i64 0)" instead of %5
 - this would open all doors to completely constant fold the whole function.

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

From bugzilla-daemon at llvm.org  Sun Oct 16 00:02:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 00:02:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11143] New: [3.0 regression] clang not mapping
 inline ask errors back to source
Message-ID: <bug-11143-206@http.llvm.org/bugs/>

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

           Summary: [3.0 regression] clang not mapping inline ask errors
                    back to source
           Product: libraries
           Version: 1.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu


As of Kevin's patch in r141814, we now are not mapping inline assembly errors
back to clang's diagnostic handler.  This prevents us from printing the source
location, and we don't realize that an error occurred, so we continue
compilation.

$ cat t.c
void foo() {
  asm("movl 0(%rax), 0(%edx)");
}
$ clang t.c
<inline asm>:1:16: error: invalid operand for instruction
        movl 0(%rax), 0(%edx)
                      ^~~~~~~
Undefined symbols for architecture x86_64:
  "_main", referenced from:
      start in crt1.10.6.o

This is what we used to get:

$ old-clang t.c
t.c:3:7: error: invalid operand for instruction
  asm("movl 0(%rax), 0(%edx)");
      ^
<inline asm>:1:16: note: instantiated into assembly here
        movl 0(%rax), 0(%edx)
                      ^
1 error generated.


It looks like the bug is in around MCParser/AsmParser.cpp:1269, not passing
diagnostics into the LLVMContext's register diagnostic handler anymore.  This
needs to be fixed for LLVM 3.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 llvm.org  Sun Oct 16 03:07:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 03:07:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9052] Kaleidoscope tutorial: JITed code fails to
 resolve functions defined in toy.cpp
In-Reply-To: <bug-9052-206@http.llvm.org/bugs/>
References: <bug-9052-206@http.llvm.org/bugs/>
Message-ID: <20111016080725.AEE702A6C12D@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #1 from Bill Wendling <wendling at apple.com> 2011-10-16 03:07:25 CDT ---
Fixed: r142123

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

From bugzilla-daemon at llvm.org  Sun Oct 16 03:16:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 03:16:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11144] New: dragonegg segfaults while compiling
 llvm/clang on Gentoo
Message-ID: <bug-11144-206@http.llvm.org/bugs/>

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

           Summary: dragonegg segfaults while compiling llvm/clang on
                    Gentoo
           Product: dragonegg
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: lucas at treffenstaedt.de
                CC: llvmbugs at cs.uiuc.edu


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

When compiling LLVM or Clang from svn on gentoo (sys-devel/llvm-9999;
sys-devel/clang-9999) with gcc-4.5.3 and the dragonegg plugin, there is a
segfault when trying to compile PrintModulePass.cpp (in both cases).

Without the plugin, both compile fine.

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

From bugzilla-daemon at llvm.org  Sun Oct 16 03:24:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 03:24:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 4780] Tutorial PNGs don't get installed
In-Reply-To: <bug-4780-206@http.llvm.org/bugs/>
References: <bug-4780-206@http.llvm.org/bugs/>
Message-ID: <20111016082446.284732A6C12D@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #1 from Bill Wendling <wendling at apple.com> 2011-10-16 03:24:45 CDT ---
Fixed here: r142125

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

From bugzilla-daemon at llvm.org  Sun Oct 16 05:49:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 05:49:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11143] [3.0 regression] clang not mapping inline
 ask errors back to source
In-Reply-To: <bug-11143-206@http.llvm.org/bugs/>
References: <bug-11143-206@http.llvm.org/bugs/>
Message-ID: <20111016104953.90AC92A6C124@llvm.org>

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

Benjamin Kramer <benny.kra at gmail.com> changed:

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2011-10-16 05:49:53 CDT ---
Fixed in r142132. Review and merging into release_30 appreciated ;)

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

From bugzilla-daemon at llvm.org  Sun Oct 16 08:16:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 08:16:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11145] New: [3.0 regression] 32 bit LLVM build on
 64 bit machine breaks lli
Message-ID: <bug-11145-206@http.llvm.org/bugs/>

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

           Summary: [3.0 regression] 32 bit LLVM build on 64 bit machine
                    breaks lli
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Configuring LLVM like this
  --build=i686-pc-linux-gnu --host=i686-pc-linux-gnu --target=i686-pc-linux-gnu
on a 64 bit machine (I did this on linux) results in an lli that dies with a
segfault when run.  For example the test
ExecutionEngine/2003-01-04-ArgumentBug.ll fails as well as many others.

While it's not unreasonable to say "don't do that", this worked in llvm-2.9.
Also, every other part of LLVM seems to work fine when built like this.

First spotted on one of the buildbots.

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

From bugzilla-daemon at llvm.org  Sun Oct 16 13:27:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 13:27:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11146] New: Crash when running static analyzer on
	chrome
Message-ID: <bug-11146-206@http.llvm.org/bugs/>

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

           Summary: Crash when running static analyzer on chrome
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


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

Run with `-arch i386` on the (unzipped) attached file. This happened at
r142072.



Subtype of ScopedDecl not handled.
UNREACHABLE executed at
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/lib/StaticAnalyzer/Checkers/../../../include/clang/Analysis/Visitors/CFGRecStmtDeclVisitor.h:72!
0  clang++           0x00000001013bbda2 PrintStackTrace(void*) + 34
1  clang++           0x00000001013bc389 SignalHandler(int) + 713
2  libSystem.B.dylib 0x00007fff80f0d1ba _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2131701344
4  clang++           0x000000010001d726 abort + 22
5  clang++           0x00000001013adb59 llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 457
6  clang++           0x00000001005676ec clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::FindEscaped, void>::Visit(clang::Stmt*) + 2748
7  clang++           0x00000001005669c2 void
clang::ento::check::ASTCodeBody::_checkBody<(anonymous
namespace)::DeadStoresChecker>(void*, clang::Decl const*,
clang::ento::AnalysisManager&, clang::ento::BugReporter&) + 562
8  clang++           0x00000001005c65bb
clang::ento::CheckerManager::runCheckersOnASTBody(clang::Decl const*,
clang::ento::AnalysisManager&, clang::ento::BugReporter&) + 111
9  clang++           0x0000000100546bba (anonymous
namespace)::AnalysisConsumer::HandleCode(clang::Decl*) + 902
10 clang++           0x0000000100546f75 (anonymous
namespace)::AnalysisConsumer::HandleDeclContext(clang::ASTContext&,
clang::DeclContext*) + 747
11 clang++           0x000000010054743a (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit(clang::ASTContext&) + 394
12 clang++           0x000000010025088f clang::ParseAST(clang::Sema&, bool) +
431
13 clang++           0x0000000100039e42
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 958
14 clang++           0x00000001000253b1
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2177
15 clang++           0x000000010001f47b cc1_main(char const**, char const**,
char const*, void*) + 2923
16 clang++           0x0000000100022430 main + 640
17 clang++           0x000000010001e904 start + 52
18 clang++           0x00000000000000db start + 4294842379
Stack dump:
0.    Program arguments: /Users/thakis/local/bin/clang++ -cc1 -triple
i386-apple-macosx10.5.0 -analyze -disable-free -main-file-name
custom_home_pages_table_model.cc -analyzer-store=region
-analyzer-opt-analyze-nested-blocks -analyzer-eagerly-assume
-analyzer-checker=core -analyzer-checker=deadcode -analyzer-checker=security
-analyzer-checker=unix -analyzer-checker=osx -analyzer-output plist -w
-pic-level 1 -mdisable-fp-elim -masm-verbose -target-cpu yonah
-target-linker-version 97.17 -resource-dir
/Users/thakis/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.1
-isysroot /Developer/SDKs/MacOSX10.5.sdk -D CHROMIUM_BUILD -D ENABLE_REMOTING=1
-D ENABLE_P2P_APIS=1 -D ENABLE_CONFIGURATION_POLICY -D ENABLE_INPUT_SPEECH -D
ENABLE_GPU=1 -D ENABLE_EGLIMAGE=1 -D ENABLE_REGISTER_PROTOCOL_HANDLER=1 -D
NACL_WINDOWS=0 -D NACL_LINUX=0 -D NACL_OSX=1 -D NACL_TARGET_SUBARCH=32 -D
NACL_BUILD_SUBARCH=32 -D ENABLE_SAFE_BROWSING -D GOOGLE_PROTOBUF_NO_RTTI -D
SK_BUILD_NO_IMAGE_ENCODE -D GR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h" -D
GR_AGGRESSIVE_SHADER_OPTS=1 -D CLD_WINDOWS -D COMPILER_GCC -D XML_STATIC -D
HUNSPELL_STATIC -D HUNSPELL_CHROME_CLIENT -D USE_HUNSPELL -D
U_USING_ICU_NAMESPACE=0 -D U_STATIC_IMPLEMENTATION -D FEATURE_ENABLE_SSL -D
FEATURE_ENABLE_VOICEMAIL -D EXPAT_RELATIVE_PATH -D WEBRTC_RELATIVE_PATH -D OSX
-D POSIX -D LIBXML_STATIC -D USE_CUPS -D __STDC_FORMAT_MACROS -D
DYNAMIC_ANNOTATIONS_ENABLED=1 -D WTF_USE_DYNAMIC_ANNOTATIONS=1 -D _DEBUG -I
third_party/icu/public/common -I third_party/icu/public/i18n -I . -I
out/Debug/obj.target/geni -I third_party/apple -I third_party/GTM -I
third_party/GTM/AppKit -I third_party/GTM/DebugUtils -I
third_party/GTM/Foundation -I gpu -I out/Debug/obj/gen/policy -I
out/Debug/obj/gen/protoc_out -I third_party/protobuf -I
third_party/protobuf/src -I out/Debug/obj/gen/chrome -I skia/config -I
third_party/skia/include/config -I third_party/skia/include/core -I
third_party/skia/include/effects -I third_party/skia/include/pdf -I
third_party/skia/include/gpu -I third_party/skia/include/ports -I skia/ext -I
third_party/skia/include/utils/mac -I third_party/bzip2 -I third_party/cld -I
third_party/expat/files/lib -I third_party/leveldatabase/src/include -I
third_party/leveldatabase/src -I third_party/libjingle/overrides -I
third_party/libjingle/source -I
out/Debug/obj/gen/protoc_out/third_party/libphonenumber -I
third_party/libxml/mac/include -I third_party/libxml/src/include -I
third_party/npapi -I third_party/npapi/bindings -I
out/Debug/obj/gen/ui/app_locale_settings -I out/Debug/obj/gen/ui/ui_strings -I
out/Debug/obj/gen/ui/ui_resources -I out/Debug/obj/gen/ui/ui_resources_large -I
out/Debug/obj/gen/ui/ui_resources_standard -I out/Debug/obj/gen/webkit
-fmodule-cache-path
/var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/clang-module-cache
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-char-subscripts
-Wno-unused-function -Wno-unnamed-type-template-args -Wno-c++0x-compat
-Wno-c++11-extensions -fdeprecated-macro -ferror-limit 19 -fmessage-length 0
-stack-protector 1 -fblocks -fblocks-runtime-optional -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -analyzer-output=html
-o /var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/scan-build-2011-10-15-2 -x
c++ chrome/browser/custom_home_pages_table_model.cc 
1.    <eof> parser at end of 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 llvm.org  Sun Oct 16 14:27:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 14:27:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11147] New: Windows (MSVC 10.0 x64) build failure
Message-ID: <bug-11147-206@http.llvm.org/bugs/>

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

           Summary: Windows (MSVC 10.0 x64) build failure
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vanboxem.ruben at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I get this error when building 64-bit LLVM/Clang with cmake, generating nmake
makefiles, and using Windows SDK 7.1 (MSVC 10.0). This used to work. I think
inline asm is being used where it shouldn't.

[ 37%] Building CXX object
lib/Target/X86/MCTargetDesc/CMakeFiles/LLVMX86Desc.dir/X86MCTargetDesc.cpp.obj
X86MCTargetDesc.cpp
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(131)
: error C4235: nonstandard extension used : '__asm' keyword not supported on
this architecture
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(132)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(132)
: error C2146: syntax error : missing ';' before identifier 'eax'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(132)
: error C2065: 'eax' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(133)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(133)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(133)
: error C2146: syntax error : missing ';' before identifier 'ecx'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(133)
: error C2065: 'ecx' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(135)
: error C2146: syntax error : missing ';' before identifier 'cpuid'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(135)
: error C2065: 'cpuid' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(135)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(135)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(135)
: error C2146: syntax error : missing ';' before identifier 'rsi'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(135)
: error C2065: 'rsi' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(136)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(136)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(136)
: error C2146: syntax error : missing ';' before identifier 'dword'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(136)
: error C2065: 'dword' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(136)
: error C2146: syntax error : missing ';' before identifier 'ptr'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(136)
: error C2065: 'ptr' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(136)
: error C2065: 'rsi' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(137)
: error C2065: 'eax' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(137)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(137)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(137)
: error C2146: syntax error : missing ';' before identifier 'rsi'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(137)
: error C2065: 'rsi' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(138)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(138)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(138)
: error C2146: syntax error : missing ';' before identifier 'dword'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(138)
: error C2065: 'dword' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(138)
: error C2146: syntax error : missing ';' before identifier 'ptr'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(138)
: error C2065: 'ptr' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(138)
: error C2065: 'rsi' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(139)
: error C2065: 'ebx' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(139)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(139)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(139)
: error C2146: syntax error : missing ';' before identifier 'rsi'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(139)
: error C2065: 'rsi' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(140)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(140)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(140)
: error C2146: syntax error : missing ';' before identifier 'dword'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(140)
: error C2065: 'dword' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(140)
: error C2146: syntax error : missing ';' before identifier 'ptr'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(140)
: error C2065: 'ptr' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(140)
: error C2065: 'rsi' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(141)
: error C2065: 'ecx' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(141)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(141)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(141)
: error C2146: syntax error : missing ';' before identifier 'rsi'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(141)
: error C2065: 'rsi' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(142)
: error C2146: syntax error : missing ';' before identifier 'mov'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(142)
: error C2065: 'mov' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(142)
: error C2146: syntax error : missing ';' before identifier 'dword'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(142)
: error C2065: 'dword' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(142)
: error C2146: syntax error : missing ';' before identifier 'ptr'
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(142)
: error C2065: 'ptr' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(142)
: error C2065: 'rsi' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(143)
: error C2065: 'edx' : undeclared identifier
M:\Development\Source\LLVM\lib\Target\X86\MCTargetDesc\X86MCTargetDesc.cpp(143)
: error C2143: syntax error : missing ';' before '}'
command failed with exit code 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 llvm.org  Sun Oct 16 16:15:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 16:15:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11142] Testcase: suboptimal code in memory
	transportation
In-Reply-To: <bug-11142-206@http.llvm.org/bugs/>
References: <bug-11142-206@http.llvm.org/bugs/>
Message-ID: <20111016211502.CFB1D3128018@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

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

--- Comment #4 from Nick Lewycky <nicholas at mxc.ca> 2011-10-16 16:15:02 CDT ---
I'm going to mark this fixed as the copy a->b, malloc c, copy b->c issue is
fixed. Your report listed many issues, please file separate bugs for 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 llvm.org  Sun Oct 16 16:26:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 16:26:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10100] Debian sid installs crt{1, i,
 n}.o in multi-arch lib directory
In-Reply-To: <bug-10100-206@http.llvm.org/bugs/>
References: <bug-10100-206@http.llvm.org/bugs/>
Message-ID: <20111016212652.73F6C3128018@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #6 from Chandler Carruth <chandlerc at gmail.com> 2011-10-16 16:26:51 CDT ---
(In reply to comment #5)
> I think the just released ubuntu uses the more complicated sid scheme.

Ok, I'm trying to find out what (if anything other than the existing hacks) are
needed there, but if there are issues with it, or issues with a future debian
package that creates a different structure they should go into new bugs.
Marking this one 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 llvm.org  Sun Oct 16 23:42:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 23:42:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3329] g++.dg/warn/pr23075.C fails
In-Reply-To: <bug-3329-206@http.llvm.org/bugs/>
References: <bug-3329-206@http.llvm.org/bugs/>
Message-ID: <20111017044231.C4E1C2A6C124@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #2 from Bill Wendling <wendling at apple.com> 2011-10-16 23:42:31 CDT ---
Looks like clang is getting this correct:

$ clang++ -O2 -Wreturn-type -c pr23075.C 
pr23075.C:8:3: warning: non-void function 'foo' should return a value
[-Wreturn-type]
  return;       // { dg-error "with no value" }
  ^
1 warning 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 llvm.org  Sun Oct 16 23:47:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 16 Oct 2011 23:47:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2690] ICE on invalid; #pragma GCC visibility pop
In-Reply-To: <bug-2690-206@http.llvm.org/bugs/>
References: <bug-2690-206@http.llvm.org/bugs/>
Message-ID: <20111017044736.59FD13128026@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #3 from Bill Wendling <wendling at apple.com> 2011-10-16 23:47:35 CDT ---
This doesn't seem to be a problem with clang:

$ clang 421.c -c
421.c:1:1: error: unknown type name 'namespace'
namespace std __attribute__ ((__visibility__ ("default"))) {
^
421.c:1:59: error: expected ';' after top level declarator
namespace std __attribute__ ((__visibility__ ("default"))) {
                                                          ^
                                                          ;
2 errors 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 llvm.org  Mon Oct 17 00:29:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 00:29:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11148] New: Clang crashes with g++ 4.6 header files
Message-ID: <bug-11148-206@http.llvm.org/bugs/>

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

           Summary: Clang crashes with g++ 4.6 header files
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: thanhdk at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When I try to compile a very simple c++ file (just declare a new stl vector)
and compile with clang 2.9:
clang -I. -I/usr/include/c++/4.6 -I/usr/include/c++/4.6/x86_64-linux-gnu/.
-I/usr/include/c++/4.6/backward -I/usr/lib/gcc/x86_64-linux-gnu/4.6.1/include
-I/usr/local/include -I/usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed
-I/usr/include/x86_64-linux-gnu -std=c++0x hello.cc

Here is the source file:
#include <vector>
using namespace std;

int main()
{
    vector<int> v;
    return 0;
}

Here's the output from clang:

In file included from /usr/include/c++/4.6/vector:60:
In file included from /usr/include/c++/4.6/bits/stl_algobase.h:65:
In file included from /usr/include/c++/4.6/bits/stl_pair.h:60:
In file included from /usr/include/c++/4.6/bits/move.h:53:
/usr/include/c++/4.6/type_traits:630:59: error: '_Tp' does not refer to a value
    : public integral_constant<bool, __is_standard_layout(_Tp)>
                                                          ^
/usr/include/c++/4.6/type_traits:628:21: note: declared here
  template<typename _Tp>
                    ^
/usr/include/c++/4.6/type_traits:631:8: error: expected class name
    { };
       ^
/usr/include/c++/4.6/type_traits:631:8: error: expected '{' after base class
list
/usr/include/c++/4.6/type_traits:643:56: error: '_Tp' does not refer to a value
    : public integral_constant<bool, __is_literal_type(_Tp)>
                                                       ^
/usr/include/c++/4.6/type_traits:641:21: note: declared here
  template<typename _Tp>
                    ^
/usr/include/c++/4.6/type_traits:644:8: error: expected class name
    { };
       ^
/usr/include/c++/4.6/type_traits:644:8: error: expected '{' after base class
list
/usr/include/c++/4.6/type_traits:647:56: error: expected function body after
function declarator
    typename add_rvalue_reference<_Tp>::type declval() noexcept;
                                                       ^
/usr/include/c++/4.6/type_traits:654:30: error: use of undeclared identifier
'declval'
        static decltype(_Tp1(declval<_Args1>()...), __one()) __test(int);
                             ^
/usr/include/c++/4.6/type_traits:654:38: error: '_Args1' does not refer to a
value
        static decltype(_Tp1(declval<_Args1>()...), __one()) __test(int);
                                     ^
/usr/include/c++/4.6/type_traits:653:43: note: declared here
      template<typename _Tp1, typename... _Args1>
                                          ^
/usr/include/c++/4.6/type_traits:654:46: error: expected expression
        static decltype(_Tp1(declval<_Args1>()...), __one()) __test(int);
                                             ^
/usr/include/c++/4.6/type_traits:654:62: error: C++ requires a type specifier
for all declarations
        static decltype(_Tp1(declval<_Args1>()...), __one()) __test(int);
        ~~~~~~                                               ^
/usr/include/c++/4.6/type_traits:668:43: error: use of undeclared identifier
'declval'
        static decltype(static_cast<_Tp1>(declval<_Arg1>()), __one())
                                          ^
/usr/include/c++/4.6/type_traits:668:51: error: '_Arg1' does not refer to a
value
        static decltype(static_cast<_Tp1>(declval<_Arg1>()), __one())
                                                  ^
/usr/include/c++/4.6/type_traits:667:40: note: declared here
      template<typename _Tp1, typename _Arg1>
                                       ^
/usr/include/c++/4.6/type_traits:668:58: error: expected expression
        static decltype(static_cast<_Tp1>(declval<_Arg1>()), __one())
                                                         ^
/usr/include/c++/4.6/type_traits:669:2: error: C++ requires a type specifier
for all declarations
        __test(int);
        ^
/usr/include/c++/4.6/type_traits:694:48: error: use of undeclared identifier
'declval'
    { static const bool __value = noexcept(_Tp(declval<_Args>()...)); };
                                               ^
/usr/include/c++/4.6/type_traits:694:56: error: '_Args' does not refer to a
value
    { static const bool __value = noexcept(_Tp(declval<_Args>()...)); };
                                                       ^
/usr/include/c++/4.6/type_traits:692:38: note: declared here
  template<typename _Tp, typename... _Args>
                                     ^
/usr/include/c++/4.6/type_traits:694:63: error: expected expression
    { static const bool __value = noexcept(_Tp(declval<_Args>()...)); };
                                                              ^
/usr/include/c++/4.6/type_traits:699:61: error: use of undeclared identifier
'declval'
      static const bool __value = noexcept(static_cast<_Tp>(declval<_Arg>()));
                                                            ^
fatal error: too many errors emitted, stopping now [-ferror-limit=]
0  libLLVM-2.9.so.1 0x00007ffd02f57caf
1  libLLVM-2.9.so.1 0x00007ffd02f58271
2  libpthread.so.0  0x00007ffd02119060
3  clang            0x00000000007f27a7
clang::Sema::CheckConstructor(clang::CXXConstructorDecl*) + 183
4  clang            0x00000000007d7533
5  clang            0x000000000093b718
clang::TemplateDeclInstantiator::VisitCXXMethodDecl(clang::CXXMethodDecl*,
clang::TemplateParameterList*) + 2552
6  clang            0x0000000000924875
clang::Sema::InstantiateClass(clang::SourceLocation, clang::CXXRecordDecl*,
clang::CXXRecordDecl*, clang::MultiLevelTemplateArgumentList const&,
clang::TemplateSpecializationKind, bool) + 1429
7  clang            0x0000000000925333
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 1235
8  clang            0x000000000094b1b9
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&, std::pair<clang::SourceLocation,
clang::PartialDiagnostic>) + 1001
9  clang            0x000000000094b217
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
unsigned int) + 87
10 clang            0x000000000078af44
clang::Sema::CheckParmsForFunctionDef(clang::ParmVarDecl**,
clang::ParmVarDecl**, bool) + 228
11 clang            0x00000000007d1e5f
clang::Sema::ActOnStartOfFunctionDef(clang::Scope*, clang::Decl*) + 463
12 clang            0x000000000075c640
clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 336
13 clang            0x000000000075c479
clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 121
14 clang            0x000000000073ed9c
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 1020
15 clang            0x000000000073fe70
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 3072
16 clang            0x00000000007301c3
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 2147
17 clang            0x00000000007570cf
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier) + 639
18 clang            0x000000000075a106
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 614
19 clang            0x000000000073181a
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 506
20 clang            0x000000000072853e
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1582
21 clang            0x000000000073bbb3 clang::Parser::ParseNamespace(unsigned
int, clang::SourceLocation&, clang::SourceLocation) + 1603
22 clang            0x00000000007317a3
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 387
23 clang            0x000000000072853e
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1582
24 clang            0x0000000000728c8d
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 109
25 clang            0x000000000070b750 clang::ParseAST(clang::Sema&, bool) +
128
26 clang            0x00000000006016c3 clang::CodeGenAction::ExecuteAction() +
51
27 clang            0x0000000000534aeb
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 283
28 clang            0x000000000051aa3b
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 971
29 clang            0x0000000000512ef7 cc1_main(char const**, char const**,
char const*, void*) + 727
30 clang            0x0000000000511a7a main + 634
31 libc.so.6        0x00007ffd0186e30d __libc_start_main + 237
32 clang            0x0000000000512ac5
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
hello.cc -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.21.53.20110810 -momit-leaf-frame-pointer -resource-dir
/usr/bin/../lib/clang/2.9 -I . -I /usr/include/c++/4.6 -I
/usr/include/c++/4.6/x86_64-linux-gnu/. -I /usr/include/c++/4.6/backward -I
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/include -I /usr/local/include -I
/usr/lib/gcc/x86_64-linux-gnu/4.6.1/include-fixed -I
/usr/include/x86_64-linux-gnu -std=c++0x -ferror-limit 19 -fmessage-length 118
-fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-xcBtq2.o -x c++ hello.cc 
1.    /usr/include/c++/4.6/bits/stl_bvector.h:540:5: current parser token ':'
2.    /usr/include/c++/4.6/bits/stl_bvector.h:457:1: parsing namespace 'std'
3.    /usr/include/c++/4.6/bits/stl_bvector.h:479:3: parsing struct/union/class
body 'vector'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 1 (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 llvm.org  Mon Oct 17 00:39:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 00:39:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11147] Windows (MSVC 10.0 x64) build failure
In-Reply-To: <bug-11147-206@http.llvm.org/bugs/>
References: <bug-11147-206@http.llvm.org/bugs/>
Message-ID: <20111017053910.B0FAB3128018@llvm.org>

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

Craig Topper <craig.topper at gmail.com> changed:

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

--- Comment #6 from Craig Topper <craig.topper at gmail.com> 2011-10-17 00:39:10 CDT ---
In r142177, I've switched to using __cpuidex and qualified with a check for
Visual Studio 2008 SP1. Unfortunately, this means that we aren't able to use
cpuid leaf 7 on earlier versions of Visual Studio.

Fortunately, no processors have shipped that use leaf 7 so we didn't really
lose anything 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 llvm.org  Mon Oct 17 01:22:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 01:22:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2577] Use static profile info from __builtin_expect
 in optimizer to improve code
In-Reply-To: <bug-2577-206@http.llvm.org/bugs/>
References: <bug-2577-206@http.llvm.org/bugs/>
Message-ID: <20111017062224.BF7882A6C12C@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |chandlerc at gmail.com
         Resolution|FIXED                       |

--- Comment #4 from Chandler Carruth <chandlerc at gmail.com> 2011-10-17 01:22:23 CDT ---
This is not yet done... It's a bit hard to prove to yourself that it is not
done by running a command because we have few optimizations using the
information, but I've added a testing layer that demonstrates that in fact
metadata produced by the LLVM expect intrinsic does not get incorporated into
the branch probability analysis, or consequentially into the block frequency
analysis, or any optimizations we do have using them.

I'm mailing patches to cfe-commits which will bridge this gap in the
infrastructure, and I've already fixed a critical bug in branch probabilities
that would have led to turning this on producing exactly *backwards*
probabilities, pessimizing code instead of optimizing it. See r142168 for that
bit of fun.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 02:33:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 02:33:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11149] New: kernel compiling: size of array is
	negative
Message-ID: <bug-11149-206@http.llvm.org/bugs/>

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

           Summary: kernel compiling: size of array is negative
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: xuzhongxing at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When compiling Linux kernel 3.0, gcc accepts this code at -O2 level. But clang
rejects it. Gcc also rejects it at -O0.

void f(int offset) {
  ((void)sizeof(char[1 - 2*!!(!__builtin_constant_p(offset))]));
}

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

From bugzilla-daemon at llvm.org  Mon Oct 17 02:34:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 02:34:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11150] New: Pure virtual specifiers broken when
 Microsoft extensions are turned on
Message-ID: <bug-11150-206@http.llvm.org/bugs/>

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

           Summary: Pure virtual specifiers broken when Microsoft
                    extensions are turned on
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: johnw at boostpro.com
                CC: llvmbugs at cs.uiuc.edu


Doug Gregor's change r141539, which removes the Init argument from
Sema::ActOnCXXMemberDeclarator, causes a problem with Microsoft extensions and
pure virtual specifiers.

There is this code in ParseDeclCXX.cpp
(Parser::ParseCXXClassMemberDeclaration):

    if (getLang().MicrosoftExt && Tok.is(tok::equal) &&
        DeclaratorInfo.isFunctionDeclarator() && 
        NextToken().is(tok::numeric_constant)) {
      ConsumeToken();
      Init = ParseInitializer();
      if (Init.isInvalid())
        SkipUntil(tok::comma, true, true);
    }

This code gets executed for every kind of pure virtual function, causing Init
to be set.  Before r141539, Sema::ActOnCXXMemberDeclarator would see that Init
was set and call AddInitializerToDecl.  This code path is ultimately
responsible for setting Abstract on the class.

With the change, that code moved to Parser::ParseCXXClassMemberDeclaration --
but only if HasInitializer is true, which it never is if the above Microsoft
extension code has consumed the tok::equal that would normally trigger
HasInitializer getting set in Parser::ParseCXXClassMemberDeclaration:

    bool HasInitializer = false;
    bool HasDeferredInitializer = false;
    if (Tok.is(tok::equal) || Tok.is(tok::l_brace)) {
      if (BitfieldSize.get()) {
        Diag(Tok, diag::err_bitfield_member_init);
        SkipUntil(tok::comma, true, true);
      } else {
        HasInitializer = true;       // <---------
        HasDeferredInitializer = !DeclaratorInfo.isDeclarationOfFunction() &&
          DeclaratorInfo.getDeclSpec().getStorageClassSpec()
            != DeclSpec::SCS_static &&
          DeclaratorInfo.getDeclSpec().getStorageClassSpec()
            != DeclSpec::SCS_typedef;
      }
    }

I'm not sure what the best way to fix this is.  I have a feeling the Microsoft
extension code that's doing the eager parsing needs to be rewritten for the new
logic.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 03:20:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 03:20:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11151] New: 'aligned' attribute ignored when
	parsing type
Message-ID: <bug-11151-206@http.llvm.org/bugs/>

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

           Summary: 'aligned' attribute ignored when parsing type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: xuzhongxing at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When compiling the Linux kernel, I met the following error:

crypto/shash.c:68:56: error: 'aligned' attribute ignored when parsing type
return len + (mask & ~(__alignof__(u8 __attribute__ ((aligned))) - 1));
                                                       ^~~~~~~

GCC accepts it. It is necessary to make it an error, instead of a warning?

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

From bugzilla-daemon at llvm.org  Mon Oct 17 03:39:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 03:39:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10902] [VECTOR-SELECT] multiple assertions fails
 when enabling promote-element
In-Reply-To: <bug-10902-206@http.llvm.org/bugs/>
References: <bug-10902-206@http.llvm.org/bugs/>
Message-ID: <20111017083926.9ADB62A6C12C@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.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 llvm.org  Mon Oct 17 03:40:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 03:40:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2314] Poor codegen of select + vector ops
In-Reply-To: <bug-2314-206@http.llvm.org/bugs/>
References: <bug-2314-206@http.llvm.org/bugs/>
Message-ID: <20111017084036.CCB45312800A@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.com> changed:

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

--- Comment #24 from Nadav Rotem <nadav.rotem at intel.com> 2011-10-17 03:40:34 CDT ---
LLVM now supports vector-select.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 03:48:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 03:48:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11152] New: suggest %zu for size_t args to printf,
 at least in c99 mode
Message-ID: <bug-11152-206@http.llvm.org/bugs/>

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

           Summary: suggest %zu for size_t args to printf, at least in c99
                    mode
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu


For the following program:

#include <stdio.h>

void f(size_t a) {
  printf("%c", a);
}

Clang suggests this:

/tmp/a.c:4:12: warning: conversion specifies type 'int' but the argument has
      type 'size_t' (aka 'unsigned long') [-Wformat]
  printf("%c", a);
          ~^   ~
          %lu


It would be better if it suggested %zu, at least in C99 (and C++11).

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

From bugzilla-daemon at llvm.org  Mon Oct 17 05:04:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 05:04:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11153] New: variable length array in structure
Message-ID: <bug-11153-206@http.llvm.org/bugs/>

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

           Summary: variable length array in structure
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: xuzhongxing at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Though this bug seems will not be fixed, I still report it to say that
compiling Linux kernel need to fix it.

arch/x86/xen/mmu.c:1236:17: error: fields must have a constant size: 'variable
length array in structure' extension will never be supported
  unsigned long mask[(((num_processors) + (8 * sizeof(long)) - 1) / (8 *
sizeof(long)))];

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

From bugzilla-daemon at llvm.org  Mon Oct 17 05:31:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 05:31:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11144] dragonegg segfaults while compiling
	llvm/clang on Gentoo
In-Reply-To: <bug-11144-206@http.llvm.org/bugs/>
References: <bug-11144-206@http.llvm.org/bugs/>
Message-ID: <20111017103127.0E6953128026@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #13 from Duncan Sands <baldrick at free.fr> 2011-10-17 05:31:26 CDT ---
This was a gcc-4.5 bug manifesting itself.  The bug was fixed in gcc 4.5.4 and
was never present in gcc-4.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 llvm.org  Mon Oct 17 07:52:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 07:52:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11142] Testcase: suboptimal code in memory
	transportation
In-Reply-To: <bug-11142-206@http.llvm.org/bugs/>
References: <bug-11142-206@http.llvm.org/bugs/>
Message-ID: <20111017125208.3A9F72A6C12C@llvm.org>

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

s3734770 at mail.zih.tu-dresden.de changed:

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

--- Comment #5 from s3734770 at mail.zih.tu-dresden.de 2011-10-17 07:52:07 CDT ---
I tried a more complex test case with llvm3.1svn and the issue is not resolved
yet.
I will upload a new test case.
Look at line 23 vs line 58 and line 43 vs line 61.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 08:58:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 08:58:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10997] _cdecl not recognized correctly on windows
In-Reply-To: <bug-10997-206@http.llvm.org/bugs/>
References: <bug-10997-206@http.llvm.org/bugs/>
Message-ID: <20111017135818.B37812A6C12C@llvm.org>

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

vanboxem.ruben at gmail.com changed:

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

--- Comment #11 from vanboxem.ruben at gmail.com 2011-10-17 08:58:17 CDT ---
The MinGW-w64 source is patched, this is a non-issue.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 10:33:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 10:33:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11149] kernel compiling: size of array is negative
In-Reply-To: <bug-11149-206@http.llvm.org/bugs/>
References: <bug-11149-206@http.llvm.org/bugs/>
Message-ID: <20111017153316.013583128026@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-17 10:33:15 CDT ---
If gcc doesn't accept a piece of code at -O0, it's probably wrong. This
construct is clearly abusive.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 10:35:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 10:35:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11154] New: findModuleDefiningSymbol &
 findModuleDefiningSymbols have inconsistent view of symTab
Message-ID: <bug-11154-206@http.llvm.org/bugs/>

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

           Summary: findModuleDefiningSymbol & findModuleDefiningSymbols
                    have inconsistent view of symTab
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-ld
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gmalecha at eecs.harvard.edu
                CC: llvmbugs at cs.uiuc.edu


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

It seems that the two functions Achive::findModuleDefiningSymbol and
Archive::findModulesDefiningSymbols are inconsistent in their use of the index
of the modules map. Code snippets:

Archive::findModulesDefiningSymbols (line 510)
const char* At  = base + firstFileOffset;
...
unsigned offset = At - base - firstFileOffset;
...
symTab.insert(std::make_pair(*I, offset)); // *I is the symbol
modules.insert(std::make_pair(offset, std::make_pair(M, mbr)));


Archive::findModuleDefininingSymbol (line 460)
SymTabType::iterator SI = symTab.find(symbol);
...
unsigned fileOffset =
    SI->second +                // offset in symbol-table-less file
    firstFileOffset;            // add offset to first "real" file in archive
...
ModuleMap::iterator MI = modules.find(fileOffset);

In findModuleDefiningSymbol, firstFileOffset is added in before looking up into
the map, while the offset associated with a symbol has this value subtracted
out. In most cases this just causes a cache miss, so the module would be loaded
but in some rare instances the offset points to a valid module which causes us
to look at the wrong module.

I think the appropriate fix is to fix the population of the modules map inside
findModulesDefiningSymbols (patch attached).

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

From bugzilla-daemon at llvm.org  Mon Oct 17 10:52:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 10:52:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11153] variable length array in structure
In-Reply-To: <bug-11153-206@http.llvm.org/bugs/>
References: <bug-11153-206@http.llvm.org/bugs/>
Message-ID: <20111017155236.D01842A6C12E@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-17 10:52:36 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon Oct 17 11:03:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 11:03:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11151] 'aligned' attribute ignored when parsing type
In-Reply-To: <bug-11151-206@http.llvm.org/bugs/>
References: <bug-11151-206@http.llvm.org/bugs/>
Message-ID: <20111017160323.644103128034@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-17 11:03:23 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon Oct 17 11:39:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 11:39:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11155] New: Request moving member listing above
 interaction diagram in documentation
Message-ID: <bug-11155-206@http.llvm.org/bugs/>

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

           Summary: Request moving member listing above interaction
                    diagram in documentation
           Product: Documentation
           Version: 2.9
          Platform: Other
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Doxygen
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clemahieu at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Request to move the class member listing above the interaction diagrams in the
class documentation.  When looking at documentation I'm almost always looking
for the member listing instead of the interaction diagram.

Example of page:
http://llvm.org/docs/doxygen/html/d2/d5c/classllvm_1_1StructType.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 llvm.org  Mon Oct 17 12:11:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 12:11:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11150] Pure virtual specifiers broken when
 Microsoft extensions are turned on
In-Reply-To: <bug-11150-206@http.llvm.org/bugs/>
References: <bug-11150-206@http.llvm.org/bugs/>
Message-ID: <20111017171129.D339F3128026@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-17 12:11:29 CDT ---
Fixed in Clang r142195.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 12:21:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 12:21:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10895] throw() with -fno-exceptions generates worse
 code than throw(std::bad_alloc)
In-Reply-To: <bug-10895-206@http.llvm.org/bugs/>
References: <bug-10895-206@http.llvm.org/bugs/>
Message-ID: <20111017172100.7B3503128034@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-17 12:20:59 CDT ---
This is C++ [expr.new]p13, which specifically states:

  If the allocation function returns null, initialization shall not be done,
the deallocation function shall not be called, and the value of the
new-expression shall be null.

In other words, the standard requires that we check for NULL when operator new
is not permitted to indicate failure by throwing an exception.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 12:41:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 12:41:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11156] New: sysexit should not have a REX.W prefix
Message-ID: <bug-11156-206@http.llvm.org/bugs/>

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

           Summary: sysexit should not have a REX.W prefix
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-as
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: enderby at apple.com
                CC: llvmbugs at cs.uiuc.edu




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

From bugzilla-daemon at llvm.org  Mon Oct 17 14:34:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 14:34:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11157] New: constexpr constructors can't initialize
 constexpr variables
Message-ID: <bug-11157-206@http.llvm.org/bugs/>

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

           Summary: constexpr constructors can't initialize constexpr
                    variables
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: max at duempel.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7471)
 --> (http://llvm.org/bugs/attachment.cgi?id=7471)
demo source code

With the attached source file, I get the following error message:

clang++ -std=c++11 -c constexpr.cc 
constexpr.cc:7:13: error: constexpr variable 'a' must be initialized by a
constant expression
constexpr X a(2);
            ^~~~
1 error generated.

The second variable "b" which calls the default constructor gets initialized
correctly, but the "constexpr" constructor cannot be called to initialize the
variable "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 llvm.org  Mon Oct 17 14:57:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 14:57:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11157] constexpr constructors can't initialize
 constexpr variables
In-Reply-To: <bug-11157-206@http.llvm.org/bugs/>
References: <bug-11157-206@http.llvm.org/bugs/>
Message-ID: <20111017195731.B0C572A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-17 14:57:31 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon Oct 17 15:14:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 15:14:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11158] New: ALL backends need to implement
 efficient trunc-store sequences
Message-ID: <bug-11158-206@http.llvm.org/bugs/>

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

           Summary: ALL backends need to implement efficient trunc-store
                    sequences
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nadav.rotem at intel.com
                CC: llvmbugs at cs.uiuc.edu


The type-legalizer often generates trunc store or anyext loads. The
type-legalizer attempts to promote elements in order to fit the vector type
into a physical register. This is a good idea because the instruction set for
non-common types tends to be sparse. However, the data is saved in memory in
its 'legal' form and trunc-ing or anyext-ing is needed.

Look at the x86backend (combine dag for load/store) for an example.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 15:26:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 15:26:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11159] New: Improve function name Recommendations
Message-ID: <bug-11159-206@http.llvm.org/bugs/>

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

           Summary: Improve function name Recommendations
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I recently had the following code:

struct S
{
    void storeBacktrack();
    void storeBacktrackChild();
};

void f()
{
    S s;
    s.storeChildBacktrack();
}

clang suggested that I probably mean 'storeBacktrack', whereas I would say
storeBacktrackChild would be a better suggestion.

I'm not sure how easy this kind of thing (rearrange the function name) would be
to add to the function name recommendations, and how useful it would 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 llvm.org  Mon Oct 17 18:49:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 18:49:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11161] New: BranchFolding pass fails to reliably
 maintain "kill" bit
Message-ID: <bug-11161-206@http.llvm.org/bugs/>

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

           Summary: BranchFolding pass fails to reliably maintain "kill"
                    bit
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pickensd at synopsys.com
                CC: llvmbugs at cs.uiuc.edu


The BranchFolding pass fails to properly maintain the kill bit in the following
hoisting scenario after register allocation:

BB:...
   %CC <- CMP %R10,...
   CJMP  TBB,condcode,%CC
   JMP FBB

TBB:
   %R11 <-  ADD %R10<kill>,1
   ...

FBB:
   %R11 <- ADD %R10<kill>,1
   ...


BranchFolding hoists the ADD as follows, but fails to maintain the <kill> bit
on the %R10 operands.

BB: ...
    %R11 <- ADD %R10<kill>,1    <-- Kill bit not cleared!
    %CC  <- CMP %R10,...        <-- Kill bit not set!
    CJMP  TBB,condcode,%CC
    JMP FBB


This problem causes the register scavenger to bomb during
post-register-allocation processing.

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

From bugzilla-daemon at llvm.org  Mon Oct 17 21:33:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 17 Oct 2011 21:33:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11162] New: Issues with -Wconversion (from
 g++.old-deja/g++.other/null1.C)
Message-ID: <bug-11162-206@http.llvm.org/bugs/>

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

           Summary: Issues with -Wconversion (from
                    g++.old-deja/g++.other/null1.C)
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Test can be accessed at
http://llvm.org/viewvc/llvm-project/clang-tests/trunk/gcc-4_2-testsuite/src/g%2B%2B.old-deja/g%2B%2B.other/null1.C?revision=109903&view=markup
; issues with output:

1. -Wconversion warnings print the macro expansion of NULL, which is completely
useless:
<stdin>:26:11: warning: implicit conversion of NULL constant to integer
[-Wconversion]
  int i = NULL; // { dg-warning "" } converting NULL to non-pointer type
      ~   ^~~~
/Volumes/storage/llvmbin/Release+Asserts/bin/../lib/clang/3.1/include/stddef.h:47:14:
note: expanded from macro: NULL
#define NULL __null
             ^~~~~~

2. We miss warnings for some cases; for example, no (relevant) warnings for the
following with -Weverything:
float f() {
float z = __null;
int x = -__null;
int arr[2]; arr[__null] = 10;
return z+x+arr[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 llvm.org  Tue Oct 18 01:39:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 01:39:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11163] New: ocaml bindings "make install" is broken
Message-ID: <bug-11163-206@http.llvm.org/bugs/>

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

           Summary: ocaml bindings "make install" is broken
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ojab at ojab.ru
                CC: llvmbugs at cs.uiuc.edu


llvm-trunk r142340.

llvm[3]: Installing Release+Asserts /usr/lib/ocaml/llvm.a
llvm[3]: Installing Release+Asserts /usr/lib/ocaml/llvm.cmx
make[3]: *** No rule to make target
`/sources/llvm-build/bindings/ocaml/llvm/Release+Asserts/META.llvm', needed by
`install-meta'.  Stop.
make[3]: Leaving directory `/sources/llvm-build/bindings/ocaml/llvm'
make[2]: *** [install] Error 1
make[2]: Leaving directory `/sources/llvm-build/bindings/ocaml'
make[1]: *** [ocaml/.makeinstall] Error 2
make[1]: Leaving directory `/sources/llvm-build/bindings'
make: *** [install] 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 llvm.org  Tue Oct 18 03:34:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 03:34:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11152] suggest %zu for size_t args to printf,
 at least in c99 mode
In-Reply-To: <bug-11152-206@http.llvm.org/bugs/>
References: <bug-11152-206@http.llvm.org/bugs/>
Message-ID: <20111018083431.8E73F3128075@llvm.org>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #1 from Hans Wennborg <hans at chromium.org> 2011-10-18 03:34:30 CDT ---
Fixed in r142342.

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

From bugzilla-daemon at llvm.org  Tue Oct 18 04:29:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 04:29:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11142] Testcase: suboptimal code in memory
	transportation
In-Reply-To: <bug-11142-206@http.llvm.org/bugs/>
References: <bug-11142-206@http.llvm.org/bugs/>
Message-ID: <20111018092906.350043128042@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

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

--- Comment #10 from Nick Lewycky <nicholas at mxc.ca> 2011-10-18 04:29:05 CDT ---
That's a completely different problem: your new testcase doesn't have
targetdata in it. If I add the targetdata line from your previous test:

  target datalayout =
"e-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-f80:32:32-v64:64:64-v128:128:128-a0:0:64"

and run it through opt -O2, we eliminate all but two memcpy's, both copying
directly from their globals @label369 and @label374.

We can't do better than that (eliminate the malloc+memcpy+free) because that
string is passed into @fwrite, and it's entirely possible that fwrite does
something like look at the address of the pointer it's given.

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

From bugzilla-daemon at llvm.org  Tue Oct 18 04:48:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 04:48:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11140] Fast nightly test buildbot failing
In-Reply-To: <bug-11140-206@http.llvm.org/bugs/>
References: <bug-11140-206@http.llvm.org/bugs/>
Message-ID: <20111018094817.EE85D3524002@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-10-18 04:48:17 CDT ---
Dgregor fixed this in commit 142187:

"When building a module, use the macro definitions on the command line
as part of the hash rather than ignoring them. This means we'll end up
building more module variants (overall), but it allows configuration
macros such as NDEBUG to work so long as they're specified via command
line. More to come in this space."

I don't understand why it fixed it, but hey :)

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

From bugzilla-daemon at llvm.org  Tue Oct 18 07:52:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 07:52:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11164] New: __sync_sub_and_fetch completely broken
	on ARM
Message-ID: <bug-11164-206@http.llvm.org/bugs/>

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

           Summary: __sync_sub_and_fetch completely broken on ARM
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu


This trivial program fails to compile with clang for ARMv7:

void die(int *obj) { __sync_sub_and_fetch(obj, 1); }

When using gas, we get this error:


$ echo 'void die(int *obj) { __sync_sub_and_fetch(obj, 1); }'|
~/WebOS/llvm/Debug+Asserts/bin/clang -B /opt/PalmPDK/arm-gcc/bin/
-ccc-host-triple arm-none-linux-gnueabi -march=armv7-a -x c -c -
/var/folders/cw/8wjq1rsd4tbb9cwd3wt6b3_m0000gn/T/--wz8N7B.s: Assembler
messages:
/var/folders/cw/8wjq1rsd4tbb9cwd3wt6b3_m0000gn/T/--wz8N7B.s:26: Error: garbage
following instruction -- `dmb ish'
/var/folders/cw/8wjq1rsd4tbb9cwd3wt6b3_m0000gn/T/--wz8N7B.s:37: Error: garbage
following instruction -- `dmb ish'
clang: error: assembler command failed with exit code 1 (use -v to see
invocation)

With the integrated assembler, it's a little more spectacular:


$ echo 'void die(int *obj) { __sync_sub_and_fetch(obj, 1); }' | clang
-ccc-host-triple arm-none-linux-gnueabi -march=armv7-a -x c -c - -integrated-as
Not implemented yet
0  clang             0x00000001057fa965 _ZL15PrintStackTracePv + 53
1  clang             0x00000001057fafcc _ZL13SignalHandleri + 364
2  libsystem_c.dylib 0x00007fff96c41cfa _sigtramp + 26
3  libsystem_c.dylib 0x00007fff6337a518 _sigtramp + 18446744072844707896
4  clang             0x00000001057facab raise + 27
5  clang             0x00000001057fad6a abort + 26
6  clang             0x0000000105784681 llvm::MCStreamer::EmitFnStart() + 49
7  clang             0x0000000105009f29
llvm::ARMException::BeginFunction(llvm::MachineFunction const*) + 41
8  clang             0x000000010500caa1 llvm::AsmPrinter::EmitFunctionHeader()
+ 1345
9  clang             0x000000010489c96b
llvm::AsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 43
10 clang             0x0000000104a7cd2c
llvm::ARMAsmPrinter::runOnMachineFunction(llvm::MachineFunction&) + 76
11 clang             0x000000010516725e
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110
12 clang             0x00000001056f1ade
llvm::FPPassManager::runOnFunction(llvm::Function&) + 478
13 clang             0x00000001056f1eaf
llvm::FPPassManager::runOnModule(llvm::Module&) + 127
14 clang             0x00000001056f2144
llvm::MPPassManager::runOnModule(llvm::Module&) + 516
15 clang             0x00000001056f28ec
llvm::PassManagerImpl::run(llvm::Module&) + 172
16 clang             0x00000001056f2dcd llvm::PassManager::run(llvm::Module&) +
29
17 clang             0x0000000103990e2b (anonymous
namespace)::EmitAssemblyHelper::EmitAssembly(clang::BackendAction,
llvm::raw_ostream*) + 1035
18 clang             0x00000001039909b8
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 104
19 clang             0x0000000103ae6920
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 656
20 clang             0x0000000103b278a9 clang::ParseAST(clang::Sema&, bool) +
889
21 clang             0x00000001037f5232
clang::ASTFrontendAction::ExecuteAction() + 258
22 clang             0x0000000103ae44ee clang::CodeGenAction::ExecuteAction() +
1182
23 clang             0x00000001037f4e35 clang::FrontendAction::Execute() + 357
24 clang             0x00000001037c1fce
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 974
25 clang             0x00000001037936f2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1170
26 clang             0x000000010377f204 cc1_main(char const**, char const**,
char const*, void*) + 1220
27 clang             0x000000010378cbaa main + 666
28 clang             0x000000010377ed34 start + 52
Stack dump:
0.    Program arguments: /Users/theraven/WebOS/llvm/Debug+Asserts/bin/clang
-cc1 -triple armv7-none-linux-gnueabi -emit-obj -mrelax-all -disable-free
-main-file-name - -mrelocation-model static -mdisable-fp-elim
-mconstructor-aliases -target-abi aapcs-linux -target-cpu cortex-a8 -mfloat-abi
soft -target-feature +soft-float-abi -target-linker-version 123.2.1
-momit-leaf-frame-pointer -coverage-file -.o -resource-dir
/Users/theraven/WebOS/llvm/Debug+Asserts/bin/../lib/clang/3.1
-fmodule-cache-path
/var/folders/cw/8wjq1rsd4tbb9cwd3wt6b3_m0000gn/T/clang-module-cache
-ferror-limit 19 -fmessage-length 200 -fno-signed-char -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fdiagnostics-show-option -fcolor-diagnostics -o -.o -x c - 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module '-'.
4.    Running pass 'ARM Assembly Printer' on function '@die'
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Error generating preprocessed source(s) - ignoring
input from stdin.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.

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

From bugzilla-daemon at llvm.org  Tue Oct 18 08:24:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 08:24:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11165] New: objective c exceptions are not catched
	on OpenBSD
Message-ID: <bug-11165-206@http.llvm.org/bugs/>

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

           Summary: objective c exceptions are not catched on OpenBSD
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sebastia at l00-bugdead-prods.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7472)
 --> (http://llvm.org/bugs/attachment.cgi?id=7472)
assembler output from clang -S on the test.m file

I'm on OpenBSD i386 5.0 -current, and use llvm/clang 3.0 (trunk 141482).
binutils on OpenBSD are version 2.15.

Since a couple of days David Chisnall tries to help me figuring out what the
problem is, now in the end, he suggested to open a bug report: here it is.

I have this test program, which works well when its compiled with gcc-4.2.1
that comes with the OpenBSD base system.
But when compiling with clang, the program aborts when it runs.

$ cat test.m
#import <Foundation/Foundation.h>


void bail_out ()
{
@throw [NSObject new];
}

int main()
{
@try {
//[NSObject thisDoesntExist];
//[NSException raise:@"TestException" format:@"This is an exception"];
bail_out();
}
@catch(id e) {}
}

I use this command line to compile the program:
clang -v -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -L/usr/local/lib -lobjc2 -pthread
-lgnustep-base -O0 -fexceptions -fobjc-exceptions -o test-clang

It doesn't matter if I add -integrated-as or not, it will abort.

when I compile the program with debugging symbols, the test program doesn't
abort:
clang -v -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -L/usr/local/lib -lobjc2 -pthread
-lgnustep-base -O0 -fexceptions -fobjc-exceptions -o test-clang -g

when I run it in gdb, then it aborts this way:
$ gdb ./test-clang                                                              
GNU gdb 6.3
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "i386-unknown-openbsd5.0"...
(gdb) r
Starting program: /home/sebastia/test-clang 

Program received signal SIGABRT, Aborted.
[Switching to process 17052, thread 0x80fd0c00]
0x0db4c73d in kill () from /usr/lib/libc.so.60.1
(gdb) thread apply all bt

Thread 3 (process 17052, thread 0x82921000):
#0  _thread_kern_sched (scp=0x0) at
/usr/src/lib/libpthread/uthread/uthread_kern.c:496
#1  0x027cc7c6 in _thread_kern_sched_state (state=PS_SLEEP_WAIT,
fname=0x227b91fc "/usr/src/lib/libpthread/uthread/uthread_nanosleep.c",
lineno=84) at /usr/src/lib/libpthread/uthread/uthread_kern.c:571
#2  0x027bf972 in nanosleep (time_to_sleep=0x7e26ff64,
time_remaining=0x7e26ff5c) at
/usr/src/lib/libpthread/uthread/uthread_nanosleep.c:84
#3  0x0db7b087 in sleep (seconds=30) at /usr/src/lib/libc/gen/sleep.c:45
#4  0x0d4ede71 in selector_table_collect_garbage (t=0x7f959ea0) at
hash_table.h:189
#5  0x0d4f003b in runloop (q=0x80ff4600) at toydispatch.c:197
#6  0x027c35ce in _thread_start () at
/usr/src/lib/libpthread/uthread/uthread_create.c:242
#7  0x0000002b in ?? ()
#8  0x00000000 in ?? ()

Thread 2 (process 17052, thread 0x82921800):
#0  _thread_kern_sched (scp=0x0) at
/usr/src/lib/libpthread/uthread/uthread_kern.c:496
#1  0x027cc75f in _thread_kern_sched_state_unlock (state=PS_COND_WAIT,
lock=0x86150558, fname=0x227b9e14
"/usr/src/lib/libpthread/uthread/uthread_cond.c", lineno=432) at
/usr/src/lib/libpthread/uthread/uthread_kern.c:602
#2  0x027c8ae7 in pthread_cond_timedwait (cond=0x227bb120, mutex=0x227bb11c,
abstime=0x898defc0) at /usr/src/lib/libpthread/uthread/uthread_cond.c:431
#3  0x027c3bae in _thread_gc (arg=0x0) at
/usr/src/lib/libpthread/uthread/uthread_gc.c:181
#4  0x027c35ce in _thread_start () at
/usr/src/lib/libpthread/uthread/uthread_create.c:242
#5  0x0000002b in ?? ()
#6  0x00000000 in ?? ()

Thread 1 (process 17052, thread 0x80fd0c00):
#0  0x0db4c73d in kill () from /usr/lib/libc.so.60.1
#1  0x0dbb2ec5 in abort () at /usr/src/lib/libc/stdlib/abort.c:68
#2  0x0d4e027a in objc_exception_throw (object=0x7ff56974) at
eh_personality.c:95
#3  0x1c000a93 in bail_out ()
#4  0x1c000aab in gnustep_base_user_main ()
#5  0xcfbc2c30 in ?? ()
#6  0x00000001 in ?? ()
#7  0x00000282 in ?? ()
#8  0x7e7ad568 in ?? ()
#9  0xcfbc2bec in ?? ()
---Type <return> to continue, or q <return> to quit---
#10 0x0bc01d37 in main (argc=-809751504, argv=0x1c000aab, env=0xcfbc2bbc) at
NSProcessInfo.m:976
#11 0x0bc01d37 in main (argc=1, argv=0xcfbc2c30, env=0xcfbc2c38) at
NSProcessInfo.m:976
#12 0x1c000887 in ___start ()
#13 0x1c000802 in _start ()


then tried to generate assembler output from clang, and assemble it with the as
from the binutils I got:
$ clang -S -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -O0 -fexceptions -fobjc-exceptions -o
test-clang.as
$ file test-clang.as
test-clang.as: Bio-Rad .PIC Image File 11785 x 26982, 25964 images in file
$ vi test-clang.as
$ as test-clang.as -o test-clang.o
test-clang.as: Assembler messages:
test-clang.as:35: Error: unknown pseudo-op: `.cfi_personality'
test-clang.as:37: Error: unknown pseudo-op: `.cfi_lsda'
test-clang.as:1558: Warning: setting incorrect section attributes for
.rodata.__objc_class_ref_NSObject
test-clang.as:1612: Warning: setting incorrect section attributes for
.rodata..objc_sel_namenew

David said to it:
This is needed for the .cfi directives to be understood. Clang now emits the
exception frame information as .cfi directives and leaves it up to the
assembler to generate them. Very old versions of GNU as did not support these,
which is why older compilers had to compute and generate these tables
themselves.

the results with and without -integrated-as. The result is always the same, the
test program aborts.

$ clang -c -integrated-as -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -O0 -fexceptions -fobjc-exceptions -o
test-clang.o
$ clang -Wl,-E test-clang.o -L/usr/local/lib -lobjc2 -pthread -lgnustep-base -o
test-clang
$ ./test-clang
Abort trap (core dumped)
$ clang -c -integrated-as -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -O0 -fexceptions -fobjc-exceptions -o
test-clang.o
$ gcc -Wl,-E test-clang.o -L/usr/local/lib -lobjc2 -pthread -lgnustep-base -o
test-clang
$ ./test-clang
Abort trap (core dumped)
$ clang -c -I/usr/local/include test.m -D_NATIVE_OBJC_EXCEPTIONS
-fconstant-string-class=NSConstantString -O0 -fexceptions -fobjc-exceptions -o
test-clang.o
$ gcc -Wl,-E test-clang.o -L/usr/local/lib -lobjc2 -pthread -lgnustep-base -o
test-clang
$ ./test-clang
Abort trap (core dumped)

It doesn't matter whether libobjc2 or gnustep-base is compiled with gcc or
clang. When I compile the test program with clang, it aborts, when I compile it
with gcc, it works.

attached is the assembler output when compiling the file witch clang -S.

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

From bugzilla-daemon at llvm.org  Tue Oct 18 08:59:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 08:59:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11166] New: Lots of compile time spent in
 LazyValueInfo::eraseBlock
Message-ID: <bug-11166-206@http.llvm.org/bugs/>

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

           Summary: Lots of compile time spent in
                    LazyValueInfo::eraseBlock
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


When compiling gcc-as-one-big-file at -O3, my profiler shows that most of the
compile time is spent in llvm::LazyValueInfo::eraseBlock:

     5.47%         llvm::LazyValueInfo::eraseBlock(llvm::BasicBlock*)
     3.43%         _int_malloc
     2.10%         llvm::Use::getImpliedUser() const
     1.51%         llvm::MachineInstr::addRegisterDead(unsigned int,
llvm::TargetRegisterInfo const*, bool)
...


Within LazyValueInfo::eraseBlock, most of the time is spent in this loop:

  for (DenseMap<LVIValueHandle, ValueCacheEntryTy>::iterator
       I = ValueCache.begin(), E = ValueCache.end(); I != E; ++I)
    I->second.erase(BB);

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

From bugzilla-daemon at llvm.org  Tue Oct 18 09:25:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 09:25:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11167] New: LLVM compiled binutils seg faults
Message-ID: <bug-11167-206@http.llvm.org/bugs/>

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

           Summary: LLVM compiled binutils seg faults
           Product: new-bugs
           Version: 2.8
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: brian-mokrzycki at uiowa.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7474)
 --> (http://llvm.org/bugs/attachment.cgi?id=7474)
Object file generated by LLVM for dis-buf.c of binutils 2.21

I believe what I am seeing is a bug in the LLVM toolchain when compiling a
custom branch of binutils 2.21.  I am able to compile this branch (binutils
2.21) with gcc-4.2.1 (Apple build 5666 dot 3) without issue. My configuration:

Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.8
  Optimized build.
  Built Mar 14 2011 (09:16:56).
  Host: x86_64-apple-darwin11
  Host CPU: penryn

On Mac OS X 10.7.2

While testing the LLVM compiled runtime of binutils, the disassembly runtime
would incur a segmentation fault.  Tracking this down with GDB, I was able to
isolate the rogue overwriting of a variable that was the source of the seg
fault.  The code in question, from dis-buf.c:30, function buffer_read_memory

 27 /* Get LENGTH bytes from info's buffer, at target address memaddr.
 28    Transfer them to myaddr.  */
 29 int
 30 buffer_read_memory (bfd_vma memaddr,
 31                     bfd_byte *myaddr,
 32                     unsigned int length,
 33                     struct disassemble_info *info)
 34 {
 35   unsigned int opb = info->octets_per_byte;
 36   unsigned int end_addr_offset = length / opb;
 37   unsigned int max_addr_offset = info->buffer_length / opb;
 38   unsigned int octets = (memaddr - info->buffer_vma) * opb;
 39 
 40   if (memaddr < info->buffer_vma
 41       || memaddr - info->buffer_vma > max_addr_offset
 42       || memaddr - info->buffer_vma + end_addr_offset > max_addr_offset)
 43     /* Out of bounds.  Use EIO because GDB uses it.  */
 44     return EIO;
 45   memcpy (myaddr, info->buffer + octets, length);
 46 
 47   return 0;
 48 }

Stepping through this function with GDB I discovered that bfd_byte *myaddr is
being overwritten line 38.  As shown in this GDB dump:


Breakpoint 3, wvfe_print_insn [inlined] () at
/Users/btm/Temp/binutils-git/binutils/opcodes/wvfe-dis.c:76

(gdb) s
buffer_read_memory (memaddr=0, myaddr=0x7fff5fbff560 "", length=8,
info=0x7fff5fbff908) at dis-buf.c:39
39      bfd_vma octets = (memaddr - info->buffer_vma) * opb;

(gdb) watch myaddr
Watchpoint 5: myaddr

(gdb) s
36      unsigned int end_addr_offset = length / opt;

(gdb) s
39      unsigned int octets = (memaddr - info->buffer_vma) * opb;

(gdb) s
Watchpoint 5: myaddr

Old value = (bfd_byte *) 0x7fff5fbff560 ""
New value = (bfd_byte *) 0x0
0x0000000100038db8 in buffer_read_memory (memaddr=0, myaddr=0x0, length=8,
info=0x7fff5fbff908) at dis-buf.c:39
39      unsigned int octets = (memaddr - info->buffer_vma) * opb;


 As can be seen, the variable myaddr should not be overwritten at this step nor
anywhere in this function.  The source file dis-buf.c was compiled with the
following line (where gcc points to gcc-llvm).

/bin/sh ./libtool --tag=CC   --mode=compile gcc -DHAVE_CONFIG_H -I.
-I../../../binutils/opcodes  -I. -I../../../binutils/opcodes -I../bfd
-I../../../binutils/opcodes/../include -I../../../binutils/opcodes/../bfd    -W
-Wall -Wstrict-prototypes -Wmissing-prototypes -Wshadow -Werror -g -O2 -MT
dis-buf.lo -MD -MP -MF .deps/dis-buf.Tpo -c -o dis-buf.lo
../../../binutils/opcodes/dis-buf.c   

I'm attaching the object file for dis-buf.c for disassembly purposes.  If more
information is needed please let me know.

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

From bugzilla-daemon at llvm.org  Tue Oct 18 11:39:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 11:39:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11127] Failed assertion:
 `!SpecializedTemplate.is<SpecializedPartialSpecialization*>() && "Already
 set to a class template partial specialization!"'
In-Reply-To: <bug-11127-206@http.llvm.org/bugs/>
References: <bug-11127-206@http.llvm.org/bugs/>
Message-ID: <20111018163936.7E5933128042@llvm.org>

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

Elias Pipping <pipping at exherbo.org> changed:

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

--- Comment #3 from Elias Pipping <pipping at exherbo.org> 2011-10-18 11:39:35 CDT ---
Losing track of all these assertion failures...

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

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

From bugzilla-daemon at llvm.org  Tue Oct 18 13:31:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 13:31:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11168] New: icu segfaults after being compiled with
 clang, behaves normal with gcc
Message-ID: <bug-11168-206@http.llvm.org/bugs/>

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

           Summary: icu segfaults after being compiled with clang, behaves
                    normal with gcc
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: balicki.aleksander at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I use xxxterm(web browser) and it depends on icu.

When I compile icu with gcc it works normally, but when I compile it on clang
it segfaults (attached backtrace) when entering on some sites (like google
calendar, google reader).

Tried with icu-4.8 and 4.8.1, same 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 llvm.org  Tue Oct 18 13:58:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 13:58:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11169] New: clang hangs/takes a really long time
 compiling sqlite
Message-ID: <bug-11169-206@http.llvm.org/bugs/>

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

           Summary: clang hangs/takes a really long time compiling sqlite
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Miscellaneous Instrumentation passes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jmuizelaar at mozilla.com
                CC: llvmbugs at cs.uiuc.edu


clang version 3.0 (http://llvm.org/git/clang.git
af37061fea31f3f1d0638edb5486e8d72c701522)

It is spending time in
llvm::InstCombiner::runOnFunction(llvm::Function&)
 llvm::InstCombiner::DoOneIteration(llvm::Function&, unsigned int)
  llvm::InstVisitor<llvm::InstCombiner,
llvm::Instruction*>::visit(llvm::Instruction&)
   llvm::InstVisitor<llvm::InstCombiner,
llvm::Instruction*>::visitLoad(llvm::LoadInst&)
    llvm::InstCombiner::visitLoadInst(llvm::LoadInst&)
     etc.

The preprocessed input is at:

http://people.mozilla.org/~jmuizelaar/sqlite3.i.gz

clang -O2 sqlite3.i

on OSX 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 llvm.org  Tue Oct 18 14:05:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 14:05:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11170] New: dllexport/dllimport should be allowed
 for full classes/structs
Message-ID: <bug-11170-206@http.llvm.org/bugs/>

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

           Summary: dllexport/dllimport should be allowed for full
                    classes/structs
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: vanboxem.ruben at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Currently, Clang does not support dll[ex|im]porting full classes, although this
is common practice and perfectly legal (see for example the Qt codebase).

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

From bugzilla-daemon at llvm.org  Tue Oct 18 14:18:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 14:18:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11171] New: BUILD_SHARED_LIBS is broken
Message-ID: <bug-11171-206@http.llvm.org/bugs/>

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

           Summary: BUILD_SHARED_LIBS is broken
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jabbey at arxan.com
                CC: llvmbugs at cs.uiuc.edu, ofv at wanadoo.es


On both x86_64 darwin and ppc darwin I'm seeing failures:


Undefined symbols for architecture x86_64:
  "vtable for llvm::raw_ostream", referenced from:
      llvm::raw_ostream::raw_ostream(bool)in gtest.cc.o
      llvm::raw_ostream::raw_ostream(bool)in gtest-death-test.cc.o
      llvm::raw_ostream::raw_ostream(bool)in gtest-port.cc.o
      llvm::raw_ostream::raw_ostream(bool)in gtest-typed-test.cc.o
  NOTE: a missing vtable usually means the first non-inline virtual member
function has no definition.
  "vtable for llvm::raw_os_ostream", referenced from:
      llvm::raw_os_ostream::raw_os_ostream(std::basic_ostream<char,
std::char_traits<char> >&)in gtest.cc.o
      llvm::raw_os_ostream::raw_os_ostream(std::basic_ostream<char,
std::char_traits<char> >&)in gtest-death-test.cc.o
      llvm::raw_os_ostream::raw_os_ostream(std::basic_ostream<char,
std::char_traits<char> >&)in gtest-port.cc.o
      llvm::raw_os_ostream::raw_os_ostream(std::basic_ostream<char,
std::char_traits<char> >&)in gtest-typed-test.cc.o
  NOTE: a missing vtable usually means the first non-inline virtual member
function has no definition.
  "llvm::raw_os_ostream::~raw_os_ostream()", referenced from:
      llvm::convertible_fwd_ostream::~convertible_fwd_ostream()in gtest.cc.o
      llvm::convertible_fwd_ostream::~convertible_fwd_ostream()in gtest.cc.o
      llvm::convertible_fwd_ostream::~convertible_fwd_ostream()in
gtest-death-test.cc.o
      llvm::convertible_fwd_ostream::~convertible_fwd_ostream()in
gtest-death-test.cc.o
      llvm::convertible_fwd_ostream::~convertible_fwd_ostream()in
gtest-port.cc.o
      llvm::convertible_fwd_ostream::~convertible_fwd_ostream()in
gtest-port.cc.o
      llvm::convertible_fwd_ostream::~convertible_fwd_ostream()in
gtest-typed-test.cc.o
      ...

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

From bugzilla-daemon at llvm.org  Tue Oct 18 14:20:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 14:20:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11172] New: Clang should support -nodefaultlibs
Message-ID: <bug-11172-206@http.llvm.org/bugs/>

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

           Summary: Clang should support -nodefaultlibs
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: missing-feature
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: austinenglish at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 10638


Needed when compiling Wine:

clang -o wine-preloader -static -nostartfiles -nodefaultlibs
-Wl,-Ttext=0x7c400000 preloader.o ../libs/port/libwine_port.a
LD_LIBRARY_PATH="../libs/wine:$LD_LIBRARY_PATH" ../tools/sfnt2fnt -o
vgas1257.fon -d 128 ./system.ttf 16,1257,7
clang: warning: argument unused during compilation: '-nodefaultlibs'
Can't find EBLC table

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

From bugzilla-daemon at llvm.org  Tue Oct 18 14:23:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 14:23:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11173] New: Dragonegg should support -fno-builtin
Message-ID: <bug-11173-206@http.llvm.org/bugs/>

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

           Summary: Dragonegg should support -fno-builtin
           Product: dragonegg
           Version: trunk
          Platform: PC
               URL: http://bugs.winehq.org/show_bug.cgi?id=28050
        OS/Version: Linux
            Status: NEW
          Keywords: missing-feature
          Severity: enhancement
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: austinenglish at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 10682


Needed when compiling wine:
austin at debian:~/wine-git/loader$ make
llvm-gcc -o wine-preloader -static -nostartfiles -nodefaultlibs
-Wl,-Ttext=0x7c400000 preloader.o ../libs/port/libwine_port.a
preloader.o: In function `set_process_name':
/home/austin/wine-git/loader//preloader.c:455: undefined reference to `memset'
preloader.o: In function `map_so_lib':
/home/austin/wine-git/loader//preloader.c:455: undefined reference to `memset'
collect2: ld returned 1 exit status
make: *** [wine-preloader] Error 1

clang is synthesizing a call to memset, breaking the wine preloader. Disabling
optimization works around it.

See also http://bugs.winehq.org/show_bug.cgi?id=28050

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

From bugzilla-daemon at llvm.org  Tue Oct 18 15:11:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 15:11:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11174] New: #define
	__GCC_HAVE_SYNC_COMPARE_AND_SWAP_
Message-ID: <bug-11174-206@http.llvm.org/bugs/>

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

           Summary: #define __GCC_HAVE_SYNC_COMPARE_AND_SWAP_
           Product: clang
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: desrt at desrt.ca
                CC: llvmbugs at cs.uiuc.edu




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

From bugzilla-daemon at llvm.org  Tue Oct 18 16:15:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 16:15:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11164] __sync_sub_and_fetch completely broken on ARM
In-Reply-To: <bug-11164-206@http.llvm.org/bugs/>
References: <bug-11164-206@http.llvm.org/bugs/>
Message-ID: <20111018211531.1BA883128034@llvm.org>

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

David Chisnall <csdavec at swan.ac.uk> changed:

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

--- Comment #7 from David Chisnall <csdavec at swan.ac.uk> 2011-10-18 16:15:30 CDT ---
Ah, the -integrated-as crash was caused by my local copy enabling the ARM EHABI
stuff.  Disabling it again works.  I'll assume that the external as works with
a newer gas - as long as there is some way of generating ARM ELF objects, I'm
happy...

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

From bugzilla-daemon at llvm.org  Tue Oct 18 17:28:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 17:28:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11175] New: LoopRotation pass too restrictive
Message-ID: <bug-11175-206@http.llvm.org/bugs/>

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

           Summary: LoopRotation pass too restrictive
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pickensd at synopsys.com
                CC: llvmbugs at cs.uiuc.edu


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

Attached is a test case that illustrates how GCC generates dramatically
superior code for a loop for ARM. LLVM could do something comparable if the
LoopRotation pass would not reject loops that have more than one exit. If
LoopRotation would properly handle such loops, then induction-variable analysis
and LICM would have more opportunities to clean things up (as is apparently
done in GCC).

Compiled with -O3, the LLVM generates the following loop code of 10
instructions:

.LBB0_1:                                @ %while.cond.i
                                        @ =>This Inner Loop Header: Depth=1
        add     r1, r0, #5
        cmp     r1, #1
        mov     r1, #0
        blt     .LBB0_3
        ldr     r2, [r4, -r0, lsl #2]
        ldr     r3, [r5, -r0, lsl #2]
        sub     r0, r0, #1
        mov     r1, #1
        tst     r3, r2
        beq     .LBB0_1


By contrast GCC generates the following 6-instruction loop:


.L3:
        ldr     r0, [r3], #4
        ldr     r1, [r2, #4]!
        tst     r0, r1
        bne     .L4
        cmp     r3, ip
        bne     .L3

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

From bugzilla-daemon at llvm.org  Tue Oct 18 17:32:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 17:32:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11176] New: Failed assertion:
 `TemplateTypeParm->getDepth() == 0 && "Can't deduce with depth > 0"'
Message-ID: <bug-11176-206@http.llvm.org/bugs/>

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

           Summary: Failed assertion: `TemplateTypeParm->getDepth() == 0
                    && "Can't deduce with depth > 0"'
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7478)
 --> (http://llvm.org/bugs/attachment.cgi?id=7478)
invalid code

% clang++ -c dirneucoupling-reduced.ii
[..]
clang: SemaTemplateDeduction.cpp:1008: Sema::TemplateDeductionResult
DeduceTemplateArguments(clang::Sema &, clang::TemplateParameterList *,
clang::QualType, clang::QualType, clang::sema::TemplateDeductionInfo &,
SmallVectorImpl<clang::DeducedTemplateArgument> &, unsigned int, bool,
SmallVectorImpl<RefParamPartialOrderingComparison> *): Assertion
`TemplateTypeParm->getDepth() == 0 && "Can't deduce with depth > 0"' failed.
0  libLLVM-3.0svn.so 0x00007ffff73fffff
1  libLLVM-3.0svn.so 0x00007ffff7400529
2  libpthread.so.0   0x00007ffff64aaf70
3  libc.so.6         0x00007ffff57c85c5 gsignal + 53

4  libc.so.6         0x00007ffff57c98c5 abort + 389
5  libc.so.6         0x00007ffff57c1235 __assert_fail + 245
6  clang             0x000000000098ab44
7  clang             0x00000000009a30c9
8  clang             0x00000000009a2470
9  clang             0x00000000009842dd
clang::Sema::DeduceTemplateArguments(clang::ClassTemplatePartialSpecializationDecl*,
clang::TemplateArgumentList const&, clang::sema::TemplateDeductionInfo&) + 205
10 clang             0x00000000009ad57a
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 650
11 clang             0x00000000009e572d
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::PartialDiagnostic const&, std::pair<clang::SourceLocation,
clang::PartialDiagnostic>) + 221
12 clang             0x00000000009dde39
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
unsigned int) + 105
13 clang             0x0000000000839c0a
clang::Sema::CheckFieldDecl(clang::DeclarationName, clang::QualType,
clang::TypeSourceInfo*, clang::RecordDecl*, clang::SourceLocation, bool,
clang::Expr*, bool, clang::SourceLocation, clang::AccessSpecifier,
clang::NamedDecl*, clang::Declarator*) + 202
14 clang             0x0000000000839a1d clang::Sema::HandleField(clang::Scope*,
clang::RecordDecl*, clang::SourceLocation, clang::Declarator&, clang::Expr*,
bool, clang::AccessSpecifier) + 1005
15 clang             0x000000000085c1f8
clang::Sema::ActOnCXXMemberDeclarator(clang::Scope*, clang::AccessSpecifier,
clang::Declarator&, clang::ASTMultiPtr<clang::TemplateParameterList*>,
clang::Expr*, clang::VirtSpecifiers const&, bool) + 1656
16 clang             0x000000000078ea32
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 4930
17 clang             0x000000000078c9e6
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 2230
18 clang             0x000000000078bb3c
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 4780
19 clang             0x000000000077cf3f
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 2927
20 clang             0x000000000078ded2
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 2018
21 clang             0x0000000000768c1d
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier, clang::AttributeList*) + 77
22 clang             0x0000000000768a04
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 740
23 clang             0x000000000076864f
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 351
24 clang             0x000000000078dc9a
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 1450
25 clang             0x000000000078c9e6
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 2230
26 clang             0x000000000078bb3c
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 4780
27 clang             0x000000000077cf3f
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 2927
28 clang             0x0000000000768e98
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier, clang::AttributeList*) + 712
29 clang             0x0000000000768a04
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 740
30 clang             0x000000000076864f
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier, clang::AttributeList*) + 351
31 clang             0x000000000077bf30
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 384
32 clang             0x00000000007710a7
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1655
33 clang             0x00000000007709be
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 254
34 clang             0x000000000075801e clang::ParseAST(clang::Sema&, bool) +
318
35 clang             0x000000000066d351 clang::CodeGenAction::ExecuteAction() +
769
36 clang             0x0000000000566f37
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 983
37 clang             0x0000000000551bb0
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2832
38 clang             0x000000000054992b cc1_main(char const**, char const**,
char const*, void*) + 5787
39 clang             0x000000000054e26a main + 634
40 libc.so.6         0x00007ffff57b4c7d __libc_start_main + 253
41 clang             0x00000000005481c9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name dirneucoupling-reduced.ii
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.21.1
-momit-leaf-frame-pointer -coverage-file dirneucoupling-reduced.o -resource-dir
/usr/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19 -fmessage-length
238 -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak
-fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o dirneucoupling-reduced.o -x c++-cpp-output
dirneucoupling-reduced.ii 
1.      dirneucoupling-reduced.ii:7:36: current parser token '='
2.      dirneucoupling-reduced.ii:2:1: parsing struct/union/class body
'Rotation'
3.      dirneucoupling-reduced.ii:5:1: parsing struct/union/class body
'Rotation'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.
%

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

From bugzilla-daemon at llvm.org  Tue Oct 18 18:54:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 18:54:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11169] clang hangs/takes a really long time
	compiling sqlite
In-Reply-To: <bug-11169-206@http.llvm.org/bugs/>
References: <bug-11169-206@http.llvm.org/bugs/>
Message-ID: <20111018235411.1D3263524002@llvm.org>

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

Jeff Muizelaar <jmuizelaar at mozilla.com> changed:

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

--- Comment #4 from Jeff Muizelaar <jmuizelaar at mozilla.com> 2011-10-18 18:54:10 CDT ---
I was using the wrong build of clang. Sorry.

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

From bugzilla-daemon at llvm.org  Tue Oct 18 19:24:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 19:24:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11177] New: 3.0rc1:
 bindings/ocaml/llvm/Release/META.llvm not created
Message-ID: <bug-11177-206@http.llvm.org/bugs/>

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

           Summary: 3.0rc1: bindings/ocaml/llvm/Release/META.llvm not
                    created
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: oneill+llvmbugs at cs.hmc.edu
                CC: llvmbugs at cs.uiuc.edu


Testing the 3.0rc1 build, make install fails with the following error

make[3]: *** No rule to make target
`/somewhere-or-other/llvm-3.0rc1/build-3.0rc1-Linux/bindings/ocaml/llvm/Release/META.llvm',
needed by `install-meta'.  Stop.
make[3]: *** Waiting for unfinished jobs....

Running

    cp -p bindings/ocaml/llvm/META.llvm bindings/ocaml/llvm/Release/META.llvm

... allowed the install to complete.

I suspect this issue only shows up for people with ocaml installed.

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

From bugzilla-daemon at llvm.org  Tue Oct 18 19:44:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 19:44:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11178] New: Mac JIT code fails on 32-bit compile of
 LLVM - LLVM 2.9 OK, 64-bit OK
Message-ID: <bug-11178-206@http.llvm.org/bugs/>

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

           Summary: Mac JIT code fails on 32-bit compile of LLVM - LLVM
                    2.9 OK, 64-bit OK
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nickwalters99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I am trying to run this test program via JIT on my Mac (10.7.1) also tested
10.7.2 where I have compiled the latest LLVM code for 32-bit and it is not
working properly. Running the same code against LLVM 2.9 works fine. I also
tried recompiling my same checkout of LLVM as 64-bit and re-compiled my test
program and that works fine, for some reason the 32-bit version is yielding
unexpected behavior. I believe I am linking with all of the required LLVM .a
files. I am building LLVM with CMake using:

cmake -DCMAKE_BUILD_TYPE="Release" -DCMAKE_OSX_ARCHITECTURES="i386" ../llvm)

Here's my code:

#include <iostream>

#include "llvm/LLVMContext.h"
#include "llvm/Module.h"
#include "llvm/Constants.h"
#include "llvm/DerivedTypes.h"
#include "llvm/Instructions.h"
#include "llvm/ExecutionEngine/JIT.h"
#include "llvm/ExecutionEngine/Interpreter.h"
#include "llvm/ExecutionEngine/GenericValue.h"
#include "llvm/Support/TargetSelect.h"
#include "llvm/Support/ManagedStatic.h"
#include "llvm/Support/raw_ostream.h"
#include "llvm/Support/IRBuilder.h"

using namespace std;
using namespace llvm;

int main(int argc, char** argv){
  InitializeNativeTarget();

  LLVMContext context;

  Module* module = new Module("test", context);

  vector<Type*> args;
  args.push_back(Type::getInt32Ty(context));

  FunctionType* ft = FunctionType::get(Type::getInt32Ty(context),
                       args, false);

  Function* f = Function::Create(ft,
                 GlobalValue::ExternalLinkage,
                 "f", module);

  Value* arg = f->arg_begin();

  BasicBlock* bb = BasicBlock::Create(context, "entry", f);

  IRBuilder<> builder(bb);

  Value* one = builder.getInt32(1);

  Value* v = builder.CreateAdd(one, arg);
  builder.CreateRet(v);

  ExecutionEngine* engine = EngineBuilder(module).create();

  void* vpf = engine->getPointerToFunction(f);

  int32_t (*fp)(int32_t) = 
    (int32_t (*)(int32_t))(intptr_t)vpf;

  int32_t out = fp(10);

  cout << "out is: " << out << endl;

  return 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 llvm.org  Tue Oct 18 20:12:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 20:12:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11090] Extremely slow compilation + high memory
 usage in "Loop Strength Reduction"
In-Reply-To: <bug-11090-206@http.llvm.org/bugs/>
References: <bug-11090-206@http.llvm.org/bugs/>
Message-ID: <20111019011203.B2EDE3524002@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #8 from Andrew Trick <atrick at apple.com> 2011-10-18 20:12:02 CDT ---
I reapplied this patch in r141895 and forgot to close the bug. This was pulled
into 3.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 llvm.org  Tue Oct 18 20:13:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 20:13:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8746] Scalar evolution loops forever (after 2h I
 got impatient :) on input file
In-Reply-To: <bug-8746-206@http.llvm.org/bugs/>
References: <bug-8746-206@http.llvm.org/bugs/>
Message-ID: <20111019011350.3B2833128034@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #7 from Andrew Trick <atrick at apple.com> 2011-10-18 20:13:49 CDT ---
This was pulled into 3.0 release.

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

From bugzilla-daemon at llvm.org  Tue Oct 18 21:11:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 18 Oct 2011 21:11:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11171] BUILD_SHARED_LIBS is broken
In-Reply-To: <bug-11171-206@http.llvm.org/bugs/>
References: <bug-11171-206@http.llvm.org/bugs/>
Message-ID: <20111019021117.E547C3128042@llvm.org>

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

jabbey at arxan.com changed:

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

--- Comment #3 from jabbey at arxan.com 2011-10-18 21:11:17 CDT ---
Fixed in r142464

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

From bugzilla-daemon at llvm.org  Wed Oct 19 00:20:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 00:20:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9789] crash after error in non-type variadic
 template parameters
In-Reply-To: <bug-9789-206@http.llvm.org/bugs/>
References: <bug-9789-206@http.llvm.org/bugs/>
Message-ID: <20111019052042.E1EF93128034@llvm.org>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #5 from David Blaikie <dblaikie at gmail.com> 2011-10-19 00:20:42 CDT ---
Fixed by pr142473.

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

From bugzilla-daemon at llvm.org  Wed Oct 19 05:40:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 05:40:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2577] Use static profile info from __builtin_expect
 in optimizer to improve code
In-Reply-To: <bug-2577-206@http.llvm.org/bugs/>
References: <bug-2577-206@http.llvm.org/bugs/>
Message-ID: <20111019104037.E42D12A6C124@llvm.org>

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

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
                 CC|                            |wendling at apple.com
         Resolution|                            |FIXED

--- Comment #7 from Chandler Carruth <chandlerc at gmail.com> 2011-10-19 05:40:37 CDT ---
Fixed with the following commits:

r142168 -- fix most egregious corruption of probability metadata
r142491 -- add testing facility to ensure we actually get expect into
probabilities
r142492 -- add support for expects which feed branches to the probability
analysis
r142493 -- add support for expects which feed switches to the probability
analysis

We're now back to the state of 1) the probabilities haven't been completely
audited, and 2) we only have a few passes that take advantage of them. But that
was the desired state for closing this PR. __builtin_expect now influences code
generation.


Chris, you had expressed an interest in pulling these into 3.0 -- it seems
somewhat borderline to me though. I'll leave the decision to you and Bill to
sort out. =]

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

From bugzilla-daemon at llvm.org  Wed Oct 19 08:47:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 08:47:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11087] Save code space on ARM Thumb with
	PC-relative LDR
In-Reply-To: <bug-11087-206@http.llvm.org/bugs/>
References: <bug-11087-206@http.llvm.org/bugs/>
Message-ID: <20111019134735.B605E3128018@llvm.org>

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

James Molloy <james.molloy at arm.com> changed:

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

--- Comment #14 from James Molloy <james.molloy at arm.com> 2011-10-19 08:47:35 CDT ---
Addendum, in Thumb mode (cortex-a8), there's a 4.9% code size improvement.

    934640      14370     125588      15764      69808        128   thumb ToT /
-O3
    842002      14066     125810      15764      69776        128   thumb ToT /
-Os
    802688      50592     125804      15764      69776        128   thumb
Patched / -Os

Again with a massive increase in literal pool size to boot. I may have a look
at optimising literal pool usage.

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

From bugzilla-daemon at llvm.org  Wed Oct 19 10:42:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 10:42:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11179] New: Crash on unsigned short template
	parameter
Message-ID: <bug-11179-206@http.llvm.org/bugs/>

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

           Summary: Crash on unsigned short template parameter
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: klimek at google.com
                CC: llvmbugs at cs.uiuc.edu


template <unsigned short T>
class X {
};

template <unsigned short T>
inline void g(X<T>& x) {
}

void f() {
  g(X<42>());
}

$CC -cc1 -fsyntax-only t.cc
t.cc:10:3: error: no matching function for call to 'g'
  g(X<42>());
  ^
Unexpected type for integer literal!
UNREACHABLE executed at
/home/klimek/local/git/llvm-1/tools/clang/lib/AST/StmtPrinter.cpp:661!
Stack dump:
0.      Program arguments: /usr/local/google/users/klimek/system/bin/clang -cc1
-fsyntax-only t.cc 
1.      t.cc:10:12: current parser token ')'
2.      t.cc:9:10: parsing function body 'f'
3.      t.cc:9:10: in compound statement ('{}')
Aborted

The problem is that for the instantiation of 'g' the template parameter becomes
an IntegerLiteral of type 'unsigned short', which is not handled in the case.

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

From bugzilla-daemon at llvm.org  Wed Oct 19 11:13:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 11:13:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11180] New: unresolved symbol when taking a local
 label's address
Message-ID: <bug-11180-206@http.llvm.org/bugs/>

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

           Summary: unresolved symbol when taking a local label's address
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pageexec at freemail.hu
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 4068


Created an attachment (id=7480)
 --> (http://llvm.org/bugs/attachment.cgi?id=7480)
preprocessed source

clang/llvm has for some time supported local labels that linux makes use of:

#define _THIS_IP_  ({ __label__ __here; __here: (unsigned long)&&__here; })

this support also seems to be partially broken lately, the produced asm
sometimes refers to an unresolved symbol instead of the label's address but
seemingly only when the above macro is used in a static inline function and an
out-of-line body is generated for this function.

the attached case reproduces the problem for the function try_module_get on
linux/amd64. the following command line was used to compile it:

clang -c -nostdinc -Wall -Wundef -Wstrict-prototypes -Wno-trigraphs -W
-Wno-unused-parameter -Wno-missing-field-initializers -Wno-self-assign
-Wno-unused-value -Wno-format -mno-sse -Wno-unknown-warning-option
-fcatch-undefined-behavior -fno-strict-aliasing -fno-common
-Werror-implicit-function-declaration -Wno-format-security
-fno-delete-null-pointer-checks -Wno-empty-body -O2 -m64 -march=core2
-mno-red-zone -mcmodel=kernel -funit-at-a-time -maccumulate-outgoing-args -pipe
-Wno-sign-compare -fno-asynchronous-unwind-tables -mno-sse -mno-mmx -mno-sse2
-mno-3dnow -Wframe-larger-than=2048 -fno-stack-protector
-Wno-unused-but-set-variable -fno-omit-frame-pointer
-fno-optimize-sibling-calls -g -femit-struct-debug-baseonly -pg
-Wdeclaration-after-statement -Wno-pointer-sign -fno-strict-overflow
-fconserve-stack -o anon_inodes.o anon_inodes.i

the resulting asm shows one inlined body of try_module_get in
anon_inode_getfile with a correct (resolved) reference to within the function
whereas the out-of-line copy has a reference to an unresolved symbol .L<xxx> 
(another, perhaps related, issue is why an out-of-line body was generated in
the first place as the function gets inlined into every caller and its address
is not taken in the given compilation unit as far as i can tell).

PS: since this is the last remaining bug that prevents compiling linux (modulo
the usual patches needed on the linux side), it'd be nice if the fix could be
backported to the 3.0 branch as well.

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

From bugzilla-daemon at llvm.org  Wed Oct 19 14:56:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 14:56:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11181] New: suboptimal code generation in strlen
 constant folding
Message-ID: <bug-11181-206@http.llvm.org/bugs/>

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

           Summary: suboptimal code generation in strlen constant folding
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


target datalayout =
"e-p:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:32:64-f32:32:32-f64:32:64-f80:32:32-v64:64:64-v128:128:128-a0:0:64"

declare i32 @strlen(i8* noalias nocapture) nounwind readonly
@nullstring = internal constant i8 0

define i32 @main() {
  %len = tail call i32 @strlen(i8* @nullstring) nounwind
  ret i32 %len
}

strlen does not seem to look at the data behind @nullstring when it does not
have a specific format

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

From bugzilla-daemon at llvm.org  Wed Oct 19 15:16:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 15:16:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11182] New: Crash "A global turned into a function?"
Message-ID: <bug-11182-206@http.llvm.org/bugs/>

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

           Summary: Crash "A global turned into a function?"
           Product: dragonegg
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: gmalecha at eecs.harvard.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7481)
 --> (http://llvm.org/bugs/attachment.cgi?id=7481)
file that causes the error

Trying to compile a file, I got the following error. I've attached the file
(after preprocessing) that causes the problem.

$ /usr/bin/gcc -fplugin=/home/gmalecha/devel/dragonegg/dragonegg.so
-fplugin-arg-dragonegg-emit-ir -S -c test.c -o /tmp/tmpa9Jdjm.ll
cc1: /home/gmalecha/devel/dragonegg/src/Backend.cpp:1121: llvm::Value*
make_decl_llvm(tree_node*): Assertion `G && G->isDeclaration() && "A global
turned into a function?"' failed.
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_FINISH_UNIT               | dragonegg
PLUGIN_FINISH                    | dragonegg
PLUGIN_START_UNIT                | dragonegg
PLUGIN_ALL_IPA_PASSES_END        | dragonegg
longjmp.c:48:1: internal compiler error: Aborted
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://bugs.gentoo.org/> for instructions.

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

From bugzilla-daemon at llvm.org  Wed Oct 19 16:47:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 16:47:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11183] New: Compiler optimized neon vector
 comparison result differs from result obtained at runtime
Message-ID: <bug-11183-206@http.llvm.org/bugs/>

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

           Summary: Compiler optimized neon vector comparison result
                    differs from result obtained at runtime
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-gcc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dcope.public at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I am using llvm-gcc on MacOS X.  I am using gcc version 4.2.1 (LLVM build
2377).  I am cross compiling for an ARM iOS device with neon instruction
support enabled.  (I can provide detailed compiler command line options if
required.)

It appears that in optimized builds the compiler is examining some constants in
my program and then eliminating some calculations (i.e. it precomputes the
result of a sequence of operation and prints out a constant value).  This
optimization would be fine, but the result of this comparison does not match
the result that would have been generated at runtime on the target.

Here is some sample code that demonstrates the problem.


#include <stdio.h>
#include <string.h>
#include <arm_neon.h>


volatile float32x4_t temp = { 1e-040f, 1e-040f, 1e-040f, 1e-040f };

int main(int argc, char**argv)
{
//#define COMPILER_UNKNOWN_CONSTANT
#ifdef COMPILER_UNKNOWN_CONSTANT
    float32x4_t smallValue;
    memcpy(&smallValue, (void*)&temp, sizeof(temp));
#else
    float32x4_t smallValue = { 1e-040f, 1e-040f, 1e-040f, 1e-040f };
#endif
    float32x4_t zero = { 0.0f, 0.0f, 0.0f, 0.0f };
    uint32x4_t compare = vceqq_f32(smallValue, zero);
    printf("compare result is 0x%x\n", vgetq_lane_u32(compare, 0));

    return 0;
}


In an optimized build (-O3) this code will print out 0x0.  However in a debug
build the program will output 0xffffffff.  The program will also output
0xffffffff in optimized builds if smallValue's value can't be determined by the
compiler at compile time (i.e. by defining COMPILER_UNKNOWN_CONSTANT).

>From what I understand, the compiler is allowed to pre-compute the result of a
calculation, but that value should match the value that would be computed at
runtime on the target platform.

So, I believe that the test should be printing out 0xffffff in all cases.

I have also encountered this issue when using clang to compile similar code, so
I believe the root of the problem is actually in the LLVM backend.  However I
decided to submit this bug under llvm-gcc since I haven't verified that is the
case.

Is this in fact a bug in LLVM as I suspect, or is the compiler's generated code
actually correct in this situation?

Thanks,
Dave

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

From bugzilla-daemon at llvm.org  Wed Oct 19 16:47:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 16:47:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11167] LLVM compiled binutils seg faults
In-Reply-To: <bug-11167-206@http.llvm.org/bugs/>
References: <bug-11167-206@http.llvm.org/bugs/>
Message-ID: <20111019214751.64AAD3128018@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-10-19 16:47:50 CDT ---
Yes, please use clang (or dragon egg).  llvm-gcc is not supported anymore.  If
you're having an issue with an apple build, make sure to upgrade to Xcode 4.2. 
IF that doesn't work, please file a bug at bugreporter.apple.com

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

From bugzilla-daemon at llvm.org  Wed Oct 19 18:40:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 18:40:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11184] New: SSE: incorrect code generated for i8
 vector shuffles
Message-ID: <bug-11184-206@http.llvm.org/bugs/>

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

           Summary: SSE: incorrect code generated for i8 vector shuffles
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


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

The attached test case generates an <8xi8> vector with values <1 2 3 4 5 6 7 8>
using a shuffle of 2 <4xi8> vectors and stores it to memory.  With top-of-tree,
it seems that incorrect values are being stored; the attached test program
should print out "1 2 3 4 5 6 7 8" but instead prints the last 4 values,
repeated twice:

% llc -filetype=obj bug.ll -o bug.o && clang bug.cpp bug.o && ./a.out
5  6  7  8  5  6  7  8  
%

Some archaeology in the checkins indicates that the enabling of element
promotion type legalization broke this.  If I check out the version immediately
before that one, I get the expected result:

% llc -filetype=obj bug.ll -o bug.o && clang bug.cpp bug.o && ./a.out
1  2  3  4  5  6  7  8  
%


Author: Nadav Rotem <nadav.rotem at intel.com>
Date:   Sun Oct 16 20:31:33 2011 +0000

    Enable element promotion type legalization by deafault.
    Changed tests which assumed that vectors are legalized by widening them.



    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 142152
91177308-0d34-0410-b5e6-96231b3b80d8

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

From bugzilla-daemon at llvm.org  Wed Oct 19 18:50:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 18:50:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11111] clang 2.9 and svn miscompiles MPFR 3.1.0
In-Reply-To: <bug-11111-206@http.llvm.org/bugs/>
References: <bug-11111-206@http.llvm.org/bugs/>
Message-ID: <20111019235002.3E5FB3164002@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #16 from Bill Wendling <wendling at apple.com> 2011-10-19 18:50:01 CDT ---
Pulled into 3.0 branch.

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

From bugzilla-daemon at llvm.org  Wed Oct 19 18:54:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 18:54:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10324] -fms-extensions doesn't set __STDC__
In-Reply-To: <bug-10324-206@http.llvm.org/bugs/>
References: <bug-10324-206@http.llvm.org/bugs/>
Message-ID: <20111019235430.D29EE2A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-19 18:54:30 CDT ---
r142554.

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

From bugzilla-daemon at llvm.org  Wed Oct 19 19:34:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 19:34:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11181] suboptimal code generation in strlen
	constant folding
In-Reply-To: <bug-11181-206@http.llvm.org/bugs/>
References: <bug-11181-206@http.llvm.org/bugs/>
Message-ID: <20111020003454.9AFAB2A6C12D@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nlewycky at google.com
         Resolution|                            |FIXED
         AssignedTo|unassignedbugs at nondot.org   |nlewycky at google.com

--- Comment #2 from Nick Lewycky <nlewycky at google.com> 2011-10-19 19:34:54 CDT ---
Fixed in r142558. Thanks for the testcase!

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

From bugzilla-daemon at llvm.org  Wed Oct 19 20:32:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 20:32:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11185] New: Add checks for setting NSError
	**outError
Message-ID: <bug-11185-206@http.llvm.org/bugs/>

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

           Summary: Add checks for setting NSError **outError
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: tjw at me.com
                CC: llvmbugs at cs.uiuc.edu


If you are implementing a method or function with a return type that can be
used as a condition, and your method takes an "NSError **" argument, then
ensure that all paths set the outError (if non-NULL) or pass outError down to
other methods/functions that can fill it out.

Passing outError down to a void-returning function or method should mark that
path as having set outError (on the presumption that it is a utility function
that fulfills this purpose).

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

From bugzilla-daemon at llvm.org  Wed Oct 19 20:39:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 20:39:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11186] New: Check for incorrect use of out-error
Message-ID: <bug-11186-206@http.llvm.org/bugs/>

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

           Summary: Check for incorrect use of out-error
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: tjw at me.com
                CC: llvmbugs at cs.uiuc.edu


NSError usage says that you shouldn't look at what was written into an outError
unless your call to the method/function that filled it returns a value that
results in a false condition check.

That is, if you have

  - (BOOL)foo:(NSError **)outError;

then this should be valid:

   NSError *error;
   if (![self foo:&error]) {
     ... do something with "error"
   }

but this should produce an diagnostic:

  NSError *error;
  [self foo:&error];
  if (error) {
    ...
  }

Non-condition return type methods/functions should be considered OK, though.
These are often used as utility functions to fill out NSError objects:

static void _makeError(NSString *domain, NSInteger code, NSError **outError) {
    if (outError) {
        ... make an 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 llvm.org  Wed Oct 19 20:47:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 19 Oct 2011 20:47:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11187] New: Add checks that completionHandlers are
	called
Message-ID: <bug-11187-206@http.llvm.org/bugs/>

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

           Summary: Add checks that completionHandlers are called
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: tjw at me.com
                CC: llvmbugs at cs.uiuc.edu


Several Cocoa APIs now take completion handler blocks and failure to call those
completion handlers results in hard to debug errors and deadlocks.

clang-sa could have an annotation on block arguments (say
"__attribute__((must_call))" for the sake of argument) and it could
automatically apply that if the block argument or method name fragment is
called 'completionHandler'.

For example:

- (void)doSomethingAsync:(void (^)(void))completionHandler;
{
    if (!thing1Works) {
        if (completionHandler)
            completionHandler(); // OK
        return;
    }

    return; // diagnostic since the completionHandler wasn't called
}

This would need to handle the pattern where the completionHandler is destined
to be invoked on another queue:

- (void)doSomethingAsync:(void (^)(NSError *errorOrNil))completionHandler;
{
    NSError *error;

    ... do some stuff ...

    if (completionHandler) {
        [[NSOperationQueue mainQueue] addOperationWithBlock:^{
            completionHandler(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 llvm.org  Thu Oct 20 02:16:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 02:16:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11096] __builtin_expect-based machine basic block
	reordering
In-Reply-To: <bug-11096-206@http.llvm.org/bugs/>
References: <bug-11096-206@http.llvm.org/bugs/>
Message-ID: <20111020071658.3D8CC3128018@llvm.org>

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

Richard Smith <richard-llvm at metafoo.co.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|LATER                       |
         AssignedTo|unassignedbugs at nondot.org   |chandlerc at gmail.com
            Summary|__builtin_expect-based      |__builtin_expect-based
                   |machine basic block         |machine basic block
                   |reordering not working in   |reordering
                   |simple cases                |
           Severity|normal                      |enhancement

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

From bugzilla-daemon at llvm.org  Thu Oct 20 02:50:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 02:50:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10632] MC Assembler generates ARM NOP instructions
 instead of Thumb NOP instructions when aligning
In-Reply-To: <bug-10632-206@http.llvm.org/bugs/>
References: <bug-10632-206@http.llvm.org/bugs/>
Message-ID: <20111020075045.DAB8A2A6C12D@llvm.org>

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

James Molloy <james.molloy at arm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |james.molloy at arm.com
         Resolution|                            |FIXED

--- Comment #2 from James Molloy <james.molloy at arm.com> 2011-10-20 02:50:44 CDT ---
Was fixed in r137723.

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

From bugzilla-daemon at llvm.org  Thu Oct 20 03:43:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 03:43:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11188] New: .bc file that loads with llvm 2.9
 refuses to load with llvm 3.0 , Unknown instruction
Message-ID: <bug-11188-206@http.llvm.org/bugs/>

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

           Summary: .bc file that loads with llvm 2.9 refuses to load with
                    llvm 3.0 , Unknown instruction
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Bitcode Reader
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hkultala at cs.tut.fi
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7486)
 --> (http://llvm.org/bugs/attachment.cgi?id=7486)
bitcode fail that fails to load with llvm 3.0

This file can be ready with llvm 2.9.

recent versions of trunk/3.0 this gives error Unknown instruction.

Easiest way to reproduce is to use llvm-dis for this file:

> llvm-dis program.bc 
llvm-dis: Unknown instruction


Reading this file broke at timeframe between mid of july and mid of august.

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

From bugzilla-daemon at llvm.org  Thu Oct 20 04:02:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 04:02:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11189] New: more precise aliasing information
Message-ID: <bug-11189-206@http.llvm.org/bugs/>

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

           Summary: more precise aliasing information
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


Hello,

I'm using a structure {i32, [0 x i8]} where I store a value into
   getelementptr {i32, [0 x i8]}, i32 0, i32 0
after that, I use
   getelementptr {i32, [0 x i8]}, i32 0, i32 1
and pass the value to a stdlib call like puts or fwrite.
After this, I read
   getelementptr {i32, [0 x i8]}, i32 0, i32 0
again and the value could not constant folded.

I would like to have more attributes for functions and parameters like:
 - io (for functions) - indicates that a function does io, but does not
manipulate any internal memory
 - nobelow (for parameters) - indicates that the function does not read memory
that lies below this pointer; maybe we need a more precise value from where the
memory starts
 - endsatzero (for parameters) - indicates that the function will not read
memory above the first occurance of i8 0 in the memory

the nobelow and endsatzero could be represented as a range, too:
 - (0..4) for a i32*
 - (0..zero) for a i8* string
 - (0..) for an array
 - (..) for some hacky struct
 - (..12) for other hacky structs (for example selinux in xorg)

This would optimize array access, too because the compiler knows which element
is accessed and that the inner function does not work with other than the one
element it got passed to.

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

From bugzilla-daemon at llvm.org  Thu Oct 20 06:42:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 06:42:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11190] New: CSA still considers struct return
 values from messages to nil as being garbage
Message-ID: <bug-11190-206@http.llvm.org/bugs/>

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

           Summary: CSA still considers struct return values from messages
                    to nil as being garbage
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: macbavarious at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7488)
 --> (http://llvm.org/bugs/attachment.cgi?id=7488)
Source file that reproduces the warning

Greg Parker has recently announced on Twitter that the Objective-C runtime now
zeroes out structs that are return values when a message is sent to nil:

https://twitter.com/#!/gparker/status/126504686583939072

?With the LLVM Compiler and Xcode 4.2, struct-returning messages to nil now
return a zero-filled struct instead of an undefined struct value.?

However, CSA checker-258 still thinks that garbage is returned in this
situation:

?The receiver of message 'xxx' is nil and returns a value of type 'yyy' that
will be garbage?

I?m attaching a sample program that reproduces this analyser warning as well as
the analyser output. I?m using stock Xcode 4.2 clang and CSA checker-258.

$ clang --version
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

$ /usr/local/checker-258/scan-build
USAGE: scan-build [options] <build command> [build options]

ANALYZER BUILD: checker-258 (2011-10-13 20:54:07)

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

From bugzilla-daemon at llvm.org  Thu Oct 20 07:00:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 07:00:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11191] New: Clang scan-build won't work with Xcode
 4.2 LLVM 3.0 build configuration
Message-ID: <bug-11191-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11191

           Summary: Clang scan-build won't work with Xcode 4.2 LLVM 3.0
                    build configuration
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: thomas.weese at team.cortado.com
                CC: llvmbugs at cs.uiuc.edu


I've installed Xcode 4.2 final version to be able to compile for iOS 5.

We are using Jenkins for CI and run Clang scan-build from the llvm.org project
page. (Version 258) The project is configured to use LLVM 3.0 (which is default
since Xcode 4.2). Now every time I try to run scan-build do I get following
error:

CompileC
build/Cortado.build/Debug-iphonesimulator/Cortado.build/Objects-normal/i386/TPContentDetailViewController_iPad.o
Classes/iPad/TPContentDetailViewController_iPad.m normal i386 objective-c
com.apple.compilers.llvm.clang.1_0.compiler
    cd "/Volumes/Sources/Starteam - Main View/Workplace/Cortado"
    setenv LANG en_US.US-ASCII
    setenv PATH
"/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/Applications/android-sdk-mac_x86/android-ndk-r6b:/Applications/android-sdk-mac_x86/platform-tools:/Applications/android-sdk-mac_x86/tools:/Volumes/Sources/Starteam
- Main
View/Tools:/Volumes/Sources/Tools:/usr/bin:/bin:/usr/sbin:/sbin:/usr/local/bin:/usr/X11/bin"
    /Users/thwee/Downloads/checker-258/libexec/ccc-analyzer -x objective-c
-arch i386 -fmessage-length=0 -fdiagnostics-print-source-range-info
-fdiagnostics-show-category=id -fdiagnostics-parseable-fixits -Wno-trigraphs
-fpascal-strings -O0 -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter
-Wunused-variable -Wunused-value -Wno-shorten-64-to-32 -DDEBUG -isysroot
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk
-fexceptions -fasm-blocks -fprofile-arcs -ftest-coverage
-mmacosx-version-min=10.6 -gdwarf-2 -Wno-sign-conversion -fobjc-abi-version=2
-fobjc-legacy-dispatch "-DIBOutlet=__attribute__((iboutlet))"
"-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))"
"-DIBAction=void)__attribute__((ibaction)"
-D__IPHONE_OS_VERSION_MIN_REQUIRED=40100 -iquote "/Volumes/Sources/Starteam -
Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Cortado-generated-files.hmap"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Cortado-own-target-headers.hmap"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Cortado-all-target-headers.hmap"
-iquote "/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Cortado-project-headers.hmap"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Debug-iphonesimulator/include"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/DerivedSources/i386"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/DerivedSources"
"-F/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Debug-iphonesimulator" -include
"/Volumes/Sources/Starteam - Main View/Workplace/Cortado/Cortado_Prefix.pch"
-MMD -MT dependencies -MF "/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Objects-normal/i386/TPContentDetailViewController_iPad.d"
-c "/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/Classes/iPad/TPContentDetailViewController_iPad.m" -o
"/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Objects-normal/i386/TPContentDetailViewController_iPad.o"
cc1obj: error: unrecognized command line option "-Wno-sign-conversion"
cc1obj: error: unrecognized command line option
"-fdiagnostics-print-source-range-info"
cc1obj: error: unrecognized command line option
"-fdiagnostics-show-category=id"
cc1obj: error: unrecognized command line option
"-fdiagnostics-parseable-fixits"


If I use the static code analyze of Xcode self I get following output which
works without issues:

CompileC
build/Cortado.build/Debug-iphonesimulator/Cortado.build/Objects-normal/i386/TPInfoCell.o
Classes/TPInfoCell.m normal i386 objective-c
com.apple.compilers.llvm.clang.1_0.compiler
    cd "/Volumes/Sources/Starteam - Main View/Workplace/Cortado"
    setenv LANG en_US.US-ASCII
    setenv PATH
"/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin/clang -x
objective-c -arch i386 -fmessage-length=0 -fdiagnostics-print-source-range-info
-fdiagnostics-show-category=id -fdiagnostics-parseable-fixits -Wno-trigraphs
-fpascal-strings -O0 -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter
-Wunused-variable -Wunused-value -Wno-shorten-64-to-32 -DDEBUG -isysroot
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk
-fexceptions -fasm-blocks -fprofile-arcs -ftest-coverage
-mmacosx-version-min=10.6 -gdwarf-2 -Wno-sign-conversion -fobjc-abi-version=2
-fobjc-legacy-dispatch "-DIBOutlet=__attribute__((iboutlet))"
"-DIBOutletCollection(ClassName)=__attribute__((iboutletcollection(ClassName)))"
"-DIBAction=void)__attribute__((ibaction)"
-D__IPHONE_OS_VERSION_MIN_REQUIRED=40100 -iquote "/Volumes/Sources/Starteam -
Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Cortado-generated-files.hmap"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Cortado-own-target-headers.hmap"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Cortado-all-target-headers.hmap"
-iquote "/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Cortado-project-headers.hmap"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Debug-iphonesimulator/include"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/DerivedSources/i386"
"-I/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/DerivedSources"
"-F/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Debug-iphonesimulator" -include
/var/folders/m7/1lwxj7113xb17b8k635bn0200000gn/C/com.apple.Xcode.501/SharedPrecompiledHeaders/Cortado_Prefix-curmpedgpezkvsgarfuwvmdrauwa/Cortado_Prefix.pch
-MMD -MT dependencies -MF "/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Objects-normal/i386/TPInfoCell.d"
-c "/Volumes/Sources/Starteam - Main
View/Workplace/Cortado/Classes/TPInfoCell.m" -o "/Volumes/Sources/Starteam -
Main
View/Workplace/Cortado/build/Cortado.build/Debug-iphonesimulator/Cortado.build/Objects-normal/i386/TPInfoCell.o"

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 20 08:39:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 08:39:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11184] SSE: incorrect code generated for i8 vector
	shuffles
In-Reply-To: <bug-11184-206@http.llvm.org/bugs/>
References: <bug-11184-206@http.llvm.org/bugs/>
Message-ID: <20111020133904.594193128034@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11184

Nadav Rotem <nadav.rotem at intel.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 llvm.org  Thu Oct 20 10:09:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 10:09:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11192] New: Invocation of operator ++ does not get
	a location
Message-ID: <bug-11192-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11192

           Summary: Invocation of operator ++ does not get a location
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hans.walheim at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


If you run this you can see that the invocations of operator ++ gets <invalid
loc> while operator << has a valid location
=====
// Command line: c-index-test -test-load-source all file.cpp

struct A
{
  int value;
  A & operator ++ ()            // preincrement
    {   
    value += 1;
    return (*this);
    }
  A & operator ++ (int)         // postincrement
    {   
      value += 2;
      return (*this);
    }
  A & operator << (int rhs)
    {
      value = 23;
      return (*this);
    }
};

A a;

void func (void)
{
  ++a;          // CHECK: <invalid loc>:0:0: DeclRefExpr=operator++:6:7
  a++;          // CHECK: <invalid loc>:0:0: DeclRefExpr=operator++:11:7
  a << 23;      // CHECK: file.cpp:29:5: DeclRefExpr=operator<<:16:7
}
=====

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 20 10:31:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 10:31:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11096] __builtin_expect-based machine basic block
	reordering
In-Reply-To: <bug-11096-206@http.llvm.org/bugs/>
References: <bug-11096-206@http.llvm.org/bugs/>
Message-ID: <20111020153138.B666F3128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11096

Bob Wilson <bob.wilson at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #6 from Bob Wilson <bob.wilson at apple.com> 2011-10-20 10:31:37 CDT ---
Chandler just fixed this.

*** This bug has been marked as a duplicate of bug 2577 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 20 10:46:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 10:46:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11096] __builtin_expect-based machine basic block
	reordering
In-Reply-To: <bug-11096-206@http.llvm.org/bugs/>
References: <bug-11096-206@http.llvm.org/bugs/>
Message-ID: <20111020154603.C21BA3128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11096

Bob Wilson <bob.wilson at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|DUPLICATE                   |

--- Comment #8 from Bob Wilson <bob.wilson at apple.com> 2011-10-20 10:46:03 CDT ---
Oh sorry, I thought you had already committed that patch.  I guess I was
confused.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 20 10:59:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 10:59:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10660] Assertion failed: (SS.isNotEmpty() && "valid
 templated tag with no SS and no direct?")
In-Reply-To: <bug-10660-206@http.llvm.org/bugs/>
References: <bug-10660-206@http.llvm.org/bugs/>
Message-ID: <20111020155915.DA5F43128034@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10660

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dgregor at apple.com
         Resolution|                            |FIXED

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-20 10:59:13 CDT ---
Fixed in Clang r142587.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 20 11:27:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 11:27:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11188] .bc file that loads with llvm 2.9 refuses to
 load with llvm 3.0 , Unknown instruction
In-Reply-To: <bug-11188-206@http.llvm.org/bugs/>
References: <bug-11188-206@http.llvm.org/bugs/>
Message-ID: <20111020162702.3EF3E3128034@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11188

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-10-20 11:27:01 CDT ---
Correct.  If you have a .bc file from before LLVM 2.9, just run it through LLVM
2.9's 'opt' program, then llvm 3.0 should read 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 llvm.org  Thu Oct 20 11:41:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 11:41:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11193] New: x86/SSE: incorrect code generated for
 simple program
Message-ID: <bug-11193-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11193

           Summary: x86/SSE: incorrect code generated for simple program
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7490)
 --> (http://llvm.org/bugs/attachment.cgi?id=7490)
test driver

The attached test case is a 5-line bitcode program that compares a vector <8 x
float> to a constant vector of 3s and converts the <8 x i1> result to <8 x
float> with uitofp.  With the attached test program, which passes it the vector
<1, 2, 3, 4, 5, 6, 7, 8>, it should print the values "1.0 1.0 0.0 0.0 0.0 0.0
0.0 0.0".  With top-of-tree (r142579) it prints "32768.0" in place of the 1.0
values.

% llc  -filetype=obj bug.ll -o bug.o && clang bug.cpp bug.o && ./a.out          
32768.0 32768.0 0.0 0.0 0.0 0.0 0.0 0.0 
%

Before the element type promotion legalization, this test case did indeed print
the expected result:

% llc  -filetype=obj bug.ll -o bug.o && clang bug.cpp bug.o && ./a.out          
1.0 1.0 0.0 0.0 0.0 0.0 0.0 0.0 
%

(It also prints the expected result with TOT if compiled with the AVX backend.)
 Immediately following r142152, it printed 0.0 values for the first two.  At
some point between then and r142579, those became 32768.0s.


commit 8fb06b3e8f7fc92e472e17fecf5ee3ba44fbb6ab
Author: Nadav Rotem <nadav.rotem at intel.com>
Date:   Sun Oct 16 20:31:33 2011 +0000

    Enable element promotion type legalization by deafault.
    Changed tests which assumed that vectors are legalized by widening them.



    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 142152
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 20 11:58:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 11:58:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11194] New: x86/SSE: incorrect code generated for
 <8xi8> to <8xfloat> conversion with sitofp
Message-ID: <bug-11194-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11194

           Summary: x86/SSE: incorrect code generated for <8xi8> to
                    <8xfloat> conversion with sitofp
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7492)
 --> (http://llvm.org/bugs/attachment.cgi?id=7492)
bitcode

The attached test program generates an <8xi8> vector with values
<1,2,3,4,5,6,7,8>, bitcasts it to an i64, shifts it and then sets the low 8
bits to be 0xff, bitcasts that back to an <8xi8> before doing a sitofp
conversion to an <8xfloat> vector.  The result of all this should be -1.0 1.0
2.0 3.0 4.0 5.0 6.0 7.0.  With top of tree, I'm seeing:

% llc  -filetype=obj bug.ll -o bug.o && clang bug.cpp bug.o && ./a.out
-1.0 257.0 514.0 771.0 1028.0 1285.0 1542.0 1799.0 
%

This bug was introduced in r142152.  (It may also be related to
http://llvm.org/bugs/show_bug.cgi?id=11193, but I'm filing it as a separate bug
for now.)


Author: Nadav Rotem <nadav.rotem at intel.com>
Date:   Sun Oct 16 20:31:33 2011 +0000

    Enable element promotion type legalization by deafault.
    Changed tests which assumed that vectors are legalized by widening them.



    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 142152
91177308-0d34-0410-b5e6-96231b3b80d8

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 20 11:59:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 11:59:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11195] New: Clang hangs on reparsing
Message-ID: <bug-11195-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11195

           Summary: Clang hangs on reparsing
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthias_kleine at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7494)
 --> (http://llvm.org/bugs/attachment.cgi?id=7494)
Source Files + Python script to trigger reparse

Clang can be made to hang by trying to reparse the attached source 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 llvm.org  Thu Oct 20 14:01:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 14:01:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11196] New: suboptimal code generation in loop
	unrolling
Message-ID: <bug-11196-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11196

           Summary: suboptimal code generation in loop unrolling
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7495)
 --> (http://llvm.org/bugs/attachment.cgi?id=7495)
test case

I attached a llvm-ir translation of the following program:
static init
begin
  if(copy('hello', 1, 2) == 'el') {
    log('correct')
  }
end


This program should be completely constant folded, but the optimization stucks
at a loop:
the loop begins at line 51 and compares two strings of the same size.
As you see in line 61+63 and 62+64, the characters of the strings at this
specific position are loaded and this exactly is the problem.

It is about the same issue like http://llvm.org/bugs/show_bug.cgi?id=11142
but this time, it's a bit more complex: the memory is not directly copied, but
it's received by a getelementptr+load from the malloced memory.
The challenge is to proof that the loop will stay exactly in the copied range
of [3 x i8]* @label416 so that the getelementptr call can fetched from
@label416 instead of %result.i.i10

An other question is why the loop that only consists of two iterations is not
constant folded.
The loop has the following structure:

start:
 br label %test
test:
 %loopvar = phi i32 [%loopvar2, %body], [0, %start]
 %finished = icmp sgt i32 %loopvar, 2 ; or any other constant or non-constant
 br i1 %finished, label %continue, label %body
body:
 ; sth fancy
 %otherbreak = icmp .....
 br i1 %otherbreak, label %exception, label %test
continue:

This report is maybe two bugs but when you fix one of the two issues, the test
case will become unusable to test the other issue because of constant folding.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 20 14:42:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 20 Oct 2011 14:42:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11197] New: varargs is unnecessarily inefficient
Message-ID: <bug-11197-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11197

           Summary: varargs is unnecessarily inefficient
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pickensd at synopsys.com
                CC: llvmbugs at cs.uiuc.edu


The way LLVM implements varargs is unnecessarily inefficient. It seems to force
the "va_list" variable into memory when it could easily be mapped to a
register.  Is there a way to circumvent this behavior? 

Consider the following test case:

#include <stdarg.h>
void foo(int *p, ...){
    va_list ap;
    va_start(ap,p);
    while(1){
        *p = va_arg(ap,int);
    if (*p == 0) break;
    p++;
    }
}


The ARM target compiles this (at -O3) such that the loop code is quite strange:

.LBB0_3:
        ldr     r2, [sp]          <--- Unnecessary
        add     r0, r0, #4
        add     r1, r2, #4
        str     r1, [sp]          <---- Unnecessary
        ldr     r2, [r2]
        str     r2, [r0]         
        cmp     r2, #0
        bne     .LBB0_3


By contrast, GCC produces a loop that is half the size without the silly load
and store of the va_list variable:

.L3:
        ldr     r0, [r1, #4]!
        cmp     r0, #0
        str     r0, [r2, #4]!
        bne     .L3

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 03:46:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 03:46:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11198] New: [3.0 regression] llvm-ld can't find
 libc on debian testing
Message-ID: <bug-11198-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11198

           Summary: [3.0 regression] llvm-ld can't find libc on debian
                    testing
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Using this bitcode mn.ll

define i32 @main() {
  ret i32 0
}

$ llvm-ld mn.bc -lc
llvm-ld: error: Cannot find library 'c'

This breaks the nightly testsuite which invokes llvm-ld like this (i.e. passing
-lc).

Presumably this is because Debian has been moving its libraries to new
locations.
The nightly testsuite can be "fixed" by adding
LLVMLD_FLAGS += -L/usr/lib/x86_64-linux-gnu/
to Makefile.programs

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 03:51:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 03:51:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11199] New: Umbrella bug for 3.0 release
Message-ID: <bug-11199-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11199

           Summary: Umbrella bug for 3.0 release
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: wendling at apple.com
                CC: llvmbugs at cs.uiuc.edu


This is an umbrella bug for the 3.0 release. It will be blocked by any issues
that come up.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 04:20:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 04:20:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11200] New: [3.0] Non-determinism in self-host on
	x86-32 linux
Message-ID: <bug-11200-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11200

           Summary: [3.0] Non-determinism in self-host on x86-32 linux
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


Using the script utils/release/test-release.sh to do a Release clang self-host,
on 64 bit linux I see the following:

# Comparing Phase 2 and Phase 3 files
file CommandLine.o differs between phase 2 and phase 3
file Path.o differs between phase 2 and phase 3

This is normal: these two files have the path and or date embedded in them
(that should be fixed if possible, but that's another story).

However on 32 bit linux I see:

# Comparing Phase 2 and Phase 3 files
file SparseBitVectorTest.o differs between phase 2 and phase 3
file CXType.o differs between phase 2 and phase 3
file LiveVariables.o differs between phase 2 and phase 3
file PrintfFormatString.o differs between phase 2 and phase 3
file FormatString.o differs between phase 2 and phase 3
file CGDebugInfo.o differs between phase 2 and phase 3
file Lexer.o differs between phase 2 and phase 3
file ExprConstant.o differs between phase 2 and phase 3
file ASTContext.o differs between phase 2 and phase 3
file Expr.o differs between phase 2 and phase 3
file SemaChecking.o differs between phase 2 and phase 3
file SemaExprMember.o differs between phase 2 and phase 3
file SemaType.o differs between phase 2 and phase 3
file ParseDecl.o differs between phase 2 and phase 3
file ParseExprCXX.o differs between phase 2 and phase 3
file ParseStmt.o differs between phase 2 and phase 3
file ClangAttrEmitter.o differs between phase 2 and phase 3
file ClangDiagnosticsEmitter.o differs between phase 2 and phase 3
file MSP430InstrInfo.o differs between phase 2 and phase 3
file TargetData.o differs between phase 2 and phase 3
file AlphaISelDAGToDAG.o differs between phase 2 and phase 3
file X86ISelLowering.o differs between phase 2 and phase 3
file X86FloatingPoint.o differs between phase 2 and phase 3
file X86CodeEmitter.o differs between phase 2 and phase 3
file X86InstrInfo.o differs between phase 2 and phase 3
file X86FastISel.o differs between phase 2 and phase 3
file X86DisassemblerDecoder.o differs between phase 2 and phase 3
file X86AsmParser.o differs between phase 2 and phase 3
file X86AsmBackend.o differs between phase 2 and phase 3
file X86MCCodeEmitter.o differs between phase 2 and phase 3
file BlackfinISelLowering.o differs between phase 2 and phase 3
file BlackfinRegisterInfo.o differs between phase 2 and phase 3
file CBackend.o differs between phase 2 and phase 3
file ARMCodeEmitter.o differs between phase 2 and phase 3
file ARMFastISel.o differs between phase 2 and phase 3
file ARMBaseInstrInfo.o differs between phase 2 and phase 3
file ARMExpandPseudoInsts.o differs between phase 2 and phase 3
file ARMDisassembler.o differs between phase 2 and phase 3
file ARMInstPrinter.o differs between phase 2 and phase 3
file ARMAsmParser.o differs between phase 2 and phase 3
file SystemZISelLowering.o differs between phase 2 and phase 3

file SPUISelDAGToDAG.o differs between phase 2 and phase 3
file SPUISelLowering.o differs between phase 2 and phase 3
file MBlazeDisassembler.o differs between phase 2 and phase 3
file MBlazeAsmParser.o differs between phase 2 and phase 3
file Lint.o differs between phase 2 and phase 3
file ConstantFolding.o differs between phase 2 and phase 3
file LiveVariables.o differs between phase 2 and phase 3
file LiveIntervalAnalysis.o differs between phase 2 and phase 3
file ShrinkWrapping.o differs between phase 2 and phase 3
file PHIElimination.o differs between phase 2 and phase 3
file MachineVerifier.o differs between phase 2 and phase 3
file AsmPrinterDwarf.o differs between phase 2 and phase 3
file DwarfException.o differs between phase 2 and phase 3
file DAGCombiner.o differs between phase 2 and phase 3
file SelectionDAGBuilder.o differs between phase 2 and phase 3
file JITDwarfEmitter.o differs between phase 2 and phase 3
file SimplifyCFG.o differs between phase 2 and phase 3
file AsmLexer.o differs between phase 2 and phase 3
file Function.o differs between phase 2 and phase 3
file ConstantFold.o differs between phase 2 and phase 3
file AsmWriter.o differs between phase 2 and phase 3
file Module.o differs between phase 2 and phase 3
file Instructions.o differs between phase 2 and phase 3
file regexec.o differs between phase 2 and phase 3
file APInt.o differs between phase 2 and phase 3
file CommandLine.o differs between phase 2 and phase 3
file Path.o differs between phase 2 and phase 3
file SubtargetEmitter.o differs between phase 2 and phase 3

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 04:41:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 04:41:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11201] New: LLVM_ETCDIR (used in Path.cpp) results
 in path being hard-coded into object file
Message-ID: <bug-11201-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11201

           Summary: LLVM_ETCDIR (used in Path.cpp) results in path being
                    hard-coded into object file
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


In a release build Path.o is the only object file with a path encoded in it
(the
install directory).  This is bad.  Consider the binary releases we do: LLVM is
built by (say) me on my machine and installed in some directory, for example in
/home/duncan/llvm-3.0/install.  The path /home/duncan/llvm-3.0/install/etc/llvm
is then hard-wired into the binaries.  We now tar up the install directory and
distribute it.  People install this somewhere, for example in /usr/local.  But
their binaries will try to do things with
/home/duncan/llvm-3.0/install/etc/llvm
that doesn't exist on their machines!

Also, this causes bootstrap comparison failures: when building LLVM+clang with
itself in a bootstrap, the Path.o object files from different stages fail to
match because they were built in different directories.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 10:12:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 10:12:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11182] Crash "A global turned into a function?"
In-Reply-To: <bug-11182-206@http.llvm.org/bugs/>
References: <bug-11182-206@http.llvm.org/bugs/>
Message-ID: <20111021151238.8E9C02A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11182

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-10-21 10:12:38 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20111017/130455.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 llvm.org  Fri Oct 21 10:48:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 10:48:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11134] Failed assertion: `(Previous.empty() ||
 Previous.isOverloadedResult() || Previous.isSingleResult()) && "Lookup of
 member name should be either overloaded, single or null"'
In-Reply-To: <bug-11134-206@http.llvm.org/bugs/>
References: <bug-11134-206@http.llvm.org/bugs/>
Message-ID: <20111021154813.1DE422A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11134

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-10-21 10:48:11 CDT ---
Fixed in Clang r142652.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 11:43:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 11:43:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11202] New: Block addresses can refer to
	non-existent symbols
Message-ID: <bug-11202-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11202

           Summary: Block addresses can refer to non-existent symbols
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Pidgeot18 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This is a minimized test case:
@bb = constant [1 x i8*] [i8* blockaddress(@main, %mid)]
define void @main() {
entry:
  br label %l1
l1:
  %a = zext i1 0 to i32
  br label %mid
mid:
  br label %l2
l2:
  %b = zext i1 0 to i32
  br label %l1
}

If you run this with llc, the output assembly/object file will refuse to
compile with an undefined reference to '.Ltmp3'. Remove any instruction, or
change any branch, and the code will assemble properly.

It seems that the cases where this problem occurs are when an empty basic
block:
1. Has its address taken
2. Is sandwiched between two non-empty basic blocks
3. The outer two basic blocks get optimized into nothing.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 11:56:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 11:56:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11203] New: determine unwished/optional side effects
Message-ID: <bug-11203-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11203

           Summary: determine unwished/optional side effects
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


I have a language that has a garbage collector. Garbage collected items are
inserted into a linked list which confuses the optimizer.
What I want is to make this list insertion optional so that the alloc+insert is
only performed when the resulting value is used.

The idea is to introduce a function modifier that indicates that the function
is unnecessary when it's result value is not used and so all the side effects
of calling this function can be ignored.
This allows me lots of very aggressive optimizations because i can tell the
compiler which side effects are unwanted.
The function should of course not be inlined until the compiler knows that the
result is really never used (worst case: never).

Other use cases are:
 - Allocating garbage collected ram
 - Counters that should react to optimizations (count how often the mem is
readed)
 - in-llvm based branch prediction profiling

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 12:37:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 12:37:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11194] x86/SSE: incorrect code generated for <8xi8>
 to <8xfloat> conversion with sitofp
In-Reply-To: <bug-11194-206@http.llvm.org/bugs/>
References: <bug-11194-206@http.llvm.org/bugs/>
Message-ID: <20111021173718.E17AB2A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11194

Nadav Rotem <nadav.rotem at intel.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 llvm.org  Fri Oct 21 13:31:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 13:31:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11156] sysexit should not have a REX.W prefix
In-Reply-To: <bug-11156-206@http.llvm.org/bugs/>
References: <bug-11156-206@http.llvm.org/bugs/>
Message-ID: <20111021183157.8FD0E3128042@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11156

Kevin Enderby <enderby at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Kevin Enderby <enderby at apple.com> 2011-10-21 13:31:57 CDT ---
This is working correctly.  The test case in incorrect and should have included
.code32 directive.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 13:49:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 13:49:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11204] New: -fms-compatibility should imply
	-fms-extensions
Message-ID: <bug-11204-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11204

           Summary: -fms-compatibility should imply -fms-extensions
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Per summary, -fms-compatibility should imply -fms-extensions; there isn't any
situation where someone would want to use -fms-compatibility without
-fms-extensions.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 15:45:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 15:45:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10162] Operands of blockaddress incorrect when
 function is inlined.
In-Reply-To: <bug-10162-206@http.llvm.org/bugs/>
References: <bug-10162-206@http.llvm.org/bugs/>
Message-ID: <20111021204530.3546C3128042@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10162

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-21 15:45:29 CDT ---
r142684.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 15:53:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 15:53:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8214] llvm release_28 branch fails to build
 documentation with latest doxygen (1.7.1)
In-Reply-To: <bug-8214-206@http.llvm.org/bugs/>
References: <bug-8214-206@http.llvm.org/bugs/>
Message-ID: <20111021205303.996013128042@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8214

Tanya Lattner <tonic at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |tonic at nondot.org
         Resolution|FIXED                       |

--- Comment #3 from Tanya Lattner <tonic at nondot.org> 2011-10-21 15:53:01 CDT ---
This has changed the links for doxygen on llvm.org and broke CSS. Its also
unclear of a newer version of doxygen is required. We should upgrade on
llvm.org and then reapply the patch. I will investigate this further.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 16:27:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 16:27:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11180] unresolved symbol when taking a local
	label's address
In-Reply-To: <bug-11180-206@http.llvm.org/bugs/>
References: <bug-11180-206@http.llvm.org/bugs/>
Message-ID: <20111021212754.25F013128042@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11180

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #10 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-10-21 16:27:53 CDT ---
I believe this is fixed, at least the undefined references I get are:

                 U __tracepoint_module_get
                 U add_preempt_count
                 U alloc_fd
                 U alloc_file
                 U current_kernel_time
                 U current_task
                 U current_tinfo
                 U d_alloc_pseudo
                 U d_instantiate
                 U dynamic_dname
                 U fd_install
                 U get_next_ino
                 U ihold
                 U kern_mount_data
                 U kill_anon_super
                 U mcount
                 U mntget
                 U mntput
                 U module_put
                 U mount_pseudo
                 U new_inode
                 U panic
                 U path_put
                 U preempt_schedule
                 U put_unused_fd
                 U register_filesystem
                 U strlen
                 U sub_preempt_count
                 U unregister_filesystem

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 17:43:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 17:43:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11180] unresolved symbol when taking a local
	label's address
In-Reply-To: <bug-11180-206@http.llvm.org/bugs/>
References: <bug-11180-206@http.llvm.org/bugs/>
Message-ID: <20111021224322.0E18B3128042@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11180

PaX Team <pageexec at freemail.hu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #13 from PaX Team <pageexec at freemail.hu> 2011-10-21 17:43:21 CDT ---
(In reply to comment #12)
> works with r142572 reverted too.

if i revert r142572 (from a base of r142689) so that the out-of-line body is
produced then it fails for me the same way (which is little surprise as the
patch posted to this bug didn't fix it either).

did you verify that the .o actually has an out-of-line body and that it
correctly passes an address inside the body to the indirect call?

the generated code for me is still this:

 327:   48 c7 c2 00 00 00 00    mov    $0x0,%rdx        32a: R_X86_64_32S      
.Ltmp181
 32e:   ff 53 f0                callq  *-0x10(%rbx)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 18:30:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 18:30:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11073] Debug info not correctly generated for
 function arguments.
In-Reply-To: <bug-11073-206@http.llvm.org/bugs/>
References: <bug-11073-206@http.llvm.org/bugs/>
Message-ID: <20111021233034.B87D52A6C12D@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11073

Eric Christopher <echristo at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Eric Christopher <echristo at gmail.com> 2011-10-21 18:30:34 CDT ---
Committed thusly, thanks!


[ghostwheel:llvm-git/tools/clang] echristo% git svn dcommit                     
Committing to https://llvm.org/svn/llvm-project/cfe/trunk ...
    M    lib/CodeGen/CodeGenFunction.cpp
    A    test/CodeGen/debug-info-args.c
    M    test/CodeGenCXX/debug-info-fn-template.cpp
Committed r142700

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 21 20:15:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 21 Oct 2011 20:15:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11205] New: Segfault compiling constructor of class
 with anonymous struct
Message-ID: <bug-11205-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11205

           Summary: Segfault compiling constructor of class with anonymous
                    struct
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: igogo.dev at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Compiling the attached file with the following command

clang++ segfault.cpp

clang crashes with the following output:

0  libLLVM-2.9.so.1 0x00007f8834fedc6f
1  libLLVM-2.9.so.1 0x00007f8834fee211
2  libpthread.so.0  0x00007f8834190020
3  libLLVM-2.9.so.1 0x00007f8834bd24a1 llvm::PointerType::get(llvm::Type
const*, unsigned int) + 17
4  clang            0x000000000063036d llvm::GetElementPtrInst*
llvm::GetElementPtrInst::Create<llvm::Value**>(llvm::Value*, llvm::Value**,
llvm::Value**, llvm::Twine const&, llvm::Instruction*) + 365
5  clang            0x000000000067c2b0
clang::CodeGen::CodeGenFunction::EmitLValueForField(llvm::Value*,
clang::FieldDecl const*, unsigned int) + 912
6  clang            0x000000000067c4c6
clang::CodeGen::CodeGenFunction::EmitLValueForFieldInitialization(llvm::Value*,
clang::FieldDecl const*, unsigned int) + 70
7  clang            0x000000000064fb93
clang::CodeGen::CodeGenFunction::EmitCtorPrologue(clang::CXXConstructorDecl
const*, clang::CXXCtorType, llvm::SmallVector<std::pair<clang::VarDecl const*,
clang::QualType>, 16u>&) + 1203
8  clang            0x00000000006503a7
clang::CodeGen::CodeGenFunction::EmitConstructorBody(llvm::SmallVector<std::pair<clang::VarDecl
const*, clang::QualType>, 16u>&) + 119
9  clang            0x0000000000706625
clang::CodeGen::CodeGenFunction::GenerateCode(clang::CodeGen::GlobalDecl,
llvm::Function*) + 901
10 clang            0x000000000063ad54
clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType) + 132
11 clang            0x000000000061eac2
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::CodeGen::GlobalDecl)
+ 482
12 clang            0x000000000061ef02
clang::CodeGen::CodeGenModule::EmitDeferred() + 146
13 clang            0x000000000061ef59 clang::CodeGen::CodeGenModule::Release()
+ 9
14 clang            0x0000000000613d42
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 98
15 clang            0x000000000071cdfb clang::ParseAST(clang::Sema&, bool) +
251
16 clang            0x0000000000612cc3 clang::CodeGenAction::ExecuteAction() +
51
17 clang            0x0000000000545ffb
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 283
18 clang            0x000000000052bfcb
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 971
19 clang            0x00000000005244d2 cc1_main(char const**, char const**,
char const*, void*) + 706
20 clang            0x00000000005230a2 main + 610
21 libc.so.6        0x00007f8833274ead __libc_start_main + 253
22 clang            0x00000000005240b5
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
segfault.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.21.90.20111004 -momit-leaf-frame-pointer -resource-dir
/usr/bin/../lib/clang/2.9 -ferror-limit 19 -fmessage-length 170
-fcxx-exceptions -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-Yxr43r.o -x c++ segfault.cpp 
1.      <eof> parser at end of file
2.      Per-file LLVM IR generation
3.      segfault.cpp:10:2: Generating code for declaration 'B::B'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 1 (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 llvm.org  Sat Oct 22 03:12:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 03:12:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11206] New: [3.0 regression] clang fails to compile
	tramp3d-v4
Message-ID: <bug-11206-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11206

           Summary: [3.0 regression] clang fails to compile tramp3d-v4
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


On x86-64 debian testing, clang fails to compile tramp3d-v4.cpp from the
testsuite:

tramp3d-v4.cpp:51974:3: error: use of undeclared identifier 'fexcept_t'

Command line used to compile (to reproduce it is enough to use -m32):

/home/duncan/llvm-3.0/32/rc1/Phase2/Release+Asserts/llvmCore-3.0-rc1.obj/Release+Asserts/bin/clang++
-fno-exceptions
-I/home/duncan/llvm-3.0/32/rc1/Phase2/Release+Asserts/llvmCore-3.0-rc1.obj/projects/llvm-test/MultiSource/Benchmarks/tramp3d-v4
-I/home/duncan/llvm-3.0/32/rc1/test-suite.src/MultiSource/Benchmarks/tramp3d-v4
-I/home/duncan/llvm-3.0/32/rc1/llvm.src/projects/llvm-test/include
-I../../../include
-I/home/duncan/llvm-3.0/32/rc1/Phase2/Release+Asserts/llvmCore-3.0-rc1.obj/include
-I/home/duncan/llvm-3.0/32/rc1/llvm.src/include -D_GNU_SOURCE
-D__STDC_LIMIT_MACROS -DNDEBUG  -O3 -mllvm -disable-llvm-optzns  -m32
-fomit-frame-pointer -S
/home/duncan/llvm-3.0/32/rc1/test-suite.src/MultiSource/Benchmarks/tramp3d-v4/tramp3d-v4.cpp
-o tramp3d-v4.ll -emit-llvm

I'm guessing that this is an include path issue.  I've attached preprocessed
source as produced by clang and gcc.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 03:18:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 03:18:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11207] New: [3.0 regression] JIT failures: pseudo
 instructions should be removed before code emission
Message-ID: <bug-11207-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11207

           Summary: [3.0 regression] JIT failures: pseudo instructions
                    should be removed before code emission
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


On x86-64 linux I'm seeing the following new JIT failures in the nightly test
suite when compiling with clang:

MultiSource/Benchmarks/Bullet/bullet
/MultiSource/Benchmarks/PAQ8p/paq8p
/SingleSource/Benchmarks/Misc-C++-EH/spirit

The JIT output looks like this:

pseudo instructions should be removed before code emission
UNREACHABLE executed at
/home/duncan/llvm-3.0/64/rc1/llvm.src/lib/Target/X86/X86CodeEmitter.cpp:720!
0  lli             0x0000000000b7e03f
1  lli             0x0000000000b7e569
2  libpthread.so.0 0x00002b29907ab020
3  libc.so.6       0x00002b299138c405 gsignal + 53
4  libc.so.6       0x00002b299138f680 abort + 384
5  lli             0x0000000000b6eb2f llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 463
6  lli             0x000000000056f86e
7  lli             0x000000000056eca2
8  lli             0x00000000008462f7
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 55
9  lli             0x0000000000b246e5
llvm::FPPassManager::runOnFunction(llvm::Function&) + 341
10 lli             0x0000000000b23f79
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 281
11 lli             0x0000000000b23e2b
llvm::FunctionPassManager::run(llvm::Function&) + 139
12 lli             0x00000000007ff1fd
llvm::JIT::runJITOnFunctionUnlocked(llvm::Function*, llvm::MutexGuard const&) +
45
13 lli             0x00000000007ff51e
llvm::JIT::getPointerToFunction(llvm::Function*) + 526
14 lli             0x00000000007fdd86 llvm::JIT::runFunction(llvm::Function*,
std::vector<llvm::GenericValue, std::allocator<llvm::GenericValue> > const&) +
54
15 lli             0x0000000000a55103
llvm::ExecutionEngine::runFunctionAsMain(llvm::Function*,
std::vector<std::string, std::allocator<std::string> > const&, char const*
const*) + 1475
16 lli             0x000000000051c2e3 main + 2595
17 libc.so.6       0x00002b2991378ead __libc_start_main + 253
18 lli             0x000000000051b7f9
Stack dump:
0.      Program arguments:
/home/duncan/llvm-3.0/64/rc1/Phase3/Release+Asserts/llvmCore-3.0-rc1.obj/Release+Asserts/bin/lli
-info-output-file=/home/duncan/llvm-3.0/64/rc1/Phase3/Release+Asserts/llvmCore-3.0-rc1.obj/projects/llvm-test/SingleSource/Benchmarks/Misc-C++-EH/Output/spirit.out-jit.info
-stats -time-passes -force-interpreter=false --disable-core-files
-enable-correct-eh-support Output/spirit.llvm.bc 
1.      Running pass 'X86 Machine Code Emitter' on function '@main'
Aborted
exit 134
RunSafely.sh detected a failure with these command-line arguments:  500 0
/dev/null Output/spirit.out-jit
/home/duncan/llvm-3.0/64/rc1/Phase3/Release+Asserts/llvmCore-3.0-rc1.obj/Release+Asserts/bin/lli
-info-output-file=/home/duncan/llvm-3.0/64/rc1/Phase3/Release+Asserts/llvmCore-3.0-rc1.obj/projects/llvm-test/SingleSource/Benchmarks/Misc-C++-EH/Output/spirit.out-jit.info
-stats -time-passes -force-interpreter=false --disable-core-files
-enable-correct-eh-support Output/spirit.llvm.bc

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 07:30:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 07:30:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9090] mingw-w64: locale implementation depends on
 POSIX headers and extensions
In-Reply-To: <bug-9090-206@http.llvm.org/bugs/>
References: <bug-9090-206@http.llvm.org/bugs/>
Message-ID: <20111022123049.962B93164003@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9090

vanboxem.ruben at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from vanboxem.ruben at gmail.com 2011-10-22 07:30:48 CDT ---
This problem has been worked around in support/win32/locale_win32.[h|cpp].
nl_types and dependent functionality has been stubbed for Windows, as in other
C++ Standard Library implementations.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 07:40:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 07:40:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11193] x86/SSE: incorrect code generated for simple
	program
In-Reply-To: <bug-11193-206@http.llvm.org/bugs/>
References: <bug-11193-206@http.llvm.org/bugs/>
Message-ID: <20111022124004.117222A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11193

Nadav Rotem <nadav.rotem at intel.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 llvm.org  Sat Oct 22 07:53:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 07:53:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9597] llvmpipe lp_test_format test fails with
	llvm-3.0svn
In-Reply-To: <bug-9597-206@http.llvm.org/bugs/>
References: <bug-9597-206@http.llvm.org/bugs/>
Message-ID: <20111022125323.BFB403164003@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9597

Nadav Rotem <nadav.rotem at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #8 from Nadav Rotem <nadav.rotem at intel.com> 2011-10-22 07:53:22 CDT ---
This was fixed a long time ago.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 07:55:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 07:55:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9235] JIT: uitofp on vector type hits assert in
 X86TargetLowering / SelectionDAG
In-Reply-To: <bug-9235-206@http.llvm.org/bugs/>
References: <bug-9235-206@http.llvm.org/bugs/>
Message-ID: <20111022125547.203672A6C12C@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9235

Nadav Rotem <nadav.rotem at intel.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 llvm.org  Sat Oct 22 07:56:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 07:56:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9623] x86: inefficient code generated for i8 vector
	types
In-Reply-To: <bug-9623-206@http.llvm.org/bugs/>
References: <bug-9623-206@http.llvm.org/bugs/>
Message-ID: <20111022125630.8BD3D2A6C124@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9623

Nadav Rotem <nadav.rotem at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Nadav Rotem <nadav.rotem at intel.com> 2011-10-22 07:56:29 CDT ---
This is fixed in ToT.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 09:31:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 09:31:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11208] New: ARC is too controlling and results in
 non-existence bugs.
Message-ID: <bug-11208-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11208

           Summary: ARC is too controlling and results in non-existence
                    bugs.
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: multiHYP at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Summary:
I had a command line tools mae (Mono Alphabetic Encryption) that heavily used
NSCountedSets. Since I moved to Xcode 4.2 and had the code inside @autorelease
{...} blocks, there was a mysterious EXC_BAD_ACCESS or segmentation fault
appearing out of nowhere.
Long story short, it related to the line 161 available here:

https://github.com/multiHYP/mae/blob/fc19e2ea7c9c44b5f3728bb4f9a268379ca52e7b/mae/main.m#L161

Now, the problem arises when that while-loop only sometimes continues executing
for items in NSCountedSet, whose count was 1. Naturally after 1 iteration the
while-loop should quit, but if ARC is turned on, it doesn't. Again, for items
in an NSCountedSet whose count is 1, only sometimes that while-loop keeps
iterating.

Thanks.

Steps to Reproduce:
Go to that Github project and download a zipball of it. See the commit I linked
to above, because my project's latest release keeps changing. Important is to
make sure that your main.m is the same as the version I linked above. Enable
ARC as it is on by default, LLDB for your debugger and add the following two
arguments under your scheme: -rn and -utf8 
Get that pg4300.txt file from project gutenberg, or some rather large text
file. I attach the file below. Make sure your path (input variable) in main.m
reflects the correct path respectively.
Run it.

Expected Results:
Every character in the text (-utf8 format) with its number of occurences should
appear in a reverse numerical/occurences (-rn) table. Notice, that some items
at the end/bottom of the table have the count 1, but suddenly the running hangs
and points you to the while-loop's line. There is only other characters with
occurrences of 1 left to print out, but despite having printed out some of
them, the others are failing.

Actual Results:
It should have in reality printed out a full table statistics of all those
characters and occurrences appearing in the text file, but it didn't.

Regression:

Notes:
Now, if you go to project settings and disable ARC, it works just fine and you
see the Actual Results.
I talked about it in #macdev irc channel and it seems that ARC is too
controlling in its nature and that results in such failure.

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 llvm.org  Sat Oct 22 14:05:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 14:05:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11209] New: [AVX] opportunities for better code
 with masked loads/stores
Message-ID: <bug-11209-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11209

           Summary: [AVX] opportunities for better code with masked
                    loads/stores
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu




-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 14:06:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 14:06:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11209] [AVX] opportunities for better code with
 masked loads/stores
In-Reply-To: <bug-11209-206@http.llvm.org/bugs/>
References: <bug-11209-206@http.llvm.org/bugs/>
Message-ID: <20111022190655.57D8B3164003@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11209

Matt Pharr <matt at pharr.org> 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 llvm.org  Sat Oct 22 14:13:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 14:13:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11210] New: [AVX] opportunity for better code with
 masked stores
Message-ID: <bug-11210-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11210

           Summary: [AVX] opportunity for better code with masked stores
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


(Trying again, with description text this time).

Consider the following bitcode:

declare <8 x float> @llvm.x86.avx.maskload.ps.256(i8 *, <8 x float> %mask)
declare void @llvm.x86.avx.maskstore.ps.256(i8 *, <8 x float>, <8 x float>)

define void @foo(i8 * %ptr, <8 x float> %val, <8 x float> %mask) {
  %v0 = call <8 x float> @llvm.x86.avx.maskload.ps.256(i8 * %ptr, <8 x float>
%mask)
  %v1 = fadd <8 x float> %v0, %v0
  call void @llvm.x86.avx.maskstore.ps.256(i8 * %ptr, <8 x float> %mask, <8 x
float> %val)
  call void @llvm.x86.avx.maskstore.ps.256(i8 * %ptr, <8 x float> %mask, <8 x
float> %v1)
  ret void
}

llc -mattr=+avx generates the following:

    vmaskmovps    (%rdi), %ymm1, %ymm2
    vmaskmovps    %ymm0, %ymm1, (%rdi)
    vaddps    %ymm2, %ymm2, %ymm0
    vmaskmovps    %ymm0, %ymm1, (%rdi)

Here, the first "vmaskmovps %ymm0, %ymm1, (%rdi)" instruction has no effect, as
the vmaskmovps after the vaddps overwrites the exact same locations (since it's
using the same mask as the first store).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 14:58:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 14:58:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11034] LLVM failed at deleting my loops
In-Reply-To: <bug-11034-206@http.llvm.org/bugs/>
References: <bug-11034-206@http.llvm.org/bugs/>
Message-ID: <20111022195846.A7D593164003@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11034

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |nicholas at mxc.ca
         Resolution|                            |FIXED

--- Comment #22 from Nick Lewycky <nicholas at mxc.ca> 2011-10-22 14:58:45 CDT ---
Thanks! Committed in r142731.

Improved compile time is not surprising; when SCEV fails to fully solve a loop,
it will get queries for that loop over and over again (sometimes without SCEV
having been preserved in between) and will spend a lot of time trying to
resolve it. Solving it once up front is faster.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 18:59:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 18:59:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11211] New: Clang fails to optimize in-sequence
 extract operations
Message-ID: <bug-11211-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11211

           Summary: Clang fails to optimize in-sequence extract operations
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: maister at archlinux.us
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7502)
 --> (http://llvm.org/bugs/attachment.cgi?id=7502)
C and disasm

Implementing a trivial float to int16_t conversion routine, Clang is unable to
optimize 8 subsequent extract/store operations into one single unaligned store.

Code and x86_64 disasm in attachment.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 22 20:49:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 22 Oct 2011 20:49:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11208] ARC is too controlling and results in
 non-existence bugs.
In-Reply-To: <bug-11208-206@http.llvm.org/bugs/>
References: <bug-11208-206@http.llvm.org/bugs/>
Message-ID: <20111023014927.883E73164003@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11208

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-10-22 20:49:26 CDT ---
This doesn't look like a static analyzer issue.  Please report Xcode 4.2 bugs
against bugreporter.apple.com with a reduced test case showing the issue.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 23 05:06:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Oct 2011 05:06:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11212] New: X86AsmBackend::WriteNopData uses long
 nops unconditionally
Message-ID: <bug-11212-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11212

           Summary: X86AsmBackend::WriteNopData uses long nops
                    unconditionally
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


X86AsmBackend::WriteNopData() uses long NOP encodings unconditionally resulting
in illegal instructions being executed on CPUs that dont support these
encodings (ie. Amd Geode). We need to check for the target CPU.

According to http://www.tortall.net/projects/yasm/manual/html/arch-x86.html we
should even differentiate between amd and intel. Gnu as uses different nops on
different cpus 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 llvm.org  Sun Oct 23 06:42:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Oct 2011 06:42:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11213] New: Remove Need for Method Prototypes
 within a Source File in Objective-C
Message-ID: <bug-11213-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11213

           Summary: Remove Need for Method Prototypes within a Source File
                    in Objective-C
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: milkservice at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This is a proposal for dropping the need for method prototypes within one .m
file.
The whole file could be parsed for getting all method declarations from their
definitions first.

Reasons:

1) It takes extra time to write prototypes, and more have to be added if method
order is changed.

2) These prototypes are more of visual noise and bloat the file.

3) The prototypes need updates too when the method signature changes.

4) Following some code guidelines (e.g. the ones in "Clean Code"), it is
advised to write methods from top to bottom more and more concrete, and thus a
method should preferably call lower-level methods from below. This asks for
prototypes for nearly all methods.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 23 13:29:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Oct 2011 13:29:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11214] New: ELF: R_ARM_THM_CALL relocation is
 written R_ARM_NONE
Message-ID: <bug-11214-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11214

           Summary: ELF: R_ARM_THM_CALL relocation is written R_ARM_NONE
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Keywords: ABI, miscompilation
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The R_ARM_THM_CALL relocation is written R_ARM_NONE.

Actually, it has been since I started using LLVM 6 months ago.
So, this has me theorizing I must be the only user of ARM Thumb 2 + ELF. :)

Might be nice to fix that before the 3.0 release 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 llvm.org  Sun Oct 23 14:22:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Oct 2011 14:22:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11215] New: Thumb 2: LLVM emits 32-bit instructions
 due to unnecessary distance between cmp and it
Message-ID: <bug-11215-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11215

           Summary: Thumb 2: LLVM emits 32-bit instructions due to
                    unnecessary distance between cmp and it
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Outside IT blocks, the MOV immediate instruction sets flags.
LLVM often avoids it when it could do something else instead, and this ends up
ballooning up code quite a bit - 0 and 1 being very common 8-bit constant.

In fact, this occurs for much more than just MOV. Here are some examples:
180:    f100 0001     add.w    r0, r0, #1    ; 0x1
186:    f04f 0009     mov.w    r0, #9    ; 0x9
1ea:    f145 0200     adc.w    r2, r5, #0    ; 0x0
1f4:    f04f 0600     mov.w    r6, #0    ; 0x0

Here is an example of why:
 1ee:    4283          cmp    r3, r0
 1f0:    f8cc 201c     str.w    r2, [ip, #28]
 1f4:    f04f 0600     mov.w    r6, #0    ; 0x0 <---
 1f8:    bf98          it    ls
 1fa:    2601          movls    r6, #1
 1fc:    428a          cmp    r2, r1
 1fe:    f04f 0500     mov.w    r5, #0    ; 0x0 <---
 202:    bfd8          it    le
...

cmp in both of these cases could be moved directly next to it, allowing mov.w
to be a 2-byte movs. Here's another example:

2c8:    2a00          cmp    r2, #0
 2ca:    bf01          itttt    eq
 2cc:    f8cc 8008     streq.w    r8, [ip, #8]
 2d0:    f8cc 100c     streq.w    r1, [ip, #12]
 2d4:    f04f 0e00     moveq.w    lr, #0    ; 0x0
 2d8:    460d          moveq    r5, r1
 2da:    f1be 0f00     cmp.w    lr, #0    ; 0x0
 2de:    f04f 0200     mov.w    r2, #0    ; 0x0 <---
 2e2:    bfb8          it    lt

Not only could cmp/itttt be turned into cbnz to save code space and processor
time, again we see a mov.w inserted between the cmp.w and it unnecessarily,
causing it to be 4 bytes instead of 2.

It would be nice if this could be fixed. The cmp are unnecessarily far from
their corresponding it.

I expect this affects performance as well as size, given that only so much code
gets retrieved at a time, and this increases it *a lot*.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 23 18:02:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Oct 2011 18:02:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11216] New: Can't derive from a decltype-specifier
Message-ID: <bug-11216-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11216

           Summary: Can't derive from a decltype-specifier
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


[class.derived]/p1 says that a "base-type-specifier" can be a
"class-or-decltype".  Here's an example code exercising the case for decltype:

struct A
{
};

A make_A();

struct B
    : decltype(make_A())
{
};

int main()
{
}

Using:

Apple clang version 3.0 (tags/Apple/clang-215.4) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix

I get:

test.cpp:10:7: error: expected class name
    : decltype(make_A())
      ^
1 error generated.

Expect: clean compile.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 23 19:21:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Oct 2011 19:21:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11217] New: LLVMTargetMachine.cpp assert not fully
	descriptive
Message-ID: <bug-11217-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11217

           Summary: LLVMTargetMachine.cpp assert not fully descriptive
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


LLVMTargetMachine.cpp says:
  // TargetSelect.h moved to a different directory between LLVM 2.9 and 3.0,
  // and if the old one gets included then MCAsmInfo will be NULL and
  // we'll crash later.
  // Provide the user with a useful error message about what's wrong.
  assert(AsmInfo && "MCAsmInfo not initialized."
     "Make sure you include the correct TargetSelect.h!");

This can also occur if you fail to do llvm::InitializeAllTargetMCs(), which is
new (to me anyway). Found this upgrading my code from 2.9-ish SVN to 3.0-ish
SVN.

It would be good if the assert mentioned this other possibility.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 23 22:19:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Oct 2011 22:19:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11218] New:
 CodeGen/PowerPC/2008-10-17-AsmMatchingOperands.ll might not crash (XPASS)
 with -Asserts
Message-ID: <bug-11218-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11218

           Summary: CodeGen/PowerPC/2008-10-17-AsmMatchingOperands.ll
                    might not crash (XPASS) with -Asserts
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 11199


This is marked as XFAIL:*, and I saw this XPASSed on cygwin -Asserts,
release_30.

This depends on +Asserts.

$ llc < CodeGen/PowerPC/2008-10-17-AsmMatchingOperands.ll

assertion "Reg < Regs.size() && "Mismatch in # registers expected"" failed:
file
"/cygdrive/e/llvm/llvm-project/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp",
line 810, function: void<unnamed>::RegsForValue::AddInlineAsmOperands(unsigned
int, bool, unsigned int, llvm::SelectionDAG&,
std::vector<llvm::SDValue,std::allocator<llvm::SDValue> >&) const

It might be easier to mark this as "REQUIRES: asserts". Any idea?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 23 22:29:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 23 Oct 2011 22:29:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8460] [win sys::Path] Assert for missing NULL
 caused by bad erase call
In-Reply-To: <bug-8460-206@http.llvm.org/bugs/>
References: <bug-8460-206@http.llvm.org/bugs/>
Message-ID: <20111024032937.2FD003524009@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8460

NAKAMURA Takumi <geek4civic at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from NAKAMURA Takumi <geek4civic at gmail.com> 2011-10-23 22:29:36 CDT ---
Applied in r142785. Reconfirmed with "opt -analyze -view-cfg blahblah.s".

I had little time to reconfirm the fix. Sorry for my delay.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 01:24:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 01:24:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11219] New: Thumb 2: llvm-objdump skips and becomes
	misaligned
Message-ID: <bug-11219-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11219

           Summary: Thumb 2: llvm-objdump skips and becomes misaligned
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


llvm-objdump becomes misaligned for this file:

llvm-objdump -arch=thumb -triple=thumb-none-eabi -disassemble BugOpt.elf >
test.txt

BugOpt.elf:    file format ELF32-arm

Disassembly of section .text:
.text:
       0:    20 20                                            movs    r0, #32
       2:    70 47                                            bx    lr
       4:    41 68                                            ldr    r1, [r0,
#4]
       6:    48 68                                            ldr    r0, [r1,
#4]
       8:    c9 68                                            ldr    r1, [r1,
#12]
       a:    08 1a                                            subs    r0, r1,
r0
       c:    20 28                                            cmp    r0, #32
       f:    bf 20 <--- No Thumb instructions are 3 bytes!                     
                     movs    r0, #191
      11:    20 70                                            strb    r0, [r4]
      13:    47 70                                            strb    r7, [r0,
#1]
      15:    47 c0                                            stm    r0!, {r0,
r1, r2, r6}
      17:    46 40                                            eors    r6, r0
      19:    68 c2                                            stm    r2!, {r3,
r5, r6}
      1b:    68 53                                            strh    r0, [r5,
r5]
      1d:    1c 02                                            lsls    r4, r3,
#8
      1f:    f0 1f                                            subs    r0, r6,
#7
      21:    02 c3                                            stm    r3!, {r1}
      23:    60 10                                            asrs    r0, r4,
#1
      25:    44 01                                            lsls    r4, r0,
#5
      27:    74 70                                            strb    r4, [r6,
#1]
      29:    47 c0                                            stm    r0!, {r0,
r1, r2, r6}

For reference, GNU Disasm gives:


bugopt.elf:     file format elf32-littlearm


Disassembly of section .text:

00000000 <_ZNK16RingSerialOutput12BufferLengthEv>:
   0:    2020          movs    r0, #32
   2:    4770          bx    lr

00000004 <_ZNK16RingSerialOutput11BytesQueuedEv>:
   4:    6841          ldr    r1, [r0, #4]
   6:    6848          ldr    r0, [r1, #4]
   8:    68c9          ldr    r1, [r1, #12]
   a:    1a08          subs    r0, r1, r0
   c:    2820          cmp    r0, #32
   e:    bf28          it    cs
  10:    2020          movcs    r0, #32
  12:    4770          bx    lr

So you can see it occurs at the first IT 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 llvm.org  Mon Oct 24 01:45:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 01:45:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11220] New: Thumb 2: Instruction encoding problem:
 Bad when -filetype=obj, *Correct* when -filetype=asm
Message-ID: <bug-11220-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11220

           Summary: Thumb 2: Instruction encoding problem: Bad when
                    -filetype=obj, *Correct* when -filetype=asm
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Keywords: miscompilation, regression
          Severity: release blocker
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7505)
 --> (http://llvm.org/bugs/attachment.cgi?id=7505)
the .bc file

2.9 did not have this problem, and this seriously broke my code. I don't know
if it breaks anyone else's, but I have included the .bc file for testing
purposes.

This gives the correct code:
llc -O2 -mtriple=thumb-none-eabi -mcpu=cortex-m3 -filetype=asm -o=BugOpt.asm
BugOpt.bc

This, round tripped back through GNU Disasm (*ALSO* tested with Keil uVision)
gives the wrong code:
llc -O2 -mtriple=thumb-none-eabi -mcpu=cortex-m3 -filetype=obj -o=BugOpt.obj
BugOpt.bc

>From this, I conclude it's probably an instruction encoding problem (hopefully
an easy fix? :)

Round tripped, I get:
  2c:    e92d 48f0     stmdb    sp!, {r4, r5, r6, r7, fp, lr}
  54:    e8bd 08f0     ldmiane.w    sp!, {r4, r5, r6, r7, fp}
140:    e8bd 08f0     ldmia.w    sp!, {r4, r5, r6, r7, fp}

>From the .asm, I get, for these same lines:
    push.w    {r4, r5, r6, r7, r11, lr}
    popne.w    {r4, r5, r6, r7, r11, pc}
    pop.w    {r4, r5, r6, r7, r11, pc}

I used Keil uVision to verify the round-tripping problem wasn't a bug in GNU
Disasm. It shows POPNE and POP instead of GNU Disasm's ldmiane and ldmia, but
the same problem: PC is not getting encoded for POP in this code.

Have a look at POP:
e8bd 08f0
11101 00010 1 1 1101 000 0100011110000
                     ^ LLVM has forgotten to encode 1 for the PC.

The end result is that these functions *do not return*, but all of their
registers are corrupted, and the code faults.

Please fix this. I'd really love to be able to upgrade to 3.0.

Thanks

James

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 01:58:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 01:58:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11221] New: suboptimal code generation in nested
	loop unrolling
Message-ID: <bug-11221-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11221

           Summary: suboptimal code generation in nested loop unrolling
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7506)
 --> (http://llvm.org/bugs/attachment.cgi?id=7506)
First file: original test case

I have two files attached: the generated file that was compiled from the
following program:

static init
begin
  var i: int = ParseInt('5', 0)
  print(IntToStr(i))
end

And the result after opt -O3. There is no ordering issue. It dosent matter how
often I call opt -O3, it dosent unloop.
When you look at the second file line 52-63 (%vergleich.i, %vergleich2.i), this
is the inner loop to compare which decimal character is stored in %char.i
The outer loop's significant lines are 49 where the exit condition is made. It
parses a string till it meets the zero.

This outer loop only has one pass. The problem is, llvm dosent notice that the
outer loop operates on a constant string and could be unfolded. (unrolling the
outer loop would pull in the rest of the optimizations)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 02:10:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 02:10:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11222] New: suboptimal code generation: integer
	ranges
Message-ID: <bug-11222-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11222

           Summary: suboptimal code generation: integer ranges
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7508)
 --> (http://llvm.org/bugs/attachment.cgi?id=7508)
First file: original test case

I have a ParseInt function which is able to parse either a integer or a hex
string (beginning with $). While parsing integers and hex numbers is really
similar, i put them into one function.

The test case is compiled from the following program:
static init
begin
  var i: int = ParseInt('5', 0)
  print(IntToStr(i))
end

I attached a second file which is the run after opt -O3.
As you see in block vergleich.i in line 54, %testpx.i is compared wether it is
smaller than 10.
In gleich.i, %textpx.i is compared wether it is greater than 9. %gleich.i's
predecessor is %vergleich2.i which predecessor is %vergleich.i
But %vergleich.i only branches into vergleich2.i when %testpx.i is smaller than
10, so it can never become greater than 9.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 02:16:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 02:16:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11223] New: Failes to compile due to missing header
	search path
Message-ID: <bug-11223-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11223

           Summary: Failes to compile due to missing header search path
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jbulow-llvm at jongel.net
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7510)
 --> (http://llvm.org/bugs/attachment.cgi?id=7510)
Adds missing include path to InitHeaderSearch.cpp

On Ubuntu 11.04 (32bit) I got the following error when running the test-release
script on 3.0-rc1:

In file included from
XXX/llvm-3-test/rc1/llvm.src/lib/Support/CommandLine.cpp:25:                    
In file included from
XXX/llvm-3-test/rc1/llvm.src/include/llvm/Support/system_error.h:227:           
In file included from /usr/include/c++/4.5/cerrno:42:                           
In file included from /usr/include/errno.h:36:                                  
In file included from /usr/include/bits/errno.h:25:                             
/usr/include/linux/errno.h:4:10: fatal error: 'asm/errno.h' file not found      
#include <asm/errno.h>                                               

Adding /usr/include/i386-linux-gnu to InitHeaderSearch.cpp solves the 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 llvm.org  Mon Oct 24 02:50:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 02:50:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11224] New: Enhancement: "notnull" modifier for a
	value
Message-ID: <bug-11224-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11224

           Summary: Enhancement: "notnull" modifier for a value
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


Iave a language feature called "auto class creation". when a pointer is null
and i access this field, the field is filled with values.
One problem i have is that this check is done every time i access a field
The problem is that a allocated memory is not null, but llvm dosent know that
So it checks it against 0 again and again
The other problem is the allocation. in some cases (the start of a function),
the probability that the mem should be allocated is 100%, in other cases the
probability is very low. so the allocation should not be inlined
(and maybe the basic block for the mem allocation should be at the end of the
function so that no jump is required)

So the solution is a "notnull" flag to constant fold "icmp eq %type* %value,
null" to "i1 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 llvm.org  Mon Oct 24 09:13:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 09:13:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11205] Segfault compiling constructor of class with
 anonymous struct
In-Reply-To: <bug-11205-206@http.llvm.org/bugs/>
References: <bug-11205-206@http.llvm.org/bugs/>
Message-ID: <20111024141316.E69B93128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11205

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-24 09:13:15 CDT ---
This is already fixed in top-of-tree 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 llvm.org  Mon Oct 24 10:27:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 10:27:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11204] -fms-compatibility should imply
	-fms-extensions
In-Reply-To: <bug-11204-206@http.llvm.org/bugs/>
References: <bug-11204-206@http.llvm.org/bugs/>
Message-ID: <20111024152735.74A3F3128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11204

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-24 10:27:35 CDT ---
Fixed in Clang r142797.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 10:57:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 10:57:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11225] New: Assert in llvm_shutdown when running llc
Message-ID: <bug-11225-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11225

           Summary: Assert in llvm_shutdown when running llc
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tjablin at cs.princeton.edu
                CC: llvmbugs at cs.uiuc.edu


$ clang --version
clang version 3.0 (trunk 139501)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ llc geti.ll

While deleting: metadata %
An asserting value handle still pointed to this value!
UNREACHABLE executed at
/home/tjablin/llvm-workspace/llvm/lib/VMCore/Value.cpp:561!
0  libLLVM-3.0svn.so 0x00007fb4a456a629
1  libLLVM-3.0svn.so 0x00007fb4a456a425
2  libpthread.so.0   0x00007fb4a294e060
3  libc.so.6         0x00007fb4a1c303a5 gsignal + 53
4  libc.so.6         0x00007fb4a1c33b0b abort + 379
5  libLLVM-3.0svn.so 0x00007fb4a4554a7b
6  libLLVM-3.0svn.so 0x00007fb4a401535d
llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 639
7  libLLVM-3.0svn.so 0x00007fb4a4013a28 llvm::Value::~Value() + 58
8  libLLVM-3.0svn.so 0x00007fb4a3feb21a llvm::MDNode::~MDNode() + 288
9  libLLVM-3.0svn.so 0x00007fb4a3feb497 llvm::MDNode::destroy() + 67
10 libLLVM-3.0svn.so 0x00007fb4a3fe1ff5
llvm::LLVMContextImpl::~LLVMContextImpl() + 889
11 libLLVM-3.0svn.so 0x00007fb4a3fe0d19 llvm::LLVMContext::~LLVMContext() + 39
12 libLLVM-3.0svn.so 0x00007fb4a3fe15e5
llvm::object_deleter<llvm::LLVMContext>::call(void*) + 30
13 libLLVM-3.0svn.so 0x00007fb4a4559ccd llvm::ManagedStaticBase::destroy()
const + 147
14 libLLVM-3.0svn.so 0x00007fb4a4559cfb llvm::llvm_shutdown() + 21
15 llc               0x0000000000421f8d
llvm::llvm_shutdown_obj::~llvm_shutdown_obj() + 17
16 llc               0x000000000041f825 main + 2802
17 libc.so.6         0x00007fb4a1c1b30d __libc_start_main + 237
18 llc               0x000000000041e629
Stack dump:
0.      Program arguments: llc bugpoint-reduced-simplified.ll 
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 llvm.org  Mon Oct 24 12:18:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 12:18:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11220] Thumb 2 Instruction encoding problem: pc is
 not encoded properly
In-Reply-To: <bug-11220-206@http.llvm.org/bugs/>
References: <bug-11220-206@http.llvm.org/bugs/>
Message-ID: <20111024171818.46449312800A@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11220

Jim Grosbach <grosbach at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Jim Grosbach <grosbach at apple.com> 2011-10-24 12:18:17 CDT ---
Ew. Nasty bug.

Fixed in r142801. I'll try to get this pulled in for 3.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 llvm.org  Mon Oct 24 13:49:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 13:49:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11213] Remove Need for Method Prototypes within a
 Source File in Objective-C
In-Reply-To: <bug-11213-206@http.llvm.org/bugs/>
References: <bug-11213-206@http.llvm.org/bugs/>
Message-ID: <20111024184933.8AEF03128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11213

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-10-24 13:49:33 CDT ---
Please file objective-C enhancement requests against Apple's
bugreporter.apple.com, not in LLVM bugzilla.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 15:25:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 15:25:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11207] [3.0 regression] JIT failures: pseudo
 instructions should be removed before code emission
In-Reply-To: <bug-11207-206@http.llvm.org/bugs/>
References: <bug-11207-206@http.llvm.org/bugs/>
Message-ID: <20111024202528.551893128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11207

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #6 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-24 15:25:27 CDT ---
r142841.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 17:26:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 17:26:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9558] "Invalid constantexpr bitcast!" assert with
 reinterpret_cast
In-Reply-To: <bug-9558-206@http.llvm.org/bugs/>
References: <bug-9558-206@http.llvm.org/bugs/>
Message-ID: <20111024222603.C02763128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9558

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-24 17:26:03 CDT ---
r142863

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 17:50:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 17:50:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11226] New: Thumb 2: Code space: Prefer R4-R7 over
	IP, LR, etc.
Message-ID: <bug-11226-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11226

           Summary: Thumb 2: Code space: Prefer R4-R7 over IP, LR, etc.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Howdy

It seems Thumb 2 code often pushes and uses R8-14 for its temporaries.
For code space, if R4-R7 are not used by arguments passed in, it would be
better if these were used instead.

For example, I noticed one function that
pushed LR (it called other functions, so this was a necessity), but presumably
to maintain 8-byte stack alignment, it also pushed IP. It then proceeded to use
it everywhere, generating 4-byte instructions left and right.

I've also seen it push FP/R11 despite not using it anywhere (alignment again, I
assume). In this case there would be no cost whatsoever to push a lower
register.

It would have been better if it had used R7 in this case, as registers R0-R7
can be used in many more two-byte instructions than R8-R15.

So, my suggestion is, unless necessary like LR, on Thumb 2 allocate from the
R0-R7 before using the later registers.

James

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 18:09:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 18:09:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10258] "cannot select" on ARM with variable-index
	insertelement
In-Reply-To: <bug-10258-206@http.llvm.org/bugs/>
References: <bug-10258-206@http.llvm.org/bugs/>
Message-ID: <20111024230902.70CEB312800A@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10258

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-24 18:09:01 CDT ---
r142871.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 18:56:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 18:56:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10873] clang messes up dependence,
 improperly moves load past use
In-Reply-To: <bug-10873-206@http.llvm.org/bugs/>
References: <bug-10873-206@http.llvm.org/bugs/>
Message-ID: <20111024235607.727BF3128034@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10873

Eric Christopher <echristo at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #11 from Eric Christopher <echristo at gmail.com> 2011-10-24 18:56:06 CDT ---
I can't duplicate the problem. I was hoping Clint would get back to me, but it
sounds like he's pretty busy. I'll close this as Resolved/Worksforme and we can
open a new one if we can get something that duplicates for me.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 19:43:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 19:43:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6308] clang ignores -march with -emit-llvm
In-Reply-To: <bug-6308-206@http.llvm.org/bugs/>
References: <bug-6308-206@http.llvm.org/bugs/>
Message-ID: <20111025004356.8E1C73128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6308

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-24 19:43:56 CDT ---
This is working on trunk.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 19:52:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 19:52:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7233] ICE on invalid pointer-to-member expression
In-Reply-To: <bug-7233-206@http.llvm.org/bugs/>
References: <bug-7233-206@http.llvm.org/bugs/>
Message-ID: <20111025005224.7FC5E3128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=7233

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #4 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-24 19:52:23 CDT ---
We don't crash for either testcase on trunk.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 21:09:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 21:09:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6434] Blackfin DAG ISel Uses Singular Iterators
In-Reply-To: <bug-6434-206@http.llvm.org/bugs/>
References: <bug-6434-206@http.llvm.org/bugs/>
Message-ID: <20111025020902.7B3A8312800A@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=6434

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #3 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-10-24 21:09:01 CDT ---
Fixed in r142880.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 22:29:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 22:29:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11227] New: exported templates not supported
Message-ID: <bug-11227-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11227

           Summary: exported templates not supported
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rkotler at mips.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7527)
 --> (http://llvm.org/bugs/attachment.cgi?id=7527)
myfirst3 from c++ templates book

Clang warns of this but I did not see a bug filed against this.


rkotler at ubuntu-rkotler:~/workspace/mips_test_code/cpp-templates/basics$
~/build_llvm/install/bin/clang++ myfirst3.cpp myfirst3main.cpp
In file included from myfirst3.cpp:12:
./myfirst3.hpp:15:1: warning: exported templates are unsupported
export
^
myfirst3.cpp:16:1: warning: exported templates are unsupported
export
^
myfirst3.cpp:18:1: error: unknown type name 'MyFirst'
MyFirst<T>::MyFirst()
^
myfirst3.cpp:18:8: error: expected unqualified-id
MyFirst<T>::MyFirst()
       ^

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 24 22:30:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 24 Oct 2011 22:30:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11227] exported templates not supported
In-Reply-To: <bug-11227-206@http.llvm.org/bugs/>
References: <bug-11227-206@http.llvm.org/bugs/>
Message-ID: <20111025033046.17C153128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11227

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-24 22:30:45 CDT ---
We have no intention of ever implementing exported templates. They have been
removed from the 2011 C++ Standard.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Oct 25 02:13:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 02:13:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10198] clang ignores -fno-operator-names when
	invoked with -c
In-Reply-To: <bug-10198-206@http.llvm.org/bugs/>
References: <bug-10198-206@http.llvm.org/bugs/>
Message-ID: <20111025071326.CEC9E3128034@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10198

Eric Christopher <echristo at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Eric Christopher <echristo at gmail.com> 2011-10-25 02:13:26 CDT ---
Looks OK to me.

Thanks!


[issola:llvm/tools/clang] echristo% svn ci
Sending        include/clang/Driver/Options.td
Sending        lib/Driver/Tools.cpp
Transmitting file data ..
Committed revision 142913.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Oct 25 10:13:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 10:13:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11216] Can't derive from a decltype-specifier
In-Reply-To: <bug-11216-206@http.llvm.org/bugs/>
References: <bug-11216-206@http.llvm.org/bugs/>
Message-ID: <20111025151322.C7CFB312800A@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11216

David Blaikie <dblaikie at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from David Blaikie <dblaikie at gmail.com> 2011-10-25 10:13:22 CDT ---
Fixed by r142926

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Oct 25 10:49:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 10:49:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11229] New: 3.0rc1: bogus symlink to clang in tools
	dir.
Message-ID: <bug-11229-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11229

           Summary: 3.0rc1: bogus symlink to clang in tools dir.
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


1. Download llvm-3.0rc1.src.tar.gz
2. Untar it.

% ls -l llvm-3.0rc1/tools/clang
lrwxr-xr-x@ 1 mmp  wheel  45 Oct 17 14:49 llvm-3.0rc1/tools/clang@ ->
/Volumes/Sandbox/llvm/3.0-release/rc1/cfe.src

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Oct 25 11:06:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 11:06:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11232] New: 3.0rc1:
 clang/Basic/DiagnosticCommonKinds.inc not being installed
Message-ID: <bug-11232-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11232

           Summary: 3.0rc1: clang/Basic/DiagnosticCommonKinds.inc not
                    being installed
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


1. Download 3.0rc1 and clang-3.0rc1 as source
2. Untar them, move clang to be in tools/clang
3. ./configure --prefix=/tmp/llvmx
4. make install ...

% echo "#include <clang/Frontend/CompilerInstance.h>" | clang -x c++ -c -
-I/tmp/llvmx/include -o /dev/null
In file included from <stdin>:1:
In file included from /tmp/llvmx/include/clang/Frontend/CompilerInstance.h:13:
In file included from
/tmp/llvmx/include/clang/Frontend/CompilerInvocation.h:19:
In file included from /tmp/llvmx/include/clang/Frontend/DiagnosticOptions.h:13:
In file included from /tmp/llvmx/include/clang/Basic/Diagnostic.h:17:
/tmp/llvmx/include/clang/Basic/DiagnosticIDs.h:53:10: fatal error:
'clang/Basic/DiagnosticCommonKinds.inc' file not found
#include "clang/Basic/DiagnosticCommonKinds.inc"
         ^
1 error generated.
%

Copying DiagnosticCommonKinds.inc from the source dir to the appropriate place
in the install dir fixes this.  (I'm not sure if other things from clang are
being missed during the install step as well, 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 llvm.org  Tue Oct 25 11:56:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 11:56:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11233] New: Documentation for -basicaa and -noaa is
 not current for Passes.html
Message-ID: <bug-11233-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11233

           Summary: Documentation for -basicaa and -noaa is not current
                    for Passes.html
           Product: Documentation
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: michael at lunarg.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7530)
 --> (http://llvm.org/bugs/attachment.cgi?id=7530)
Patch to fix documentation

Revision 116820 changed the default alias analysis from basicaa to noaa, I
believe (unfortunately, this is not mentioned in the commit message). Attached
a patch to bring Passes.html up to date with this change.

Alternatively, since it's not mentioned in the commit message, perhaps the
change to use noaa was unintentional?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Oct 25 13:29:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 13:29:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11234] New: llvm.memory.barrier() : llvm
 optimization does not respect barrier
Message-ID: <bug-11234-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11234

           Summary: llvm.memory.barrier() :  llvm optimization does not
                    respect barrier
           Product: compiler-rt
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jgu222 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


A memory barrier intrinsic should have two roles:

1.  All compiler optimizations shall respect any memory barrier.

    No optimizations shall be allowed to optimize across any barrier intrinisic

2.  Generate correct machine barrier instructions if needed.

    On some hardware that does memory operation reordering, a memory barrier
instruction should be generated.


Currently,  llvm does not do 1.  Especially,  alias analysis is a
flow-insensitive approach, which does not respect memory 

barrier.  In addition, since the up-coming c++xx standardizes memory/sync
operations, respecting memory barrier is a must.

Here is an example to show the problem:


Issue 1: a barrier with all false arguments prevents optimizations, which it
should not.

// pesudo code
void foo(int *x) {
  x[2] = 10;
  llvm.memory.barrier(0, 0, 0, 0, 0);
  x[2] = 20;
}


The barrier is actually noop,  but it prevents "x[2] = 10" from being deleted.

Issue 2: a barrier with all true arguments is not respected, which is wrong.

// pesudo code
void foo(int * restrict x) {
  x[2] = 10;
  llvm.memory.barrier(1, 1, 1, 1, 1);
  x[2] = 20;
  return void
}

"x[2] = 10' should not be deleted because barrier is present.  But it
is deleted (DCE).


Here is llvm ir for the first case (commented code is for the second case).

declare void @llvm.memory.barrier(i1 , i1 , i1 , i1 , i1)

define void @foo(i32* %x) nounwind {
; define void @foo(i32* noalias %x) nounwind {
entry:
  %x.addr = alloca i32*, align 4
  store i32* %x, i32** %x.addr, align 4
  %tmp = load i32** %x.addr, align 4
  %arrayidx = getelementptr i32* %tmp, i32 2
  store i32 10, i32* %arrayidx, align 4
  call void @llvm.memory.barrier(i1 0, i1 0, i1 0, i1 0, i1 0) nounwind
; call void @llvm.memory.barrier(i1 1, i1 1, i1 1, i1 1, i1 1) nounwind
  %tmp1 = load i32** %x.addr, align 4
  %arrayidx1 = getelementptr i32* %tmp, i32 2
  store i32 20, i32* %arrayidx, align 4
  ret void
}


Using "opt -O3 " and result is

 declare void @llvm.memory.barrier(i1, i1, i1, i1, i1) nounwind

define void @foo(i32* nocapture %x) nounwind {
entry:
  %arrayidx = getelementptr i32* %x, i32 2
  store i32 10, i32* %arrayidx, align 4
  tail call void @llvm.memory.barrier(i1 false, i1 false, i1 false, i1
false, i1 false) nounwind
  store i32 20, i32* %arrayidx, align 4
  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 llvm.org  Tue Oct 25 14:29:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 14:29:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11234] llvm.memory.barrier() : llvm optimization
 does not respect barrier
In-Reply-To: <bug-11234-206@http.llvm.org/bugs/>
References: <bug-11234-206@http.llvm.org/bugs/>
Message-ID: <20111025192918.73BA53128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11234

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |INVALID

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-25 14:29:18 CDT ---
llvm.memory.barrier is gone on trunk and in the 3.0 RC; please file a new bug
if you have issues with the new atomic operations.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Oct 25 15:33:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 15:33:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11217] LLVMTargetMachine.cpp assert not fully
	descriptive
In-Reply-To: <bug-11217-206@http.llvm.org/bugs/>
References: <bug-11217-206@http.llvm.org/bugs/>
Message-ID: <20111025203325.0E59B312800A@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11217

Jim Grosbach <grosbach at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |grosbach at apple.com
         Resolution|                            |FIXED

--- Comment #1 from Jim Grosbach <grosbach at apple.com> 2011-10-25 15:33:24 CDT ---
Fixed in r142956. Now also mentions, "and that InitializeAllTargetMCs() is
being invoked!"

Bill, I don't think this is absolutely necessary to pull in for the release,
but on the other hand, it's very low risk since it's just changing the message
text on an assert().

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Tue Oct 25 20:48:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 25 Oct 2011 20:48:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11200] [3.0] Non-determinism in self-host on x86-32
	linux
In-Reply-To: <bug-11200-206@http.llvm.org/bugs/>
References: <bug-11200-206@http.llvm.org/bugs/>
Message-ID: <20111026014850.DAE303128034@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11200

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #14 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-10-25 20:48:49 CDT ---
Fixed in r143006. Duncan, please verify. Bill, please merge.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 04:27:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 04:27:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11235] New: suboptimal code with load/store vs
	memcpy
Message-ID: <bug-11235-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11235

           Summary: suboptimal code with load/store vs memcpy
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7532)
 --> (http://llvm.org/bugs/attachment.cgi?id=7532)
Test case x.ll

The attached example is a Hello World example.
I'm storing 1 into the reference counter %ref.i.i (line 38), then i'm calling
some memcpy intrinsics and then I read from %ref.i.i again (line 49-51).

The memcpy range did not overlap the value which i loaded/stored, but it loaded
it again.
So the memcpy intrinsic should look at the range which it operates (alias
analysis).

After fixing this issue, `opt -O3 x.ll -S` should return a main function with
only one block.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 04:52:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 04:52:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11236] New: module import of STL fails assert in
 RevertTokenIDToIdentifier
Message-ID: <bug-11236-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11236

           Summary: module import of STL fails assert in
                    RevertTokenIDToIdentifier
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Axel.Naumann at cern.ch
                CC: llvmbugs at cs.uiuc.edu


$ cat stl.h
#include <string>
$ clang++ -Xclang -emit-module -c -o stl.pcm -x c++ stl.h
$ cat usestl.cxx
__import_module__ stl
std::string s="ABC";
extern "C" int printf(const char*,...);
int main(int, char*[]) {
   printf("s is \"%s\"\n", s.c_str());
   return 0;
}
$ clang++ -Xclang -fmodule-cache-path -Xclang . -Xclang -fdisable-module-hash
usestl.cxx
clang:
/build/llvm/src/tools/clang/lib/Serialization/../../include/clang/Basic/IdentifierTable.h:153:
void clang::IdentifierInfo::RevertTokenIDToIdentifier(): Assertion `TokenID !=
tok::identifier && "Already at tok::identifier"' failed.
0  clang           0x0000000002aa757e
1  clang           0x0000000002aa7a7a
2  libpthread.so.0 0x00007fb61ca8b060
3  libc.so.6       0x00007fb61bd6d3a5 gsignal + 53
4  libc.so.6       0x00007fb61bd70b0b abort + 379
5  libc.so.6       0x00007fb61bd65d4d __assert_fail + 221
6  clang           0x000000000120a28a
clang::IdentifierInfo::RevertTokenIDToIdentifier() + 74
7  clang           0x00000000011ee81c
clang::serialization::reader::ASTIdentifierLookupTrait::ReadData(std::pair<char
const*, unsigned int> const&, unsigned char const*, unsigned int) + 668
8  clang           0x000000000123cfbb
clang::OnDiskChainedHashTable<clang::serialization::reader::ASTIdentifierLookupTrait>::iterator::operator*()
const + 43
9  clang           0x00000000011f9307
10 clang           0x00000000012f5cce
clang::serialization::ModuleManager::visit(bool
(*)(clang::serialization::Module&, void*), void*) + 414
11 clang           0x00000000011f9118 clang::ASTReader::ReadAST(std::string
const&, clang::serialization::ModuleKind) + 616
12 clang           0x0000000001137ec2
clang::CompilerInstance::loadModule(clang::SourceLocation,
clang::IdentifierInfo&, clang::SourceLocation) + 2546
13 clang           0x00000000015c92a9
clang::Sema::ActOnModuleImport(clang::SourceLocation, clang::IdentifierInfo&,
clang::SourceLocation) + 89
14 clang           0x00000000014c31f4 clang::Parser::ParseModuleImport() + 292
15 clang           0x00000000014c29ab
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 3083
16 clang           0x00000000014c1d59
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 361
17 clang           0x000000000149846e clang::ParseAST(clang::Sema&, bool) + 334
18 clang           0x000000000115be18 clang::ASTFrontendAction::ExecuteAction()
+ 264
19 clang           0x00000000012fb693 clang::CodeGenAction::ExecuteAction() +
1059
20 clang           0x000000000115ba63 clang::FrontendAction::Execute() + 307
21 clang           0x00000000011372ad
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 797
22 clang           0x0000000001101081
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 961
23 clang           0x00000000010ef64e cc1_main(char const**, char const**, char
const*, void*) + 926
24 clang           0x00000000010fb05d main + 477
25 libc.so.6       0x00007fb61bd5830d __libc_start_main + 237
26 clang           0x00000000010ef1e9
Stack dump:
0.    Program arguments: /build/llvm/deb-inst/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
usestl.cxx -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.21.53.20110810 -momit-leaf-frame-pointer -resource-dir
/build/llvm/deb-inst/bin/../lib/clang/3.1 -fmodule-cache-path
/var/tmp/clang-module-cache -fdeprecated-macro -fdebug-compilation-dir
/build/root/cintcling -ferror-limit 19 -fmessage-length 157 -fgnu-runtime
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-fragile-abi
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics
-fmodule-cache-path . -fdisable-module-hash -o /tmp/usestl-nhNAqx.o -x c++
usestl.cxx 
1.    usestl.cxx:2:1: current parser token 'std'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: note: diagnostic msg: Preprocessed source(s) are located at:
clang: note: diagnostic msg: /tmp/usestl-vHMJJk.ii

The token causing this (identifier "__is_fundamental") sits in 
/usr/include/c++/4.6/bits/cpp_type_traits.h:334:    struct __is_fundamental

$ clang --version
clang version 3.1 (trunk 142797)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Let me know if I can help with debugging (e.g. where to look...)

Cheers, Axel.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 09:40:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 09:40:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11206] clang fails to compile tramp3d-v4
In-Reply-To: <bug-11206-206@http.llvm.org/bugs/>
References: <bug-11206-206@http.llvm.org/bugs/>
Message-ID: <20111026144013.F0D803128060@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11206

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE
            Summary|[3.0 regression] clang      |clang fails to compile
                   |fails to compile tramp3d-v4 |tramp3d-v4

--- Comment #15 from Douglas Gregor <dgregor at apple.com> 2011-10-26 09:40:13 CDT ---
Thanks, Axel. So this isn't actually a regression; dup'ing to 6907.

*** This bug has been marked as a duplicate of bug 6907 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 11:44:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 11:44:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10676] [x86 disassembler] L bit in VEX prefix is
 not ignored properly
In-Reply-To: <bug-10676-206@http.llvm.org/bugs/>
References: <bug-10676-206@http.llvm.org/bugs/>
Message-ID: <20111026164435.3A24E312800A@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10676

Kay Tiong Khoo <kkhoo at perfwizard.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #9 from Kay Tiong Khoo <kkhoo at perfwizard.com> 2011-10-26 11:44:34 CDT ---
Using llvm-mc built from r141535, all of the cases listed in this bug report
work, except the vcomisd tests shown in comment 7:

$ echo '0xc4 0xc1 0x7b 0x2f 0xc1'| ./llvm-mc -disassemble -triple="x86_64"
<stdin>:1:1: warning: invalid instruction encoding
0xc4 0xc1 0x7b 0x2f 0xc1
^
<stdin>:1:21: warning: invalid instruction encoding
0xc4 0xc1 0x7b 0x2f 0xc1

$ echo '0xc5 0xfb 0x2f 0xc1'| ./llvm-mc -disassemble -triple="x86_64"
<stdin>:1:1: warning: invalid instruction encoding
0xc5 0xfb 0x2f 0xc1
^
<stdin>:1:16: warning: invalid instruction encoding
0xc5 0xfb 0x2f 0xc1
               ^

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 12:08:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 12:08:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7824] Warning improvement for cv-qualified free
	functions
In-Reply-To: <bug-7824-206@http.llvm.org/bugs/>
References: <bug-7824-206@http.llvm.org/bugs/>
Message-ID: <20111026170831.DA6753128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=7824

ace2001ac at gmail.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 llvm.org  Wed Oct 26 12:22:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 12:22:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9705] LLVM miscompiles Wine's
	dlls/msctf/categorymgr.c at -O0
In-Reply-To: <bug-9705-206@http.llvm.org/bugs/>
References: <bug-9705-206@http.llvm.org/bugs/>
Message-ID: <20111026172212.B84053128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9705

austinenglish at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #7 from austinenglish at gmail.com 2011-10-26 12:22:11 CDT ---
Fixed in Wine, by
http://source.winehq.org/git/wine.git/commitdiff/d5090fd9757fbee2190eaa0f54ea39ebcfe657e3.

Valgrind also showed a problem. From Wine's bugzilla:
=========
Valgrind found a write buffer overrun on a stack buffer,
though since it doesn't really know about stack buffer
ends, we got lucky and the overrun was caught by a sanity
check on memcpy:

Source and destination overlap in memcpy(0x7f22f8c8, 0x7f22f904, 76)
   at memcpy (mc_replace_strmem.c:635)
   by format_string (string.c:339)
   by vsnprintfW (string.c:429)
   by sprintfW (string.c:514)
   by CategoryMgr_FindClosestCategory (categorymgr.c:219)
   by next_LanguageProfile (inputprocessor.c:1030)
   by EnumTfLanguageProfiles_Next (inputprocessor.c:1065)
   by test_EnumLanguageProfiles (inputprocessor.c:935)
   by func_inputprocessor (inputprocessor.c:2202)
   by run_test (test.h:556)
   by main (test.h:624)

so likely not an llvm bug.
=========

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 12:24:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 12:24:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11237] New: ARC: Warning when setter declared
 alongside property cannot be satisfied
Message-ID: <bug-11237-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11237

           Summary: ARC: Warning when setter declared alongside property
                    cannot be satisfied
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jeremyw.sherman at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7534)
 --> (http://llvm.org/bugs/attachment.cgi?id=7534)
Minimal example reproducing the problem.

When compiling a class that declares both a setter and a property using
`-fobjc-arc`, a warning is given about a type mismatch between the setter
declaration and the property declaration. This mismatch cannot be addressed by
changing the type of the setter argument, as you can see by changing the
ownership qualification of the setter argument variable and recompiling with
each different qualifier in turn.

Declaring the setter the exact same way in the @implementation block
rather than the @interface block does NOT trigger any warning.

The warning is also frustrating: it says there is a type mismatch, but it does
not name the types involved in the mismatch so that you can see what's
mismatched and how.

Code reproducing the problem follows and is also attached:
{{{
//clang -fobjc-arc -c weak_prop.m -o weak_prop
/*
> weak_prop.m:25:33: warning: type of property 'child' does not match type of accessor 'setChild:'
> @property(strong, nonatomic) id child;
>                                 ^
> weak_prop.m:24:1: note: declared here
> - (void)setChild:(__strong id)child;
> ^
> 1 warning generated.

Problem only occurs when compiling with -fobjc-arc.

No matter what type is given to chind in -setChild:, the same warning is given.
Whether the setter declaration precedes or follows the property declaration
has no effect.

Declaring the setter as - (void)setChild:(id)child in the @implementation block
does NOT trigger any warning.
Only doing so in the @interface block triggers the warning.
*/

@interface Foo
- (id)child;  // Doesn't care about getter.
- (void)setChild:(__strong id)child;
@property(strong, nonatomic) id child;
@end
}}}

System information:
$ clang --version
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin11.2.0
Thread model: posix
$ sw_vers
ProductName:    Mac OS X
ProductVersion:    10.7.2
BuildVersion:    11C74
$ uname -a
Darwin Hermes.local 11.2.0 Darwin Kernel Version 11.2.0: Tue Aug  9 20:54:00
PDT 2011; root:xnu-1699.24.8~1/RELEASE_X86_64 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 llvm.org  Wed Oct 26 12:54:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 12:54:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11195] Clang hangs on reparsing
In-Reply-To: <bug-11195-206@http.llvm.org/bugs/>
References: <bug-11195-206@http.llvm.org/bugs/>
Message-ID: <20111026175414.747C03128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11195

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-10-26 12:54:14 CDT ---
Fixed in Clang r143037.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 13:18:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 13:18:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11238] New: suboptimal code generation in pointer
 comparison (this also affects std::vector.push_back())
Message-ID: <bug-11238-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11238

           Summary: suboptimal code generation in pointer comparison (this
                    also affects std::vector.push_back())
           Product: new-bugs
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: s3734770 at mail.zih.tu-dresden.de
                CC: llvmbugs at cs.uiuc.edu


Test Case:

; ModuleID = 'x.ll'
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"

%t = type { i32, i32 }

define i32 @main() nounwind readnone {
r1:
  %x = alloca %t, align 8
  %a = getelementptr %t* %x, i64 0, i32 0
  %b = getelementptr %t* %x, i64 0, i32 1
  %equal = icmp eq i32* %a, %b
  %merge = select i1 %equal, i32 1, i32 2
  ret i32 %merge
}

I think the issue should be obviously.
Have fun fixing it. This code occurs also on code generation of the C++
template std::vector:

#include <vector>
#include <iostream>

using namespace std;

int main() {
  vector<int> v;
  v.push_back(1);
  v.push_back(2);
  v.push_back(3);
  for(vector<int>::iterator it = v.begin(); it < v.end(); it++) {
    cout << *it << endl;
  }
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 14:42:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 14:42:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11239] New: Comparison with GCC: GPL statement is
	misleading
Message-ID: <bug-11239-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11239

           Summary: Comparison with GCC: GPL statement is misleading
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: Windows 2000
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dontbugme at mailinator.com
                CC: llvmbugs at cs.uiuc.edu


http://clang.llvm.org/comparison.html

"GCC is licensed under the GPL license. clang uses a BSD license, which allows
it to be used by projects that do not themselves want to be GPL."

It should be clear that this applies only to compiler derivatives and not ones
that use GCC to compile their 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 llvm.org  Wed Oct 26 14:42:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 14:42:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8996] SPARC backend crashes when emitting dwarf
 debug information from dbg_value
In-Reply-To: <bug-8996-206@http.llvm.org/bugs/>
References: <bug-8996-206@http.llvm.org/bugs/>
Message-ID: <20111026194231.D4CCC3128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8996

Venkatraman Govindaraju <venkatra at cs.wisc.edu> 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 llvm.org  Wed Oct 26 15:58:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 15:58:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11240] New: redundant new/delete pair not removed
Message-ID: <bug-11240-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11240

           Summary: redundant new/delete pair not removed
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7535)
 --> (http://llvm.org/bugs/attachment.cgi?id=7535)
Reduced testcase

The attached IR has a redundant new/delete pair (for %alloc1, whose only other
use is a dead store). The code has been manually reduced from this (compiled
with a large inlining threshold):

#include <vector>
void resize() {
  std::vector<int> v;
  v.push_back(1);
  v.push_back(2);
  // ...
}

The optimizer is unable to remove this new/delete pair. The outcome seems to be
quite sensitive to the other instructions in the IR: the optimization did fire
in various partially-reduced testcases containing this IR plus some other
seemingly-irrelevant instructions.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 16:10:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 16:10:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11241] New: known constant not folded: new() + 4 !=
	0
Message-ID: <bug-11241-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11241

           Summary: known constant not folded: new() + 4 != 0
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7536)
 --> (http://llvm.org/bugs/attachment.cgi?id=7536)
Testcase

This IR:

  %alloc2 = tail call noalias i8* @_Znwm(i64 8) nounwind
  %add = getelementptr inbounds i8* %alloc2, i64 4
  %always_false = icmp eq i8* %add, null
  ret i1 %always_false

... is collapsed to "ret i1 0". However, this IR:

  %alloc2 = tail call noalias i8* @_Znwm(i64 8) nounwind
  %add = getelementptr inbounds i8* %alloc2, i64 4
  %always_false = icmp eq i8* %add, null
  br i1 %always_false, label %skipinit2, label %init2

init2:                                            ; preds = %entry
  store i8 1, i8* %alloc2, align 1
  ret void

skipinit2:                                        ; preds = %entry
  ret void

... is not optimized any further.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 16:29:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 16:29:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11242] New: Missing /usr/include/i386-linux-gnu
 include path on Ubuntu 11.04
Message-ID: <bug-11242-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11242

           Summary: Missing /usr/include/i386-linux-gnu include path on
                    Ubuntu 11.04
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stoklund at 2pi.dk
                CC: llvmbugs at cs.uiuc.edu


Clang doesn't check the /usr/include/i386-linux-gnu include path, causing
#include <errno.h> to fail.

gcc -x c++ -v /dev/null
Using built-in specs.
COLLECT_GCC=gcc
COLLECT_LTO_WRAPPER=/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/lto-wrapper
Target: i686-linux-gnu
Configured with: ../src/configure -v --with-pkgversion='Ubuntu/Linaro
4.5.2-8ubuntu4' --with-bugurl=file:///usr/share/doc/gcc-4.5/README.Bugs
--enable-languages=c,c++,fortran,objc,obj-c++ --prefix=/usr
--program-suffix=-4.5 --enable-shared --enable-multiarch
--with-multiarch-defaults=i386-linux-gnu --enable-linker-build-id
--with-system-zlib --libexecdir=/usr/lib/i386-linux-gnu
--without-included-gettext --enable-threads=posix
--with-gxx-include-dir=/usr/include/c++/4.5 --libdir=/usr/lib/i386-linux-gnu
--enable-nls --with-sysroot=/ --enable-clocale=gnu --enable-libstdcxx-debug
--enable-libstdcxx-time=yes --enable-plugin --enable-gold --enable-ld=default
--with-plugin-ld=ld.gold --enable-objc-gc --enable-targets=all --disable-werror
--with-arch-32=i686 --with-tune=generic --enable-checking=release
--build=i686-linux-gnu --host=i686-linux-gnu --target=i686-linux-gnu
Thread model: posix
gcc version 4.5.2 (Ubuntu/Linaro 4.5.2-8ubuntu4) 
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686'
 /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/cc1plus -quiet -v
-D_GNU_SOURCE /dev/null -D_FORTIFY_SOURCE=2 -quiet -dumpbase null
-mtune=generic -march=i686 -auxbase null -version -fstack-protector -o
/tmp/ccGB998T.s
GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (i686-linux-gnu)
    compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
ignoring nonexistent directory "/usr/local/include/i386-linux-gnu"
ignoring nonexistent directory
"/usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/../../../../../i686-linux-gnu/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/include/c++/4.5
 /usr/include/c++/4.5/i686-linux-gnu
 /usr/include/c++/4.5/backward
 /usr/local/include
 /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include
 /usr/lib/i386-linux-gnu/gcc/i686-linux-gnu/4.5.2/include-fixed
 /usr/include/i386-linux-gnu
 /usr/include
End of search list.
GNU C++ (Ubuntu/Linaro 4.5.2-8ubuntu4) version 4.5.2 (i686-linux-gnu)
    compiled by GNU C version 4.5.2, GMP version 4.3.2, MPFR version 3.0.0-p8,
MPC version 0.9
GGC heuristics: --param ggc-min-expand=100 --param ggc-min-heapsize=131072
Compiler executable checksum: 0c5cb630517b5952f4898dfa56d7e8e5
COLLECT_GCC_OPTIONS='-v' '-mtune=generic' '-march=i686'
 as -V -Qy --32 -o /tmp/ccW90a0k.o /tmp/ccGB998T.s

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 16:37:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 16:37:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11243] New: -deadargelim changes function return
	value
Message-ID: <bug-11243-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11243

           Summary: -deadargelim changes function return value
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: tbfleming at gmail.com
                CC: llvmbugs at cs.uiuc.edu


-deadargelim replaces a constant pointer with null

Source
======
%InnerStruct = type { i8* }
%OuterStruct = type { i32, %InnerStruct }

@str = internal constant [4 x i8] c"aaa\00"

declare void @externalFunction(i8*)

define private fastcc %OuterStruct @privateFunction(%OuterStruct %a) {
entry:
  ret %OuterStruct %a
}

define void @main() {
entry:
  %0 = call fastcc %OuterStruct @privateFunction(%OuterStruct { i32 9,
%InnerStruct { i8* getelementptr inbounds ([4 x i8]* @str, i32 0, i32 0) } })
  %s = extractvalue %OuterStruct %0, 1, 0
  call void @externalFunction(i8* %s)
  ret void
}

After -deadargelim
==================
%InnerStruct = type { i8* }
%OuterStruct = type { i32, %InnerStruct }

@str = internal constant [4 x i8] c"aaa\00"

declare void @externalFunction(i8*)

define private fastcc %InnerStruct @privateFunction() {
entry:
  %oldret = extractvalue %OuterStruct zeroinitializer, 1
  ret %InnerStruct %oldret
}

define void @main() {
entry:
  %0 = call fastcc %InnerStruct @privateFunction()
  %oldret = insertvalue %OuterStruct undef, %InnerStruct %0, 1
  %s = extractvalue %OuterStruct %oldret, 1, 0
  call void @externalFunction(i8* %s)
  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 llvm.org  Wed Oct 26 18:00:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 18:00:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11239] Comparison with GCC: GPL statement is
	misleading
In-Reply-To: <bug-11239-206@http.llvm.org/bugs/>
References: <bug-11239-206@http.llvm.org/bugs/>
Message-ID: <20111026230003.35F033128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11239

Chris Lattner <clattner at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |clattner at apple.com
         Resolution|                            |WONTFIX

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-10-26 18:00:02 CDT ---
Not interested in pedantic discussions here.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Wed Oct 26 19:10:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 26 Oct 2011 19:10:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10938] [SPARC] wrong results from 'sgt'
In-Reply-To: <bug-10938-206@http.llvm.org/bugs/>
References: <bug-10938-206@http.llvm.org/bugs/>
Message-ID: <20111027001048.D0F223128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10938

Venkatraman Govindaraju <venkatra at cs.wisc.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |venkatra at cs.wisc.edu
         Resolution|                            |FIXED

--- Comment #2 from Venkatraman Govindaraju <venkatra at cs.wisc.edu> 2011-10-26 19:10:48 CDT ---
I can not reproduce this problem with the current trunk.
It may be fixed by the revision r122607

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 27 02:16:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 02:16:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11244] New: Objective-C - readonly attribute in
 property declaration
Message-ID: <bug-11244-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11244

           Summary: Objective-C - readonly attribute in property
                    declaration
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: muthuveerappan.al at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7537)
 --> (http://llvm.org/bugs/attachment.cgi?id=7537)
sample objective-c program to explain the bug

As per Objective-C documentation, readonly attribute can't be used in a
property declaration along with the setter attribute.

Documentation 
==========
Quoted from the document The Objective?C Programming Language (page 71)

"If you specify that a property is readonly and also specify a setter with
setter=, you get a compiler warning."

Sample Program
==========
see attachment for small program in objective-c explaining the problem

Actual behavior:
==========
Clang doesn't throw an error in line 20 in the attached program

Expected Behavior
===========
Clang should throw an error stating that "setter cannot be specified for a
'readonly' property ?n1?"

Pls can you pls fix this, let me know if you need more information.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 27 10:30:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 10:30:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10676] [x86 disassembler] L bit in VEX prefix is
 not ignored properly
In-Reply-To: <bug-10676-206@http.llvm.org/bugs/>
References: <bug-10676-206@http.llvm.org/bugs/>
Message-ID: <20111027153003.605EA3128060@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=10676

Kay Tiong Khoo <kkhoo at perfwizard.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #11 from Kay Tiong Khoo <kkhoo at perfwizard.com> 2011-10-27 10:30:02 CDT ---
Oops! Yes, my test case was off.

All of the examples here are working now. 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 llvm.org  Thu Oct 27 12:58:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 12:58:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11245] New: clang incorrectly accepts ::template
	S<...>
Message-ID: <bug-11245-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11245

           Summary: clang incorrectly accepts ::template S<...>
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


clang accepts this in C++11 mode, and with a warning in C++98 mode:

template<typename T> struct S {};
::template S<int> s;

This is not legal in either language (and not legal even within a template in
C++98). The grammar for elaborated-type-specifiers requires a
nested-name-specifier before the 'template' keyword in this context, and :: is
not one.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 27 15:37:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 15:37:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11246] New: Assertion failed: "Cannot split
 critical edge from IndirectBrInst" with constant expression in PHI
Message-ID: <bug-11246-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11246

           Summary: Assertion failed: "Cannot split critical edge from
                    IndirectBrInst" with constant expression in PHI
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7538)
 --> (http://llvm.org/bugs/attachment.cgi?id=7538)
Testcase

Testcase attached; llc crashes with:

Assertion failed: (!isa<IndirectBrInst>(TI) && "Cannot split critical edge from
IndirectBrInst"), function SplitCriticalEdge, file
/Volumes/storage/llvm/lib/Transforms/Utils/BreakCriticalEdges.cpp, line 175.

Not sure anyone is actually likely to hit this in practice, but it seems
possible.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 27 16:36:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 16:36:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11247] New: as complains about "junk at end of
 line" when run from llvm-ld
Message-ID: <bug-11247-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11247

           Summary: as complains about "junk at end of line" when run from
                    llvm-ld
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: scott+llvm+bugzilla at pakin.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7539)
 --> (http://llvm.org/bugs/attachment.cgi?id=7539)
"Hello, world" -- although any program should trigger the same bug

Something seems to be screwed up with the way the x86_64 code generator is
mapping metadata to assembly directives.  The following works fine:

  $ clang -emit-llvm -S -o hello.ll hello.c
  $ llvm-as hello.ll
  $ llvm-ld -native -o hello hello.bc

However, when I compile with -g, badness happens:

  $ clang -g -emit-llvm -S -o hello.ll hello.c
  $ llvm-as hello.ll
  $ llvm-ld -native -o hello hello.bc
  hello.s: Assembler messages:
  hello.s:2: Error: junk at end of line, first unrecognized character is `"'
  llvm-ld:
  $ head hello.s
      .file   "hello.bc"
      .file   1 "/tmp" "hello.c"
      .section        .debug_info,"", at progbits
  .Lsection_info:
      .section        .debug_abbrev,"", at progbits
  .Lsection_abbrev:
      .section        .debug_aranges,"", at progbits
      .section        .debug_macinfo,"", at progbits
      .section        .debug_line,"", at progbits
  .Lsection_line:

This is with the trunk build from a few minutes ago:

  $ svn info
  Path: .
  URL: http://llvm.org/svn/llvm-project/llvm/trunk
  Repository Root: http://llvm.org/svn/llvm-project
  Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
  Revision: 143148
  Node Kind: directory
  Schedule: normal
  Last Changed Author: ddunbar
  Last Changed Rev: 143148
  Last Changed Date: 2011-10-27 15:25:09 -0600 (Thu, 27 Oct 2011)

-- Scott

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 27 16:52:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 16:52:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11248] New: clang++ generates compilation error due
 to eager template instantiation
Message-ID: <bug-11248-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11248

           Summary: clang++ generates compilation error due to eager
                    template instantiation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stefan at seefeld.name
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The attached code generates this error:

/home/stefan/test.cc:12:38: error: implicit instantiation of undefined template
'Map<1>'
      (is_same_map<Map<1>, B>::value(Map<1>(), b.block()) &&
                                     ^
/home/stefan/test.cc:1:30: note: template is declared here                      
template <unsigned D> struct Map;
                             ^
1 error generated.   

The code is the result of heavy reduction. The original code obviously defines
the "Map" templates. The point here appears to be that clang++ wants to
instantiate it too early (inside another template !) where the definition
hasn't been seen 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 llvm.org  Thu Oct 27 16:58:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 16:58:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11248] clang++ generates compilation error due to
 eager template instantiation
In-Reply-To: <bug-11248-206@http.llvm.org/bugs/>
References: <bug-11248-206@http.llvm.org/bugs/>
Message-ID: <20111027215821.813853128075@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11248

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-27 16:58:21 CDT ---
This code is actually invalid. See

  http://clang.llvm.org/compatibility.html#undep_incomplete

for an explanation.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 27 17:13:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 17:13:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11237] ARC: Warning when setter declared alongside
 property cannot be satisfied
In-Reply-To: <bug-11237-206@http.llvm.org/bugs/>
References: <bug-11237-206@http.llvm.org/bugs/>
Message-ID: <20111027221309.E9EBE3524007@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11237

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-27 17:13:09 CDT ---
This works correctly with clang built from trunk.  (And in general, please file
bugs found with the clang distributed with Xcode at bugreporter.apple.com.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 27 17:32:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 17:32:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11233] Documentation for -basicaa and -noaa is not
 current for Passes.html
In-Reply-To: <bug-11233-206@http.llvm.org/bugs/>
References: <bug-11233-206@http.llvm.org/bugs/>
Message-ID: <20111027223236.36B0C3128075@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11233

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-27 17:32:35 CDT ---
r143159 (and in the future, please send patches like this to llvm-commits).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Thu Oct 27 19:37:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 19:37:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11249] New: clang analyzer crash when initializing
 struct with unnamed bitfield
Message-ID: <bug-11249-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11249

           Summary: clang analyzer crash when initializing struct with
                    unnamed bitfield
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: shartwell at vmware.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7542)
 --> (http://llvm.org/bugs/attachment.cgi?id=7542)
minimal C statements to cause static analyzer crash

Running Checker-258 on the attached C source file crashes the clang analyzer.
It also crashes when directly invoking /usr/bin/clang --analyze from the Xcode
4.2 Lion SDK (clang 3.0).

The minimal source seems to require the following conditions in order to crash:
-- the initialization must happen inside a function
-- the struct must have an unnamed bitfield
-- which must be followed by an array and an unsigned field
Changing any of these conditions will cause the static analyzer to run without
crashing.

Note that clang compiles this file just fine; this only affects the static
analyzer.

Example invocation:
       ./checker-258/scan-build clang -c staticanalyzer_crash.c
Output:
       Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible
type!"), function cast, file
/tmp/checker-258-src/include/llvm/Support/Casting.h, line 194.
Stack dump:
0.    Program arguments:
/Volumes/Development/tools/clang-static-analyzer/checker-258/bin/clang-3.0 -cc1
-triple x86_64-apple-macosx10.7.2 -analyze -disable-free -main-file-name
staticanalyzer_crash.c -analyzer-store=region
-analyzer-opt-analyze-nested-blocks -analyzer-eagerly-assume
-analyzer-checker=core -analyzer-checker=deadcode -analyzer-checker=security
-analyzer-checker=unix -analyzer-checker=osx -analyzer-output plist -w
-pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2
-resource-dir
/Volumes/Development/tools/clang-static-analyzer/checker-258/bin/../lib/clang/3.0
-fmodule-cache-path
/var/folders/t_/nkqdpfz139gbxcl1f7nx_87h63cm03/T/clang-module-cache
-ferror-limit 19 -fmessage-length 0 -stack-protector 1 -fblocks
-fobjc-runtime-has-arc -fobjc-runtime-has-weak -fobjc-dispatch-method=mixed
-fdiagnostics-show-option -analyzer-output=html -o
/var/folders/t_/nkqdpfz139gbxcl1f7nx_87h63cm03/T/scan-build-2011-10-27-2 -x c
staticanalyzer_crash.c 
1.    <eof> parser at end of file
2.    staticanalyzer_crash.c:8:6: Error evaluating statement
3.    staticanalyzer_crash.c:8:6: 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 llvm.org  Thu Oct 27 19:48:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 19:48:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9751] -Wformat doesn't point to the callsite when
 format string is a variable
In-Reply-To: <bug-9751-206@http.llvm.org/bugs/>
References: <bug-9751-206@http.llvm.org/bugs/>
Message-ID: <20111028004827.9AA733128076@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9751

rtrieu at google.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rtrieu at google.com
         Resolution|                            |FIXED

--- Comment #1 from rtrieu at google.com 2011-10-27 19:48:26 CDT ---
Committed a fix at r143168.

--Source--
#include <stdio.h>

const char kFormatStr[] = "%d %s\n";

void f() {
  printf(kFormatStr, 0);
  printf(kFormatStr, 1);
}

--Clang Messages--
format.c:6:10: warning: more '%' conversions than data arguments [-Wformat]
  printf(kFormatStr, 0);
         ^~~~~~~~~~
format.c:3:32: note: format string is defined here
const char kFormatStr[] = "%d %s\n";
                              ~^
format.c:7:10: warning: more '%' conversions than data arguments [-Wformat]
  printf(kFormatStr, 1);
         ^~~~~~~~~~
format.c:3:32: note: format string is defined here
const char kFormatStr[] = "%d %s\n";
                              ~^
2 warnings 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 llvm.org  Thu Oct 27 21:01:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 27 Oct 2011 21:01:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8156] LegalizeOp incorrect node updates!
In-Reply-To: <bug-8156-206@http.llvm.org/bugs/>
References: <bug-8156-206@http.llvm.org/bugs/>
Message-ID: <20111028020127.7C7FB3128075@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8156

Bruno Cardoso Lopes <bruno.cardoso at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |bruno.cardoso at gmail.com
         Resolution|                            |FIXED

--- Comment #3 from Bruno Cardoso Lopes <bruno.cardoso at gmail.com> 2011-10-27 21:01:26 CDT ---
Fixed by Dan Gohman in r143177!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 05:03:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 05:03:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8156] LegalizeOp incorrect node updates!
In-Reply-To: <bug-8156-206@http.llvm.org/bugs/>
References: <bug-8156-206@http.llvm.org/bugs/>
Message-ID: <20111028100356.3CC693128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8156

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         Resolution|FIXED                       |

--- Comment #4 from Duncan Sands <baldrick at free.fr> 2011-10-28 05:03:55 CDT ---
I reverted the patch that fixed 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 llvm.org  Fri Oct 28 05:19:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 05:19:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11250] New: no code emitted for virtual inline
 function inherited indirectly from class template
Message-ID: <bug-11250-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11250

           Summary: no code emitted for virtual inline function inherited
                    indirectly from class template
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: stephan.bergmann.secondary at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=7544)
 --> (http://llvm.org/bugs/attachment.cgi?id=7544)
test case

The attached run.sh fails for me (on Fedora 15 x86_64) with Clang built from
today's trunk with the following output:

++ cat
++ cat
++ clang++ --version
clang version 3.1 (trunk 143187)
Target: x86_64-unknown-linux-gnu
Thread model: posix
++ clang++ -shared -fPIC -fvisibility=hidden lib1.cc -o lib1.so
++ clang++ -shared -fPIC lib2.cc -L. -l1 -Wl,-z,defs -o lib2.so
/tmp/lib2-I0DZ8n.o:(.data.rel.ro+0x20): undefined reference to `S1<int>::f()'
clang: error: linker command failed with exit code 1 (use -v to see invocation)

GCC on the other hand works fine, emitting f() weakly in lib2.o.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 09:39:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 09:39:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11250] no code emitted for virtual inline function
 inherited indirectly from class template
In-Reply-To: <bug-11250-206@http.llvm.org/bugs/>
References: <bug-11250-206@http.llvm.org/bugs/>
Message-ID: <20111028143938.6D2CE3128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11250

Stephan Bergmann <stephan.bergmann.secondary at googlemail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #1 from Stephan Bergmann <stephan.bergmann.secondary at googlemail.com> 2011-10-28 09:39:38 CDT ---


*** This bug has been marked as a duplicate of bug 10113 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 11:40:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 11:40:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11251] New: lshr of character vector inefficient on
	x86
Message-ID: <bug-11251-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11251

           Summary: lshr of character vector inefficient on x86
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: pete.cooper at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The following code is expanded out to 16 extracts, 16 byte shifts, and 16
inserts.

As neighbouring bytes (0 1, 2 3, etc) have equal shift amounts, this could be
done with an 8xi16 shift and then a mask on the high bits of the odd bytes
which were shifted down from the even byte in the pair but which should instead
be 0.

define <16 x i8> @shift_vec16x8(<16 x i8> %var) {
entry:
%0 = lshr <16 x i8> %var, <i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2,
                           i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2, i8 2>
ret <16 x i8> %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 llvm.org  Fri Oct 28 12:16:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 12:16:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11252] New: C++11 implementation status of
 defaulted functions is incorrect (cxx_status.html)
Message-ID: <bug-11252-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11252

           Summary: C++11 implementation status of defaulted functions is
                    incorrect (cxx_status.html)
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Documentation
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mimomorin at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The web page (http://clang.llvm.org/cxx_status.html) says that defaulted
functions are implemented on clang-2.9. But, actually, they are not implemented
on clang-2.9. Trunk (and maybe clang-3.0 too)  has support of defaulted
functions.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 12:18:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 12:18:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11253] New: There is no querying macro for C++11
 defaulted functions
Message-ID: <bug-11253-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11253

           Summary: There is no querying macro for C++11 defaulted
                    functions
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mimomorin at gmail.com
                CC: llvmbugs at cs.uiuc.edu




-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 12:33:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 12:33:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11254] New: Reparsing crashes for files that use
 pragmas when precompiled preamble is enabled
Message-ID: <bug-11254-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11254

           Summary: Reparsing crashes for files that use pragmas when
                    precompiled preamble is enabled
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthias_kleine at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=7545)
 --> (http://llvm.org/bugs/attachment.cgi?id=7545)
Source Files + Python script to trigger reparse

Trying to re-parse the attached file with PrecompiledPreamble enabled crashes
libclang. It reports the following assertion:

Assertion failed: (0 && "Invalid SLocOffset or bad function choice"), function
getFileIDLoaded, file
/Users/mkl/projects/llvm/llvm/tools/clang/lib/Basic/SourceManager.cpp, line
735.
libclang: crash detected during reparsing

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 12:48:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 12:48:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11255] New: Incorrect code generation of asm("sp")
 by clang on ARM
Message-ID: <bug-11255-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11255

           Summary: Incorrect code generation of asm("sp") by clang on ARM
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mcharleb at codeaurora.org
                CC: llvmbugs at cs.uiuc.edu


I have been working on compiling the ARM Linux kernel with clang and found a
bug in the code generated by clang for current_thread_info(). I have isolated
the problem to the handling of the following statement:

register unsigned long sp asm ("sp");

I attached a simple test program (test2.c) to demonstrate the bug.

Here are the output results from GCC and then from clang:

$ /opt/arm-2011.03/bin/arm-none-linux-gnueabi-gcc -o test2 test2.c -g -static
qemu-arm test2

&p = 0x408002fc sp = 408002f8
f1: p = 0x40800000
f2: p = 0x40800000

$ clang -g -march=armv7-a -ccc-host-triple arm -mfloat-abi=softfp -mfpu=neon
-ccc-gcc-name none-linux-gnueabi-gcc -I
/shared/llvm/llvm-upstream-arm/install-cross-3.0/lib/clang/3.0/include -o test2
test2.c -static

$ qemu-arm test2
&p = 0x40800300 sp = 0
f1: p = (nil)
f2: p = 0x40800000

Other times I see the following or other values of p from f2():

$ qemu-arm test2
&p = 0x40800300 sp = 0
f1: p = 0x6e000
f2: p = 0x40800000

Clearly the value returned from f2() is undefined.

Here is the assembly generated for f1() when compiled with clang:

(gdb) disassemble /m f1  
Dump of assembler code for function f1:
6    {

7        register unsigned long sp asm ("sp");
8    
9        return (void *)(sp & ~(THREAD_SIZE - 1));
   0x0000824c <+0>:    sub    sp, sp, #4
   0x00008250 <+4>:    ldr    r0, [sp]
   0x00008254 <+8>:    bfc    r0, #0, #13
   0x00008258 <+12>:    add    sp, sp, #4
   0x0000825c <+16>:    bx    lr

End of assembler dump.


Here is the assembly generated by gcc for f1():

(gdb) disassemble /m f1
Dump of assembler code for function f1:
6    {
   0x000081cc <+0>:    push    {r11}        ; (str r11, [sp, #-4]!)
   0x000081d0 <+4>:    add    r11, sp, #0

7        register unsigned long sp asm ("sp");
8    
9        return (void *)(sp & ~(THREAD_SIZE - 1));
   0x000081d4 <+8>:    mov    r3, sp
   0x000081d8 <+12>:    bic    r3, r3, #8128    ; 0x1fc0
   0x000081dc <+16>:    bic    r3, r3, #63    ; 0x3f

10    }
   0x000081e0 <+20>:    mov    r0, r3
   0x000081e4 <+24>:    add    sp, r11, #0
   0x000081e8 <+28>:    pop    {r11}        ; (ldr r11, [sp], #4)
   0x000081ec <+32>:    bx    lr

End of assembler dump.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 13:06:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 13:06:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11256] New: Lots of headers don't compile clean
 with gcc 4.5.3 with -Wall
Message-ID: <bug-11256-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11256

           Summary: Lots of headers don't compile clean with gcc 4.5.3
                    with -Wall
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Kevin.Harris at unisys.com
                CC: llvmbugs at cs.uiuc.edu


On our project, one of the aspects that we enjoy about LLVM is the fact that it
compiles cleanly with ?Wall with gcc.  We were previously running with a gcc
4.1.x compiler, but we recently upgraded to gcc/g++ 4.5.3.  We were glad to see
that LLVM 2.9 still compiles cleanly with this version, even though the gnu
folks have added several warnings in the intervening time.

Just this week, I decided to try the latest LLVM ? the current trunk version
(3.1svn) and I also tried the tags/RELEASE_30 version.  I was surprised and
disappointed to see that, combined with the new gcc, and the changes to the
headers in the intervening time, our code no longer compiles cleanly.   In
particular, we are suffering a spate of ?-Wshadow? warnings in the new versions
of the headers.  See a discussion of this issue at:
http://stackoverflow.com/questions/2958457/gcc-wshadow-is-too-strict for some
simple examples of this warning.

Whether gcc?s ?Wshadow is too strict or not, I found I was able to suppress all
these warnings by the simple expedient of changing the spelling of the
variables (mostly parameters) mentioned in these warnings.  I just added a ?1?
suffix to each name that appears in a warning, and all uses of the name in any
code bodies that appear in the headers.

Since we haven?t systematically attempted to use all the LLVM and Clang
headers, we obviously don?t have a complete list of the instances of this
issue, but I?ll provide a list of the headers, line numbers associated with the
warnings, and names associated with the warnings, for which we?re seeing this
problem:

    Header                                  line number(s)      variable
name(s)

    llvm/GlobalValue.h                      62                  Name
    llvm/Instructions.h                     611,1265,1274,2739  SubclassData,
Value
    llvm/ADT/StringRef.h                    72                  data
    llvm/ADT/ilist_node.h                   81, 92              Next
    llvm/ADT/ArrayRef.h                     57, 61              data, begin,
end
    llvm/ADT/FoldingSet.h                   481                 Context
    llvm/ADT/ValueMap.h                     95, 203, 278, 326   Data, Map, I
    llvm/Analysis/CFGPrinter.h              29                  isSimple
    llvm/CodeGen/MachineInstr.h             365                 isKill
    llvm/ExecutionEngine/ExecutionEngine.h  531                 M
    llvm/MC/MCDisassembler.h                58                  STI
    llvm/Support/CFG.h                      103                 idx
    llvm/Support/TimeValue.h                89,266,315,323,333  seconds,
microseconds, milliseconds
    llvm/Support/GraphWriter.h              65                  O
    llvm/Support/ValueHandle.h              284                 VP
    llvm/Support/IRBuilder.h                138                 InsertPoint

In all cases except one, the files are identical between the 3.0 rc1 and the
3.1svn versions (rev 143124).  The exception is Instructions.h, where there are
7 additional lines added in the 3.1svn version, prior to the last instance of
the problem.

I'd be glad to attach my edited versions of these files upon request.

There are at least 2 open problem reports against -Wshadow behavior in Clang,
but this is not related - it is strictly an LLVM header compilation issue.

It would be great if these name changes could be included in the final release
version of 3.0.  Thanks in advance,
    -Kevin

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 13:35:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 13:35:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11257] New: "Unused parameter" warnings when
 compiling headers with gcc 4.5.3 and -Wall
Message-ID: <bug-11257-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11257

           Summary: "Unused parameter" warnings when compiling headers
                    with gcc 4.5.3 and -Wall
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: Kevin.Harris at unisys.com
                CC: llvmbugs at cs.uiuc.edu


On our project, one of the aspects that we enjoy about LLVM is the fact that it
compiles cleanly with ?Wall with gcc.  We were previously running with a gcc
4.1.x compiler, but we recently upgraded to gcc/g++ 4.5.3.  We were glad to see
that LLVM 2.9 still compiles cleanly with this version, even though the gnu
folks have added several warning messages in the intervening time.

Just this week, I decided to try the latest LLVM ? the current trunk version
(3.1svn) and I also tried the tags/RELEASE_30 version.  I was surprised and
disappointed to see that, combined with the new gcc, and the changes to the
headers in the intervening time, our code no longer compiles cleanly.   In
particular, we are suffering several "Unused parameter" warnings.  These
warnings only appear when including headers for which functions are DEFINED -
rather than just declared.

It isn't obvious why these functions take these unused parameters, perhaps to
provide future functionality. I was able to suppress the warnings by adding a
harmless use of the offending variables in the bodies of the functions that
appear in the headers.

Our project doesn't use all the headers in LLVM by any means, so I obviously
don't have a complete list of all instances of this problem.  But I will list
all the instances that we're seeing in our builds, with associated line numbers
and names for each warning:

    Header                                   Line(s)          Name(s)
    llvm/Analysis/CFGPrinter.h               35, 47           Graph
    llvm/Assembly/AssemblyAnnotationWriter.h 35,41,47,53,58   F, OS, BB, I, V
    llvm/ExecutionEngine/JITEventListener.h  62, 74           F, Code, Size,
Details, OldPtr
    llvm/Support/DOTGraphTraits.h            64, 129, 135     Node, I

In all instances, the files are identical between the 3.0 rc1 and the 3.1svn
versions (rev 143124).

I'd be glad to attach my edited versions of these files upon request.

I was not able to find any previous bug reports on this topic.

It would be great if these "Unused parameter" problems could be resolved in the
final release version of 3.0.  Thanks in advance,
    -Kevin

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 13:37:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 13:37:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11258] New: ARM-Linux: compilation of llvm-2.9
 fails: SPUISelDAGToDAG.cpp:222:60: error: 'SelectCode' was not declared in
 this scope
Message-ID: <bug-11258-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11258

           Summary: ARM-Linux: compilation of llvm-2.9 fails:
                    SPUISelDAGToDAG.cpp:222:60: error: 'SelectCode' was
                    not declared in this scope
           Product: new-bugs
           Version: 2.9
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: aapo.rantalainen at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I'm on Linux armv5tel
Self compiled gcc-4.6.1 (installed on /opt/gcc-4.6)

Downloaded: llvm-2.9.tgz
Configured with: CC=/opt/gcc-4.6/bin/gcc CPP=/opt/gcc-4.6/bin/cpp
CXX=/opt/gcc-4.6/bin/g++ ./configure
Compiled with: LD_LIBRARY_PATH=/opt/gcc-4.6/lib/:$LD_LIBRARY_PATH make

After several hours it encounters error:

llvm[3]: Compiling SPUISelDAGToDAG.cpp for Release build
SPUISelDAGToDAG.cpp: In member function 'llvm::SDNode*
{anonymous}::SPUDAGToDAGISel::emitBuildVector(llvm::SDNode*)':
SPUISelDAGToDAG.cpp:222:60: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp: In member function 'virtual llvm::SDNode*
{anonymous}::SPUDAGToDAGISel::Select(llvm::SDNode*)':
SPUISelDAGToDAG.cpp:696:66: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp:707:59: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp:715:42: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp:726:58: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp:738:58: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp:749:58: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp:898:24: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp: In member function 'llvm::SDNode*
{anonymous}::SPUDAGToDAGISel::SelectI64Constant(uint64_t, llvm::EVT,
llvm::DebugLoc)':
SPUISelDAGToDAG.cpp:1184:55: error: 'SelectCode' was not declared in this scope
SPUISelDAGToDAG.cpp: In member function 'virtual llvm::SDNode*
{anonymous}::SPUDAGToDAGISel::Select(llvm::SDNode*)':
SPUISelDAGToDAG.cpp:899:1: warning: control reaches end of non-void function
[-Wreturn-type]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 13:54:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 13:54:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11259] New: possible optimization: convert ui2fp
 into a select instr if i1 type is used
Message-ID: <bug-11259-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11259

           Summary: possible optimization: convert ui2fp into a select
                    instr if i1 type is used
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nadav.rotem at intel.com
                CC: llvmbugs at cs.uiuc.edu


when calling si2fp or ui2fp and the input number is of type i1, it is possible
to convert it to a select (i1 %c, 0, -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 llvm.org  Fri Oct 28 14:42:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 14:42:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11260] New: Fold ADCS Rd, Rn, Rm to ADCS Rdn,
 Rm when d=n and .W not specified
Message-ID: <bug-11260-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11260

           Summary: Fold ADCS Rd, Rn, Rm to ADCS Rdn, Rm when d=n and .W
                    not specified
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Very minor feature suggestion:

I caught this while looking at the output of some Thumb 2 inline assembler.
ADCS Rd, Rn, Rm was encoded in wide form

...
  44:    f7ff fffe     bl    0 <s32_ufract_mul>
  48:    182d          adds    r5, r5, r0
  4a:    eb54 0401     adcs.w    r4, r4, r1
  4e:    bf64          itt    vs
  50:    17e5          asrvs    r5, r4, #31
...

The original inline assembler was

...
    "adds %Q0, %Q0, %Q1\n"
    "adcs %R0, %R0, %R1\n"
    "itt vs\n"
...

GCC folded this to the narrow form.
Granted in this particular case (porting it over from GCC), I could have just
used the two-argument, but what if I hadn't? If it folded after register
assignment into 16-bit forms where possible, this could save code space.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 14:44:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 14:44:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11252] C++11 implementation status of defaulted
 functions is incorrect (cxx_status.html)
In-Reply-To: <bug-11252-206@http.llvm.org/bugs/>
References: <bug-11252-206@http.llvm.org/bugs/>
Message-ID: <20111028194436.069D83128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11252

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-28 14:44:35 CDT ---
Fixed in r143216.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 15:25:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 15:25:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11255] Incorrect code generation of asm("sp") by
	clang on ARM
In-Reply-To: <bug-11255-206@http.llvm.org/bugs/>
References: <bug-11255-206@http.llvm.org/bugs/>
Message-ID: <20111028202555.1CBF63128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11255

Jakob Stoklund Olesen <stoklund at 2pi.dk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #4 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-10-28 15:25:54 CDT ---
Thanks, Mark.

That asm("sp") doesn't do anything when the sp variable isn't used as an inline
assembly operand.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 15:45:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 15:45:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9614] clang generates endless loop
In-Reply-To: <bug-9614-206@http.llvm.org/bugs/>
References: <bug-9614-206@http.llvm.org/bugs/>
Message-ID: <20111028204543.9F1773128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=9614

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #26 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-10-28 15:45:42 CDT ---
fixed in r143222.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 16:44:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 16:44:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8237] [selectiondag] Clang crashes with -O3
	optimization
In-Reply-To: <bug-8237-206@http.llvm.org/bugs/>
References: <bug-8237-206@http.llvm.org/bugs/>
Message-ID: <20111028214404.2A7C83128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=8237

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rafael.espindola at gmail.com
         Resolution|                            |FIXED

--- Comment #15 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-10-28 16:44:02 CDT ---
Looks like it works on trunk too. Closing.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 17:11:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 17:11:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11261] New: Compiler error when using "_Generic"
 identifier in C++ source code
Message-ID: <bug-11261-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11261

           Summary: Compiler error when using "_Generic" identifier in C++
                    source code
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: max at quendi.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


When compiling code with clang++ 3.0 (as shipped with Apple XCode 4.2) that
contains _Generic, an error is raised, like this:

test.cc:5:6: error: expected unqualified-id
        int _Generic = 0;

After some googling around, this seems to be related to the "C1X generic
selections" extension (see
http://clang.llvm.org/doxygen/classclang_1_1GenericSelectionExpr.html).
However, I could not find further information on this, and it is not clear to
me whether this is part of C++11, or of a future extension of the C++ standard.

If this error really is intentional behavior, then please change the warning to
something more helpful, like "_Generic is a C1X reserved keyword". 

But personally I'd prefer if using _Generic was again made possible for code
that does not explicitly request C1X extensions, as "legacy code" is using
this.

For reference, this was with
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.8.0
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 llvm.org  Fri Oct 28 17:34:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 17:34:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11262] New: function templates used within VLA
 array bounds don't get instantiated
Message-ID: <bug-11262-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11262

           Summary: function templates used within VLA array bounds don't
                    get instantiated
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu


Building this code:

  template<typename T> T min(T a, T b) { return a < b ? a : b; }
  void g(int*);
  void f() {
    int a[min(1,2)];
    g(a);
  }

... results in IR where min<int> is declared but not defined.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 18:01:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 18:01:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11261] Compiler error when using "_Generic"
 identifier in C++ source code
In-Reply-To: <bug-11261-206@http.llvm.org/bugs/>
References: <bug-11261-206@http.llvm.org/bugs/>
Message-ID: <20111028230136.8A8673128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11261

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WONTFIX

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-28 18:01:36 CDT ---
Since _Generic is (and has always been) a reserved name, so user code that's
using this name has always been non-conforming. For that reason, and because
likely that people want to use _Generic in (say) C++ or C99 mode, I'm closing
this as "won't fix".

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 18:07:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 18:07:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11250] no code emitted for virtual inline function
 inherited indirectly from class template
In-Reply-To: <bug-11250-206@http.llvm.org/bugs/>
References: <bug-11250-206@http.llvm.org/bugs/>
Message-ID: <20111028230744.7236C3128026@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11250

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|DUPLICATE                   |

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-28 18:07:44 CDT ---
Reopening; I'm convinced this is a different issue.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 18:21:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 18:21:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11262] function templates used within VLA array
 bounds don't get instantiated
In-Reply-To: <bug-11262-206@http.llvm.org/bugs/>
References: <bug-11262-206@http.llvm.org/bugs/>
Message-ID: <20111028232119.B77613128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11262

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-28 18:21:19 CDT ---


*** This bug has been marked as a duplicate of bug 7614 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 21:57:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 21:57:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11263] New: __has_include does not work correctly
 (compilation fails)
Message-ID: <bug-11263-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11263

           Summary: __has_include does not work correctly (compilation
                    fails)
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mimomorin at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The following code fails to compile (tested on release build of trunk and
clang-3.0 rc1). 

#include <iostream>

int main (int argc, char* argv[])
{
    std::cout << __has_include(<iostream>) << std::endl;

    return 0;
}

Here is the error messages.
Assertion failed: (ParsingPreprocessorDirective && ParsingFilename == false &&
"Must be in a preprocessing directive!"), function LexIncludeFilename, file
llvm/tools/clang/lib/Lex/PreprocessorLexer.cpp, line 33.
0  clang             0x0000000105f11e22 _ZL15PrintStackTracePv + 34
1  clang             0x0000000105f12409 _ZL13SignalHandleri + 745
2  libsystem_c.dylib 0x00007fff94292cfa _sigtramp + 26
3  libsystem_c.dylib 000000000000000000 _sigtramp + 18446603338030437152
4  clang             0x0000000105f12076 abort + 22
5  clang             0x0000000105f12038 __assert_rtn + 56
6  clang             0x0000000105448ef4
clang::PreprocessorLexer::LexIncludeFilename(clang::Token&) + 164
7  clang             0x000000010543a9b2
_ZL24EvaluateHasIncludeCommonRN5clang5TokenEPNS_14IdentifierInfoERNS_12PreprocessorEPKNS_15DirectoryLookupE
+ 242
8  clang             0x0000000105437c1e
clang::Preprocessor::ExpandBuiltinMacro(clang::Token&) + 9774
9  clang             0x00000001054351e4
clang::Preprocessor::HandleMacroExpandedIdentifier(clang::Token&,
clang::MacroInfo*) + 100
10 clang             0x0000000105447933
clang::Preprocessor::HandleIdentifier(clang::Token&) + 211
11 clang             0x0000000105419fd2
clang::Lexer::LexIdentifier(clang::Token&, char const*) + 226
12 clang             0x000000010541e285
clang::Lexer::LexTokenInternal(clang::Token&) + 5829
13 clang             0x0000000105426538
clang::Preprocessor::CachingLex(clang::Token&) + 216
14 clang             0x0000000104d8bdea
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*,
true>, clang::prec::Level) + 730
15 clang             0x0000000104d8badc
clang::Parser::ParseAssignmentExpression() + 188
16 clang             0x0000000104d8b9fe clang::Parser::ParseExpression() + 14
17 clang             0x0000000104dae624
clang::Parser::ParseExprStatement(clang::ParsedAttributes&) + 52
18 clang             0x0000000104dadf14
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool) + 2052
19 clang             0x0000000104db3b44
clang::Parser::ParseCompoundStatementBody(bool) + 1348
20 clang             0x0000000104db51f7
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 167
21 clang             0x0000000104dc2f62
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 2210
22 clang             0x0000000104d74363
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1059
23 clang             0x0000000104dc2111
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 849
24 clang             0x0000000104dc2302
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 386
25 clang             0x0000000104dc12dc
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 3388
26 clang             0x0000000104dc0526
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 246
27 clang             0x0000000104d69e4d clang::ParseAST(clang::Sema&, bool) +
333
28 clang             0x0000000104d35ebc clang::CodeGenAction::ExecuteAction() +
1020
29 clang             0x0000000104b2521b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 955
30 clang             0x0000000104b0e555
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 2789
31 clang             0x0000000104b0696d cc1_main(char const**, char const**,
char const*, void*) + 5421
32 clang             0x0000000104b0a811 main + 753
33 clang             0x0000000104b05434 start + 52
Stack dump:
0.    Program arguments: build/Release+Asserts/bin/clang -cc1 -triple
x86_64-apple-macosx10.7.2 -emit-obj -disable-free -main-file-name
untitled_47.cc -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 123.2.1 -resource-dir
build/Release+Asserts/bin/../lib/clang/3.1 -I /Users/niji/Boosty/boost-trunk -I
/Users/niji/Include -I libcxx/include -stdlib=libc++ -fmodule-cache-path
/var/folders/r5/h6yf9zwn68z4slg54d38smq80000gn/T/clang-module-cache -O3 -Wall
-fdeprecated-macro -fdebug-compilation-dir
/private/var/folders/r5/h6yf9zwn68z4slg54d38smq80000gn/T -ferror-limit 19
-fmessage-length 0 -stack-protector 1 -fblocks -fobjc-runtime-has-arc
-fobjc-runtime-has-weak -fobjc-dispatch-method=mixed -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -o
/var/folders/r5/h6yf9zwn68z4slg54d38smq80000gn/T/untitled_47-4U8F2w.o -x c++
untitled 
1.    untitled:5:31: current parser token '('
2.    untitled:4:1: parsing function body 'main'
3.    untitled:4:1: in compound statement ('{}')
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang: error: unable to execute command: Illegal instruction: 4
clang: note: diagnostic msg: Error generating preprocessed source(s).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 21:59:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 21:59:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11264] New: Duplicate strings
Message-ID: <bug-11264-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11264

           Summary: Duplicate strings
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rkotler at mips.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


In a simple program with duplicate strings in printf, clang creates two
identical string constants:

#include <stdio.h>

void gp2() {
  printf("hello\n");
  printf("hello\n");
}

The bitcode file has two different string constants.

The x86 code generator removes the duplicate but in both Arm and Mips the
duplicate is preserved.


    .file    "gp2.c"
    .text
    .globl    gp2
    .align    16, 0x90
    .type    gp2, at function
gp2:                                    # @gp2
.Ltmp2:
    .cfi_startproc
# BB#0:                                 # %entry
    pushq    %rbp
.Ltmp3:
    .cfi_def_cfa_offset 16
.Ltmp4:
    .cfi_offset %rbp, -16
    movq    %rsp, %rbp
.Ltmp5:
    .cfi_def_cfa_register %rbp
    movl    $str, %edi
    callq    puts
    movl    $str1, %edi
    popq    %rbp
    jmp    puts                    # TAILCALL
.Ltmp6:
    .size    gp2, .Ltmp6-gp2
.Ltmp7:
    .cfi_endproc
.Leh_func_end0:

    .type    str, at object             # @str
    .section    .rodata,"a", at progbits
str:
    .asciz     "hello"
    .size    str, 6

    .type    str1, at object            # @str1
str1:
    .asciz     "hello"
    .size    str1, 6


    .section    ".note.GNU-stack","", at progbits

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Fri Oct 28 22:19:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 28 Oct 2011 22:19:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 11263] [Clang-3.0 Regression] __has_include does
 not work correctly (compilation fails)
In-Reply-To: <bug-11263-206@http.llvm.org/bugs/>
References: <bug-11263-206@http.llvm.org/bugs/>
Message-ID: <20111029031953.6D5643128018@llvm.org>

http://llvm.org/bugs/show_bug.cgi?id=11263

mimomorin at gmail.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |INVALID

--- Comment #1 from mimomorin at gmail.com 2011-10-28 22:19:52 CDT ---
I realized that my code is not intentional use of __has_include. 
Sorry for the noise.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 29 10:48:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 29 Oct 2011 15:48:28 +0000
Subject: [LLVMbugs] [Bug 11263] [Clang-3.0 Regression] __has_include does
 not work correctly (compilation fails)
In-Reply-To: <bug-11263-206@>
References: <bug-11263-206@>
Message-ID: <bug-11263-206-kXxAwS3eVT@>

show_bug.cgi?id=11263

Anders Carlsson <andersca at mac.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |andersca at mac.com
         Resolution|INVALID                     |

--- Comment #2 from Anders Carlsson <andersca at mac.com> 2011-10-29 10:48:28 CDT ---
If clang is asserting on a code snippet, that sounds like something we'd like
to fix, reopening

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 29 14:46:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 29 Oct 2011 19:46:00 +0000
Subject: [LLVMbugs] [Bug 11264] Duplicate strings
In-Reply-To: <bug-11264-206@>
References: <bug-11264-206@>
Message-ID: <bug-11264-206-Qo3gm7KyeY@>

show_bug.cgi?id=11264

Benjamin Kramer <benny.kra at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |FIXED

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2011-10-29 14:46:00 CDT ---
Fixed in r143289.

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 29 18:56:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 29 Oct 2011 23:56:54 +0000
Subject: [LLVMbugs] [Bug 11218]
 CodeGen/PowerPC/2008-10-17-AsmMatchingOperands.ll might not crash (XPASS)
 with -Asserts
In-Reply-To: <bug-11218-206@>
References: <bug-11218-206@>
Message-ID: <bug-11218-206-ss60eZbscA@>

show_bug.cgi?id=11218

Bill Wendling <wendling at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 29 18:57:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 29 Oct 2011 23:57:41 +0000
Subject: [LLVMbugs] [Bug 11229] 3.0rc1: bogus symlink to clang in tools dir.
In-Reply-To: <bug-11229-206@>
References: <bug-11229-206@>
Message-ID: <bug-11229-206-TWTUahWzcb@>

show_bug.cgi?id=11229

Bill Wendling <wendling at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Bill Wendling <wendling at apple.com> 2011-10-29 18:57:41 CDT ---
Fixed: 143302

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sat Oct 29 19:09:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 00:09:21 +0000
Subject: [LLVMbugs] [Bug 11265] New: Weird compiler error triggered by
 template friend statement
Message-ID: <bug-11265-206@>

show_bug.cgi?id=11265

             Bug #: 11265
           Summary: Weird compiler error triggered by template friend
                    statement
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: max at quendi.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7547
  --> attachment.cgi?id=7547
Reduced test case

Compiling the attached file results in a compiler error with Apple clang 3.0 on
my Mac OS X 10.6.8 system:


$ clang -Wall -c test3.cc
test3.cc:15:14: error: no matching constructor for initialization of
'A::C<A::b0>'
        A::C<A::b0> bar;
                    ^
test3.cc:11:35: note: candidate constructor (the implicit copy constructor) not
viable: requires 1 argument, but 0 were provided
        template <A::B> friend struct A::C;
                                         ^
1 error generated.
$ clang -v
Apple clang version 3.0 (tags/Apple/clang-211.10.1) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.8.0
Thread model: posix



Removing the "friend" statement in struct D, or moving either B or C out of
namespace A, as well as all sorts of other minimal changes, gets rid of the
error. In particular, replacing the single friend statement by these two works:
    friend struct A::C<A::b0>;
    friend struct A::C<A::b1>;


If this code is in some way wrong, I fail to see it and would greatly
appreciate any pointers as to in which way it is wrong. But then, the mere fact
that clang claims that the "friend" statement constitutes a copy constructor
makes me think something is very fishy here, even if my code turns out to be
somehow flawed.


Note that this is a heavily reduced version of an error that occurred in
production code. The original errors are of the form

error: 'N::M::C<1, true>::foo' is not a member of class 'N::M::C<1, true>'

and

error: non-const lvalue reference to type 'N::M::C<1, true>' cannot bind to a
value of unrelated type 'N::M::C<1, true>'

where N, M are namespaces and C a class similar to class C in the attached
example. Here, too, I identified a single friend statement as "cause" of the
problem in the sense that removing it cures the error.

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 02:08:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 07:08:04 +0000
Subject: [LLVMbugs] [Bug 11266] New: Inefficient x86 vector code generation
 for add v16i8; 
Message-ID: <bug-11266-206@>

show_bug.cgi?id=11266

             Bug #: 11266
           Summary: Inefficient x86 vector code generation for add v16i8;
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nadav.rotem at intel.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


>From the email exchange between Andrew and Chris:

Consider the following function which doubles a <16 x i8> vector:
> 
> define <16 x i8> @test(<16 x i8> %a) {
>       %b = add <16 x i8> %a, %a
>       ret <16 x i8> %b
> }
> 
> If I compile it for x86 with llc like so:
> 
> llc paddb.ll -filetype=asm -o=/dev/stdout
> 
> I get a two-op function that just does paddb %xmm0 %xmm0 and then 
> returns. llc does this regardless of the optimization level. Great!
> 
> If I let the instcombine pass touch it like so:
> 
> opt -instcombine paddb.ll |  llc -filetype=asm -o=/dev/stdout
> 
> or like so:
> 
> opt -O3 paddb.ll |  llc -filetype=asm -o=/dev/stdout
> 
> then the add gets converted to a vector left shift by 1, which then 
> lowers to a much slower function with about a hundred ops. No amount 
> of optimization after the fact will simplify it back to paddy.

This sounds like a really serious X86 backend performance bug.  Canonicalizing
"x+x" to a shift is the "right thing to do", the backend should match it.

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 02:22:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 07:22:37 +0000
Subject: [LLVMbugs] [Bug 11267] New: [Clang 3.0]
 __has_feature(cxx_raw_string_literals) and
 __has_feature(cxx_unicode_literals) do not work correctly
Message-ID: <bug-11267-206@>

show_bug.cgi?id=11267

             Bug #: 11267
           Summary: [Clang 3.0] __has_feature(cxx_raw_string_literals) and
                    __has_feature(cxx_unicode_literals) do not work
                    correctly
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mimomorin at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7548
  --> attachment.cgi?id=7548
A patch for lib/Lex/PPMacroExpansion.cpp (against trunk)

C++11 feature querying macros for "raw string literals" and "unicode string
literals" 
do not work on clang-3.0 and trunk. 
According to the C++11 Implementation status page
(http://clang.llvm.org/cxx_status.html), 
"raw string literals" and "unicode string literals" are already implemented on
clang-3.0. 
I also tested some codes and the codes worked well. 

A patch attached.

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 03:52:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 08:52:26 +0000
Subject: [LLVMbugs] [Bug 11268] New: CPP backend not support some new
 instructions (such as atomicrmw)
Message-ID: <bug-11268-206@>

show_bug.cgi?id=11268

             Bug #: 11268
           Summary: CPP backend not support some new instructions (such as
                    atomicrmw)
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: css20 at mail.ru
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7550
  --> attachment.cgi?id=7550
Bitcode with "atomicrmw or" instruction

llc -march=cpp test.ll

causes:

LLVM ERROR: Invalid instruction

see lib/Target/CppBackEnd/CppBackEnd.cpp:1031

  switch (I->getOpcode()) {
  default:
    error("Invalid instruction");
    break;

CppBackEnd does not handle this instruction:   %15 = atomicrmw or i8*
%.reload24, i8 %14 seq_cst

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 06:16:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 11:16:18 +0000
Subject: [LLVMbugs] [Bug 11085] error in backend: expected relocatable
 expression when compiling objective-c header file
In-Reply-To: <bug-11085-206@>
References: <bug-11085-206@>
Message-ID: <bug-11085-206-bNGcg3ur94@>

show_bug.cgi?id=11085

David Chisnall <csdavec at swan.ac.uk> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #15 from David Chisnall <csdavec at swan.ac.uk> 2011-10-30 06:16:18 CDT ---
Oops, sorry!  You applied the fix for this to the 3.0 branch on the 25th, I
just forgot to update the status.

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 07:22:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 12:22:54 +0000
Subject: [LLVMbugs] [Bug 11269] New: add a -std=c++11 option to the driver
Message-ID: <bug-11269-206@>

show_bug.cgi?id=11269

             Bug #: 11269
           Summary: add a -std=c++11 option to the driver
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: vanboxem.ruben at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Since the new Standard has been ratified and published, I think it's more than
time this gets added. In the next release, there could be a warning about the
deprecation of -std=c++0x in favor of the new one.

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 08:40:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 13:40:37 +0000
Subject: [LLVMbugs] [Bug 11266] Inefficient x86 vector code generation for
	add v16i8; 
In-Reply-To: <bug-11266-206@>
References: <bug-11266-206@>
Message-ID: <bug-11266-206-TK9YCTwpJc@>

show_bug.cgi?id=11266

Nadav Rotem <nadav.rotem at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Nadav Rotem <nadav.rotem at intel.com> 2011-10-30 08:40:37 CDT ---
Fixed in t143311.

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 10:55:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 15:55:57 +0000
Subject: [LLVMbugs] [Bug 10457] Delegating constructor template doesn't seem
	to delegate
In-Reply-To: <bug-10457-206@>
References: <bug-10457-206@>
Message-ID: <bug-10457-206-HNTNSU5gBq@>

show_bug.cgi?id=10457

jonathan.sauer at gmx.de changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |jonathan.sauer at gmx.de
         Resolution|FIXED                       |

--- Comment #3 from jonathan.sauer at gmx.de 2011-10-30 10:55:57 CDT ---
After the fix, clang r143312 crashes when compiling the following program:

struct Foo {
    Foo(int) { }


    template <typename T>
    Foo(T, int i) : Foo(i) { }
};

int main(int, char**)
{
    Foo    f(1, 1);
}


$clang++ -std=c++0x clang.cpp

Assertion failed: (!CurContext->isDependentContext()), function
BuildDelegatingInitializer, file
/Users/rynnsauer/LLVM/llvm/tools/clang/lib/Sema/SemaDeclCXX.cpp, line 2161.
0  clang             0x00000001012afac2 PrintStackTrace(void*) + 34
1  clang             0x00000001012aff49 SignalHandler(int) + 697
2  libSystem.B.dylib 0x00007fff83db41ba _sigtramp + 26
3  libSystem.B.dylib 0x00007fff5fbfa740 _sigtramp + 3689178528
4  clang             0x00000001000188e6 abort + 22
5  clang             0x00000001000188a5 __assert_rtn + 53
6  clang             0x000000010038bad9
clang::Sema::BuildDelegatingInitializer(clang::TypeSourceInfo*,
clang::MultiInitializer const&, clang::SourceLocation, clang::CXXRecordDecl*) +
793
7  clang             0x000000010038af67
clang::Sema::BuildBaseInitializer(clang::QualType, clang::TypeSourceInfo*,
clang::MultiInitializer const&, clang::CXXRecordDecl*, clang::SourceLocation) +
727
8  clang             0x0000000100389f03
clang::Sema::BuildMemInitializer(clang::Decl*, clang::Scope*,
clang::CXXScopeSpec&, clang::IdentifierInfo*,
clang::OpaquePtr<clang::QualType>, clang::SourceLocation,
clang::MultiInitializer const&, clang::SourceLocation) + 3811
9  clang             0x000000010038a044
clang::Sema::ActOnMemInitializer(clang::Decl*, clang::Scope*,
clang::CXXScopeSpec&, clang::IdentifierInfo*,
clang::OpaquePtr<clang::QualType>, clang::SourceLocation,
clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation,
clang::SourceLocation) + 100
10 clang             0x000000010027684c
clang::Parser::ParseMemInitializer(clang::Decl*) + 892
11 clang             0x0000000100276191
clang::Parser::ParseConstructorInitializer(clang::Decl*) + 449
12 clang             0x000000010025a1bc
clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 412
13 clang             0x0000000100259bb4
clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 132
14 clang             0x0000000100272af2
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 3122
[...]

1.    clang.cpp:6:25: current parser token '{'
2.    clang.cpp:1:1: parsing struct/union/class body 'Foo'
clang: error: unable to execute command: Illegal instruction


If the template parameter T is actually used in the constructor, the code
compiles.

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 12:04:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 17:04:47 +0000
Subject: [LLVMbugs] [Bug 11270] New: Template specialisation inside class
	accepted
Message-ID: <bug-11270-206@>

show_bug.cgi?id=11270

             Bug #: 11270
           Summary: Template specialisation inside class accepted
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following code compiles with clang but not gcc 4.4.6 or 4.5.3 for me:

cat > foo.cc <<EOF
template <int dim>
class A
{
public:
  A<1>(double a1);
  A<2>(double a1, double a2);

private:
  double a1_, a2_;
};

template<>
A<1>::A(double a1)
  : a1_(a1), a2_(0)
{}

template<>
A<2>::A(double a1)
  : a1_(a1), a2_(2)
{}
EOF

-- 
Configure bugmail: userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 13:41:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 30 Oct 2011 18:41:00 +0000
Subject: [LLVMbugs] [Bug 11271] New: llc: Unable to find compile unit!
Message-ID: <bug-11271-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11271

             Bug #: 11271
           Summary: llc: Unable to find compile unit!
           Product: tools
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: viridia at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7551
  --> http://llvm.org/bugs/attachment.cgi?id=7551
Sample bitcode file that exhibits the problem

This is in regards to the thread on llvm-dev about null compile units. I'm
attempting to determine whether the problem is in llc, or if it is in fact
further upstream.

The actual error I get is:

Assertion failed: (TheCU && "Unable to find compile unit!"), function
endFunction, file
/Users/talin/Projects/llvm/lib/CodeGen/AsmPrinter/DwarfDebug.cpp, line 1306.

The arguments that I am giving to llc are as follows:

  llc -load="${GC_PLUGIN}" -disable-fp-elim -filetype=obj \
     -o Minimal.o Minimal.lnk.bc

I've included Minimal.lnk.bc as an attachment. Could you please verify whether
or not this file is correct so I can narrow my search for the problem. Note
that minimal.lnk.bc was produced by the following command:

   llvm-ld -disable-opt -link-as-library -o Minimal.lnk.bc Minimal.bc
Support.bc

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 20:07:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 01:07:13 +0000
Subject: [LLVMbugs] [Bug 11247] as complains about "junk at end of line"
 when run from llvm-ld
In-Reply-To: <bug-11247-206@http.llvm.org/bugs/>
References: <bug-11247-206@http.llvm.org/bugs/>
Message-ID: <bug-11247-206-HjZSFSVgEk@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11247

Nick Lewycky <nicholas at mxc.ca> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Nick Lewycky <nicholas at mxc.ca> 2011-10-30 20:07:13 CDT ---
Fixed in r143326.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Sun Oct 30 23:21:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 04:21:27 +0000
Subject: [LLVMbugs] [Bug 11272] New: document implementation-defined behavior
Message-ID: <bug-11272-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11272

             Bug #: 11272
           Summary: document implementation-defined behavior
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Documentation
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The clang documentation should specify how clang behaves in cases specified to
be implementation-defined in the relevant standards. Perhaps simply saying that
our behavior is the same as GCC's would suffice?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 02:41:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 07:41:49 +0000
Subject: [LLVMbugs] [Bug 11273] New: building llvm 3.0rc1 hangs on OpenBSD
 sparc64 in llvm-tblgen
Message-ID: <bug-11273-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11273

             Bug #: 11273
           Summary: building llvm 3.0rc1 hangs on OpenBSD sparc64 in
                    llvm-tblgen
           Product: new-bugs
           Version: trunk
          Platform: Sun
        OS/Version: OpenBSD
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sebastia at l00-bugdead-prods.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


trying to build llvm/clang on OpenBSD 5.0 -current sparc64, hangs here:

llvm[3]: Building PPC.td code emitter with tblgen
/home/ports/pobj/llvm-3.0rc1.src/build-sparc64/Release/bin/llvm-tblgen -I 
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/lib/Target/PowerPC -I 
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/include -I 
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/include -I 
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/lib/Target -gen-emitter -o 
/home/ports/pobj/llvm-3.0rc1.src/build-sparc64/lib/Target/PowerPC/Release/PPCGenCodeEmitter.inc.tmp
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/lib/Target/PowerPC/PPC.td
/usr/bin/cmp -s PPCGenCodeEmitter.inc
/home/ports/pobj/llvm-3.0rc1.src/build-sparc64/lib/Target/PowerPC/Release/PPCGenCodeEmitter.inc.tmp
|| /bin/cp
/home/ports/pobj/llvm-3.0rc1.src/build-sparc64/lib/Target/PowerPC/Release/PPCGenCodeEmitter.inc.tmp
PPCGenCodeEmitter.inc
llvm[3]: Building PPC.td instruction information with tblgen
/home/ports/pobj/llvm-3.0rc1.src/build-sparc64/Release/bin/llvm-tblgen -I 
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/lib/Target/PowerPC -I 
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/include -I 
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/include -I 
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/lib/Target -gen-instr-info -o 
/home/ports/pobj/llvm-3.0rc1.src/build-sparc64/lib/Target/PowerPC/Release/PPCGenInstrInfo.inc.tmp
/home/ports/pobj/llvm-3.0rc1.src/llvm-3.0rc1/lib/Target/PowerPC/PPC.td

top output:
load averages:  1.17,  1.25,  1.17                                             
                                                       enterprise.ds9 08:35:41
42 processes:  40 idle, 2 on processor
CPU0 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU1 states:  0.0% user,  0.0% nice,  0.0% system,  0.0% interrupt,  100% idle
CPU2 states:  0.2% user,  0.0% nice,  0.0% system,  0.0% interrupt, 99.8% idle
CPU3 states:  0.0% user,  0.0% nice,  100% system,  0.0% interrupt,  0.0% idle
Memory: Real: 48M/536M act/tot Free: 1468M Cache: 373M Swap: 0K/587M

  PID USERNAME PRI NICE  SIZE   RES STATE     WAIT      TIME    CPU COMMAND
25101 root      64    0   15M   17M onproc/3  -       949:46 99.80% llvm-tblgen
 2040 sebastia  28    0 1696K 2928K onproc/2  -         1:59  0.00% top

The build was started at around 2 pm, now its 9 am next day. As top shows, this
process was very busy for a loooong time. The system is a Sun Enterprise Server
E450 with 4x400MHz and 2GB RAM.

attaching to the process with gdb, it hangs here:

(gdb) bt
#0  0x000000000021e7d8 in std::vector<llvm::Record*,
std::allocator<llvm::Record*> >::size ()
#1  0x0000000000225538 in llvm::Record::isSubClassOf ()
#2  0x00000000003723ac in llvm::InstrInfoEmitter::GetOperandInfo ()
#3  0x0000000000373c50 in llvm::InstrInfoEmitter::EmitOperandInfo ()
#4  0x000000000037451c in llvm::InstrInfoEmitter::run ()
#5  0x00000000003b9724 in LLVMTableGenAction::operator() ()
#6  0x00000000003cc020 in llvm::TableGenMain ()
#7  0x00000000003b5c08 in main ()

I marked this as release blocker, but you may decide otherwise. As far as I
know, llvm 2.9 also did not built or worked on OpenBSD sparc64. Don't know the
exact problem, but in the ports tree it was marked as broken.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 03:31:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 08:31:41 +0000
Subject: [LLVMbugs] [Bug 11242] Missing /usr/include/i386-linux-gnu include
 path on Ubuntu 11.04
In-Reply-To: <bug-11242-206@http.llvm.org/bugs/>
References: <bug-11242-206@http.llvm.org/bugs/>
Message-ID: <bug-11242-206-kROA2BYvEI@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11242

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2011-10-31 03:31:41 CDT ---
Yea, Debian or Ubuntu; this is the same bug.

*** This bug has been marked as a duplicate of bug 11223 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 03:44:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 08:44:18 +0000
Subject: [LLVMbugs] [Bug 11223] Fails to compile due to missing header
	search path
In-Reply-To: <bug-11223-206@http.llvm.org/bugs/>
References: <bug-11223-206@http.llvm.org/bugs/>
Message-ID: <bug-11223-206-kHJSZ5Igiw@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11223

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dgregor at apple.com
         Resolution|                            |FIXED

--- Comment #7 from Chandler Carruth <chandlerc at gmail.com> 2011-10-31 03:44:18 CDT ---
Both the header search and library search aspect of this should be fixed in
r143344 and r143345.

Adding Doug to confirm that this should go into 3.0, but it was discovered
during release testing so it seems like a good candidate 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 baldrick at free.fr  Fri Oct 28 14:32:11 2011
From: baldrick at free.fr (Duncan Sands)
Date: Fri, 28 Oct 2011 21:32:11 +0200
Subject: [LLVMbugs] [Bug 11257] New: "Unused parameter" warnings when
 compiling headers with gcc 4.5.3 and -Wall
In-Reply-To: <bug-11257-206@http.llvm.org/bugs/>
References: <bug-11257-206@http.llvm.org/bugs/>
Message-ID: <4EAB033B.1050701@free.fr>

Hi Kevin,

> Just this week, I decided to try the latest LLVM ? the current trunk version
> (3.1svn) and I also tried the tags/RELEASE_30 version.  I was surprised and
> disappointed to see that, combined with the new gcc, and the changes to the
> headers in the intervening time, our code no longer compiles cleanly.   In
> particular, we are suffering several "Unused parameter" warnings.  These
> warnings only appear when including headers for which functions are DEFINED -
> rather than just declared.
>
> It isn't obvious why these functions take these unused parameters, perhaps to
> provide future functionality. I was able to suppress the warnings by adding a
> harmless use of the offending variables in the bodies of the functions that
> appear in the headers.

I cleaned up a bunch of these a week or so ago - so it used to be worse!  C++
allows the following trick: if a parameter is unused, don't give it a name.
For example, in
   void foo(int x) {
   }
if x is unused then you can write
   void foo(int) {
   }
and the warning goes away.

> Our project doesn't use all the headers in LLVM by any means, so I obviously
> don't have a complete list of all instances of this problem.  But I will list
> all the instances that we're seeing in our builds, with associated line numbers
> and names for each warning:

One curiosity I noticed is that you don't see this while compiling LLVM itself,
only when compiling projects that use LLVM.  I don't know why.  Probably that's
the reason they haven't been fixed: they don't show up in LLVM builds.

> I'd be glad to attach my edited versions of these files upon request.

Feel free to send a patch.  It probably won't be fixed otherwise since this
presumably doesn't impact anyone else.

Ciao, Duncan.

From bugzilla-daemon at llvm.org  Mon Oct 31 03:54:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 08:54:41 +0000
Subject: [LLVMbugs] [Bug 11274] New: Missing warning for -Wconversion with
 compound assignment
Message-ID: <bug-11274-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11274

             Bug #: 11274
           Summary: Missing warning for -Wconversion with compound
                    assignment
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pat.pannuto+llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


A warning is not generated for the compound assignment case, though it is for
standard operation + assignment.

Simple test case:

int main() {
    uint8_t a = 1;
    a <<= 1;     // missing warning

    uint8_t b = 1;
    b = b << 1;  // warns correctly
}

Generates a warning only for b, but not for a:

conv.c:9:6: warning: implicit conversion loses integer precision: 'int' to
'uint8_t'
      (aka 'unsigned char') [-Wconversion]
        b = b << 1;
          ~ ^~~~~~

gcc v4.5 gets this right:

conv.c:6:2: warning: conversion to ?uint8_t? from ?int? may alter its value
conv.c:9:2: warning: conversion to ?uint8_t? from ?int? may alter its value


By my reading of 6.5.16.2 Compound assignment, the two should be consistent.
  For the other operators, each operand shall have arithmetic type consistent
with those
allowed by the corresponding binary operator.


--

First bug report of any kind to llvm, I believe I've followed preferred style /
info, please let me know if otherwise.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 06:25:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 11:25:44 +0000
Subject: [LLVMbugs] [Bug 11275] New: The unwind destination does not have a
 landingpad instruction!
Message-ID: <bug-11275-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11275

             Bug #: 11275
           Summary: The unwind destination does not have a landingpad
                    instruction!
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7555
  --> http://llvm.org/bugs/attachment.cgi?id=7555
testcase .ll

This occurs when building 447.dealII using the nightly testsuite.  Somewhat
reduced testcase attached.  Reproduce using:

$ opt lpad.ll -instcombine -disable-output
The unwind destination does not have a landingpad instruction!
  invoke void @_ZSt20__throw_length_errorPKc(i8* getelementptr inbounds ([23 x
i8]* @.cst16814, i64 0, i64 0)) noreturn
          to label %.noexc75.i unwind label %"63.i.nonloopexit"
The unwind destination does not have a landingpad instruction!
  invoke void @_ZSt17__throw_bad_allocv() noreturn
          to label %.noexc76.i unwind label %"63.i.nonloopexit"
LandingPadInst not the first non-PHI instruction in the block.
  %lpad.nonloopexit262 = landingpad { i8*, i32 } personality i32 (i32, i64,
i8*, i8*)* @__gxx_personality_v0
          cleanup
Broken module found, compilation aborted!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 06:43:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 11:43:17 +0000
Subject: [LLVMbugs] [Bug 11276] New: Linux/ppc asm not understood by GNU as
Message-ID: <bug-11276-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11276

             Bug #: 11276
           Summary: Linux/ppc asm not understood by GNU as
           Product: new-bugs
           Version: 2.9
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ulrik.sverdrup at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7556
  --> http://llvm.org/bugs/attachment.cgi?id=7556
puts("hello world!")

On linux/ppc llvm 2.9 (using clang) generates assembler in darwin style that
gnu as does not accept. A simple testcase with llvm and gcc output is attached.

It seems to be a simple case of ha16(x) versus  x at ha  and lo16(x) versus x at l 
where the formers are darwin style and latters gnu style. Using corresponding
#defines and preprocessing clang's assembler will enable us to make a
functioning program.

$ clang -v
Debian clang version 2.9-16 (tags/RELEASE_29/final) (based on LLVM 2.9)
Target: powerpc-unknown-linux-gnu

gcc version 4.6.1 (Debian 4.6.1-15)

gcc -std=c99 -S -o simple_gcc.s simple.c

clang -std=c99 -S -o simple_clang.s simple.c

$ clang -std=c99 -c -o simple_clang simple.c
/tmp/cc-jdQ4Dp.s: Assembler messages:
/tmp/cc-jdQ4Dp.s:14: Error: syntax error; found `(', expected `,'
/tmp/cc-jdQ4Dp.s:14: Error: junk at end of line: `(.L.str)'
/tmp/cc-jdQ4Dp.s:15: Error: junk at end of line: `(3)'
clang: error: assembler command failed with exit code 1 (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 llvm.org  Mon Oct 31 07:44:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 12:44:15 +0000
Subject: [LLVMbugs] [Bug 11277] New: clang hides the type of template
	arguments
Message-ID: <bug-11277-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11277

             Bug #: 11277
           Summary: clang hides the type of template arguments
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider the following simple code:
#include <vector>

typedef void* hidden_type;

int f(double d);

int main(void)
{
    hidden_type w;
    std::vector<hidden_type> v;
    f(w);
    f(v);
}

This produces as output:


t.cc:11:2: error: no matching function for call to 'f'
        f(w);
        ^
t.cc:5:5: note: candidate function not viable: cannot convert argument of
      incomplete type 'hidden_type' (aka 'void *') to 'double'
int f(double d);
    ^
t.cc:12:2: error: no matching function for call to 'f'
        f(v);
        ^
t.cc:5:5: note: candidate function not viable: no known conversion from
      'std::vector<hidden_type>' to 'double' for 1st argument;
int f(double d);
    ^

Notice how I am told in the first error that 'hidden_type' is void*, but in the
second case I am just given std::vector<hidden_type>.

In code I had this actually occur in, the type argument was a much more
complicated template monstrosity, and in the end I had to introduce a new error
into my code just to get the compiler to tell me what the 'hidden_type'
actually was.

As g++ seems to not track template arguments, in this case it produces the more
helpful:

t.cc:11:5: error: cannot convert ?hidden_type {aka void*}? to ?double? for
argument ?1? to ?int f(double)?
t.cc:12:5: error: cannot convert ?std::vector<void*>? to ?double? for argument
?1? to ?int f(double)?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 10:09:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 15:09:38 +0000
Subject: [LLVMbugs] [Bug 7006] Missed struct allocation escape analysis
In-Reply-To: <bug-7006-206@http.llvm.org/bugs/>
References: <bug-7006-206@http.llvm.org/bugs/>
Message-ID: <bug-7006-206-VVSCxN3IM2@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=7006

David Blaikie <dblaikie at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dblaikie at gmail.com
         Resolution|                            |FIXED

--- Comment #2 from David Blaikie <dblaikie at gmail.com> 2011-10-31 10:09:38 CDT ---
I believe this has been fixed some time since the bug was filed. (I can take
the time to find a particular revision if necessary)

With or without WITH_Y defined, 'clang malloc.c -S -o - -Os -emit-llvm | opt
-O3 -S' produces the following main:

define i32 @main() nounwind uwtable optsize {
entry:
  %call.i = tail call i64 @strtol(i8* nocapture getelementptr inbounds ([3 x
i8]* @.str, i64 0, i64 0), i8** null, i32 10) nounwind optsize
  %conv.i = trunc i64 %call.i to i32
  %mul2.i = mul nsw i32 %conv.i, 3
  %conv.i4 = sitofp i32 %mul2.i to double
  %call2 = tail call i32 (i8*, ...)* @printf(i8* getelementptr inbounds ([4 x
i8]* @.str1, i64 0, i64 0), double %conv.i4) nounwind optsize
  ret i32 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 llvm.org  Mon Oct 31 10:47:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 15:47:33 +0000
Subject: [LLVMbugs] [Bug 7209] Seek out invalid candidates that GCC would
 find when overload resolution fails
In-Reply-To: <bug-7209-206@http.llvm.org/bugs/>
References: <bug-7209-206@http.llvm.org/bugs/>
Message-ID: <bug-7209-206-zp90i1K1os@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=7209

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-31 10:47:33 CDT ---
This is fixed in top-of-tree Clang:


t.cpp:10:15: error: call to function 'operator<<' that is neither visible in
the
      template definition nor found by argument-dependent lookup
    std::clog << t;
              ^
t.cpp:15:17: note: in instantiation of function template specialization
      'log<N::X>' requested here
  template void log(const X&);
                ^
t.cpp:13:17: note: 'operator<<' should be declared prior to the call site or in
      namespace 'N'
  std::ostream &operator<<(std::ostream&, const X& x);

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 10:48:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 15:48:49 +0000
Subject: [LLVMbugs] [Bug 6678] incoherent warning when calling a non-const
 method with a const object
In-Reply-To: <bug-6678-206@http.llvm.org/bugs/>
References: <bug-6678-206@http.llvm.org/bugs/>
Message-ID: <bug-6678-206-t2ZF7bpSDg@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=6678

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-10-31 10:48:49 CDT ---
Top-of-tree Clang does much better:


t.cpp:7:3: error: member function 'bar' not viable: 'this' argument has type
      'const Foo', but function is not marked const
  x->bar();
  ^
t.cpp:3:8: note: 'bar' declared here
  void bar();
       ^

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 10:51:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 15:51:33 +0000
Subject: [LLVMbugs] [Bug 11270] Template specialisation inside class accepted
In-Reply-To: <bug-11270-206@http.llvm.org/bugs/>
References: <bug-11270-206@http.llvm.org/bugs/>
Message-ID: <bug-11270-206-C9chDOVVQv@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11270

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |DUPLICATE

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-31 10:51:33 CDT ---


*** This bug has been marked as a duplicate of bug 8170 ***

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 10:52:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 15:52:18 +0000
Subject: [LLVMbugs] [Bug 9993] Enum with explicit enum-base is not promoted
	to int
In-Reply-To: <bug-9993-206@http.llvm.org/bugs/>
References: <bug-9993-206@http.llvm.org/bugs/>
Message-ID: <bug-9993-206-96roYbmbSo@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=9993

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-10-31 10:52:18 CDT ---
Great. Closing...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 10:52:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 15:52:40 +0000
Subject: [LLVMbugs] [Bug 11278] New: Make llvm-ld fallback to clang when gcc
 is not found
Message-ID: <bug-11278-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11278

             Bug #: 11278
           Summary: Make llvm-ld fallback to clang when gcc is not found
           Product: tools
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llvm-ld
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: maruel at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7559
  --> http://llvm.org/bugs/attachment.cgi?id=7559
Try to find clang if gcc is not found

Repro:
- On a system without gcc installed (like Windows):
- Build llvm+clang with MSVS2010. I used MinSizeRel configuration but it
shouldn't matter.
- Add ...\build\bin\MinSizeRel to PATH to make sure all llvm tools and clang
are in PATH.
- echo int main() { return 0; } > hello.c
- clang -c hello.c -emit-llvm -o hello.bc
- llc -filetype=obj hello.bc
- llvm-ld hello.obj -o=hello.ld.exe -native

Result:
llvm-ld: Failed to find gcc

Expected:
Uses clang.

Notes:
I kept the behavior to try to find gcc first and only fallback to clang if gcc
is not found to reduce the side-effects of this patch.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 10:55:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 15:55:03 +0000
Subject: [LLVMbugs] [Bug 11269] add a -std=c++11 option to the driver
In-Reply-To: <bug-11269-206@http.llvm.org/bugs/>
References: <bug-11269-206@http.llvm.org/bugs/>
Message-ID: <bug-11269-206-8Tr8UCNJfw@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11269

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-31 10:55:03 CDT ---
This was implemented in top-of-tree as soon as the standard was published.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 13:12:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 18:12:38 +0000
Subject: [LLVMbugs] [Bug 11278] Make llvm-ld fallback to clang when gcc is
	not found
In-Reply-To: <bug-11278-206@http.llvm.org/bugs/>
References: <bug-11278-206@http.llvm.org/bugs/>
Message-ID: <bug-11278-206-XMjjqPams3@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11278

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rafael.espindola at gmail.com
         Resolution|                            |WONTFIX

--- Comment #2 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-10-31 13:12:38 CDT ---
(In reply to comment #1)
> I think the plan is to remove llvm-ld since it doesn't work well, and what it
> can do could be done better by other programs.

Or it should become a real linker, and be called by a driver instead of calling
one :-)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 13:53:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 18:53:22 +0000
Subject: [LLVMbugs] [Bug 8269] clang produces incorrect fixit for invalid
	main decl.
In-Reply-To: <bug-8269-206@http.llvm.org/bugs/>
References: <bug-8269-206@http.llvm.org/bugs/>
Message-ID: <bug-8269-206-vrGEzzrkbl@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8269

David Blaikie <dblaikie at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dblaikie at gmail.com
         Resolution|                            |FIXED

--- Comment #1 from David Blaikie <dblaikie at gmail.com> 2011-10-31 13:53:22 CDT ---
We no longer suggest the wrong fixit here, but we actually don't suggest any
fixit. The addition of a (correct) fixit will be part of PR8104.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 14:39:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 19:39:37 +0000
Subject: [LLVMbugs] [Bug 11279] New: Assertion
 `!IVLimit->getType()->isPointerTy() && "Should not expand pointer types"'
 failed.
Message-ID: <bug-11279-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11279

             Bug #: 11279
           Summary: Assertion `!IVLimit->getType()->isPointerTy() &&
                    "Should not expand pointer types"' failed.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 7561
  --> http://llvm.org/bugs/attachment.cgi?id=7561
Test case

Compile attached test case with "-ffreestanding -O -mllvm
-enable-iv-rewrite=true" to reproduce.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 16:36:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 21:36:39 +0000
Subject: [LLVMbugs] [Bug 11280] New: __sync_bool_compare_and_swap build error
Message-ID: <bug-11280-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11280

             Bug #: 11280
           Summary: __sync_bool_compare_and_swap build error
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: abiryan at ryand.net
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I've been keeping up with Clang/LLVM trunk - shortly after 139216 (which I am
assuming is the commit that broke it), applications using OpenSceneGraph fail
to build due to a compile error in the OpenThreads/Atomic header.  I've
stripped down that header to just the minimal portion that causes the error.

void* volatile _ptr;

bool
assign(void* ptrNew, const void* const ptrOld)
{
    return __sync_bool_compare_and_swap(&_ptr, ptrOld, ptrNew);
}


If you compile this with clang++ Atomic.cpp -o Atomic.o, you get the following
error:

Atomic.cpp:19:48: error: cannot initialize a parameter of type 'void *' with an
lvalue of type 'const void *const'
    return __sync_bool_compare_and_swap(&_ptr, ptrOld, ptrNew);
                                               ^~~~~~

This did work sometime before 139216, and works with a wide range of GCC
versions - that code hasn't been touched since 2008 in the upstream project.

Wondering if this is a Clang error or an error in OpenThreads - I would suspect
since it works with GCC and it's a GCC intrinsic, it's a Clang 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 llvm.org  Mon Oct 31 16:42:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 21:42:05 +0000
Subject: [LLVMbugs] [Bug 11281] New: False positive for interation of
 counter with addition and multiplication of self
Message-ID: <bug-11281-206@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11281

             Bug #: 11281
           Summary: False positive for interation of counter with addition
                    and multiplication of self
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: brent.gulanowski at nulayer.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following code is from the leveldb project.

bool ConsumeDecimalNumber(Slice* in, uint64_t* val) {
  uint64_t v = 0;
  int digits = 0;
  while (!in->empty()) {
    char c = (*in)[0];
    if (c >= '0' && c <= '9') {
      ++digits;
      const int delta = (c - '0');
      static const uint64_t kMaxUint64 = ~static_cast<uint64_t>(0);
      if (v > kMaxUint64/10 ||
          (v == kMaxUint64/10 && delta > kMaxUint64%10)) {
        // Overflow
        return false;
      }
      v = (v * 10) + delta;
      in->remove_prefix(1);
    } else {
      break;
    }
  }
  *val = v;
  return (digits > 0);
}


When using Analyze in Xcode, the following result is reported:

Analyze leveldb/util/logging.cc
    cd /Users/bgulanowski/Dev/Nulayer/NULevelDB
    setenv LANG en_US.US-ASCII
    setenv PATH
"/Developer/Platforms/iPhoneSimulator.platform/Developer/usr/bin:/Developer/usr/bin:/usr/bin:/bin:/usr/sbin:/sbin"
    /Developer/usr/bin/clang -x c++ -arch i386 -fmessage-length=0
-fdiagnostics-print-source-range-info -fdiagnostics-show-category=id
-fdiagnostics-parseable-fixits -Wno-trigraphs -fpascal-strings -O0
-Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter -Wunused-variable
-Wunused-value -Wno-shorten-64-to-32 -Wc++0x-extensions -DDEBUG=1 -isysroot
/Developer/Platforms/iPhoneSimulator.platform/Developer/SDKs/iPhoneSimulator5.0.sdk
-fexceptions -fasm-blocks -mmacosx-version-min=10.6 -gdwarf-2
-Wno-sign-conversion -D__IPHONE_OS_VERSION_MIN_REQUIRED=40300 -iquote
/Users/Shared/bgulanowski/Developer/Intermediates/NULevelDB.build/Debug-iphonesimulator/leveldb.build/leveldb-generated-files.hmap
-I/Users/Shared/bgulanowski/Developer/Intermediates/NULevelDB.build/Debug-iphonesimulator/leveldb.build/leveldb-own-target-headers.hmap
-I/Users/Shared/bgulanowski/Developer/Intermediates/NULevelDB.build/Debug-iphonesimulator/leveldb.build/leveldb-all-target-headers.hmap
-iquote
/Users/Shared/bgulanowski/Developer/Intermediates/NULevelDB.build/Debug-iphonesimulator/leveldb.build/leveldb-project-headers.hmap
-iquote/Users/bgulanowski/Dev/Nulayer/NULevelDB/leveldb/include
-iquote/Users/bgulanowski/Dev/Nulayer/NULevelDB/leveldb
-I/Users/Shared/bgulanowski/Developer/Products/Debug-iphonesimulator/include
-I/Users/Shared/bgulanowski/Developer/Intermediates/NULevelDB.build/Debug-iphonesimulator/leveldb.build/DerivedSources/i386
-I/Users/Shared/bgulanowski/Developer/Intermediates/NULevelDB.build/Debug-iphonesimulator/leveldb.build/DerivedSources
-F/Users/Shared/bgulanowski/Developer/Products/Debug-iphonesimulator
-DOS_MACOSX -DLEVELDB_PLATFORM_POSIX -MMD -MT dependencies -MF
/Users/Shared/bgulanowski/Developer/Intermediates/NULevelDB.build/Debug-iphonesimulator/leveldb.build/StaticAnalyzer/normal/i386/logging.d
--analyze /Users/bgulanowski/Dev/Nulayer/NULevelDB/leveldb/util/logging.cc -o
/Users/Shared/bgulanowski/Developer/Intermediates/NULevelDB.build/Debug-iphonesimulator/leveldb.build/StaticAnalyzer/normal/i386/logging.plist

/Users/bgulanowski/Dev/Nulayer/NULevelDB/leveldb/util/logging.cc:71:22:{71:20-71:21}:
warning: The left operand to '*' is always 0
       v = delta + (v * 10);
                    ~ ^
/Users/bgulanowski/Dev/Nulayer/NULevelDB/leveldb/util/logging.cc:71:17:{71:19-71:27}:
warning: The right operand to '+' is always 0
       v = delta + (v * 10);
                 ^ ~~~~~~~~
2 warnings generated.


If you wish, you may download NULevelDB from github and run the Analyzer on
that.

As far as I can tell, delta is > 0 if c is > '0', so v is *not* always zero.

Thanks for your awesome work, you people are amazing.

Cheers,
Brent Gulanowski

This is for version 3.0 of clang. At least, that's what it output in Terminal.
I am using Xcode 4.2 for Lion.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 17:09:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 22:09:24 +0000
Subject: [LLVMbugs] [Bug 11265] Weird compiler error triggered by template
 friend statement
In-Reply-To: <bug-11265-206@http.llvm.org/bugs/>
References: <bug-11265-206@http.llvm.org/bugs/>
Message-ID: <bug-11265-206-7OJa4vbSmh@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11265

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |WORKSFORME

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-31 17:09:24 CDT ---
This is already fixed in trunk 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 llvm.org  Mon Oct 31 18:05:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 23:05:48 +0000
Subject: [LLVMbugs] [Bug 11180] unresolved symbol when taking a local
	label's address
In-Reply-To: <bug-11180-206@http.llvm.org/bugs/>
References: <bug-11180-206@http.llvm.org/bugs/>
Message-ID: <bug-11180-206-j9MxcjIMm3@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11180

PaX Team <pageexec at freemail.hu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #15 from PaX Team <pageexec at freemail.hu> 2011-10-31 18:05:48 CDT ---
so i rechecked with r143361 (minus r142572) and it does look fine now, not sure
what was different before, thanks for your patience ;).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 18:47:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 23:47:40 +0000
Subject: [LLVMbugs] [Bug 8214] llvm release_28 branch fails to build
 documentation with latest doxygen (1.7.1)
In-Reply-To: <bug-8214-206@http.llvm.org/bugs/>
References: <bug-8214-206@http.llvm.org/bugs/>
Message-ID: <bug-8214-206-0ltUoxXA6i@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=8214

Tanya Lattner <tonic at nondot.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Tanya Lattner <tonic at nondot.org> 2011-10-31 18:47:40 CDT ---
Reapplied. It was the CREATE_SUBDIRS change that Bill made that broke the CSS
links and also generated the much longer URLS. I've changed it back to the old
style.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 18:59:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 31 Oct 2011 23:59:38 +0000
Subject: [LLVMbugs] [Bug 11268] CPP backend not support some new
 instructions (such as atomicrmw)
In-Reply-To: <bug-11268-206@http.llvm.org/bugs/>
References: <bug-11268-206@http.llvm.org/bugs/>
Message-ID: <bug-11268-206-2tybLYISnH@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11268

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-31 18:59:38 CDT ---
r143406.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 20:16:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 01 Nov 2011 01:16:17 +0000
Subject: [LLVMbugs] [Bug 10457] Delegating constructor template doesn't seem
	to delegate
In-Reply-To: <bug-10457-206@http.llvm.org/bugs/>
References: <bug-10457-206@http.llvm.org/bugs/>
Message-ID: <bug-10457-206-sKwClGFU4K@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=10457

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |RESOLVED
         Resolution|                            |FIXED

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-10-31 20:16:17 CDT ---
Fixed in Clang r143410

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 20:23:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 01 Nov 2011 01:23:58 +0000
Subject: [LLVMbugs] [Bug 11267] [Clang 3.0]
 __has_feature(cxx_raw_string_literals) and
 __has_feature(cxx_unicode_literals) do not work correctly
In-Reply-To: <bug-11267-206@http.llvm.org/bugs/>
References: <bug-11267-206@http.llvm.org/bugs/>
Message-ID: <bug-11267-206-IFOnQujIdn@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11267

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-10-31 20:23:58 CDT ---
Committed as r143412, with test case.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 20:27:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 01 Nov 2011 01:27:52 +0000
Subject: [LLVMbugs] [Bug 11236] module import of STL fails assert in
 RevertTokenIDToIdentifier
In-Reply-To: <bug-11236-206@http.llvm.org/bugs/>
References: <bug-11236-206@http.llvm.org/bugs/>
Message-ID: <bug-11236-206-Lqexvkrpvp@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11236

Douglas Gregor <dgregor at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |WORKSFORME

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-10-31 20:27:52 CDT ---
I'm not seeing any of these failures now. Please re-open if it's still failing
for you.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 20:50:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 01 Nov 2011 01:50:17 +0000
Subject: [LLVMbugs] [Bug 11253] There is no querying macro for C++11
	defaulted functions
In-Reply-To: <bug-11253-206@http.llvm.org/bugs/>
References: <bug-11253-206@http.llvm.org/bugs/>
Message-ID: <bug-11253-206-rEb5qoZcbs@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11253

Michel Morin <mimomorin at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #4 from Michel Morin <mimomorin at gmail.com> 2011-10-31 20:50:17 CDT ---
Fixed in r143411.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.

From bugzilla-daemon at llvm.org  Mon Oct 31 23:49:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 01 Nov 2011 04:49:39 +0000
Subject: [LLVMbugs] [Bug 11275] The unwind destination does not have a
 landingpad instruction!
In-Reply-To: <bug-11275-206@http.llvm.org/bugs/>
References: <bug-11275-206@http.llvm.org/bugs/>
Message-ID: <bug-11275-206-gM7Q3MwgFi@http.llvm.org/bugs/>

http://llvm.org/bugs/show_bug.cgi?id=11275

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-10-31 23:49:39 CDT ---
r143437.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are on the CC list for the bug.