From bugzilla-daemon at llvm.org  Thu Nov  1 02:18:27 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 09:18:27 +0000
Subject: [LLVMbugs] [Bug 14234] Incorrect warning "unused function ..."
In-Reply-To: <bug-14234-206@http.llvm.org/bugs/>
References: <bug-14234-206@http.llvm.org/bugs/>
Message-ID: <bug-14234-206-UXkN5cEINE@http.llvm.org/bugs/>

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

Daniel Jasper <djasper at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |djasper at google.com
         Resolution|                            |INVALID

--- Comment #2 from Daniel Jasper <djasper at google.com> 2012-11-01 04:18:27 CDT ---
I think this was a misunderstanding of unnamed namespaces. Works as intended.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 03:27:53 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 10:27:53 +0000
Subject: [LLVMbugs] [Bug 14233] jump-threading crash
In-Reply-To: <bug-14233-206@http.llvm.org/bugs/>
References: <bug-14233-206@http.llvm.org/bugs/>
Message-ID: <bug-14233-206-RskaOpSyQF@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> 2012-11-01 05:27:53 CDT ---
"Fixed" by backing out the offending change which will need some thought to
figure out how to correctly design this.

The fixing commit is r167221 and I added this to the jump threading crasher
test cases in r167224.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 10:14:27 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 17:14:27 +0000
Subject: [LLVMbugs] [Bug 14229] Clang crashes when enum values are declared
 to be bitwise ORs of values from different enum
In-Reply-To: <bug-14229-206@http.llvm.org/bugs/>
References: <bug-14229-206@http.llvm.org/bugs/>
Message-ID: <bug-14229-206-OhfuFsoRF9@http.llvm.org/bugs/>

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

Ryan Molden <ryan.molden at gmail.com> changed:

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

--- Comment #2 from Ryan Molden <ryan.molden at gmail.com> 2012-11-01 12:14:27 CDT ---
Ugggh, this apparently had to do with some changes I had made locally long,
long ago and forgotten about, sorry for the false alarm.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 10:15:00 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 17:15:00 +0000
Subject: [LLVMbugs] [Bug 14232] Clang crashes comparing unsigned short to
	enum value
In-Reply-To: <bug-14232-206@http.llvm.org/bugs/>
References: <bug-14232-206@http.llvm.org/bugs/>
Message-ID: <bug-14232-206-Wsm9y3FplX@http.llvm.org/bugs/>

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

Ryan Molden <ryan.molden at gmail.com> changed:

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

--- Comment #5 from Ryan Molden <ryan.molden at gmail.com> 2012-11-01 12:15:00 CDT ---
Ugggh, this apparently had to do with some changes I had made locally long,
long ago and forgotten about, sorry for the false alarm.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 11:45:10 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 18:45:10 +0000
Subject: [LLVMbugs] [Bug 14235] New: Linking modules in different order
 produces different results
Message-ID: <bug-14235-206@http.llvm.org/bugs/>

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

             Bug #: 14235
           Summary: Linking modules in different order produces different
                    results
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Linker
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xiao_yi_guo at yahoo.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Given three modules:
-----------------------------------------------------------------
s1.ll:

%0 = type <{ i32, i32 }>

define void @s1(%0* byval %myStruct) nounwind {
return:
  ret void
}
-----------------------------------------------------------------
s2.ll:

%0 = type <{ i32, i32 }>

define void @s2(%0* byval %myStruct) nounwind {
return:
  ret void
}
-----------------------------------------------------------------
s3.ll:
%0 = type <{ i32, i32 }>

declare void @s1(%0* byval) nounwind readonly declare void @s2(%0* byval)
nounwind readonly

define  void @s3(%0* byval %myStruct) nounwind {
    call void @s1(%0* %myStruct) nounwind
    call void @s2(%0* %myStruct) nounwind
    ret void
}
-----------------------------------------------------------------
If they are linked in one order:
$ llvm-link -o s.bc s1.ll s2.ll s3.ll
The linked IR is:

%0 = type <{ i32, i32 }>
%1 = type <{ i32, i32 }>

define  void @s1(%0* byval %myStruct) nounwind {
return:
  ret void
}

define  void @s2(%1* byval %myStruct) nounwind {
return:
  ret void
}

define  void @s3(%0* byval %myStruct) nounwind {
  call  void @s1(%0* %myStruct) nounwind
  call  void bitcast (void (%1*)* @s2 to void (%0*)*)(%0* %myStruct) nounwind
  ret void
}

-----------------------------------------------------------------
If they are linked in a different order:
$ llvm-link -o s.bc s3.ll s1.ll s2.ll
The linked IR is:

%0 = type <{ i32, i32 }>

define  void @s3(%0* byval %myStruct) nounwind {
  call  void @s1(%0* %myStruct) nounwind
  call  void @s2(%0* %myStruct) nounwind
  ret void
}

define  void @s1(%0* byval %myStruct) nounwind {
return:
  ret void
}

define  void @s2(%0* byval %myStruct) nounwind {
return:
  ret void
}

-----------------------------------------------------------------
The second linked IR should be generated regardless of the order the modules
are linked in.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 13:01:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 20:01:51 +0000
Subject: [LLVMbugs] [Bug 14118] missing namespace in mangling
In-Reply-To: <bug-14118-206@http.llvm.org/bugs/>
References: <bug-14118-206@http.llvm.org/bugs/>
Message-ID: <bug-14118-206-B7Zsf7nrd3@http.llvm.org/bugs/>

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

John McCall <rjmccall at apple.com> changed:

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

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


From bugzilla-daemon at llvm.org  Thu Nov  1 14:20:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 21:20:39 +0000
Subject: [LLVMbugs] [Bug 14236] New: Assertion in DiagnosticsBuilder:
 NumRanges < DiagnosticsEngine::MaxRanges "Too many arguments to
 diagnostic!"
Message-ID: <bug-14236-206@http.llvm.org/bugs/>

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

             Bug #: 14236
           Summary: Assertion in DiagnosticsBuilder: NumRanges <
                    DiagnosticsEngine::MaxRanges "Too many arguments to
                    diagnostic!"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: qneill at codeaurora.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 14:27:19 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 21:27:19 +0000
Subject: [LLVMbugs] [Bug 14236] Assertion in DiagnosticsBuilder: NumRanges <
 DiagnosticsEngine::MaxRanges "Too many arguments to diagnostic!"
In-Reply-To: <bug-14236-206@http.llvm.org/bugs/>
References: <bug-14236-206@http.llvm.org/bugs/>
Message-ID: <bug-14236-206-l8xQBFG8G5@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |FIXED

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-01 16:27:19 CDT ---
This has already been fixed (r167059).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 14:32:55 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 21:32:55 +0000
Subject: [LLVMbugs] [Bug 14015] Clang crashes issuing error message for
 clearly invalid code
In-Reply-To: <bug-14015-206@http.llvm.org/bugs/>
References: <bug-14015-206@http.llvm.org/bugs/>
Message-ID: <bug-14015-206-REYfyfl0kN@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

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

--- Comment #5 from rtrieu at google.com 2012-11-01 16:32:55 CDT ---
Fixed at r167252

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 15:30:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 22:30:26 +0000
Subject: [LLVMbugs] [Bug 11854] floating point division by 0.0 vs -ftrapv vs
 IEEE floating point semantics
In-Reply-To: <bug-11854-206@http.llvm.org/bugs/>
References: <bug-11854-206@http.llvm.org/bugs/>
Message-ID: <bug-11854-206-T01mbAoR07@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |FIXED

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-01 17:30:26 CDT ---
As of r167258, -ftrapv no longer catches division by zero, and now has the same
behavior as g++'s -ftrapv. -fcatch-undefined-behavior still catches it (and
soon, -fsanitize=divide-by-zero will allow the requested fine-grained control
over 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  Thu Nov  1 16:16:12 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 23:16:12 +0000
Subject: [LLVMbugs] [Bug 14237] New: Clang crashes on invalid code with
	attributes
Message-ID: <bug-14237-206@http.llvm.org/bugs/>

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

             Bug #: 14237
           Summary: Clang crashes on invalid code with attributes
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rtrieu at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Reproduction:

class Table {
  void Foo(int x) {
    {
      return Foo(Foo(
    }
    return 1;
  }

  void Bar() __attribute__((exclusive_locks_required(something)));
};

It appears the crash happens at clang/lib/Parse/ParseCXXInlineMethods.cpp:374
374        Class.LateParsedDeclarations[i]->ParseLexedMethodDefs();

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 16:21:58 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 01 Nov 2012 23:21:58 +0000
Subject: [LLVMbugs] [Bug 14238] New: CommandLine.h cl::bits fails to compile
 with clang++ and g++ 4.7
Message-ID: <bug-14238-206@http.llvm.org/bugs/>

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

             Bug #: 14238
           Summary: CommandLine.h cl::bits fails to compile with clang++
                    and g++ 4.7
           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
    Classification: Unclassified


Created attachment 9484
  --> http://llvm.org/bugs/attachment.cgi?id=9484
Reproducer that compiles with g++ 4.6 but not g++ 4.7 or clang++

The attached LLVM pass compiles fine with GCC 4.6:

$ g++ --version | head -1
g++ (GCC) 4.6.1
$ llvm-config --cxxflags
-I/ssdsata/pakin/byfl/include  -DNDEBUG -D_GNU_SOURCE -D__STDC_CONSTANT_MACROS
-D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS -O3 -fomit-frame-pointer -g
-fvisibility-inlines-hidden -fno-exceptions -fno-rtti -fPIC
-Woverloaded-virtual -Wcast-qual
$ g++ `llvm-config --cxxflags` hello.cpp -c

...but not with GCC 4.7:

$ g++ --version | head -1
g++ (GCC) 4.7.1
$ g++ `llvm-config --cxxflags` hello.cpp -c
In file included from hello.cpp:4:0:
/ssdsata/pakin/byfl/include/llvm/Support/CommandLine.h: In instantiation of
‘bool llvm::cl::bits<DataType, Storage, ParserClass>::handleOccurrence(unsigned
int, llvm::StringRef, llvm::StringRef) [with DataType = {anonymous}::FailType;
Storage = bool; ParserClass = llvm::cl::parser<{anonymous}::FailType>]’:
hello.cpp:32:72:   required from here
/ssdsata/pakin/byfl/include/llvm/Support/CommandLine.h:1510:5: error:
‘addValue’ was not declared in this scope, and no declarations were found by
argument-dependent lookup at the point of instantiation [-fpermissive]
/ssdsata/pakin/byfl/include/llvm/Support/CommandLine.h:1510:5: note:
declarations in dependent base ‘llvm::cl::bits_storage<{anonymous}::FailType,
bool>’ are not found by unqualified lookup
/ssdsata/pakin/byfl/include/llvm/Support/CommandLine.h:1510:5: note: use
‘this->addValue’ instead

...or with Clang++:

$ clang++ `llvm-config --cxxflags` hello.cpp -c
In file included from hello.cpp:4:
/ssdsata/pakin/byfl/include/llvm/Support/CommandLine.h:1510:5: error: use of
undeclared identifier 'addValue'
    addValue(Val);
    ^
    this->
hello.cpp:11:3: note: in instantiation of member function
'llvm::cl::bits<<anonymous>::FailType, bool,
llvm::cl::parser<<anonymous>::FailType> >::handleOccurrence' requested here
  Fail("fail", cl::NotHidden, cl::CommaSeparated, cl::ValueOptional,
  ^
/ssdsata/pakin/byfl/include/llvm/Support/CommandLine.h:1476:8: note: must
qualify identifier to find this declaration in dependent base class
  void addValue(const T &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  Thu Nov  1 17:19:38 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 00:19:38 +0000
Subject: [LLVMbugs] [Bug 12260] Lowering struct copies to memcpy loses tons
 of useful TBAA info
In-Reply-To: <bug-12260-206@http.llvm.org/bugs/>
References: <bug-12260-206@http.llvm.org/bugs/>
Message-ID: <bug-12260-206-yBc7k16vu6@http.llvm.org/bugs/>

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

Dan Gohman <dan433584 at gmail.com> changed:

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

--- Comment #5 from Dan Gohman <dan433584 at gmail.com> 2012-11-01 19:19:38 CDT ---
Yes.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 18:09:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 01:09:26 +0000
Subject: [LLVMbugs] [Bug 11852] C++ parser crashes
In-Reply-To: <bug-11852-206@http.llvm.org/bugs/>
References: <bug-11852-206@http.llvm.org/bugs/>
Message-ID: <bug-11852-206-GdivfKG6tE@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rtrieu at google.com
         Resolution|                            |FIXED

--- Comment #3 from rtrieu at google.com 2012-11-01 20:09:26 CDT ---
Fixed in revision 167268.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 18:10:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 01:10:15 +0000
Subject: [LLVMbugs] [Bug 14239] New: Crash
Message-ID: <bug-14239-206@http.llvm.org/bugs/>

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

             Bug #: 14239
           Summary: Crash
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dave at boostpro.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9485
  --> http://llvm.org/bugs/attachment.cgi?id=9485
Crash log

See enclosed files

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  1 23:30:28 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 06:30:28 +0000
Subject: [LLVMbugs] [Bug 14241] New: LoopIdiomRecognize forms an invalid
	memcpy
Message-ID: <bug-14241-206@http.llvm.org/bugs/>

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

             Bug #: 14241
           Summary: LoopIdiomRecognize forms an invalid memcpy
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: benny.kra at gmail.com, dblaikie at gmail.com,
                    llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider the following test case:

% cat bug.cpp 
struct S { int v; };

void f(S *s, unsigned size) {
  S *i = s, *e = s + size - 1;
  while (i != e) {
    *i = *(i + 1);
    ++i;
  }
}

% ./bin/clang -S -emit-llvm -o - -O1 bug.cpp
; ModuleID = 'bug.cpp'
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-S128"
target triple = "x86_64-unknown-linux-gnu"

%struct.S = type { i32 }

define void @_Z1fP1Sj(%struct.S* %s, i32 %size) nounwind uwtable {
entry:
  %cmp7 = icmp eq i32 %size, 1
  br i1 %cmp7, label %while.end, label %while.cond.while.end_crit_edge

while.cond.while.end_crit_edge:                   ; preds = %entry
  %s9 = bitcast %struct.S* %s to i8*
  %scevgep = getelementptr %struct.S* %s, i64 1
  %scevgep10 = bitcast %struct.S* %scevgep to i8*
  %0 = zext i32 %size to i64
  %1 = shl nuw nsw i64 %0, 2
  %2 = add i64 %1, -4
  call void @llvm.memcpy.p0i8.p0i8.i64(i8* %s9, i8* %scevgep10, i64 %2, i32 4,
i1 false)
  br label %while.end

while.end:                                        ; preds =
%while.cond.while.end_crit_edge, %entry
  ret void
}

declare void @llvm.memcpy.p0i8.p0i8.i64(i8* nocapture, i8* nocapture, i64, i32,
i1) nounwind


Note that we produce a single memcpy call based on the loop trip count. This
isn't valid because the destination overlaps with the source. We need to form
memmove if we do this optimization at all.

Many thanks to David Blaikie for the excellent reduction 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 Nov  2 01:40:58 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 08:40:58 +0000
Subject: [LLVMbugs] [Bug 14241] LoopIdiomRecognize forms an invalid memcpy
In-Reply-To: <bug-14241-206@http.llvm.org/bugs/>
References: <bug-14241-206@http.llvm.org/bugs/>
Message-ID: <bug-14241-206-kWB4hTmjKr@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #7 from Chandler Carruth <chandlerc at gmail.com> 2012-11-02 03:40:58 CDT ---
(In reply to comment #6)
> I guess so.  Is anything else using DependenceAnalysis?

Nope, nothing else is using DependenceAnalysis. This is enough to get us to
"clean" on this front at least.

Reverted in r167286, test case added in r167287.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  2 06:17:48 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 13:17:48 +0000
Subject: [LLVMbugs] [Bug 14213] Handle single quoted strings
In-Reply-To: <bug-14213-206@http.llvm.org/bugs/>
References: <bug-14213-206@http.llvm.org/bugs/>
Message-ID: <bug-14213-206-wWhGCjhrSg@http.llvm.org/bugs/>

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

Jan-Simon Möller <dl9pf at gmx.de> changed:

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

--- Comment #7 from Jan-Simon Möller <dl9pf at gmx.de> 2012-11-02 08:17:48 CDT ---
Closing issue after follow-up discussion. Ignore 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  Fri Nov  2 06:46:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 13:46:26 +0000
Subject: [LLVMbugs] [Bug 14242] New: typeid() on dereferenced null pointer
 does not throw std::bad_typeid
Message-ID: <bug-14242-206@http.llvm.org/bugs/>

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

             Bug #: 14242
           Summary: typeid() on dereferenced null pointer does not throw
                    std::bad_typeid
           Product: clang
           Version: 3.0
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ulfalizer at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


No exception is thrown for

#include <typeinfo>

int main() { typeid(*(int*)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 Nov  2 07:53:34 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 14:53:34 +0000
Subject: [LLVMbugs] [Bug 14242] typeid() on dereferenced null pointer does
 not throw std::bad_typeid
In-Reply-To: <bug-14242-206@http.llvm.org/bugs/>
References: <bug-14242-206@http.llvm.org/bugs/>
Message-ID: <bug-14242-206-hqlxpdjGpe@http.llvm.org/bugs/>

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

Ulf Magnusson <ulfalizer at gmail.com> changed:

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

--- Comment #3 from Ulf Magnusson <ulfalizer at gmail.com> 2012-11-02 09:53:34 CDT ---
Reading C++03, 5.2.8.2 a second time, it seems this only applies when the
lvalue is a polymorphic class type (which makes sense), and

#include <typeinfo>

struct C { virtual ~C(); };

int main() { typeid(*(C*)0); }

does work as expected. (It throws std::bad_typeid.)

Close this as invalid then :).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  2 09:37:38 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 16:37:38 +0000
Subject: [LLVMbugs] [Bug 14243] New: scan-build should not report compiler
 errors as analyzer failures
Message-ID: <bug-14243-206@http.llvm.org/bugs/>

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

             Bug #: 14243
           Summary: scan-build should not report compiler errors as
                    analyzer failures
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: jordan_rose at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Currently, if a file can't be parsed, it's reported as a "failure" by
scan-build. In the past, this was most likely due to Clang's incomplete support
for various esoteric language features (or even "C++" if you go back far
enough), but today the compiler errors are usually valid errors or the result
of other compilers being more permissive than Clang.

We should
- not report these as failures of the analyzer
- not suggest filing a bug report
- report the compiler errors in some useful 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  Fri Nov  2 11:08:57 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 18:08:57 +0000
Subject: [LLVMbugs] [Bug 14244] New: "signedness mismatch" assertions
 failing everywhere [ppc/darwin8]
Message-ID: <bug-14244-206@http.llvm.org/bugs/>

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

             Bug #: 14244
           Summary: "signedness mismatch" assertions failing everywhere
                    [ppc/darwin8]
           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: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In a recent build of clang on powerpc-darwin8 (g++-4.0.1 built), I get numerous
crashes and assertion failures in the first hundred+ tests in the test suite.

log:
http://www.csl.cornell.edu/~fang/sw/llvm/logs/clang-r167161-powerpc-darwin8-g++-4.0.1-debug-check.log

clang is built with cmake here, and configured as a Debug build (-g only).

I picked an arbitrary test to debug: Analysis/complex.c

[fangism:~/temp/clang] fang%
/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./clang -cc1
-internal-isystem
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/../lib/clang/3.2/include
-analyze -analyzer-checker=core -analyzer-store=region
-analyzer-constraints=range -verify -Wno-unreachable-code -ffreestanding
/Volumes/Isolde/sources/LLVM-svn/clang/test/Analysis/complex.c
/Users/fang/local/src/LLVM-svn/llvm/include/llvm/ADT/APSInt.h:245: failed
assertion `IsUnsigned == RHS.IsUnsigned && "Signedness mismatch!"'
Stack dump:
0.      Program arguments:
/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./clang -cc1
-internal-isystem
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/../lib/clang/3.2/include
-analyze -analyzer-checker=core -analyzer-store=region
-analyzer-constraints=range -verify -Wno-unreachable-code -ffreestanding
/Volumes/Isolde/sources/LLVM-svn/clang/test/Analysis/complex.c 
1.      <eof> parser at end of file
2.      /Volumes/Isolde/sources/LLVM-svn/clang/test/Analysis/complex.c:9:7:
Error evaluating branch
Abort

stacktrace from assert-fail:
[fangism:~/temp/clang] fang% gdb
/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./clang                   
                                               GNU gdb 6.3.50-20050815 (Apple
version gdb-696) (Sat Oct 20 18:20:28 GMT 2007)
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 "powerpc-apple-darwin"...
warning: --arch option not supported in this gdb.
Reading symbols for shared libraries
............................................................. done

(gdb) run -cc1 -internal-isystem
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/../lib/clang/3.2/include
-analyze -analyzer-checker=core -analyzer-store=region
-analyzer-constraints=range -verify -Wno-unreachable-code -ffreestanding
/Volumes/Isolde/sources/LLVM-svn/clang/test/Analysis/complex.c
Starting program: /Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/clang -cc1
-internal-isystem
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/../lib/clang/3.2/include
-analyze -analyzer-checker=core -analyzer-store=region
-analyzer-constraints=range -verify -Wno-unreachable-code -ffreestanding
/Volumes/Isolde/sources/LLVM-svn/clang/test/Analysis/complex.c
tcsh: Word too long.
Reading symbols for shared libraries
.+++++++++++++++++++++++++++++++++++++++++++++++++++++++++ done
/Users/fang/local/src/LLVM-svn/llvm/include/llvm/ADT/APSInt.h:245: failed
assertion `IsUnsigned == RHS.IsUnsigned && "Signedness mismatch!"'

Program received signal SIGABRT, Aborted.
0x90047dac in kill ()
(gdb) where
#0  0x90047dac in kill ()
#1  0x9012d7b4 in abort ()
#2  0x94c870b0 in __eprintf ()
#3  0x5f159d48 in llvm::APSInt::operator- (this=0xbfffb0f4, RHS=@0xbfffb1ac) at
/Users/fang/local/src/LLVM-svn/llvm/include/llvm/ADT/APSInt.h:245
#4  0x5f0d748c in (anonymous namespace)::RangeConstraintManager::assumeSymEQ
(this=0x66109e00, St=@0xbfffb190, Sym=0x6583719c, Int=@0xbfffb1c4,
Adjustment=@0xbfffb1ac) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/RangeConstraintManager.cpp:457
#5  0x5f0e45bc in clang::ento::SimpleConstraintManager::assumeSymRel
(this=0x66109e00, state=@0xbfffb274, LHS=0x6583719c, op=BO_EQ, Int=@0x65837324)
at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp:267
#6  0x5f0e512c in clang::ento::SimpleConstraintManager::assumeAux
(this=0x66109e00, state=@0xbfffb30c, Cond={<DefinedSVal> =
{<DefinedOrUnknownSVal> = {<SVal> = {Data = 0x65837334, Kind = 7}, <No data
fields>}, <No data fields>}, <No data fields>}, Assumption=true) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp:202
#7  0x5f0e52b8 in clang::ento::SimpleConstraintManager::assume
(this=0x66109e00, state=@0xbfffb38c, cond={<DefinedSVal> =
{<DefinedOrUnknownSVal> = {<SVal> = {Data = 0x65837334, Kind = 7}, <No data
fields>}, <No data fields>}, <No data fields>}, assumption=true) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp:117
#8  0x5f0e5438 in clang::ento::SimpleConstraintManager::assume
(this=0x66109e00, state=@0xbfffb3f0, Cond={<DefinedOrUnknownSVal> = {<SVal> =
{Data = 0x65837334, Kind = 7}, <No data fields>}, <No data fields>},
Assumption=true) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/SimpleConstraintManager.cpp:62
#9  0x5f19bafc in clang::ento::ProgramState::assume (this=0x65837380,
Cond={<SVal> = {Data = 0x65837334, Kind = 7}, <No data fields>},
Assumption=true) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ProgramState.h:616
#10 0x5f0af720 in clang::ento::ExprEngine::processBranch (this=0xbfffba3c,
Condition=0x6580ec70, Term=0x6580ed08, BldCtx=@0xbfffb628, Pred=0x65837398,
Dst=@0xbfffb634, DstT=0x658328f4, DstF=0x658327dc) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/ExprEngine.cpp:1253
#11 0x5f0a583c in clang::ento::CoreEngine::HandleBranch (this=0xbfffba48,
Cond=0x6580ec70, Term=0x6580ed08, B=0x65832968, Pred=0x65837398) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:454
#12 0x5f0a6d98 in clang::ento::CoreEngine::HandleBlockExit (this=0xbfffba48,
B=0x65832968, Pred=0x65837398) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:350
#13 0x5f0a730c in clang::ento::CoreEngine::HandlePostStmt (this=0xbfffba48,
B=0x65832968, StmtIdx=3, Pred=0x65837398) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:465
#14 0x5f0a790c in clang::ento::CoreEngine::dispatchWorkItem (this=0xbfffba48,
Pred=0x65837398, Loc={Data1 = 0x6580ec70, Data2 = {Value = 2}, L = {Value =
1712354177}, Tag = {Value = 0}}, WU=@0xbfffb8f0) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:266
#15 0x5f0a7d34 in clang::ento::CoreEngine::ExecuteWorkList (this=0xbfffba48,
L=0x66107380, Steps=149995, InitState=@0xbfffb9d8) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Core/CoreEngine.cpp:222
#16 0x4df3d9e4 in clang::ento::ExprEngine::ExecuteWorkList (this=0xbfffba3c,
L=0x66107380, Steps=150000) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/include/clang/StaticAnalyzer/Core/PathSensitive/ExprEngine.h:104
#17 0x4df01c9c in (anonymous namespace)::AnalysisConsumer::ActionExprEngine
(this=0x66106b20, D=0x6580ebe0, ObjCGCEnabled=false, VisitedCallees=0xbfffbf10)
at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:613
#18 0x4df01df0 in (anonymous
namespace)::AnalysisConsumer::RunPathSensitiveChecks (this=0x66106b20,
D=0x6580ebe0, Visited=0xbfffbf10) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:632
#19 0x4df030c0 in (anonymous namespace)::AnalysisConsumer::HandleCode
(this=0x66106b20, D=0x6580ebe0, Mode=2, VisitedCallees=0xbfffbf10) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:581
#20 0x4df03508 in (anonymous namespace)::AnalysisConsumer::HandleDeclsCallGraph
(this=0x66106b20, LocalTUDeclsSize=29) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:434
#21 0x4df03844 in (anonymous
namespace)::AnalysisConsumer::HandleTranslationUnit (this=0x66106b20,
C=@0x6580be00) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/StaticAnalyzer/Frontend/AnalysisConsumer.cpp:481
#22 0x37c2f588 in clang::ParseAST (S=@0x65817000, PrintStats=false,
SkipFunctionBodies=false) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/Parse/ParseAST.cpp:111
#23 0x337d1e50 in clang::ASTFrontendAction::ExecuteAction (this=0x66102e20) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:467
#24 0x337d19a8 in clang::FrontendAction::Execute (this=0x66102e20) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/Frontend/FrontendAction.cpp:384
#25 0x337b4fe8 in clang::CompilerInstance::ExecuteAction (this=0x66102940,
Act=@0x66102e20) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/Frontend/CompilerInstance.cpp:678
#26 0x1f41c990 in clang::ExecuteCompilerInvocation (Clang=0x66102940) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:189
#27 0x00015460 in cc1_main (ArgBegin=0xbfffd0e0, ArgEnd=0xbfffd108,
Argv0=0x6610252c "/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/clang",
MainAddr=0x124b4) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/tools/driver/cc1_main.cpp:168
#28 0x00013dac in main (argc_=12, argv_=0xbfffd6a8) at
/Users/fang/local/src/LLVM-svn/llvm/tools/clang/tools/driver/driver.cpp:358

Does anyone see the first thing that may have gone wrong?

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


From bugzilla-daemon at llvm.org  Fri Nov  2 12:10:19 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 19:10:19 +0000
Subject: [LLVMbugs] [Bug 14246] New: Apple llvm compiler (4.1) : very VERY
 slow linking time, eating up a lot of memory
Message-ID: <bug-14246-206@http.llvm.org/bugs/>

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

             Bug #: 14246
           Summary: Apple llvm compiler (4.1) : very VERY slow linking
                    time, eating up a lot of memory
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: olivier at myvr-software.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hello,

First time filling a bug here, and I'm not sure if it is the right place. So if
it a mistake, I'm really sorry.

I'm working on a SDK for displaying maps on mobile devices. The library is made
in C++ using boost and (not so much) templates.

Everything is going fine on Android and Windows, which are not using clang, but
when I have a big issue with iOS compilation using apple llvm 4.1 ( latest
version of XCode ). The library compile fine by itself, but when I use the
actual library with an application, in release build, the linking take a lot of
times ( more than 20 minutes, when it does not fails or need to reboot the
computer because of memory ) and eat a lot ( more than 5 gigs ) of memory. 

LTO on/off does not seems to change anything. 

Everything is going fine if I use llvm-gcc4.2, but apple is going to deprecate
it in the next-next relase, so I need to find a solution.

If needed I can provide a binary (.a) version of the library and a sample
project, if it is not public.

The library is quite big ( 150 megs ) but should compress OK.

Thanks for your support,
Olivier Chatry.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  2 12:54:29 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 19:54:29 +0000
Subject: [LLVMbugs] [Bug 14246] Apple llvm compiler (4.1) : very VERY slow
 linking time, eating up a lot of memory
In-Reply-To: <bug-14246-206@http.llvm.org/bugs/>
References: <bug-14246-206@http.llvm.org/bugs/>
Message-ID: <bug-14246-206-IRHtoR4C2s@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-02 14:54:29 CDT ---
Please file bugs for tools shipped by Apple 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  Fri Nov  2 14:15:34 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 21:15:34 +0000
Subject: [LLVMbugs] [Bug 6343] clang should produce warning on duplicate
 enumeration values
In-Reply-To: <bug-6343-206@http.llvm.org/bugs/>
References: <bug-6343-206@http.llvm.org/bugs/>
Message-ID: <bug-6343-206-2Jd0v6MVwT@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

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

--- Comment #3 from rtrieu at google.com 2012-11-02 16:15:34 CDT ---
r164083 removed -Wduplicate-enum

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  2 15:42:41 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 22:42:41 +0000
Subject: [LLVMbugs] [Bug 14247] New: -fcatch-undefined-behavior should allow
 severity levels and recoverability
Message-ID: <bug-14247-206@http.llvm.org/bugs/>

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

             Bug #: 14247
           Summary: -fcatch-undefined-behavior should allow severity
                    levels and recoverability
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: htam at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Clang should support one or both of the following:
1.  An option to turn -fcatch-undefined-behavior traps into run-time warnings
or at least recoverable traps
(-fbreak-undefined-behavior/-fwarn-undefined-behavior?).  The former would
allow a programmer to quickly get a sense of issues in the entire program by
just by piping through uniq.  The second would allow someone to get through a
few warnings at a time in a debugger.
2.  Fine-grained control on which types of UB are caught; similar to
-Werror=/-Wno-error= (-f[no-]catch-udefined-behavior=X?).

Motivation:
I'm using clang built with compiler-rt on x86_64 Linux.  All are from trunk at
r167261.  The -fcatch-undefined-behavior option emits an irrecoverable trap,
even when debugging a program under gdb.  In the program I am trying to debug
with -fcatch-undefined-behavior, there are a large number of "1 << 31"
operations that cause the program to terminate very early in the run.  This is
preventing me from investigating more important UB later on in the program.

I know that this is, strictly speaking, undefined behavior, but it is
exceedingly unlikely to be the cause of the bug I'm looking for.  Instead of
fixing one issue at a time, being able to get a list of all the undefined
behavior points would make it much easier to triage bugs in large, legacy
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 Nov  2 16:57:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 02 Nov 2012 23:57:17 +0000
Subject: [LLVMbugs] [Bug 14206] Regression(r162254 ): V8 garbage collection
 performance regressed 10%
In-Reply-To: <bug-14206-206@http.llvm.org/bugs/>
References: <bug-14206-206@http.llvm.org/bugs/>
Message-ID: <bug-14206-206-SYkfabWyiM@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #5 from Nico Weber <nicolasweber at gmx.de> 2012-11-02 18:57:17 CDT ---
Looks like I can't repro with today's HEAD (r167331).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  3 01:03:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Nov 2012 08:03:46 +0000
Subject: [LLVMbugs] [Bug 14205] Crash in
	llvm::LiveVariables::HandleVirtRegUse
In-Reply-To: <bug-14205-206@http.llvm.org/bugs/>
References: <bug-14205-206@http.llvm.org/bugs/>
Message-ID: <bug-14205-206-IUnhMTsDT8@http.llvm.org/bugs/>

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

İsmail "cartman" Dönmez <ismail at namtrac.org> changed:

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

--- Comment #4 from İsmail "cartman" Dönmez <ismail at namtrac.org> 2012-11-03 03:03:46 CDT ---
Works with latest 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  Sat Nov  3 03:34:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Nov 2012 10:34:03 +0000
Subject: [LLVMbugs] [Bug 14248] New: SROA.cpp:2506: Assertion `[...] &&
 "Only alloca-wide loads can be split and recomposed"' failed.
Message-ID: <bug-14248-206@http.llvm.org/bugs/>

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

             Bug #: 14248
           Summary: SROA.cpp:2506: Assertion `[...] && "Only alloca-wide
                    loads can be split and recomposed"' failed.
           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: antoine.balestrat at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


With LLVM/Clang 3.2 as of r166877, at -O1 and higher :

$ cat alloca.c
void f(void)
{
    int *pa, **pb = &pa;
    char c;

    while(*pa)
        *pb = &c;
}

$ clong -O1 -w alloca.c
clang: /home/merkil/git/clang/llvm/lib/Transforms/Scalar/SROA.cpp:2506: bool
<anonymous namespace>::AllocaPartitionRewriter::visitLoadInst(llvm::LoadInst
&): Assertion `LI.getType()->getIntegerBitWidth() ==
TD.getTypeSizeInBits(OldAI.getAllocatedType()) && "Only alloca-wide loads can
be split and recomposed"' failed.
0  clang           0x0000000001a8b7bf
1  clang           0x0000000001a8bca3
2  libpthread.so.0 0x00007f031abbe970
3  libc.so.6       0x00007f0319e2ac75 gsignal + 53
4  libc.so.6       0x00007f0319e2bf87 abort + 327
5  libc.so.6       0x00007f0319e23d82
6  libc.so.6       0x00007f0319e23e32
7  clang           0x0000000001736ae6
8  clang           0x0000000001734737
9  clang           0x0000000001730101
10 clang           0x00000000019f0a0b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 443
11 clang           0x00000000019eff88
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 168
12 clang           0x00000000019efe6c
llvm::FunctionPassManager::run(llvm::Function&) + 108
13 clang           0x000000000079f055
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 5669
14 clang           0x000000000079cbca
15 clang           0x00000000008cf0f4 clang::ParseAST(clang::Sema&, bool, bool)
+ 532
16 clang           0x000000000079bc12 clang::CodeGenAction::ExecuteAction() +
178
17 clang           0x000000000063ec95 clang::FrontendAction::Execute() + 101
18 clang           0x000000000061e2dd
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 973
19 clang           0x00000000006067f8
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3768
20 clang           0x00000000005faedf cc1_main(char const**, char const**, char
const*, void*) + 767
21 clang           0x0000000000602a06 main + 3574
22 libc.so.6       0x00007f0319e17695 __libc_start_main + 245
23 clang           0x00000000005faafd
Stack dump:
0.    Program arguments: /home/merkil/git/clang/build/Release+Asserts/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
alloca.c -mrelocation-model static -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -fuse-init-array -target-cpu x86-64
-target-linker-version 2.22.90.20120727 -momit-leaf-frame-pointer -resource-dir
/home/merkil/git/clang/build/Release+Asserts/bin/../lib/clang/3.2
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/local/include -internal-isystem
/home/merkil/git/clang/build/Release+Asserts/bin/../lib/clang/3.2/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O1
-w -fdebug-compilation-dir /home/merkil -ferror-limit 19 -fmessage-length 0
-mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -o
/tmp/alloca-0fTUZc.o -x c alloca.c 
1.    <eof> parser at end of file
2.    Per-function optimization
3.    Running pass 'SROA' on function '@f'
clang: error: unable to execute command: 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  Sat Nov  3 07:26:08 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Nov 2012 14:26:08 +0000
Subject: [LLVMbugs] [Bug 14249] New: Type-tag safety attribute checking
 fails when 0 is passed as a pointer
Message-ID: <bug-14249-206@http.llvm.org/bugs/>

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

             Bug #: 14249
           Summary: Type-tag safety attribute checking fails when 0 is
                    passed as a pointer
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The easiest way to reproduce this error is the following:
in test/Sema/warn-type-safety.c

after this:

void test_tag_mismatch(int *ptr)
{
  A_func(ptr, &A_tag); // no-warning
  A_func(ptr, &B_tag); // expected-warning {{this type tag was not designed to
be used with this function}}
  C_func(ptr, C_tag); // no-warning
  C_func(ptr, D_tag); // expected-warning {{this type tag was not designed to
be used with this function}}
  C_func(ptr, 10); // no-warning
  C_func(ptr, 20); // should warn, but may cause false positives
}

add this:

void test_void_void(const void *a)
{
  C_func(0, C_tag);
}

and this will cause clang to assert:
clang:
/src/llvm-trunk-writable/tools/clang/lib/Frontend/../../include/clang/AST/Type.h:547:
const clang::ExtQualsTypeCommonBase* clang::QualType::getCommonPtr() const:
Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed.

in

11 clang           0x000000000114e160
clang::Sema::CheckArgumentWithTypeTag(clang::ArgumentWithTypeTagAttr const*,
clang::Expr const* const*) + 968
12 clang           0x00000000011382c0 clang::Sema::checkCall(clang::NamedDecl*,
clang::Expr**, unsigned int, unsigned int, bool, clang::SourceLocation,
clang::SourceRange, clang::Sema::VariadicCallType) + 462
13 clang           0x00000000011384b4
clang::Sema::CheckFunctionCall(clang::FunctionDecl*, clang::CallExpr*,
clang::FunctionProtoType const*) + 306
14 clang           0x0000000001268179
clang::Sema::BuildResolvedCallExpr(clang::Expr*, clang::NamedDecl*,
clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation,
clang::Expr*, bool) + 3887
15 clang           0x0000000001384e4c
16 clang           0x000000000138555f
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr**, unsigned
int, clang::SourceLocation, clang::Expr*, bool) + 417
17 clang           0x0000000001266d20 clang::Sema::ActOnCallExpr(clang::Scope*,
clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>,
clang::SourceLocation, clang::Expr*, bool) + 1976
...
1.    /tmp/warn-type-safety.c:85:18: current parser token ')'
2.    /tmp/warn-type-safety.c:84:1: parsing function body 'test_void_void'
3.    /tmp/warn-type-safety.c:84:1: in compound statement ('{}')
clang: error: unable to execute command: Aborted (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 Nov  3 08:47:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Nov 2012 15:47:51 +0000
Subject: [LLVMbugs] [Bug 14250] New: incorrect
 -Wunneeded-internal-declaration warning with weak symbols
Message-ID: <bug-14250-206@http.llvm.org/bugs/>

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

             Bug #: 14250
           Summary: incorrect -Wunneeded-internal-declaration warning with
                    weak symbols
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bonzini at gnu.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This file:

static int g()
{
    return 42;
}
typeof(g) f __attribute__((__weak__, __alias__("g")));

compiled with -Wall gives:

g2.c:3:12: warning: function 'g' is not needed and will not be emitted
      [-Wunneeded-internal-declaration]

even though the function is emitted:

    .file    "g2.c"
    .text
    .align    16, 0x90
    .type    g, at function
g:                                      # @g
    .cfi_startproc
# BB#0:
    movl    $42, %eax
    ret
.Ltmp0:
    .size    g, .Ltmp0-g
    .cfi_endproc


    .weak    f
f = g
    .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  Sat Nov  3 09:08:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Nov 2012 16:08:09 +0000
Subject: [LLVMbugs] [Bug 14249] Type-tag safety attribute checking fails
 when 0 is passed as a pointer
In-Reply-To: <bug-14249-206@http.llvm.org/bugs/>
References: <bug-14249-206@http.llvm.org/bugs/>
Message-ID: <bug-14249-206-c1MnhIRnXI@http.llvm.org/bugs/>

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

Dmitri Gribenko <gribozavr at gmail.com> changed:

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

--- Comment #3 from Dmitri Gribenko <gribozavr at gmail.com> 2012-11-03 11:08:09 CDT ---
Should be fixed in r167358.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  3 09:13:36 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Nov 2012 16:13:36 +0000
Subject: [LLVMbugs] [Bug 14251] New: strncpy-overflow.cc and
 use-after-free.cc AddressSanitizer failures on x86_64-apple-darwin12
Message-ID: <bug-14251-206@http.llvm.org/bugs/>

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

             Bug #: 14251
           Summary: strncpy-overflow.cc and use-after-free.cc
                    AddressSanitizer failures on x86_64-apple-darwin12
           Product: compiler-rt
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Two AddressSanitizer failures exist on x86_64-apple-darwin12 with a debug build
at   r167357...

Failing Tests (2):
    AddressSanitizer :: strncpy-overflow.cc
    AddressSanitizer :: use-after-free.cc

% cat strncpy-overflow.cc.tmp.out
=================================================================
==72320== ERROR: AddressSanitizer: heap-buffer-overflow on address
0x0001113bb049 at pc 0x10f0da71b bp 0x7fff50b2c970 sp 0x7fff50b2c118
WRITE of size 1 at 0x0001113bb049 thread T0
    #0 0x10f0da71a in _wrap_strncpy _asan_rtl_:5
    #1 0x10f0d4945 in _main
/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/projects/compiler-unsigned short
restrict/lib/asan/lit_tests/strncpy-overflow.cc:24:0
    #2 0x7fff8bd827e0 in start (in libdyld.dylib) + 0
    #3 0x0
0x0001113bb049 is located 0 bytes to the right of 9-byte region
[0x0001113bb040,0x0001113bb049)
allocated by thread T0 here:
    #0 0x10f0dd2a2 in (anonymous namespace)::mz_malloc(_malloc_zone_t*,
unsigned long) _asan_rtl_:3
    #1 0x7fff94c3b152 in malloc_zone_malloc (in libsystem_c.dylib) + 70
    #2 0x7fff94c3bba6 in malloc (in libsystem_c.dylib) + 40
    #3 0x10f0d48b4 in _main
/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/projects/compiler-unsigned short
restrict/lib/asan/lit_tests/strncpy-overflow.cc:23:0
    #4 0x7fff8bd827e0 in start (in libdyld.dylib) + 0
Shadow byte and word:
  0x100022277609: 1
  0x100022277608: 00 01 fb fb fb fb fb fb
long double restrictunsigned __int128::* shadow bytes:
  0x1000222775e8: fa fa fa fa fa fa fa fa
  0x1000222775f0: fa fa fa fa fa fa fa fa
  0x1000222775f8: 06 fb fb fb fb fb fb fb
  0x100022277600: fa fa fa fa fa fa fa fa
=>0x100022277608: 00 01 fb fb fb fb fb fb
  0x100022277610: fa fa fa fa fa fa fa fa
  0x100022277618: fa fa fa fa fa fa fa fa
  0x100022277620: fa fa fa fa fa fa fa fa
  0x100022277628: fa fa fa fa fa fa fa fa
Stats: 0M malloced (0M for red zones) by 2 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 0 calls
Stats: 0M really freed by 0 calls
Stats: 0M (128 full pages) mmaped in 1 calls
  mmaps   by size class: 7:4095;
  mallocs by size class: 7:2;
  frees   by size class:
  rfrees  by size class:
Stats: malloc large: 0 small slow: 1
==72320== ABORTING

=================================================================
==72453== ERROR: AddressSanitizer: heap-use-after-free on address
0x00010525efc5 at pc 0x102f79b9e bp 0x7fff5cc86ab0 sp 0x7fff5cc86aa8
READ of size 1 at 0x00010525efc5 thread T0
    #0 0x102f79b9d in _main
/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/projects/compiler-unsigned short
restrict/lib/asan/lit_tests/use-after-free.cc:22:0
    #1 0x7fff8bd827e0 in start (in libdyld.dylib) + 0
    #2 0x0
0x00010525efc5 is located 5 bytes inside of 10-byte region
[0x00010525efc0,0x00010525efca)
freed by thread T0 here:
    #0 0x102f825e8 in free_common _asan_rtl_:5
    #1 0x102f825e8 in (anonymous namespace)::mz_free(_malloc_zone_t*, void*)
_asan_rtl_:0
    #2 0x102f81c62 in _wrap_free _asan_rtl_:7
    #3 0x102f79b17 in _main
/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/projects/compiler-unsigned short
restrict/lib/asan/lit_tests/use-after-free.cc:21:0
    #4 0x7fff8bd827e0 in start (in libdyld.dylib) + 0
    #4 0x0
previously allocated by thread T0 here:
    #0 0x102f823f2 in (anonymous namespace)::mz_malloc(_malloc_zone_t*,
unsigned long) _asan_rtl_:3
    #1 0x7fff94c3b152 in malloc_zone_malloc (in libsystem_c.dylib) + 70
    #2 0x7fff94c3bba6 in malloc (in libsystem_c.dylib) + 40
    #3 0x102f79ad4 in _main
/sw/src/fink.build/llvm32-3.2-0/llvm-3.2/projects/compiler-unsigned short
restrict/lib/asan/lit_tests/use-after-free.cc:20:0
    #4 0x7fff8bd827e0 in start (in libdyld.dylib) + 0
Shadow byte and word:
  0x100020a4bdf8: fd
  0x100020a4bdf8: fd fd fd fd fd fd fd fd
long double restrictunsigned __int128::* shadow bytes:
  0x100020a4bdd8: fa fa fa fa fa fa fa fa
  0x100020a4bde0: fa fa fa fa fa fa fa fa
  0x100020a4bde8: fa fa fa fa fa fa fa fa
  0x100020a4bdf0: fa fa fa fa fa fa fa fa
=>0x100020a4bdf8: fd fd fd fd fd fd fd fd
  0x100020a4be00: fa fa fa fa fa fa fa fa
  0x100020a4be08: fa fa fa fa fa fa fa fa
  0x100020a4be10: fa fa fa fa fa fa fa fa
  0x100020a4be18: fa fa fa fa fa fa fa fa
Stats: 0M malloced (0M for red zones) by 1 calls
Stats: 0M realloced by 0 calls
Stats: 0M freed by 1 calls
Stats: 0M really freed by 0 calls
Stats: 0M (128 full pages) mmaped in 1 calls
  mmaps   by size class: 7:4095;
  mallocs by size class: 7:1;
  frees   by size class: 7:1;
  rfrees  by size class:
Stats: malloc large: 0 small slow: 1
==72453== ABORTING

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  3 10:54:54 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 03 Nov 2012 17:54:54 +0000
Subject: [LLVMbugs] [Bug 8737] [mc assembler] .extern directive ignored
In-Reply-To: <bug-8737-206@http.llvm.org/bugs/>
References: <bug-8737-206@http.llvm.org/bugs/>
Message-ID: <bug-8737-206-NwgjShT5yg@http.llvm.org/bugs/>

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

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> 2012-11-03 12:54:54 CDT ---
This was fixed a while 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 Nov  3 18:29:12 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 01:29:12 +0000
Subject: [LLVMbugs] [Bug 14208] assertion in selectInterestingSourceRegion
 found while fuzz testing diagnostic ranges in string literals
In-Reply-To: <bug-14208-206@http.llvm.org/bugs/>
References: <bug-14208-206@http.llvm.org/bugs/>
Message-ID: <bug-14208-206-vm7E4RopUf@http.llvm.org/bugs/>

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

Seth <seth.cantrell at gmail.com> changed:

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

--- Comment #3 from Seth <seth.cantrell at gmail.com> 2012-11-03 20:29:12 CDT ---
fixed in r167360

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  4 00:57:33 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 07:57:33 +0000
Subject: [LLVMbugs] [Bug 14252] New: libclang crash when parsing c++11 code
Message-ID: <bug-14252-206@http.llvm.org/bugs/>

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

             Bug #: 14252
           Summary: libclang crash when parsing  c++11 code
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: xiemeilong.ok at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I am using sublime text with sublimeclang plugin, but sublime text is always
crashing when reparsing my code.

my code:
#include <cppa/cppa.hpp>
#include <Poco/DirectoryIterator.h>
using namespace std;
using namespace cppa;
using namespace Poco;

class FileTraceActor : public sb_actor<FileTraceActor> {

    // grant access to the private init_state member
    friend class sb_actor<FileTraceActor>;


    behavior empty = (
        on(atom("to_be"), arg_match) >> [](string parent,string name) {      
//case by this line!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

            become();
        }
    );


    behavior& init_state = empty;

};


int main(int argc, char const *argv[])
{
    /* code */
    return 0;
}



Backtrace:

*** glibc detected *** /usr/lib/sublime-text-2/sublime_text: double free or
corruption (out): 0x00007f2e46e1f530 ***
======= Backtrace: =========
/lib/x86_64-linux-gnu/libc.so.6(+0x7eb96)[0x7f2e8e94cb96]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x390e5c)[0x7f2e67882e5c]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x49997d)[0x7f2e6798b97d]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x346f14)[0x7f2e67838f14]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x37cc86)[0x7f2e6786ec86]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x37c23c)[0x7f2e6786e23c]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x343d58)[0x7f2e67835d58]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x3429c0)[0x7f2e678349c0]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x3302e2)[0x7f2e678222e2]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x326c51)[0x7f2e67818c51]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x326faf)[0x7f2e67818faf]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x32632c)[0x7f2e6781832c]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x3258c0)[0x7f2e678178c0]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x322e1b)[0x7f2e67814e1b]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x1fc4e8)[0x7f2e676ee4e8]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x2008d3)[0x7f2e676f28d3]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x9d2ea)[0x7f2e6758f2ea]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x7b4acb)[0x7f2e67ca6acb]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x7b4b84)[0x7f2e67ca6b84]
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/clang/../libclang.so(+0x7c8bba)[0x7f2e67cbabba]
/lib/x86_64-linux-gnu/libpthread.so.0(+0x7e9a)[0x7f2e8fbeae9a]
/lib/x86_64-linux-gnu/libc.so.6(clone+0x6d)[0x7f2e8e9c1cbd]
======= Memory map: ========
00400000-00bce000 r-xp 00000000 08:12 1326149                           
/usr/lib/sublime-text-2/sublime_text
00dcd000-00dce000 r--p 007cd000 08:12 1326149                           
/usr/lib/sublime-text-2/sublime_text
00dce000-00e47000 rw-p 007ce000 08:12 1326149                           
/usr/lib/sublime-text-2/sublime_text
00e47000-00e5f000 rw-p 00000000 00:00 0 
011fc000-0271b000 rw-p 00000000 00:00 0                                  [heap]
7f2e38000000-7f2e3a185000 rw-p 00000000 00:00 0 
7f2e3a185000-7f2e3c000000 ---p 00000000 00:00 0 
7f2e3d56b000-7f2e3dffc000 r--p 00000000 08:12 1983024                   
/tmp/preamble.pch-HY4oSv
7f2e3dffc000-7f2e3dffd000 ---p 00000000 00:00 0 
7f2e3dffd000-7f2e3e7fd000 rw-p 00000000 00:00 0                         
[stack:7053]
7f2e3e7fd000-7f2e3e7fe000 ---p 00000000 00:00 0 
7f2e3e7fe000-7f2e3effe000 rw-p 00000000 00:00 0 
7f2e3effe000-7f2e3efff000 ---p 00000000 00:00 0 
7f2e3efff000-7f2e3f7ff000 rw-p 00000000 00:00 0                         
[stack:7050]
7f2e3f7ff000-7f2e3f800000 ---p 00000000 00:00 0 
7f2e3f800000-7f2e40000000 rw-p 00000000 00:00 0 
7f2e40000000-7f2e408a6000 rw-p 00000000 00:00 0 
7f2e408a6000-7f2e44000000 ---p 00000000 00:00 0 
7f2e44000000-7f2e47ff8000 rw-p 00000000 00:00 0 
7f2e47ff8000-7f2e48000000 ---p 00000000 00:00 0 
7f2e48000000-7f2e487fa000 rw-p 00000000 00:00 0 
7f2e487fa000-7f2e4c000000 ---p 00000000 00:00 0 
7f2e4c344000-7f2e4c4dc000 rw-p 00000000 00:00 0 
7f2e4c4dc000-7f2e4c4dd000 ---p 00000000 00:00 0 
7f2e4c4dd000-7f2e4ccdd000 rw-p 00000000 00:00 0 
7f2e4ccdd000-7f2e4cce4000 r-xp 00000000 08:12 919578                    
/lib/x86_64-linux-gnu/libnss_dns-2.15.so
7f2e4cce4000-7f2e4cee3000 ---p 00007000 08:12 919578                    
/lib/x86_64-linux-gnu/libnss_dns-2.15.so
7f2e4cee3000-7f2e4cee4000 r--p 00006000 08:12 919578                    
/lib/x86_64-linux-gnu/libnss_dns-2.15.so
7f2e4cee4000-7f2e4cee5000 rw-p 00007000 08:12 919578                    
/lib/x86_64-linux-gnu/libnss_dns-2.15.so
7f2e4cee5000-7f2e4cee7000 r-xp 00000000 08:12 915751                    
/lib/libnss_mdns4_minimal.so.2
7f2e4cee7000-7f2e4d0e6000 ---p 00002000 08:12 915751                    
/lib/libnss_mdns4_minimal.so.2
7f2e4d0e6000-7f2e4d0e7000 r--p 00001000 08:12 915751                    
/lib/libnss_mdns4_minimal.so.2
7f2e4d0e7000-7f2e4d0e8000 rw-p 00002000 08:12 915751                    
/lib/libnss_mdns4_minimal.so.2
7f2e4d0e8000-7f2e4d0e9000 ---p 00000000 00:00 0 
7f2e4d0e9000-7f2e4d8e9000 rw-p 00000000 00:00 0 
7f2e4d8e9000-7f2e4d98e000 r--p 00000000 08:12 2093740                   
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans-Bold.ttf
7f2e4d98e000-7f2e4d98f000 ---p 00000000 00:00 0 
7f2e4d98f000-7f2e4e18f000 rw-p 00000000 00:00 0                         
[stack:7035]
7f2e4e18f000-7f2e4e190000 ---p 00000000 00:00 0 
7f2e4e190000-7f2e4e990000 rw-p 00000000 00:00 0                         
[stack:7034]
7f2e4e990000-7f2e4e991000 ---p 00000000 00:00 0 
7f2e4e991000-7f2e4f191000 rw-p 00000000 00:00 0                         
[stack:7033]
7f2e4f191000-7f2e4f192000 ---p 00000000 00:00 0 
7f2e4f192000-7f2e4f992000 rw-p 00000000 00:00 0                         
[stack:7032]
7f2e4f992000-7f2e4f99c000 r-xp 00000000 08:12 1573719                   
/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
7f2e4f99c000-7f2e4fb9b000 ---p 0000a000 08:12 1573719                   
/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
7f2e4fb9b000-7f2e4fb9c000 r--p 00009000 08:12 1573719                   
/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
7f2e4fb9c000-7f2e4fb9d000 rw-p 0000a000 08:12 1573719                   
/usr/lib/x86_64-linux-gnu/gio/modules/libdconfsettings.so
7f2e4fb9d000-7f2e4fbb6000 r-xp 00000000 08:12 1573723                   
/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so
7f2e4fbb6000-7f2e4fdb6000 ---p 00019000 08:12 1573723                   
/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so
7f2e4fdb6000-7f2e4fdb9000 r--p 00019000 08:12 1573723                   
/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so
7f2e4fdb9000-7f2e4fdba000 rw-p 0001c000 08:12 1573723                   
/usr/lib/x86_64-linux-gnu/gio/modules/libgioremote-volume-monitor.so
7f2e4fdba000-7f2e4fdfd000 r-xp 00000000 08:12 1316651                   
/usr/lib/x86_64-linux-gnu/libibus-1.0.so.0.401.0
7f2e4fdfd000-7f2e4fffc000 ---p 00043000 08:12 1316651                   
/usr/lib/x86_64-linux-gnu/libibus-1.0.so.0.401.0
7f2e4fffc000-7f2e4fffe000 r--p 00042000 08:12 1316651                   
/usr/lib/x86_64-linux-gnu/libibus-1.0.so.0.401.0
7f2e4fffe000-7f2e4ffff000 rw-p 00044000 08:12 1316651                   
/usr/lib/x86_64-linux-gnu/libibus-1.0.so.0.401.0
7f2e4ffff000-7f2e50000000 rw-p 00000000 00:00 0 
7f2e50000000-7f2e50110000 rw-p 00000000 00:00 0 
7f2e50110000-7f2e54000000 ---p 00000000 00:00 0 
7f2e54000000-7f2e5464a000 rw-p 00000000 00:00 0 
7f2e5464a000-7f2e58000000 ---p 00000000 00:00 0 
7f2e58000000-7f2e58021000 rw-p 00000000 00:00 0 
7f2e58021000-7f2e5c000000 ---p 00000000 00:00 0 
7f2e5c000000-7f2e5c021000 rw-p 00000000 00:00 0 
7f2e5c021000-7f2e60000000 ---p 00000000 00:00 0 
7f2e60000000-7f2e60021000 rw-p 00000000 00:00 0 
7f2e60021000-7f2e64000000 ---p 00000000 00:00 0 
7f2e6404e000-7f2e64054000 r-xp 00000000 08:12 1573864                   
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so
7f2e64054000-7f2e64253000 ---p 00006000 08:12 1573864                   
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so
7f2e64253000-7f2e64254000 r--p 00005000 08:12 1573864                   
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so
7f2e64254000-7f2e64255000 rw-p 00006000 08:12 1573864                   
/usr/lib/x86_64-linux-gnu/gtk-2.0/2.10.0/immodules/im-ibus.so
7f2e64255000-7f2e64259000 r-xp 00000000 08:13 791625                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/sgmlop.so
7f2e64259000-7f2e64458000 ---p 00004000 08:13 791625                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/sgmlop.so
7f2e64458000-7f2e64459000 r--p 00003000 08:13 791625                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/sgmlop.so
7f2e64459000-7f2e6445a000 rw-p 00004000 08:13 791625                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/sgmlop.so
7f2e6445a000-7f2e6450a000 r--p 00000000 08:12 2093741                   
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSans.ttf
7f2e6450a000-7f2e6450c000 r-xp 00000000 08:12 1574098                   
/usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so
7f2e6450c000-7f2e6470b000 ---p 00002000 08:12 1574098                   
/usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so
7f2e6470b000-7f2e6470c000 r--p 00001000 08:12 1574098                   
/usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so
7f2e6470c000-7f2e6470d000 rw-p 00002000 08:12 1574098                   
/usr/lib/x86_64-linux-gnu/pango/1.6.0/modules/pango-basic-fc.so
7f2e6470d000-7f2e6475f000 r--p 00000000 08:12 2093743                   
/usr/share/fonts/truetype/ttf-dejavu/DejaVuSansMono.ttf
7f2e6475f000-7f2e64760000 r--s 00000000 08:12 1717562                   
/var/cache/fontconfig/c05880de57d1f5e948fdfacc138775d9-le64.cache-3
7f2e64760000-7f2e64769000 r--s 00000000 08:12 1717554                   
/var/cache/fontconfig/945677eb7aeaf62f1d50efc3fb3ec7d8-le64.cache-3
7f2e64769000-7f2e6476d000 r--s 00000000 08:12 1719903                   
/var/cache/fontconfig/99e8ed0e538f840c565b6ed5dad60d56-le64.cache-3
7f2e6476d000-7f2e64772000 r--s 00000000 08:12 1717539                   
/var/cache/fontconfig/2cd17615ca594fa2959ae173292e504c-le64.cache-3
7f2e64772000-7f2e64773000 r--s 00000000 08:12 1717570                   
/var/cache/fontconfig/e7071f4a29fa870f4323321c154eba04-le64.cache-3
7f2e64773000-7f2e64774000 r--s 00000000 08:12 1717536                   
/var/cache/fontconfig/0d8c3b2ac0904cb8a57a757ad11a4a08-le64.cache-3
7f2e64774000-7f2e6477a000 r--s 00000000 08:12 1717558                   
/var/cache/fontconfig/a755afe4a08bf5b97852ceb7400b47bc-le64.cache-3
7f2e6477a000-7f2e6477e000 r--s 00000000 08:12 1717549                   
/var/cache/fontconfig/6d41288fd70b0be22e8c3a91e032eec0-le64.cache-3
7f2e6477e000-7f2e6478e000 r--s 00000000 08:12 1717534                   
/var/cache/fontconfig/04aabc0a78ac019cf9454389977116d2-le64.cache-3
7f2e6478e000-7f2e6478f000 r--s 00000000 08:12 1717538                   
/var/cache/fontconfig/1ac9eb803944fde146138c791f5cc56a-le64.cache-3
7f2e6478f000-7f2e64792000 r--s 00000000 08:12 1717543                   
/var/cache/fontconfig/385c0604a188198f04d133e54aba7fe7-le64.cache-3
7f2e64792000-7f2e64793000 r--s 00000000 08:12 1717568                   
/var/cache/fontconfig/dc05db6664285cc2f12bf69c139ae4c3-le64.cache-3
7f2e64793000-7f2e64795000 r--s 00000000 08:12 1717551                   
/var/cache/fontconfig/767a8244fc0220cfb567a839d0392e0b-le64.cache-3
7f2e64795000-7f2e64796000 r--s 00000000 08:12 1717544                   
/var/cache/fontconfig/4794a0821666d79190d59a36cb4f44b5-le64.cache-3
7f2e64796000-7f2e64799000 r--s 00000000 08:12 1717553                   
/var/cache/fontconfig/8801497958630a81b71ace7c5f9b32a8-le64.cache-3
7f2e64799000-7f2e6479e000 r--s 00000000 08:12 1717540                   
/var/cache/fontconfig/3047814df9a2f067bd2d96a2b9c36e5a-le64.cache-3
7f2e6479e000-7f2e6479f000 r--s 00000000 08:12 1717546                   
/var/cache/fontconfig/56cf4f4769d0f4abc89a4895d7bd3ae1-le64.cache-3
7f2e6479f000-7f2e647a0000 r--s 00000000 08:12 1717561                   
/var/cache/fontconfig/b9d506c9ac06c20b433354fa67a72993-le64.cache-3
7f2e647a0000-7f2e647a5000 r--s 00000000 08:12 1717560                   
/var/cache/fontconfig/b47c4e1ecd0709278f4910c18777a504-le64.cache-3
7f2e647a5000-7f2e647b6000 r--s 00000000 08:12 1717566                   
/var/cache/fontconfig/d52a8644073d54c13679302ca1180695-le64.cache-3
7f2e647b6000-7f2e647bc000 r--s 00000000 08:12 1719800                   
/var/cache/fontconfig/105b9c7e6f0a4f82d8c9b6e39c52c6f9-le64.cache-3
7f2e647bc000-7f2e647c8000 r--s 00000000 08:12 1719902                   
/var/cache/fontconfig/089dead882dea3570ffc31a9898cfb69-le64.cache-3
7f2e647c8000-7f2e647c9000 r--s 00000000 08:12 1717535                   
/var/cache/fontconfig/0c9eb80ebd1c36541ebe2852d3bb0c49-le64.cache-3
7f2e647c9000-7f2e647cc000 r--s 00000000 08:12 1707996                   
/var/cache/fontconfig/e13b20fdb08344e0e664864cc2ede53d-le64.cache-3
7f2e647cc000-7f2e647d0000 r--s 00000000 08:12 1719901                   
/var/cache/fontconfig/7ef2298fde41cc6eeb7af42e48b7d293-le64.cache-3
7f2e647d0000-7f2e647d1000 ---p 00000000 00:00 0 
7f2e647d1000-7f2e64fd1000 rw-p 00000000 00:00 0                         
[stack:7030]
7f2e64fd1000-7f2e65001000 r-xp 00000000 08:13 791624                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/ciElementTree.so
7f2e65001000-7f2e65201000 ---p 00030000 08:13 791624                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/ciElementTree.so
7f2e65201000-7f2e65203000 r--p 00030000 08:13 791624                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/ciElementTree.so
7f2e65203000-7f2e65204000 rw-p 00032000 08:13 791624                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/ciElementTree.so
7f2e65204000-7f2e652e9000 r-xp 00000000 08:13 791622                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/_SilverCity.so
7f2e652e9000-7f2e654e8000 ---p 000e5000 08:13 791622                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/_SilverCity.so
7f2e654e8000-7f2e654ea000 r--p 000e4000 08:13 791622                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/_SilverCity.so
7f2e654ea000-7f2e654ec000 rw-p 000e6000 08:13 791622                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeCodeIntel/libs/_linux_libcpp6_x86_64/_SilverCity.so
7f2e654ec000-7f2e654ee000 rw-p 00000000 00:00 0 
7f2e654ee000-7f2e654ef000 ---p 00000000 00:00 0 
7f2e654ef000-7f2e65cef000 rw-p 00000000 00:00 0                         
[stack:7029]
7f2e65cef000-7f2e65cf0000 ---p 00000000 00:00 0 
7f2e65cf0000-7f2e664f0000 rw-p 00000000 00:00 0                         
[stack:7028]
7f2e664f0000-7f2e664f1000 ---p 00000000 00:00 0 
7f2e664f1000-7f2e66cf1000 rw-p 00000000 00:00 0                         
[stack:7027]
7f2e66cf1000-7f2e66cf2000 ---p 00000000 00:00 0 
7f2e66cf2000-7f2e674f2000 rw-p 00000000 00:00 0                         
[stack:7026]
7f2e674f2000-7f2e67db6000 r-xp 00000000 08:13 659276                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/libclang.so
7f2e67db6000-7f2e67fb5000 ---p 008c4000 08:13 659276                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/libclang.so
7f2e67fb5000-7f2e67ffd000 r--p 008c3000 08:13 659276                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/libclang.so
7f2e67ffd000-7f2e67ffe000 rw-p 0090b000 08:13 659276                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/libclang.so
7f2e67ffe000-7f2e68000000 rw-p 00000000 00:00 0 
7f2e68000000-7f2e68021000 rw-p 00000000 00:00 0 
7f2e68021000-7f2e6c000000 ---p 00000000 00:00 0 
7f2e6c000000-7f2e6c021000 rw-p 00000000 00:00 0 
7f2e6c021000-7f2e70000000 ---p 00000000 00:00 0 
7f2e70000000-7f2e7006a000 rw-p 00000000 00:00 0 
7f2e7006a000-7f2e74000000 ---p 00000000 00:00 0 
7f2e74000000-7f2e74387000 rw-p 00000000 00:00 0 
7f2e74387000-7f2e78000000 ---p 00000000 00:00 0 
7f2e78000000-7f2e78022000 rw-p 00000000 00:00 0 
7f2e78022000-7f2e7c000000 ---p 00000000 00:00 0 
7f2e7c000000-7f2e7c065000 rw-p 00000000 00:00 0 
7f2e7c065000-7f2e80000000 ---p 00000000 00:00 0 
7f2e80000000-7f2e80021000 rw-p 00000000 00:00 0 
7f2e80021000-7f2e84000000 ---p 00000000 00:00 0 
7f2e8401f000-7f2e8407f000 rw-s 00000000 00:04 52723760                  
/SYSV00000000 (deleted)
7f2e8407f000-7f2e8409c000 r--p 00000000 08:12 2093659                   
/usr/share/fonts/truetype/liberation/LiberationMono-BoldItalic.ttf
7f2e8409c000-7f2e840bb000 r--p 00000000 08:12 2093660                   
/usr/share/fonts/truetype/liberation/LiberationMono-Italic.ttf
7f2e840bb000-7f2e840cc000 r-xp 00000000 08:13 659280                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/libcache.so
7f2e840cc000-7f2e842cb000 ---p 00011000 08:13 659280                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/libcache.so
7f2e842cb000-7f2e842cc000 r--p 00010000 08:13 659280                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/libcache.so
7f2e842cc000-7f2e842cd000 rw-p 00011000 08:13 659280                    
/home/xiemeilong/.config/sublime-text-2/Packages/SublimeClang/libcache.so
7f2e842cd000-7f2e842e9000 r-xp 00000000 08:13 791202                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_ctypes.so
7f2e842e9000-7f2e844e8000 ---p 0001c000 08:13 791202                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_ctypes.so
7f2e844e8000-7f2e844e9000 r--p 0001b000 08:13 791202                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_ctypes.so
7f2e844e9000-7f2e844ed000 rw-p 0001c000 08:13 791202                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_ctypes.so
7f2e844ed000-7f2e844ee000 ---p 00000000 00:00 0 
7f2e844ee000-7f2e84cee000 rw-p 00000000 00:00 0                         
[stack:7023]
7f2e84cee000-7f2e84cef000 ---p 00000000 00:00 0 
7f2e84cef000-7f2e854ef000 rw-p 00000000 00:00 0                         
[stack:7022]
7f2e854ef000-7f2e854f5000 r-xp 00000000 08:13 791185                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_multiprocessing.so
7f2e854f5000-7f2e856f4000 ---p 00006000 08:13 791185                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_multiprocessing.so
7f2e856f4000-7f2e856f5000 r--p 00005000 08:13 791185                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_multiprocessing.so
7f2e856f5000-7f2e856f6000 rw-p 00006000 08:13 791185                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_multiprocessing.so
7f2e856f6000-7f2e856f9000 r-xp 00000000 08:13 791198                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_json.so
7f2e856f9000-7f2e858f8000 ---p 00003000 08:13 791198                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_json.so
7f2e858f8000-7f2e858f9000 r--p 00002000 08:13 791198                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_json.so
7f2e858f9000-7f2e858fa000 rw-p 00003000 08:13 791198                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_json.so
7f2e858fa000-7f2e85a98000 r-xp 00000000 08:12 919525                    
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f2e85a98000-7f2e85c97000 ---p 0019e000 08:12 919525                    
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f2e85c97000-7f2e85cb2000 r--p 0019d000 08:12 919525                    
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f2e85cb2000-7f2e85cbd000 rw-p 001b8000 08:12 919525                    
/lib/x86_64-linux-gnu/libcrypto.so.1.0.0
7f2e85cbd000-7f2e85cc1000 rw-p 00000000 00:00 0 
7f2e85cda000-7f2e85cdd000 r-xp 00000000 08:13 791188                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_hashlib.so
7f2e85cdd000-7f2e85edc000 ---p 00003000 08:13 791188                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_hashlib.so
7f2e85edc000-7f2e85edd000 r--p 00002000 08:13 791188                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_hashlib.so
7f2e85edd000-7f2e85ede000 rw-p 00003000 08:13 791188                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_hashlib.so
7f2e85ede000-7f2e85ee1000 r-xp 00000000 08:13 791191                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_heapq.so
7f2e85ee1000-7f2e860e0000 ---p 00003000 08:13 791191                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_heapq.so
7f2e860e0000-7f2e860e1000 r--p 00002000 08:13 791191                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_heapq.so
7f2e860e1000-7f2e860e3000 rw-p 00003000 08:13 791191                    
/home/xiemeilong/.pythonbrew/pythons/Python-2.6.7/lib/python2.6/lib-dynload/_heapq.so
7f2e860e3000-7f2e860e4000 ---p 00000000 00:00 0 
7f2e860e4000-7f2e868e4000 rw-p 00000000 00:00 0                         
[stack:7021]
7f2e868e4000-7f2e868e5000 ---p 00000000 00:00 0 
7f2e868e5000-7f2e870e5000 rw-p 00000000 00:00 0                         
[stack:7020]
7f2e870e5000-7f2e870e9000 r-xp 00000000 08:12 1573707                   
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7f2e870e9000-7f2e872e9000 ---p 00004000 08:12 1573707                   
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7f2e872e9000-7f2e872ea000 r--p 00004000 08:12 1573707                   
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7f2e872ea000-7f2e872eb000 rw-p 00005000 08:12 1573707                   
/usr/lib/x86_64-linux-gnu/gdk-pixbuf-2.0/2.10.0/loaders/libpixbufloader-png.so
7f2e872eb000-7f2e872ec000 ---p 00000000 00:00 0 
7f2e872ec000-7f2e87aec000 rw-p 00000000 00:00 0                         
[stack:7018]
7f2e87aec000-7f2e87aed000 ---p 00000000 00:00 0 
7f2e87aed000-7f2e882ed000 rw-p 00000000 00:00 0                         
[stack:7017]
7f2e882ed000-7f2e882ee000 ---p 00000000 00:00 0 
7f2e882ee000-7f2e88aee000 rw-p 00000000 00:00 0                         
[stack:7016]
7f2e88aee000-7f2e88afa000 r-xp 00000000 08:12 919580                    
/lib/x86_64-linux-gnu/libnss_files-2.15.so
7f2e88afa000-7f2e88cf9000 ---p 0000c000 08:12 919580                    
/lib/x86_64-linux-gnu/libnss_files-2.15.so
7f2e88cf9000-7f2e88cfa000 r--p 0000b000 08:12 919580                    
/lib/x86_64-linux-gnu/libnss_files-2.15.so
7f2e88cfa000-7f2e88cfb000 rw-p 0000c000 08:12 919580                    
/lib/x86_64-linux-gnu/libnss_files-2.15.so
7f2e88cfb000-7f2e88d05000 r-xp 00000000 08:12 919584                    
/lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f2e88d05000-7f2e88f05000 ---p 0000a000 08:12 919584                    
/lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f2e88f05000-7f2e88f06000 r--p 0000a000 08:12 919584                    
/lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f2e88f06000-7f2e88f07000 rw-p 0000b000 08:12 919584                    
/lib/x86_64-linux-gnu/libnss_nis-2.15.so
7f2e88f07000-7f2e88f1e000 r-xp 00000000 08:12 919574                    
/lib/x86_64-linux-gnu/libnsl-2.15.so
7f2e88f1e000-7f2e8911d000 ---p 00017000 08:12 919574                    
/lib/x86_64-linux-gnu/libnsl-2.15.so
7f2e8911d000-7f2e8911e000 r--p 00016000 08:12 919574                    
/lib/x86_64-linux-gnu/libnsl-2.15.so
7f2e8911e000-7f2e8911f000 rw-p 00017000 08:12 919574                    
/lib/x86_64-linux-gnu/libnsl-2.15.so
7f2e8911f000-7f2e89121000 rw-p 00000000 00:00 0 
7f2e89121000-7f2e89129000 r-xp 00000000 08:12 919576                    
/lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f2e89129000-7f2e89328000 ---p 00008000 08:12 919576                    
/lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f2e89328000-7f2e89329000 r--p 00007000 08:12 919576                    
/lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f2e89329000-7f2e8932a000 rw-p 00008000 08:12 919576                    
/lib/x86_64-linux-gnu/libnss_compat-2.15.so
7f2e8932a000-7f2e89a0b000 r--p 00000000 08:12 1314994                   
/usr/lib/locale/locale-archive
7f2e89a0b000-7f2e89a2a000 r-xp 00000000 08:12 1316329                   
/usr/lib/x86_64-linux-gnu/libatk-1.0.so.0.20609.1
7f2e89a2a000-7f2e89c2a000 ---p 0001f000 08:12 1316329                   
/usr/lib/x86_64-linux-gnu/libatk-1.0.so.0.20609.1
7f2e89c2a000-7f2e89c2c000 r--p 0001f000 08:12 1316329                   
/usr/lib/x86_64-linux-gnu/libatk-1.0.so.0.20609.1
7f2e89c2c000-7f2e89c2d000 rw-p 00021000 08:12 1316329                   
/usr/lib/x86_64-linux-gnu/libatk-1.0.so.0.20609.1
7f2e89c2d000-7f2e8a05a000 r-xp 00000000 08:12 1316625                   
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.13
7f2e8a05a000-7f2e8a259000 ---p 0042d000 08:12 1316625                   
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.13
7f2e8a259000-7f2e8a260000 r--p 0042c000 08:12 1316625                   
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.13
7f2e8a260000-7f2e8a264000 rw-p 00433000 08:12 1316625                   
/usr/lib/x86_64-linux-gnu/libgtk-x11-2.0.so.0.2400.13
7f2e8a264000-7f2e8a266000 rw-p 00000000 00:00 0 
7f2e8a266000-7f2e8a26e000 r-xp 00000000 08:12 1317003                   
/usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f2e8a26e000-7f2e8a46e000 ---p 00008000 08:12 1317003                   
/usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f2e8a46e000-7f2e8a46f000 r--p 00008000 08:12 1317003                   
/usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f2e8a46f000-7f2e8a470000 rw-p 00009000 08:12 1317003                   
/usr/lib/x86_64-linux-gnu/libxcb-render.so.0.0.0
7f2e8a470000-7f2e8a472000 r-xp 00000000 08:12 1317007                   
/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f2e8a472000-7f2e8a671000 ---p 00002000 08:12 1317007                   
/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f2e8a671000-7f2e8a672000 r--p 00001000 08:12 1317007                   
/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f2e8a672000-7f2e8a673000 rw-p 00002000 08:12 1317007                   
/usr/lib/x86_64-linux-gnu/libxcb-shm.so.0.0.0
7f2e8a673000-7f2e8a698000 r-xp 00000000 08:12 919606                    
/lib/x86_64-linux-gnu/libpng12.so.0.49.0
7f2e8a698000-7f2e8a897000 ---p 00025000 08:12 919606                    
/lib/x86_64-linux-gnu/libpng12.so.0.49.0
7f2e8a897000-7f2e8a898000 r--p 00024000 08:12 919606                    
/lib/x86_64-linux-gnu/libpng12.so.0.49.0
7f2e8a898000-7f2e8a899000 rw-p 00025000 08:12 919606                    
/lib/x86_64-linux-gnu/libpng12.so.0.49.0
7f2e8a899000-7f2e8a919000 r-xp 00000000 08:12 1316812                   
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.26.0
7f2e8a919000-7f2e8ab18000 ---p 00080000 08:12 1316812                   
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.26.0
7f2e8ab18000-7f2e8ab1e000 r--p 0007f000 08:12 1316812                   
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.26.0
7f2e8ab1e000-7f2e8ab1f000 rw-p 00085000 08:12 1316812                   
/usr/lib/x86_64-linux-gnu/libpixman-1.so.0.26.0
7f2e8ab1f000-7f2e8ab45000 r-xp 00000000 08:12 919535                    
/lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f2e8ab45000-7f2e8ad45000 ---p 00026000 08:12 919535                    
/lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f2e8ad45000-7f2e8ad47000 r--p 00026000 08:12 919535                    
/lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f2e8ad47000-7f2e8ad48000 rw-p 00028000 08:12 919535                    
/lib/x86_64-linux-gnu/libexpat.so.1.6.0
7f2e8ad48000-7f2e8ad60000 r-xp 00000000 08:12 919617                    
/lib/x86_64-linux-gnu/libresolv-2.15.solibclang: 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  Sun Nov  4 01:04:06 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 09:04:06 +0000
Subject: [LLVMbugs] [Bug 14160] BasicAA omits swapping of TBAAInfo
In-Reply-To: <bug-14160-206@http.llvm.org/bugs/>
References: <bug-14160-206@http.llvm.org/bugs/>
Message-ID: <bug-14160-206-HG63WYhg0f@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #6 from Duncan Sands <baldrick at free.fr> 2012-11-04 03:04:06 CST ---
Patch applied in commit 167370.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  4 02:56:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 10:56:49 +0000
Subject: [LLVMbugs] [Bug 14253] New: No unused warning for variables of
 non-trivial types
Message-ID: <bug-14253-206@http.llvm.org/bugs/>

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

             Bug #: 14253
           Summary: No unused warning for variables of non-trivial types
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: l.lunak at suse.cz
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Clang warns about unused variables e.g. of type 'int', but not 'std::string' :

$ cat a.cpp
#include <string>

void foo()
    {
    int i;
    std::string s;
    }
$ clang++ -Wall -Wunused -c a.cpp
a.cpp:5:9: warning: unused variable 'i' [-Wunused-variable]
    int i;
        ^
1 warning generated.                                                            

In the function 's' is apparently unused too, but the compiler cannot tell 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  Sun Nov  4 03:54:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 11:54:44 +0000
Subject: [LLVMbugs] [Bug 14254] New: llvm-config --libfiles lists libraries
 which don't appear to exist.
Message-ID: <bug-14254-206@http.llvm.org/bugs/>

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

             Bug #: 14254
           Summary: llvm-config --libfiles lists libraries which don't
                    appear to exist.
           Product: tools
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvm-config
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: terrywallwork at netscape.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I recently built llvm 3.1 final, on Fedora 17 box 32 bit Intel box, using the
following configure options:

${SVNROOTDIRLLVMCOLLECTION}/llvm/configure --enable-optimized
--prefix="${LLVMCOLLECTIONBUILDIR}/LLVMInstall"

This all worked well (as far as I can tell), install seems to have gone
correctly as well.  But when I then try to build an application that uses LLVM
(Blender in my case for OSL).  I get linking  errors about libraries not
existing.  I checked with llvm-config --libfiles which libraries llvm was
saying it needed to be successfully linked and it seems to list libraries that
don't seem to exist in llvm lib directory.  

In my case:

${LLVMCOLLECTIONBUILDIR}/LLVMInstall/lib/libLLVMIntelJITEvents.a
${LLVMCOLLECTIONBUILDIR}/LLVMInstall/lib/libLLVMOProfileJIT.a
${LLVMCOLLECTIONBUILDIR}/LLVMInstall/lib/libgtest_main.a
${LLVMCOLLECTIONBUILDIR}/LLVMInstall/lib/libgtest.a

To get it to work I ended up intercepting calls to llvm-config and filtering
out these libraries so Blender would compile.  Once it did compile Blender OSL
works fine.

I know this is not the correct way to do things but I am not a hard core
programmer so doing it the correct way is beyond me.

I posted here because i am not sure if this is the same bug as this one:

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

Apologies if this is simply me not knowing how to configure LLVM correctly.

If you need any more information please let me know.

Terry Wallwork

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  4 04:27:25 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 12:27:25 +0000
Subject: [LLVMbugs] [Bug 14255] New: _GLIBCXX_DEBUG broken?
Message-ID: <bug-14255-206@http.llvm.org/bugs/>

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

             Bug #: 14255
           Summary: _GLIBCXX_DEBUG broken?
           Product: libc++
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: dave at boostpro.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The following program prints "invalid quantifier" when compiled with "g++ -I
~/src/boost/svn/release  -D_GLIBCXX_DEBUG bug.cpp".  Of course this could
always be a bug in Boost.XPressive, but g++ (with libstdc++) doesn't have this
problem.  Haven't gone further to track it down, sorry. I've enclosed
preprocessed source.

#include <boost/xpressive/xpressive.hpp>

int main()
{
    try
    {
        boost::xpressive::sregex::compile("x{4}");
    }
    catch(std::exception& e)
    {
        std::cout << e.what() << std::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  Sun Nov  4 06:18:57 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 14:18:57 +0000
Subject: [LLVMbugs] [Bug 14256] New: Reference to non-existent class in the
 CodeGenerator.html doc
Message-ID: <bug-14256-206@http.llvm.org/bugs/>

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

             Bug #: 14256
           Summary: Reference to non-existent class in the
                    CodeGenerator.html doc
           Product: Documentation
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eliben at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


CodeGenerator.html mentions:

"The initial SelectionDAG is naïvely peephole expanded from the LLVM input by
the SelectionDAGLowering class in the
lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp file"

However, SelectionDAGLowering does not exist in the above file (or anywhere
else).

P.S. this class is also mentioned in a comment in
./include/llvm/Target/TargetLowering.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  Sun Nov  4 13:10:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 21:10:44 +0000
Subject: [LLVMbugs] [Bug 14257] New: clang/docs/Makefile is not safe for
	multithreading
Message-ID: <bug-14257-206@http.llvm.org/bugs/>

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

             Bug #: 14257
           Summary: clang/docs/Makefile is not safe for multithreading
           Product: Build scripts
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: blubberquark at v4hn.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The relevant failing part of a build with --enable-doxygen and two build jobs
is the following:

make[3]: Entering directory `/usr/src/llvm-3.1.src/tools/clang/docs'
llvm[3]: Building doxygen documentation
llvm[3]: Packaging HTML documentation
[some unrelated warnings about obsolete symbols in doxygen.cfg...]
Notice: Output directory `/usr/src/llvm-3.1.src/tools/clang/docs/doxygen' does
not exist. I have created it for you.
llvm[3]: Packaging doxygen documentation
/bin/tar: doxygen: file changed as we read it
make[3]: *** [/usr/src/llvm-3.1.src/tools/clang/docs/doxygen.tar.gz] Error 1
make[3]: *** Waiting for unfinished jobs....
warning: source /usr/src/llvm-3.1.src/tools/clang/docs/img is not a readable
file or directory... skipping.
Searching for include files...
Searching for files in directory /usr/src/llvm-3.1.src/tools/clang/include
Searching for files in directory
/usr/src/llvm-3.1.src/tools/clang/include/clang
Searching for files in directory
/usr/src/llvm-3.1.src/tools/clang/include/clang/Analysis
[...]

Observe that (1.) the "Packaging ... documentation" goals doesn't wait for the
"Building doxygen documentation" goal and (2.) the doxygen job goes on and
produces over 5000 dot graphs before the
build actually fails!
Also you might not want to build all these graphs by default in the first place
when building the documentation (at least not for releases), but that's a
different story.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  4 13:22:00 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 04 Nov 2012 21:22:00 +0000
Subject: [LLVMbugs] [Bug 14258] New: clang should check NSKeyValueCoding.h
 methods for key and keypath naming rules
Message-ID: <bug-14258-206@http.llvm.org/bugs/>

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

             Bug #: 14258
           Summary: clang should check NSKeyValueCoding.h methods for key
                    and keypath naming rules
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sean at rogue-research.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Two suggestions:

(1) Due to autocompletion, copy-pasting things around, or lack of coffee, I
sometimes mix up KVC keys and keypaths. ex:

  [obj setValue:value forKey:@"selection.foo"];

that should be setValue:forKey*Path*:!

clang could warn whenever a '.' char is found in a string passed to one of the
'key' methods, and even have a fix-it directing the user to the 'keyPath'
variant.

(2) Even more generally, you could validate this requirement of the "Key-Value
Coding Programming Guide":

"Keys must use ASCII encoding, begin with a lowercase letter, and may not
contain whitespace"

I think these checks would be more useful in the compiler, not the static
analyzer.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  4 19:02:37 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 03:02:37 +0000
Subject: [LLVMbugs] [Bug 14256] Reference to non-existent class in the
 CodeGenerator.html doc
In-Reply-To: <bug-14256-206@http.llvm.org/bugs/>
References: <bug-14256-206@http.llvm.org/bugs/>
Message-ID: <bug-14256-206-YZqMOYqnDv@http.llvm.org/bugs/>

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

Eli Bendersky <eliben at gmail.com> changed:

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

--- Comment #2 from Eli Bendersky <eliben at gmail.com> 2012-11-04 21:02:37 CST ---
Thanks. Fix committed in r167378

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 02:55:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 10:55:39 +0000
Subject: [LLVMbugs] [Bug 14045] Miscompilation of load from nocapture
 argument that is indirectly copied to a local alloca
In-Reply-To: <bug-14045-206@http.llvm.org/bugs/>
References: <bug-14045-206@http.llvm.org/bugs/>
Message-ID: <bug-14045-206-5pZU6f6v10@http.llvm.org/bugs/>

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

Richard Osborne <richard at xmos.com> changed:

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

--- Comment #1 from Richard Osborne <richard at xmos.com> 2012-11-05 04:55:39 CST ---
This is fixed in r167381:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155155.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 Nov  5 05:33:41 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 13:33:41 +0000
Subject: [LLVMbugs] [Bug 14259] New: "Should not see dependent types" in
 ASTContext.cpp:1284 executed
Message-ID: <bug-14259-206@http.llvm.org/bugs/>

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

             Bug #: 14259
           Summary: "Should not see dependent types" in
                    ASTContext.cpp:1284 executed
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Test case:

template <class type>
struct fastscriptmember {
    type Member __attribute__ ((packed));
};

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 06:58:04 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 14:58:04 +0000
Subject: [LLVMbugs] [Bug 14238] CommandLine.h cl::bits fails to compile with
 clang++ and g++ 4.7
In-Reply-To: <bug-14238-206@http.llvm.org/bugs/>
References: <bug-14238-206@http.llvm.org/bugs/>
Message-ID: <bug-14238-206-7nJAiFlAN9@http.llvm.org/bugs/>

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

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 #1 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> 2012-11-05 08:58:04 CST ---
Fixed in r167383.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 07:04:31 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 15:04:31 +0000
Subject: [LLVMbugs] [Bug 14260] New: Invalid write of size 1
Message-ID: <bug-14260-206@http.llvm.org/bugs/>

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

             Bug #: 14260
           Summary: Invalid write of size 1
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9494
  --> http://llvm.org/bugs/attachment.cgi?id=9494
testcase

Thanks Joerg Sonnenberger 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  Mon Nov  5 07:17:37 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 15:17:37 +0000
Subject: [LLVMbugs] [Bug 14261] New: Allow disabling backtrace support by
 environment variable
Message-ID: <bug-14261-206@http.llvm.org/bugs/>

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

             Bug #: 14261
           Summary: Allow disabling backtrace support by environment
                    variable
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Bugs like 14260 can result in nasty dead locks at least on Linux. Problem is
that the malloc lock is hold by the current thread and backtrace in glibc wants
to allocate more memory. It would be nice to disable the fancy signal handlers
via environment to make it easier to build test cases without having to hack
the source.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 09:09:28 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 17:09:28 +0000
Subject: [LLVMbugs] [Bug 14262] New: VTable not emitted if key function is
 inline and function is not emitted
Message-ID: <bug-14262-206@http.llvm.org/bugs/>

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

             Bug #: 14262
           Summary: VTable not emitted if key function is inline and
                    function is not emitted
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9496
  --> http://llvm.org/bugs/attachment.cgi?id=9496
Test case

Test case is attached. GCC always emits the vtable, clang only with -O0.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 10:32:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 18:32:02 +0000
Subject: [LLVMbugs] [Bug 14237] Clang crashes on invalid code with attributes
In-Reply-To: <bug-14237-206@http.llvm.org/bugs/>
References: <bug-14237-206@http.llvm.org/bugs/>
Message-ID: <bug-14237-206-lcXox7A1iZ@http.llvm.org/bugs/>

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

rtrieu at google.com changed:

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

--- Comment #2 from rtrieu at google.com 2012-11-05 12:32:02 CST ---
It was crashing, then DeLesley fixed it in r167321.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 11:44:29 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 19:44:29 +0000
Subject: [LLVMbugs] [Bug 14263] New: cc1as asserts "Expected to find
 -main-file-name" on silly input
Message-ID: <bug-14263-206@http.llvm.org/bugs/>

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

             Bug #: 14263
           Summary: cc1as asserts "Expected to find -main-file-name" on
                    silly input
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I found this while bisecting something else:

hummer:delta thakis$ cat foo.S
.byte (~$0 << 3) | 4
hummer:delta thakis$
/Users/thakis/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang
-c foo.S
Assertion failed: (HadError && "Parse statement returned an error, but none
emitted!"), function Run, file
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/lib/MC/MCParser/AsmParser.cpp,
line 558.
0  clang             0x000000010169af45 PrintStackTrace(void*) + 37
1  clang             0x000000010169b304 SignalHandler(int) + 500
2  libSystem.B.dylib 0x00007fff886681ba _sigtramp + 26
3  libSystem.B.dylib 000000000000000000 _sigtramp + 2006548064
4  clang             0x000000010004e9d6 abort + 22
5  clang             0x000000010004e9b1 __assert_rtn + 81
6  clang             0x000000010117dc95 (anonymous
namespace)::AsmParser::Run(bool, bool) + 437
7  clang             0x000000010005653a cc1as_main(char const**, char const**,
char const*, void*) + 8490
8  clang             0x0000000100057a41 main + 2273
9  clang             0x0000000100051764 start + 52
10 clang             0x0000000000000009 start + 4294633689

hummer:delta thakis$
/Users/thakis/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang
--version
clang version 3.2 (trunk 165787)
Target: x86_64-apple-darwin10.8.0
Thread model: posix


Happens with r167287 too, so this seems to have existed for a while. The
assertion was added in Chad's r156117

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 11:51:25 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 19:51:25 +0000
Subject: [LLVMbugs] [Bug 14264] New: cc1as regression (165787:167287):
 "Expected to find -main-file-name" on valid input when -gdwarf-2 is used
Message-ID: <bug-14264-206@http.llvm.org/bugs/>

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

             Bug #: 14264
           Summary: cc1as regression (165787:167287): "Expected to find
                    -main-file-name" on valid input when -gdwarf-2 is used
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is happening while compiling a .S file in chromium. Reduced:

hummer:delta thakis$ cat foo.S
.macro switcher
        ljmp *0x38(%ecx)
.endmacro
        switcher NaClSwitchNoSSE, 0
hummer:delta thakis$
/Users/thakis/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang
-c foo.S -gdwarf-2
0  clang             0x00000001016cb955 PrintStackTrace(void*) + 37
1  clang             0x00000001016cbd64 SignalHandler(int) + 564
2  libSystem.B.dylib 0x00007fff886681ba _sigtramp + 26
3  clang             0x00000001017d1b65
clang::StringLiteral::outputString(llvm::raw_ostream&)::Hex + 468133
4  clang             0x00000001011b008b (anonymous
namespace)::AsmParser::ParseStatement((anonymous
namespace)::ParseStatementInfo&) + 5355
5  clang             0x00000001011ab9b3 (anonymous
namespace)::AsmParser::Run(bool, bool) + 451
6  clang             0x0000000100055552 cc1as_main(char const**, char const**,
char const*, void*) + 8674
7  clang             0x0000000100056a35 main + 2261
8  clang             0x00000001000527c4 start + 52
Stack dump:
0.    Program arguments:
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang
-cc1as -triple x86_64-apple-macosx10.6.0 -filetype obj -g -o foo.o
/var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/foo-6Xf2NG.s 
1.    Program arguments: -triple x86_64-apple-macosx10.6.0 -filetype obj -g -o
foo.o /var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/foo-6Xf2NG.s 
0  clang             0x00000001016cb955 PrintStackTrace(void*) + 37
1  clang             0x00000001016cbd64 SignalHandler(int) + 564
2  libSystem.B.dylib 0x00007fff886681ba _sigtramp + 26
3  clang             0x00000001017d1b65
clang::StringLiteral::outputString(llvm::raw_ostream&)::Hex + 468133
4  clang             0x00000001011b008b (anonymous
namespace)::AsmParser::ParseStatement((anonymous
namespace)::ParseStatementInfo&) + 5355
5  clang             0x00000001011ab9b3 (anonymous
namespace)::AsmParser::Run(bool, bool) + 451
6  clang             0x0000000100055552 cc1as_main(char const**, char const**,
char const*, void*) + 8674
7  clang             0x0000000100056a35 main + 2261
8  clang             0x00000001000527c4 start + 52
clang: error: unable to execute command: Segmentation fault
clang: error: clang integrated assembler command failed due to signal (use -v
to see invocation)
clang version 3.2 (trunk 167287)
Target: x86_64-apple-darwin10.8.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 

This is a somewhat recent regresion.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 12:55:31 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 20:55:31 +0000
Subject: [LLVMbugs] [Bug 14265] New: Crash on invalid trying to delete a
 member function declared with a typedef'd function type
Message-ID: <bug-14265-206@http.llvm.org/bugs/>

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

             Bug #: 14265
           Summary: Crash on invalid trying to delete a member function
                    declared with a typedef'd function type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


struct S { typedef int F(); F f = delete; }

Gives:

<stdin>:1:35: error: '= delete' is a function definition and must occur in a
standalone declaration
struct S { typedef int F(); F f = delete; }
                                  ^
clang-3.2: include/llvm/Support/Casting.h:79: static bool
llvm::isa_impl_cl<clang::IntegerLiteral, clang::Expr *>:
:doit(const From *) [To = clang::IntegerLiteral, From = clang::Expr *]:
Assertion `Val && "isa<> used on a null pointer"' failed.
[...]
11 clang-3.2       0x00000000021ddd92
clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) + 130
12 clang-3.2       0x0000000001c75220
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::AttributeList*, clang::Parser::ParsedTemplateInfo const&,
clang::ParsingDeclRAIIObject*) + 6704

That diagnostic isn't great, and we shouldn't crash 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  Mon Nov  5 13:57:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 05 Nov 2012 21:57:03 +0000
Subject: [LLVMbugs] [Bug 14264] cc1as regression (r167237): crash with
 "Expected to find -main-file-name" on valid input when -gdwarf-2 is used
In-Reply-To: <bug-14264-206@http.llvm.org/bugs/>
References: <bug-14264-206@http.llvm.org/bugs/>
Message-ID: <bug-14264-206-v5QZyD5JC8@http.llvm.org/bugs/>

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

Kevin Enderby <enderby at apple.com> changed:

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

--- Comment #3 from Kevin Enderby <enderby at apple.com> 2012-11-05 15:57:03 CST ---
Thanks for the reduced test case!  Fixed with revision r167408.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  5 16:45:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 00:45:26 +0000
Subject: [LLVMbugs] [Bug 14266] New: Problem with PCH serialization and
 friend template specializations
Message-ID: <bug-14266-206@http.llvm.org/bugs/>

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

             Bug #: 14266
           Summary: Problem with PCH serialization and friend template
                    specializations
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ripzonetriton at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9497
  --> http://llvm.org/bugs/attachment.cgi?id=9497
PCH

Clang asserts when trying to compile a file using a previously generated PCH.

Assertion failed: (!Canon.isNull() || T.isDependent() ||
anyDependentTemplateArguments(Args, NumArgs, InstantiationDependent)) && "No
canonical type for non-dependent class template specialization", file
..\..\..\..\..\tools\clang\lib\AST\Type.cpp, line 1917

This affects MSVC 2008 <list> header but I was able to reduce it to a much more
reasonable test case:

PCH:

template<class T> class list {
  template <bool> class A;
  friend class A<0>;
};

Steps to reproduce:

1. Generate PCH
clang -cc1 -xc++ -emit-pch -o pch.h.pch pch.h

2. Compile file with PCH
clang -cc1 -xc++ -include-pch pch.h.pch main.cpp

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


From bugzilla-daemon at llvm.org  Mon Nov  5 17:41:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 01:41:35 +0000
Subject: [LLVMbugs] [Bug 14267] New: TargetLowering operation legality
 should be largely inferred from .td files
Message-ID: <bug-14267-206@http.llvm.org/bugs/>

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

             Bug #: 14267
           Summary: TargetLowering operation legality should be largely
                    inferred from .td files
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: grosbach at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In a thread on llvm-commits, Chris made the comment, "I really regret not
having the TargetLowering operation legality tables not be inferred from the
.td files from the get-go." That got me thinking about it a bit, and that seems
a very doable refactorization.

Every target has a long list of setOperationAction() calls in the constructor
for the TargetLowering. The .td files have a lot of information about what
operations are legal for what types from the instruction selection patterns. If
a target only marked explicitly those actions which are required to be Custom,
everything else could default to Expand, and a lot of error-prone boilerplate
code in the constructor would go 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  Mon Nov  5 19:09:25 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 03:09:25 +0000
Subject: [LLVMbugs] [Bug 14268] New: _mm_dp_ps generating 55% more
 inefficient instructions
Message-ID: <bug-14268-206@http.llvm.org/bugs/>

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

             Bug #: 14268
           Summary: _mm_dp_ps generating 55% more inefficient instructions
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ramihg at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9499
  --> http://llvm.org/bugs/attachment.cgi?id=9499
Simple test case

OS used: Mac OS X Mountain Lion
Clang/LLVM Used: 3.2-r167157
Processor: Intel Core i7

I was recently doing some SSE dot product implementations when I noticed a
severe performance drop after using _mm_dp_ps. This didn't make sense as the
x86 instruction latency manual showed that the dpps instruction is only 12
cycles latency.

Further investigation showed that dpps with a memory operand source: (e.g. dpps
$15, (%rex, %rdx), %xmm0) is about 55% slower than issuing a movaps then a dpps
with a register source/destination!

I've created and attached a simple test case that does dpps using intrinsics,
then using hand-written assembly with register operands, then using
hand-written assembly with memory source operand. The intrinsics version issued
instructions with memory operands.

Here is how I compiled the test:
clang++ -march=native -std=c++11 -stdlib=libc++ -O3 dotps.cpp

Here are the results I got (running each version 100000000 times):
DotPsIntrin: 249.332 ms
DotPsFast: 159.916 ms
DotPsSlow: 249.076 ms

I also tried the intrinsics version with Visual Studio 2012 and the Intel
compiler. Both generated the efficient movaps/dpps version even when specifying
"Optimize for 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  Tue Nov  6 01:41:06 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 09:41:06 +0000
Subject: [LLVMbugs] [Bug 14269] New: clang crashes when trying to get
 address of the bitfield and generates incorrect code
Message-ID: <bug-14269-206@http.llvm.org/bugs/>

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

             Bug #: 14269
           Summary: clang crashes when trying to get address of the
                    bitfield and generates incorrect code
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: a.bataev at gmx.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9500
  --> http://llvm.org/bugs/attachment.cgi?id=9500
preprocessed source and associated run script

The following code crashes clang compiled with Asserts

typedef struct foo {
    unsigned int field1 : 1;
    unsigned int field2 : 2;
    unsigned int field3 : 3;
} foo;
foo x;
void bar()
{
    __asm__ ( "movl $5, %0" :
              "=rm" (x.field3));
}
int main()
{
    bar();
    return (x.field3);
}

Here is the report

Assertion failed: (isSimple()), function getAddress, file
/llvm_trunk/llvm/tools/clang/lib/CodeGen/CGValue.h, line 230.
0  clang             0x000000010b904e82 _ZL15PrintStackTracePv + 34
1  clang             0x000000010b905489 _ZL13SignalHandleri + 793
2  libsystem_c.dylib 0x00007fff8ee66cfa _sigtramp + 26
3  libsystem_c.dylib 0x000000010c212f38 _sigtramp + 18446603342617166424
4  clang             0x000000010b9050c6 abort + 22
5  clang             0x000000010b905087 __assert_rtn + 55
6  clang             0x000000010a782711
clang::CodeGen::CodeGenFunction::EmitAsmStmt(clang::AsmStmt const&) + 8769
7  clang             0x000000010a77e605
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 565
8  clang             0x000000010a782e6b
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 235
9  clang             0x000000010a77e9bd
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 125
10 clang             0x000000010a77e3f9
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 41
11 clang             0x000000010a78f816
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 694
12 clang             0x000000010a798a2d
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 1933
13 clang             0x000000010a795c34
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 340
14 clang             0x000000010a797bca
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 698
15 clang             0x000000010a79d238
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 296
16 clang             0x000000010a7b950f (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 127
17 clang             0x000000010a78c88a
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 170
18 clang             0x000000010a7c67d3 clang::ParseAST(clang::Sema&, bool,
bool) + 323
19 clang             0x000000010a78bc16 clang::CodeGenAction::ExecuteAction() +
1286
20 clang             0x000000010a588e5b clang::FrontendAction::Execute() + 107
21 clang             0x000000010a568f4a
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 986
22 clang             0x000000010a53137c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3388
23 clang             0x000000010a5278fd cc1_main(char const**, char const**,
char const*, void*) + 3005
24 clang             0x000000010a52d2b1 main + 689
25 clang             0x000000010a526d34 start + 52
26 clang             0x000000000000002c start + 18446744069241410348
Stack dump:
0.      Program arguments: /llvm_trunk/build/Release+Asserts/bin/clang -cc1
-triple x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free
-main-file-name tr27771.c -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 127.2 -coverage-file
/tr27771.o -resource-dir /llvm_trunk/build/Release+Asserts/bin/../lib/clang/3.2
-fmodule-cache-path
/var/folders/zz/zyxvpxvq6csfxvn_n01bj6140_w9h9/T/clang-module-cache
-fdebug-compilation-dir / -ferror-limit 19 -fmessage-length 157
-stack-protector 1 -mstackrealign -fblocks -fobjc-runtime=macosx-10.7.0
-fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties
-fdiagnostics-show-option -fcolor-diagnostics -o tr27771.o -x c tr27771.c
1.      tr27771.c:17:1: current parser token 'int'
2.      tr27771.c:10:6: LLVM IR generation of declaration 'bar'
3.      tr27771.c:10:6: Generating code for declaration 'bar'
4.      tr27771.c:11:1: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk 166569)
Target: x86_64-apple-darwin11.2.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg:
/var/folders/zz/zyxvpxvq6csfxvn_n01bj6140_w9h9/T/tr27771-s6qSaT.c
clang: note: diagnostic msg:
/var/folders/zz/zyxvpxvq6csfxvn_n01bj6140_w9h9/T/tr27771-s6qSaT.sh
clang: note: diagnostic msg:

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



Clang without asserts generates incorrect code which writes to field3 incorrect
value.


Alexey Bataev
Software Engineer
Intel Compiler Team
Intel Corp.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 02:18:25 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 10:18:25 +0000
Subject: [LLVMbugs] [Bug 14270] New: Support for __builtin_iceil() is
 missing in dragonegg
Message-ID: <bug-14270-206@http.llvm.org/bugs/>

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

             Bug #: 14270
           Summary: Support for __builtin_iceil() is missing in dragonegg
           Product: dragonegg
           Version: 3.0
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: anitha.boyapati at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9501
  --> http://llvm.org/bugs/attachment.cgi?id=9501
Testcase to reproduce the bug

Testcase attached. Compile it as follows:

gcc -fplugin=dragonegg.so -o t t.c -O2 -lm -ffast-math

This presently outputs:

/tmp/ccsEVygv.o: In function `main':
t.c:(.text+0x73): undefined reference to `__builtin_iceil'
/tmp/ccsEVygv.o: In function `iceil':
t.c:(.text+0x1): undefined reference to `__builtin_iceil'
collect2: error: ld returned 1 exit status

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 03:52:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 11:52:16 +0000
Subject: [LLVMbugs] [Bug 14271] New: Assertion `N.getNode()->getNodeId() !=
 NewNode && "Mapped to new node!"'
Message-ID: <bug-14271-206@http.llvm.org/bugs/>

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

             Bug #: 14271
           Summary: Assertion `N.getNode()->getNodeId() != NewNode &&
                    "Mapped to new node!"'
           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: antoine.balestrat at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hello !
LLVM/Clang as of r167445 fails to compile the following testcase at -O1 and
higher in 32 bits mode.

$ cat newnode.c
void f(void)
{
    unsigned short a, *p;
    long long b;

    for(;;)
    {
        a = ++b;
        (a *= a || 1 | (b = 0)) && (*p = a + b ? : a == 1);
        p = &b;
    }
}

$ clong -w -O1 -m32 newnode.c
clang:
/home/merkil/git/clang/llvm/lib/CodeGen/SelectionDAG/LegalizeTypes.cpp:618:
void llvm::DAGTypeLegalizer::RemapValue(llvm::SDValue &): Assertion
`N.getNode()->getNodeId() != NewNode && "Mapped to new node!"' failed.
0  clang           0x0000000001aad3ef
1  clang           0x0000000001aad8d3
2  libpthread.so.0 0x00007fb73248a910
3  libc.so.6       0x00007fb7316f3ff5 gsignal + 53
4  libc.so.6       0x00007fb7316f5307 abort + 327
5  libc.so.6       0x00007fb7316ed1b2
6  libc.so.6       0x00007fb7316ed262
7  clang           0x00000000014831bf
8  clang           0x0000000001482d72
9  clang           0x00000000014821cf
10 clang           0x0000000001482256
11 clang           0x0000000001481a82
12 clang           0x0000000001488607 llvm::SelectionDAG::LegalizeTypes() + 423
13 clang           0x0000000001431f29
llvm::SelectionDAGISel::CodeGenAndEmitDAG() + 1433
14 clang           0x00000000014314f6
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 7014
15 clang           0x000000000142edf4
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1156
16 clang           0x0000000001568f94
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 116
17 clang           0x0000000001a12a4b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 443
18 clang           0x0000000001a12cab
llvm::FPPassManager::runOnModule(llvm::Module&) + 155
19 clang           0x0000000001a12f23
llvm::MPPassManager::runOnModule(llvm::Module&) + 419
20 clang           0x0000000001a134a8 llvm::PassManagerImpl::run(llvm::Module&)
+ 408
21 clang           0x0000000001a1360a llvm::PassManager::run(llvm::Module&) +
10
22 clang           0x00000000007a2947
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 5863
23 clang           0x00000000007a03fa
24 clang           0x00000000008d4d05 clang::ParseAST(clang::Sema&, bool, bool)
+ 549
25 clang           0x000000000079f442 clang::CodeGenAction::ExecuteAction() +
178
26 clang           0x0000000000641295 clang::FrontendAction::Execute() + 101
27 clang           0x000000000062332d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 973
28 clang           0x00000000006098a8
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3768
29 clang           0x00000000006009c6 cc1_main(char const**, char const**, char
const*, void*) + 694
30 clang           0x0000000000605a16 main + 3574
31 libc.so.6       0x00007fb7316e0985 __libc_start_main + 245
32 clang           0x000000000060064d
Stack dump:
0.    Program arguments: /home/merkil/git/clang/build/Release+Asserts/bin/clang
-cc1 -triple i386-unknown-linux-gnu -emit-obj -disable-free -main-file-name
newnode.c -mrelocation-model static -fmath-errno -masm-verbose
-mconstructor-aliases -fuse-init-array -target-cpu pentium4
-target-linker-version 2.22.90.20120727 -momit-leaf-frame-pointer -resource-dir
/home/merkil/git/clang/build/Release+Asserts/bin/../lib/clang/3.2
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/local/include -internal-isystem
/home/merkil/git/clang/build/Release+Asserts/bin/../lib/clang/3.2/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O1
-w -fdebug-compilation-dir /home/merkil -ferror-limit 19 -fmessage-length 0
-mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -o
/tmp/newnode-r5qEJB.o -x c newnode.c 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'newnode.c'.
4.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@f'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk 167445)
Target: i386-unknown-linux-gnu

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 04:11:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 12:11:15 +0000
Subject: [LLVMbugs] [Bug 13624] powerpc64 complex return value handling does
 not match PPC64 ELF ABI
In-Reply-To: <bug-13624-206@http.llvm.org/bugs/>
References: <bug-13624-206@http.llvm.org/bugs/>
Message-ID: <bug-13624-206-y1muoih681@http.llvm.org/bugs/>

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

Adhemerval Zanella <azanella at linux.vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |azanella at linux.vnet.ibm.com
         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 Nov  6 04:12:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 12:12:30 +0000
Subject: [LLVMbugs] [Bug 13313] powerpc64 failures running llvmpipe /
	lp_test_* tests
In-Reply-To: <bug-13313-206@http.llvm.org/bugs/>
References: <bug-13313-206@http.llvm.org/bugs/>
Message-ID: <bug-13313-206-I1nCvEtPDX@http.llvm.org/bugs/>

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

Adhemerval Zanella <azanella at linux.vnet.ibm.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  Tue Nov  6 05:39:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 13:39:20 +0000
Subject: [LLVMbugs] [Bug 13624] powerpc64 complex return value handling does
 not match PPC64 ELF ABI
In-Reply-To: <bug-13624-206@http.llvm.org/bugs/>
References: <bug-13624-206@http.llvm.org/bugs/>
Message-ID: <bug-13624-206-oGpEJP5p0T@http.llvm.org/bugs/>

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

Adhemerval Zanella <azanella at linux.vnet.ibm.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
         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 Nov  6 06:12:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 14:12:44 +0000
Subject: [LLVMbugs] [Bug 14272] New: clang crash due to nested static
 initializer list in combination with auto type
Message-ID: <bug-14272-206@http.llvm.org/bugs/>

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

             Bug #: 14272
           Summary: clang crash due to nested static initializer list in
                    combination with auto type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: firzen2510 at freenet.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


==== DESCRIPTION ====
Attempting to initialize a multi-dimensional static field using a nested static
initializer and the auto-type feature results in a clang crash.
A simplified test code as well as the crash backtrace follow.
The crash did not occur with a single-dimensional type like std::vector.
Instead of that clang complained about a redefinition of different type
('std::initializer_list<int>' vs 'std::vector<int>')(which is probably right
according to the standard).
Other types haven't been tested.

==== TEST CODE ====
#include <unordered_map>

class foo
{
        static std::unordered_map<int, int> bar;
};

// std::unordered_map<int, int> foo::bar { { 0, 0 } }; // << WORKS
// decltype(foo::bar) foo::bar { { 0, 0 } }; // << WORKS
auto foo::bar { { 0, 0 } }; // << clang CRASH

int main(void)
{ return 0; }

==== CRASH BACKTRACE ====
clang:
/home/impulze/llvm/tools/clang/lib/Sema/../../include/clang/AST/TemplateBase.h:223:
clang::QualType clang::TemplateArgument::getAsType() const: Assertion `Kind ==
Type && "Unexpected kind"' failed.
0  clang           0x00000000020a838f
1  clang           0x00000000020a88b9
2  libpthread.so.0 0x00002ae36be0c060
3  libc.so.6       0x00002ae36c9f63a5 gsignal + 53
4  libc.so.6       0x00002ae36c9f9b0b abort + 379
5  libc.so.6       0x00002ae36c9eed4d __assert_fail + 221
6  clang           0x0000000000659056
7  clang           0x0000000000d6bbb9
clang::Sema::DeduceAutoType(clang::TypeSourceInfo*, clang::Expr*&,
clang::TypeSourceInfo*&) + 2361
8  clang           0x0000000000b5ada6
clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) +
1334
9  clang           0x0000000000a524e1
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 1745
10 clang           0x0000000000a60f76
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1302
11 clang           0x0000000000a48215
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 245
12 clang           0x0000000000a488e9
13 clang           0x0000000000a4895f
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 31
14 clang           0x0000000000a49cd9
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 105
15 clang           0x0000000000a4a538
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 184
16 clang           0x0000000000a41fed clang::ParseAST(clang::Sema&, bool, bool)
+ 509
17 clang           0x0000000000784f81 clang::FrontendAction::Execute() + 145
18 clang           0x000000000076a5b4
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 340
19 clang           0x0000000000751d76
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1462
20 clang           0x000000000074ac90 cc1_main(char const**, char const**, char
const*, void*) + 1248
21 clang           0x0000000000733783 main + 787
22 libc.so.6       0x00002ae36c9e130d __libc_start_main + 237
23 clang           0x000000000074a64d
Stack dump:
0.      Program arguments: /home/impulze/install/llvm/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
clang_auto_bug.cc -mrelocation-model static -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64
-target-linker-version 2.21.53.20110810 -momit-leaf-frame-pointer -resource-dir
/home/impulze/install/llvm/bin/../lib/clang/3.2 -I /home/impulze/libcxx/include
-I /home/impulze/install/boost-1.51.0/include -fmodule-cache-path
/var/tmp/clang-module-cache -internal-isystem /usr/include/c++/v1
-internal-isystem /usr/local/include -internal-isystem
/home/impulze/install/llvm/bin/../lib/clang/3.2/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-std=c++11 -fdeprecated-macro -fdebug-compilation-dir
/home/firzen/programming/c++11/clang_auto_bug -ferror-limit 19 -fmessage-length
271 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/clang_auto_bug-luayKr.o
-x c++ clang_auto_bug.cc 
1.      clang_auto_bug.cc:12:27: current parser token ';'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (http://llvm.org/git/clang.git
292d67bb69e878104d2cdc1a1f72264e4fc2852a) (http://llvm.org/git/llvm.git
174fbec3dfdf5e20ad5b75dcfcc709011ddb1a12)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang++: /home/impulze/llvm/include/llvm/ADT/SmallVector.h:143: const T&
llvm::SmallVectorTemplateCommon<T, <template-parameter-1-2>
>::operator[](unsigned int) const [with T = const char*,
<template-parameter-1-2> = void, llvm::SmallVectorTemplateCommon<T,
<template-parameter-1-2> >::const_reference = const char* const&]: Assertion
`begin() + idx < end()' failed.
0  clang++         0x00000000020a838f
1  clang++         0x00000000020a88b9
2  libpthread.so.0 0x00002b41fd814060
3  libc.so.6       0x00002b41fe3fe3a5 gsignal + 53
4  libc.so.6       0x00002b41fe401b0b abort + 379
5  libc.so.6       0x00002b41fe3f6d4d __assert_fail + 221
6  clang++         0x000000000062acc5
7  clang++         0x00000000007e9596
clang::driver::Driver::generateCompilationDiagnostics(clang::driver::Compilation&,
clang::driver::Command const*) + 870
8  clang++         0x00000000007342f4 main + 3716
9  libc.so.6       0x00002b41fe3e930d __libc_start_main + 237
10 clang++         0x000000000074a64d
Stack dump:
0.      Program arguments: /home/impulze/install/llvm/bin/clang++
-I/home/impulze/libcxx/include -L/home/impulze/build-libcxx/lib -stdlib=libc++
-I/home/impulze/install/boost-1.51.0/include
-L/home/impulze/install/boost-1.51.0/lib -std=c++11 clang_auto_bug.cc -lstdc++
-lsupc++ -Wl,-rpath,/home/impulze/build-libcxx/lib
-Wl,-rpath,/home/impulze/install/boost-1.51.0/lib -Qunused-arguments

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 07:23:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 15:23:16 +0000
Subject: [LLVMbugs] [Bug 14270] Support for __builtin_iceil() is missing in
	dragonegg
In-Reply-To: <bug-14270-206@http.llvm.org/bugs/>
References: <bug-14270-206@http.llvm.org/bugs/>
Message-ID: <bug-14270-206-igKrtAKA88@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2012-11-06 09:23:16 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155252.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 Nov  6 08:23:57 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 16:23:57 +0000
Subject: [LLVMbugs] [Bug 14273] New: sizeof... in return type causes segfault
Message-ID: <bug-14273-206@http.llvm.org/bugs/>

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

             Bug #: 14273
           Summary: sizeof... in return type causes segfault
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Using sizeof... in the return type of a function with variadic arguments
segfaults. See the following code example, reduced from a simple
'make_std_array' function. As you can see, if I use a template to calculate the
size of the variadic arguments, rather than sizeof..., then the code works
fine.

Broken in today's svn.


template<typename T, int i>
struct myType
{ };

template<typename T, typename... Args>
struct Counter
{
  static const int count = 1 + Counter<Args...>::count;
};

template<typename T>
struct Counter<T>
{
  static const int count = 1;
};

// This works fine.
template<typename Arg, typename... Args>
myType<Arg, Counter<Args...>::count>* make_array_with_type_with_counter(const
Args&... args)
{
    return 0;
}

// This segfaults
template<typename Arg, typename... Args>
myType<Arg, sizeof...(Args)>* make_array_with_type(const Args&... args)
{
    return 0;
}


int main(void)
{
     make_array_with_type<char>(1,2,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  Tue Nov  6 09:15:42 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 17:15:42 +0000
Subject: [LLVMbugs] [Bug 8772] debugging info for subroutine type with
 multiple returns is wrong
In-Reply-To: <bug-8772-206@http.llvm.org/bugs/>
References: <bug-8772-206@http.llvm.org/bugs/>
Message-ID: <bug-8772-206-rZutAHKGaO@http.llvm.org/bugs/>

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

Brian G. Lucas <bagel99 at gmail.com> changed:

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

--- Comment #4 from Brian G. Lucas <bagel99 at gmail.com> 2012-11-06 11:15:42 CST ---
No longer applicable.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 11:51:58 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 19:51:58 +0000
Subject: [LLVMbugs] [Bug 13288] Crash on invalid
In-Reply-To: <bug-13288-206@http.llvm.org/bugs/>
References: <bug-13288-206@http.llvm.org/bugs/>
Message-ID: <bug-13288-206-8DIhbxinUW@http.llvm.org/bugs/>

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

Jason Haslam <jason.haslam at gmail.com> changed:

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

--- Comment #2 from Jason Haslam <jason.haslam at gmail.com> 2012-11-06 13:51:58 CST ---
Test case no longer crashes in TOT. Closing 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  Tue Nov  6 11:57:24 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 19:57:24 +0000
Subject: [LLVMbugs] [Bug 14274] New: double free or corruption with lamba
 expression in template using libstdc++
Message-ID: <bug-14274-206@http.llvm.org/bugs/>

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

             Bug #: 14274
           Summary: double free or corruption with lamba expression in
                    template using libstdc++
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: markus at trippelsdorf.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider (testcase from http://gcc.gnu.org/bugzilla/show_bug.cgi?id=55223):

markus at x4 tmp % cat lamb.cpp
#include <iostream>
#include <functional>

template<typename T> struct C
{
    static T test(std::function<T(int)> f = [](int i){return i;})
    {return f(42);}
};

int main()
{
    C<int>::test();
    return 0;
}

markus at x4 tmp % clang++ -std=c++11 lamb.cpp
*** Error in `/usr/local/bin/clang': double free or corruption (out):
0x00000000023790a0 ***
======= Backtrace: =========
/lib/libc.so.6(+0x79046)[0x7f2943672046]
/lib/libc.so.6(+0x79d27)[0x7f2943672d27]
/usr/local/bin/clang[0x89f32b]
/usr/local/bin/clang(_ZN5clang4Sema30PopExpressionEvaluationContextEv+0x215)[0x9a67f5]
/usr/local/bin/clang(_ZN5clang4Sema22BuildCXXDefaultArgExprENS_14SourceLocationEPNS_12FunctionDeclEPNS_11ParmVarDeclE+0x41f)[0x99201f]
/usr/local/bin/clang(_ZN5clang4Sema22GatherArgumentsForCallENS_14SourceLocationEPNS_12FunctionDeclEPKNS_17FunctionProtoTypeEjPPNS_4ExprEjRN4llvm11SmallVectorIS8_Lj8EEENS0_16V
ariadicCallTypeEb+0x1d6)[0x992af6]
/usr/local/bin/clang(_ZN5clang4Sema23ConvertArgumentsForCallEPNS_8CallExprEPNS_4ExprEPNS_12FunctionDeclEPKNS_17FunctionProtoTypeEPS4_jNS_14SourceLocationEb+0x300)[0x9924f0]
/usr/local/bin/clang(_ZN5clang4Sema21BuildResolvedCallExprEPNS_4ExprEPNS_9NamedDeclENS_14SourceLocationEPS2_jS5_S2_b+0x731)[0x9939e1]
...
======= Memory map: ========
00400000-0187f000 r-xp 00000000 08:12 35976                             
/usr/local/bin/clang
0187f000-01933000 rw-p 0147f000 08:12 35976                             
/usr/local/bin/clang
01933000-0193d000 rw-p 00000000 00:00 0 
019f0000-023d3000 rw-p 00000000 00:00 0                                  [heap]
7f29435f9000-7f294375d000 r-xp 00000000 08:12 4467637                   
/lib64/libc-2.16.90.so
7f294375d000-7f294395d000 ---p 00164000 08:12 4467637                   
/lib64/libc-2.16.90.so
7f294395d000-7f2943961000 r--p 00164000 08:12 4467637                   
/lib64/libc-2.16.90.so
7f2943961000-7f2943963000 rw-p 00168000 08:12 4467637                   
/lib64/libc-2.16.90.so
7f2943963000-7f2943967000 rw-p 00000000 00:00 0 
7f2943967000-7f2943a52000 r-xp 00000000 08:12 72115136                  
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.0/libstdc++.so.6.0.17
...
0  clang           0x0000000001620b02
1  clang           0x0000000001620e83
2  libpthread.so.0 0x00007f2943f0c250
3  libc.so.6       0x00007f294362df07 gsignal + 55
4  libc.so.6       0x00007f294362f398 abort + 328
5  libc.so.6       0x00007f294366c477
6  libc.so.6       0x00007f2943672046
7  libc.so.6       0x00007f2943672d27
8  clang           0x000000000089f32b
9  clang           0x00000000009a67f5
clang::Sema::PopExpressionEvaluationContext() + 533
10 clang           0x000000000099201f
clang::Sema::BuildCXXDefaultArgExpr(clang::SourceLocation,
clang::FunctionDecl*, clang::ParmVarDecl*) + 1055
11 clang           0x0000000000992af6
clang::Sema::GatherArgumentsForCall(clang::SourceLocation,
clang::FunctionDecl*, clang::FunctionProtoType const*, unsigned int,
clang::Expr**, unsigned int, llvm::SmallVector<clang::Expr*, 8u>&,
clang::Sema::VariadicCallType, bool) + 470
12 clang           0x00000000009924f0
clang::Sema::ConvertArgumentsForCall(clang::CallExpr*, clang::Expr*,
clang::FunctionDecl*, clang::FunctionProtoType const*, clang::Expr**, unsigned
int, clang::SourceLocation, bool) + 768
13 clang           0x00000000009939e1
clang::Sema::BuildResolvedCallExpr(clang::Expr*, clang::NamedDecl*,
clang::SourceLocation, clang::Expr**, unsigned int, clang::SourceLocation,
clang::Expr*, bool) + 1841
14 clang           0x0000000000988f60 clang::Sema::ActOnCallExpr(clang::Scope*,
clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>,
clang::SourceLocation, clang::Expr*, bool) + 1200
15 clang           0x00000000008589e7
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*,
true>) + 2791
16 clang           0x000000000085bdbb clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::Parser::TypeCastState) + 11835
17 clang           0x00000000008567c6
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 118
18 clang           0x0000000000856739
clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 9
19 clang           0x000000000087d918 clang::Parser::ParseExprStatement() + 56
20 clang           0x000000000087d4d3
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&)
+ 2291
21 clang           0x000000000087cb7a
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*) + 154
22 clang           0x00000000008831be
clang::Parser::ParseCompoundStatementBody(bool) + 1614
23 clang           0x0000000000884cbd
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 157
24 clang           0x000000000083072a
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
1914
25 clang           0x000000000083c57b
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1403
26 clang           0x000000000082feba
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 586
27 clang           0x000000000082fa65
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 309
28 clang           0x000000000082ef3f
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 2191
29 clang           0x000000000082e62a
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 314
30 clang           0x000000000082ba46 clang::ParseAST(clang::Sema&, bool, bool)
+ 470
31 clang           0x000000000072a27d clang::CodeGenAction::ExecuteAction() +
77
32 clang           0x00000000005fcebb clang::FrontendAction::Execute() + 91
33 clang           0x00000000005e15ad
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 845
34 clang           0x00000000005cb821
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3505
35 clang           0x00000000005c2ded cc1_main(char const**, char const**, char
const*, void*) + 621
36 clang           0x00000000005c7cac main + 2988
37 libc.so.6       0x00007f294361a885 __libc_start_main + 245
38 clang           0x00000000005c2ab9
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name lamb.cpp -mrelocation-model static
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version
2.23.51.20121009 -momit-leaf-frame-pointer -resource-dir
/usr/local/bin/../lib/clang/3.2 -fmodule-cache-path /var/tmp/clang-module-cache
-I/var/intel/composer_xe_2013.1.117/mkl/include
-I/var/intel/composer_xe_2013.1.117/tbb/include -internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4 -internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/x86_64-pc-linux-gnu
-internal-isystem
/usr/lib64/gcc/x86_64-pc-linux-gnu/4.8.0/include/g++-v4/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/local/bin/../lib/clang/3.2/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro
-fdebug-compilation-dir /var/tmp -ferror-limit 19 -fmessage-length 174
-mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/lamb-tzmWOZ.o -x c++
lamb.cpp 
1.      lamb.cpp:12:18: current parser token ')'
2.      lamb.cpp:11:1: parsing function body 'main'
3.      lamb.cpp:11:1: in compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 
Target: x86_64-unknown-linux-gnu
Thread model: posix

libc++ is fine:
markus at x4 tmp % clang++ -stdlib=libc++ -std=c++11 lamb.cpp
markus at x4 tmp %

(clang was build with --disable-assertions --enable-optimized)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 13:05:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 21:05:02 +0000
Subject: [LLVMbugs] [Bug 14092] hash_map fails to compile
In-Reply-To: <bug-14092-206@http.llvm.org/bugs/>
References: <bug-14092-206@http.llvm.org/bugs/>
Message-ID: <bug-14092-206-gBTzRdTQbZ@http.llvm.org/bugs/>

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

vvavrychuk at gmail.com changed:

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

--- Comment #2 from vvavrychuk at gmail.com 2012-11-06 15:05:02 CST ---
For some reason, now I can not reproduce this too. I suggest to close 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  Tue Nov  6 14:45:00 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 22:45:00 +0000
Subject: [LLVMbugs] [Bug 11480] attribute((init_priority(N))) is not
	codegen'ed properly
In-Reply-To: <bug-11480-206@http.llvm.org/bugs/>
References: <bug-11480-206@http.llvm.org/bugs/>
Message-ID: <bug-11480-206-lyphjpGUTT@http.llvm.org/bugs/>

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

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

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

--- Comment #5 from Anton Korobeynikov <asl at math.spbu.ru> 2012-11-06 16:45:00 CST ---
Fixed in r167496

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 15:57:06 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 06 Nov 2012 23:57:06 +0000
Subject: [LLVMbugs] [Bug 14272] clang crash due to nested static initializer
 list in combination with auto type
In-Reply-To: <bug-14272-206@http.llvm.org/bugs/>
References: <bug-14272-206@http.llvm.org/bugs/>
Message-ID: <bug-14272-206-UUvJzNWhu7@http.llvm.org/bugs/>

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

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> 2012-11-06 17:57:06 CST ---
r167506.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 16:13:00 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 00:13:00 +0000
Subject: [LLVMbugs] [Bug 13552] Wrong end location for C++ "new"
In-Reply-To: <bug-13552-206@http.llvm.org/bugs/>
References: <bug-13552-206@http.llvm.org/bugs/>
Message-ID: <bug-13552-206-23PAVQvpJI@http.llvm.org/bugs/>

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

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> 2012-11-06 18:13:00 CST ---
Fixed in r167507.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 16:37:32 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 00:37:32 +0000
Subject: [LLVMbugs] [Bug 14259] "Should not see dependent types" in
 ASTContext.cpp:1284 executed
In-Reply-To: <bug-14259-206@http.llvm.org/bugs/>
References: <bug-14259-206@http.llvm.org/bugs/>
Message-ID: <bug-14259-206-Y9ZZWRDVTT@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.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 Nov  6 16:38:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 00:38:35 +0000
Subject: [LLVMbugs] [Bug 14275] New: clang tests fail: unknown target triple
 'unknown-apple-darwin8.11.0', expect 'powerpc'
Message-ID: <bug-14275-206@http.llvm.org/bugs/>

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

             Bug #: 14275
           Summary: clang tests fail: unknown target triple
                    'unknown-apple-darwin8.11.0', expect 'powerpc'
           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: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In my latest run of check-clang on powerpc-darwin8 (r167261, patched), a vast
number of test failures report:

error: unknown target triple 'unknown-apple-darwin8.11.0', please use -triple
or -arch

http://www.csl.cornell.edu/~fang/sw/llvm/logs/clang-r167261-nopure-powerpc-darwin8-g++-4.0.1-debug-check.log

For example,
[fangism:src/LLVM-svn/gcc40-cmake-build] fang% bin/clang -emit-llvm -S -O0 -g
/Volumes/Isolde/sources/LLVM-svn/clang/test/CodeGen/2010-02-18-Dbg-VectorType.c
-o -
\-{ static std::string llvm::Triple::normalize(llvm::StringRef)
/-} static std::string llvm::Triple::normalize(llvm::StringRef)
\-{ llvm::Triple::Triple(const llvm::Twine&)
/-} llvm::Triple::Triple(const llvm::Twine&)
\-{ llvm::Triple::Triple(const llvm::Twine&)
/-} llvm::Triple::Triple(const llvm::Twine&)
\-{ static std::string llvm::Triple::normalize(llvm::StringRef)
/-} static std::string llvm::Triple::normalize(llvm::StringRef)
\-{ llvm::Triple::Triple(const llvm::Twine&)
/-} llvm::Triple::Triple(const llvm::Twine&)
\-{ llvm::Triple::Triple(const llvm::Twine&)
/-} llvm::Triple::Triple(const llvm::Twine&)
\-{ llvm::Triple::Triple(const llvm::Twine&)
/-} llvm::Triple::Triple(const llvm::Twine&)
\-{ llvm::Triple::Triple(const llvm::Twine&)
/-} llvm::Triple::Triple(const llvm::Twine&)
\-{ int cc1_main(const char**, const char**, const char*, void*)
| \-{ clang::CompilerInvocationBase::CompilerInvocationBase()
| /-} clang::CompilerInvocationBase::CompilerInvocationBase()
| \-{ clang::CompilerInstance::CompilerInstance()
| /-} clang::CompilerInstance::CompilerInstance()
| \-{ static std::string llvm::Triple::normalize(llvm::StringRef)
| /-} static std::string llvm::Triple::normalize(llvm::StringRef)
| \-{ bool clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
| | \-{ bool clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
| | | \-{ static clang::TargetInfo*
clang::TargetInfo::CreateTargetInfo(clang::DiagnosticsEngine&,
clang::TargetOptions&)
| | | | :  Opts.Triple: unknown-apple-darwin8.11.0
| | | | \-{ llvm::Triple::Triple(const llvm::Twine&)
| | | | /-} llvm::Triple::Triple(const llvm::Twine&)
| | | | \-{ clang::TargetInfo* AllocateTarget(const std::string&)
| | | | | :  arg: unknown-apple-darwin8.11.0
| | | | | \-{ llvm::Triple::Triple(const llvm::Twine&)
| | | | | /-} llvm::Triple::Triple(const llvm::Twine&)
| | | | | :  default -> NULL
| | | | /-} clang::TargetInfo* AllocateTarget(const std::string&)
error: unknown target triple 'unknown-apple-darwin8.11.0', please use -triple
or
      -arch
| | | /-} static clang::TargetInfo*
clang::TargetInfo::CreateTargetInfo(clang::DiagnosticsEngine&,
clang::TargetOptions&)
| | /-} bool clang::CompilerInstance::ExecuteAction(clang::FrontendAction&)
| /-} bool clang::ExecuteCompilerInvocation(clang::CompilerInstance*)
/-} int cc1_main(const char**, const char**, const char*, void*)

I'm trying to track down where things went wrong.
Either in or before Triple::normalize()...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 17:03:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 01:03:49 +0000
Subject: [LLVMbugs] [Bug 14276] New: Example for running individual test
 with llvm-lit uses BitCast.ll, which was removed in r133244
Message-ID: <bug-14276-206@http.llvm.org/bugs/>

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

             Bug #: 14276
           Summary: Example for running individual test with llvm-lit uses
                    BitCast.ll, which was removed in r133244
           Product: Documentation
           Version: trunk
          Platform: Other
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: flash at pobox.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The example in http://llvm.org/docs/TestingGuide.html#quickregressiontests for
running an individual test is 

% llvm-lit ~/llvm/test/Integer/BitCast.ll 

but BitCast.ll was removed in r133244, with the comment that “…this isn't
pascal anymore.”  I’d suggest substituting BitPacked.ll, which works.  (I’d
also suggest replacing “~/llvm/…”, perhaps with just “llvm/…“, like a few lines
earlier.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 17:15:52 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 01:15:52 +0000
Subject: [LLVMbugs] [Bug 11851] clang doesn't instantiate constexpr
 functions where necessary during overload resolution
In-Reply-To: <bug-11851-206@http.llvm.org/bugs/>
References: <bug-11851-206@http.llvm.org/bugs/>
Message-ID: <bug-11851-206-6OlNgUdVp9@http.llvm.org/bugs/>

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

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

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

--- Comment #11 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-06 19:15:52 CST ---
Fixed, or at least worked around, in r167514. The core working group hasn't
established a firm direction on how to behave here, but our behavior is now a
very close match for g++'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 Nov  6 21:45:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 05:45:16 +0000
Subject: [LLVMbugs] [Bug 14277] New: asan crash
Message-ID: <bug-14277-206@http.llvm.org/bugs/>

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

             Bug #: 14277
           Summary: asan crash
           Product: compiler-rt
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Nicos-MacBook-Pro:delta thakis$ cat repro.ii
void __asan_report_load1() { }
Nicos-MacBook-Pro:delta thakis$
~/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang -x c
-fsanitize=address repro.ii
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 208.
0  clang             0x00000001016d4b45 PrintStackTrace(void*) + 37
1  clang             0x00000001016d4f54 SignalHandler(int) + 564
2  libsystem_c.dylib 0x00007fff9257c8ea _sigtramp + 26
3  libsystem_c.dylib 0x00007fff925ad7d6 szone_free_definite_size + 2013
4  clang             0x000000010004faf6 abort + 22
5  clang             0x000000010004fad1 __assert_rtn + 81
6  clang             0x0000000100c17bbd (anonymous
namespace)::AddressSanitizer::doInitialization(llvm::Module&) + 3197
7  clang             0x0000000101687978
llvm::FPPassManager::runOnModule(llvm::Module&) + 104
8  clang             0x0000000101687bb1
llvm::MPPassManager::runOnModule(llvm::Module&) + 305
9  clang             0x00000001016881a5
llvm::PassManagerImpl::run(llvm::Module&) + 437
10 clang             0x000000010168834d llvm::PassManager::run(llvm::Module&) +
13
11 clang             0x00000001001e018a
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 5178
12 clang             0x00000001002c3ca8
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 600
13 clang             0x0000000100300ed4 clang::ParseAST(clang::Sema&, bool,
bool) + 516
14 clang             0x00000001002c29ea clang::CodeGenAction::ExecuteAction() +
458
15 clang             0x00000001000b2938 clang::FrontendAction::Execute() + 104
16 clang             0x000000010009446d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 941
17 clang             0x000000010005a61a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3450
18 clang             0x0000000100052c48 cc1_main(char const**, char const**,
char const*, void*) + 840
19 clang             0x0000000100056e75 main + 3077
20 clang             0x00000001000528d4 start + 52
21 clang             0x000000000000002b start + 18446744069414246283
Stack dump:
0.    Program arguments:
/Users/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/clang
-cc1 -triple x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free
-main-file-name repro.ii -pic-level 2 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 97.17 -resource-dir
/Users/thakis/src/chrome/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.2
-fmodule-cache-path
/var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/clang-module-cache
-fdebug-compilation-dir /Users/thakis/src/delta -ferror-limit 19
-fmessage-length 187 -fsanitize=address -stack-protector 1 -mstackrealign
-fblocks -fobjc-runtime=macosx-10.8.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fdiagnostics-show-option
-fcolor-diagnostics -o
/var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/repro-TkrI8n.o -x c repro.ii 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'Function Pass Manager' on module 'repro.ii'.
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk 167488)
Target: x86_64-apple-darwin12.2.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg:
/var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/repro-UOLOsL.c
clang: note: diagnostic msg:
/var/folders/c5/8d7sdn1x2mg92mj0rndghhdr0000gn/T/repro-UOLOsL.sh
clang: note: diagnostic msg: 

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 22:12:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 06:12:11 +0000
Subject: [LLVMbugs] [Bug 14278] New: LLVM test failures:
 AllocationTests/MappedMemoryTest.* [powerpc-darwin8]
Message-ID: <bug-14278-206@http.llvm.org/bugs/>

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

             Bug #: 14278
           Summary: LLVM test failures: AllocationTests/MappedMemoryTest.*
                    [powerpc-darwin8]
           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: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


After some patching, the only remaining failures on powerpc-darwin8 in LLVM's
tests are AllocationTests/MappedMemoryTest* (10).

http://www.csl.cornell.edu/~fang/sw/llvm/logs/llvm-r167261-powerpc-darwin8-g++-4.0.1-debug-check.log


FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.BasicWrite/1 (6512
of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.BasicWrite/1'
FAILED ********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.BasicWrite/1
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.BasicWrite/1

********************
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.AllocAndRelease/3
(6513 of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.AllocAndRelease/3'
FAILED ********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.AllocAndRelease/3
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.AllocAndRelease/3

********************
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.BasicWrite/2 (6514
of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.BasicWrite/3 (6515
of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.BasicWrite/4 (6516
of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.BasicWrite/5 (6517
of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.DuplicateNear/0
(6518 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.DuplicateNear/1
(6519 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.DuplicateNear/2
(6520 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.DuplicateNear/4
(6521 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.DuplicateNear/5
(6522 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/0
(6523 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/1
(6524 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/2
(6525 of 6776)
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.DuplicateNear/3
(6526 of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.DuplicateNear/3'
FAILED ********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.DuplicateNear/3
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.DuplicateNear/3

********************
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/4
(6527 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/5
(6528 of 6776)
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/3
(6529 of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.EnabledWrite/3'
FAILED ********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.EnabledWrite/3
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.EnabledWrite/3

********************
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/0
(6530 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/1
(6531 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/2
(6532 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/4
(6533 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/5
(6534 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleWrite/0
(6535 of 6776)
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/3
(6536 of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/3'
FAILED ********************
Note: Google Test filter =
AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/3
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.MultipleAllocAndRelease/3

********************
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleWrite/2
(6537 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleWrite/3
(6538 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleWrite/4
(6539 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleWrite/5
(6540 of 6776)
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleWrite/1
(6541 of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.MultipleWrite/1'
FAILED ********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.MultipleWrite/1
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.MultipleWrite/1

********************
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.SuccessiveNear/0
(6542 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.SuccessiveNear/1
(6543 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.SuccessiveNear/2
(6544 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.SuccessiveNear/4
(6545 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.SuccessiveNear/5
(6546 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.UnalignedNear/0
(6547 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.UnalignedNear/1
(6548 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.UnalignedNear/2
(6549 of 6776)
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.SuccessiveNear/3
(6550 of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.SuccessiveNear/3'
FAILED ********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.SuccessiveNear/3
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.SuccessiveNear/3

********************
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.UnalignedNear/4
(6551 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.UnalignedNear/5
(6552 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroNear/0 (6553 of
6776)
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.UnalignedNear/3
(6554 of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.UnalignedNear/3'
FAILED ********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.UnalignedNear/3
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.UnalignedNear/3

********************
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroNear/1 (6555 of
6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroNear/2 (6556 of
6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroNear/4 (6557 of
6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroNear/5 (6558 of
6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroSizeNear/0
(6559 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroSizeNear/1
(6560 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroSizeNear/2
(6561 of 6776)
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroNear/3 (6562 of
6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroNear/3' FAILED
********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.ZeroNear/3
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.ZeroNear/3

********************
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroSizeNear/4
(6563 of 6776)
PASS: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroSizeNear/5
(6564 of 6776)
PASS: LLVM-Unit :: Support/Debug/SupportTests/AllocatorTest.Basics (6565 of
6776)
PASS: LLVM-Unit :: Support/Debug/SupportTests/AllocatorTest.TestAlignment (6566
of 6776)
FAIL: LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroSizeNear/3
(6567 of 6776)
******************** TEST 'LLVM-Unit ::
Support/Debug/SupportTests/AllocationTests/MappedMemoryTest.ZeroSizeNear/3'
FAILED ********************
Note: Google Test filter = AllocationTests/MappedMemoryTest.ZeroSizeNear/3
[==========] Running 1 test from 1 test case.
[----------] Global test environment set-up.
[----------] 1 test from AllocationTests/MappedMemoryTest
[ RUN      ] AllocationTests/MappedMemoryTest.ZeroSizeNear/3

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


Suggestions for where I should begin to look?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  6 22:40:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 06:40:01 +0000
Subject: [LLVMbugs] [Bug 14279] New: mishandling of implicit move in class
 with copy-only member
Message-ID: <bug-14279-206@http.llvm.org/bugs/>

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

             Bug #: 14279
           Summary: mishandling of implicit move in class with copy-only
                    member
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider this:

struct list {
  list() { p = this; }
  list(const list&) { p = this; }

  list *p;
};

struct val {
  val() : b() {}
  val(const val&) = default;
  val(val&&) = default;

  list b;
};

bool f(val &&v) {
  val w(static_cast<val&&>(v));
  return w.b.p == &w.b;
}

int main() {
  return f(val());
}

This program should return 1, since 'list' enforces that 'p == this'. Built
with Clang, it returns 0, because we implement val's move constructor with
memcpy, presumably because we incorrectly think that it's trivial.

This breaks self-host in C++11 mode using libstdc++-4.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  Wed Nov  7 02:18:37 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 10:18:37 +0000
Subject: [LLVMbugs] [Bug 14198] dlopen(/sw/lib/gcc4.7/lib/dragonegg.so,
 10): Symbol not found: __ZTIN4llvm2cl18GenericOptionValueE
In-Reply-To: <bug-14198-206@http.llvm.org/bugs/>
References: <bug-14198-206@http.llvm.org/bugs/>
Message-ID: <bug-14198-206-YTLl9FF7ZI@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #16 from Duncan Sands <baldrick at free.fr> 2012-11-07 04:18:37 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121105/155317.html
This is a workaround for PR14200.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 04:43:53 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 12:43:53 +0000
Subject: [LLVMbugs] [Bug 14277] asan crash
In-Reply-To: <bug-14277-206@http.llvm.org/bugs/>
References: <bug-14277-206@http.llvm.org/bugs/>
Message-ID: <bug-14277-206-uYYPr8kS5z@http.llvm.org/bugs/>

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

Kostya Serebryany <kcc at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kcc at google.com
         Resolution|                            |FIXED

--- Comment #1 from Kostya Serebryany <kcc at google.com> 2012-11-07 06:43:53 CST ---
We should not be asserting on this example, but instead we should report a
fatal error. 

Fixed in 167529 (not sure how to best write a regression test, any ideas?)

Nico, just curious, where did you get this reproducer?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 08:58:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 16:58:02 +0000
Subject: [LLVMbugs] [Bug 14276] Example for running individual test with
 llvm-lit uses BitCast.ll, which was removed in r133244
In-Reply-To: <bug-14276-206@http.llvm.org/bugs/>
References: <bug-14276-206@http.llvm.org/bugs/>
Message-ID: <bug-14276-206-6RqmuLS17P@http.llvm.org/bugs/>

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

Pawel Wodnicki <pawel at 32bitmicro.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 Nov  7 09:06:18 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 17:06:18 +0000
Subject: [LLVMbugs] [Bug 14280] New: warning correct does not handle -Wno
 options correctly
Message-ID: <bug-14280-206@http.llvm.org/bugs/>

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

             Bug #: 14280
           Summary: warning correct does not handle -Wno options correctly
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chris at bubblescope.net
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9504
  --> http://llvm.org/bugs/attachment.cgi?id=9504
Example patch fixing '-Wno' handling

clang does a bad job of giving recommendations on misformed '-Wno' options.
Basically if an option doesn't start with '-Wno-', it can never match a '-Wno-'
option.

Consider:

$ clang++ -Wbrc
clang: warning: unknown warning option '-Wbrc'; did you mean '-Warc'?
$ clang++ -Wno-brc
clang: warning: unknown warning option '-Wno-brc'; did you mean '-Wno-arc'?
$ clang++ -Wnobrc
clang: warning: unknown warning option '-Wnobrc'; did you mean '-Warc'?
$ clang++ -Wnoarc
clang: warning: unknown warning option '-Wnoarc'; did you mean '-Warc'?

I attach a patch which takes an attempt at fixing this problem. However, I
realised that I'm not really 100% sure about quite a few parts of the clang
coding standard, so I suspect this isn't acceptably finished. In particular I'm
worried I'm breaking the internationalisation. In Warnings.cpp, the two terms
diag::warn_unknown_warning_option_suggest and
diag::warn_unknown_negative_warning_option_suggest look identical to me, so I
was tempted to remove one. But, I assume there is a reason for two of them?

However, this patch does give:

$ clang++ -Wnobrc
clang: warning: unknown warning option '-Wnobrc'; did you mean '-Wno-arc'?
$ clang++ -Won-arc
clang: warning: unknown warning option '-Won-arc'; did you mean '-Wno-arc'?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 09:49:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 17:49:26 +0000
Subject: [LLVMbugs] [Bug 14281] New: boost::units::conversion_factor reaches
 UNREACHABLE "Impossible TemplateArgument"
Message-ID: <bug-14281-206@http.llvm.org/bugs/>

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

             Bug #: 14281
           Summary: boost::units::conversion_factor reaches UNREACHABLE
                    "Impossible TemplateArgument"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: llvm+bugs at trds.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Triggering the bug:

#include <iostream>
#include <boost/units/systems/si/plane_angle.hpp>
#include <boost/units/systems/angle/gradians.hpp>
#include <boost/units/conversion.hpp>

int main(int argc, char **argv) {
    using namespace boost::units;
    std::cout << boost::units::conversion_factor(gradian::gradians,si::radians)
<< std::endl;
    return 0;
}

The template stuff in Boost.Units is too heavy for me, I have no idea what the
problem could be. Message from clang was:

Impossible TemplateArgument
UNREACHABLE executed at
/home/ds/devel/llvm/tools/clang/lib/AST/TypeLoc.cpp:325!
0  clang-3.2       0x000000000131a41f
1  clang-3.2       0x000000000131a949
2  libpthread.so.0 0x00002b0802c33cb0
3  libc.so.6       0x00002b080368e425 gsignal + 53
4  libc.so.6       0x00002b0803691b8b abort + 379
5  clang-3.2       0x00000000012e44bc
6  clang-3.2       0x0000000002063878
clang::TemplateSpecializationTypeLoc::initializeArgLocs(clang::ASTContext&,
unsigned int, clang::TemplateArgument const*, clang::TemplateArgumentLocInfo*,
clang::SourceLocation) + 200
7  clang-3.2       0x0000000002063f2b
clang::TypeLoc::initializeImpl(clang::ASTContext&, clang::TypeLoc,
clang::SourceLocation) + 731
8  clang-3.2       0x0000000001f08abe
clang::ASTContext::getTrivialTypeSourceInfo(clang::QualType,
clang::SourceLocation) const + 62
9  clang-3.2       0x0000000001abf820
10 clang-3.2       0x0000000001ac26d9
11 clang-3.2       0x0000000001ac9442
clang::Sema::getMoreSpecializedPartialSpecialization(clang::ClassTemplatePartialSpecializationDecl*,
clang::ClassTemplatePartialSpecializationDecl*, clang::SourceLocation) + 866
12 clang-3.2       0x0000000001afdf90
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 1088
13 clang-3.2       0x0000000001b4d65b
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::Sema::TypeDiagnoser&) + 1307
14 clang-3.2       0x000000000184cf61
clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&,
clang::DeclContext*) + 353
15 clang-3.2       0x0000000001a84039
clang::Sema::CheckTypenameType(clang::ElaboratedTypeKeyword,
clang::SourceLocation, clang::NestedNameSpecifierLoc, clang::IdentifierInfo
const&, clang::SourceLocation) + 217
16 clang-3.2       0x0000000001b03d69
17 clang-3.2       0x0000000001af8f18
18 clang-3.2       0x0000000001af87a6
19 clang-3.2       0x0000000001af9f60
clang::Sema::SubstFunctionDeclType(clang::TypeSourceInfo*,
clang::MultiLevelTemplateArgumentList const&, clang::SourceLocation,
clang::DeclarationName, clang::CXXRecordDecl*, unsigned int) + 1440
20 clang-3.2       0x0000000001b21828
clang::TemplateDeclInstantiator::SubstFunctionType(clang::FunctionDecl*,
llvm::SmallVectorImpl<clang::ParmVarDecl*>&) + 248
21 clang-3.2       0x0000000001b2770d
clang::TemplateDeclInstantiator::VisitFunctionDecl(clang::FunctionDecl*,
clang::TemplateParameterList*) + 317
22 clang-3.2       0x0000000001b26a37 clang::Sema::SubstDecl(clang::Decl*,
clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 119
23 clang-3.2       0x0000000001ae8788
clang::Sema::FinishTemplateArgumentDeduction(clang::FunctionTemplateDecl*,
llvm::SmallVectorImpl<clang::DeducedTemplateArgument>&, unsigned int,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&,
llvm::SmallVectorImpl<clang::Sema::OriginalCallArg> const*) + 2328
24 clang-3.2       0x0000000001aeb0b6
clang::Sema::DeduceTemplateArguments(clang::FunctionTemplateDecl*,
clang::TemplateArgumentListInfo*, llvm::ArrayRef<clang::Expr*>,
clang::FunctionDecl*&, clang::sema::TemplateDeductionInfo&) + 1046
25 clang-3.2       0x0000000001a3e352
clang::Sema::AddTemplateOverloadCandidate(clang::FunctionTemplateDecl*,
clang::DeclAccessPair, clang::TemplateArgumentListInfo*,
llvm::ArrayRef<clang::Expr*>, clang::OverloadCandidateSet&, bool) + 386
26 clang-3.2       0x0000000001a3ffbd
clang::Sema::AddOverloadedCallCandidates(clang::UnresolvedLookupExpr*,
llvm::ArrayRef<clang::Expr*>, clang::OverloadCandidateSet&, bool) + 445
27 clang-3.2       0x0000000001a40236
clang::Sema::buildOverloadedCallSet(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::Expr**, unsigned int,
clang::SourceLocation, clang::OverloadCandidateSet*,
clang::ActionResult<clang::Expr*, true>*) + 310
28 clang-3.2       0x0000000001a40b88
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr**, unsigned
int, clang::SourceLocation, clang::Expr*, bool) + 456
29 clang-3.2       0x0000000001990347 clang::Sema::ActOnCallExpr(clang::Scope*,
clang::Expr*, clang::SourceLocation, llvm::MutableArrayRef<clang::Expr*>,
clang::SourceLocation, clang::Expr*, bool) + 1383
30 clang-3.2       0x0000000001b1103f
31 clang-3.2       0x0000000001b110b6
32 clang-3.2       0x0000000001b0735a
33 clang-3.2       0x0000000001b11453
34 clang-3.2       0x0000000001b07a3b
35 clang-3.2       0x0000000001b1638d
36 clang-3.2       0x0000000001b077ab
37 clang-3.2       0x0000000001b17517
38 clang-3.2       0x0000000001b18bf1
39 clang-3.2       0x0000000001b176bd
40 clang-3.2       0x0000000001b19e7f clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 79
41 clang-3.2       0x0000000001b2ef63
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 803
42 clang-3.2       0x0000000001b2e921
clang::Sema::PerformPendingInstantiations(bool) + 657
43 clang-3.2       0x0000000001b2eff2
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 946
44 clang-3.2       0x0000000001b2e921
clang::Sema::PerformPendingInstantiations(bool) + 657
45 clang-3.2       0x0000000001b2eff2
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 946
46 clang-3.2       0x0000000001b2e921
clang::Sema::PerformPendingInstantiations(bool) + 657
47 clang-3.2       0x000000000183bdf2 clang::Sema::ActOnEndOfTranslationUnit()
+ 466
48 clang-3.2       0x000000000160c4e6
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 374
49 clang-3.2       0x0000000001603edd clang::ParseAST(clang::Sema&, bool, bool)
+ 509
50 clang-3.2       0x000000000153dd51 clang::FrontendAction::Execute() + 145
51 clang-3.2       0x0000000001521ed4
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 340
52 clang-3.2       0x000000000131d7b6
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1462
53 clang-3.2       0x0000000000617730 cc1_main(char const**, char const**, char
const*, void*) + 1248
54 clang-3.2       0x0000000000615dc3 main + 787
55 libc.so.6       0x00002b080367976d __libc_start_main + 237
56 clang-3.2       0x0000000000612ae9
Stack dump:
0.    Program arguments: /usr/local/bin/clang-3.2 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name test_clang.cpp
-mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -momit-leaf-frame-pointer
-ffunction-sections -fdata-sections -coverage-file
/home/ds/src/lpr/build-charon-clang/CMakeFiles/test_clang.dir/test/test_clang.cpp.o
-resource-dir /usr/local/bin/../lib/clang/3.2 -isystem
/usr/lib/x86_64-linux-gnu/wx/include/gtk2-unicode-release-2.8 -isystem
/usr/include/wx-2.8 -isystem /home/ds/src/lpr/modules/be7a/include -isystem
/home/ds/src/lpr/modules/lmfit/lib -isystem
/home/ds/src/lpr/modules/jsoncpp/include -D _FILE_OFFSET_BITS=64 -D
_LARGE_FILES -D __WXGTK__ -D BOOST_FILESYSTEM_VERSION=3 -D BUILD_TYPE_RELEASE
-D NDEBUG -I /usr/local/include -I /home/ds/src/lpr/libs/peak-linux-driver/lib
-I /home/ds/src/lpr/libs/peak-linux-driver/driver -I
/home/ds/src/lpr/libs/gtest/include -I /home/ds/src/lpr/abstract -I
/home/ds/src/lpr/data -I /home/ds/src/lpr/math -I /home/ds/src/lpr/tools -I
/home/ds/src/lpr/hal -I /home/ds/src/lpr/ppm-transform -I
/home/ds/src/lpr/sensors -I /home/ds/src/lpr/gui -I /home/ds/src/lpr/test
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7 -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/x86_64-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.7/../../../../include/c++/4.7/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/local/bin/../lib/clang/3.2/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O3 -Wall -Werror -Wextra
-Wno-unused-parameter -Wpointer-arith -Wwrite-strings -Wno-gnu
-Wno-c99-extensions -Wno-extra-semi -Wno-variadic-macros -Wno-c++11-extensions
-Wunreachable-code -Wno-error=unreachable-code -Winit-self -Wcast-qual
-pedantic -fconst-strings -fdeprecated-macro -fdebug-compilation-dir
/home/ds/src/lpr/build-charon-clang -ferror-limit 19 -fmessage-length 177
-pthread -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
CMakeFiles/test_clang.dir/test/test_clang.cpp.o -x c++
/home/ds/src/lpr/test/test_clang.cpp 
1.    <eof> parser at end of file
2.    /usr/local/include/boost/units/conversion.hpp:176:1: instantiating
function definition 'conversion_factor'
3.    /usr/local/include/boost/units/detail/conversion_impl.hpp:446:17:
instantiating function definition 'value'
4.    /usr/local/include/boost/units/detail/conversion_impl.hpp:317:21:
instantiating function definition 'value'
clang-3: error: unable to execute command: Aborted (core dumped)
clang-3: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk 167528)
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  Wed Nov  7 10:04:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 18:04:16 +0000
Subject: [LLVMbugs] [Bug 14282] New: crash when reading a gch file produced
 by an older clang
Message-ID: <bug-14282-206@http.llvm.org/bugs/>

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

             Bug #: 14282
           Summary: crash when reading a gch file produced by an older
                    clang
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I accidentally didn't delete a gch file when switching my chromium checkout
from clang r 165787 to r167488.

When building a file that used a gch file `-include-pch
obj/third_party/WebKit/Source/WebCore/webcore_platform.WebCorePrefix.h-mm.gch`,
I got this crash:

Assertion failed: (begin() + idx < end()), function operator[], file
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/include/llvm/ADT/SmallVector.h,
line 139.
0  clang             0x00000001016d4b45 PrintStackTrace(void*) + 37
1  clang             0x00000001016d4f54 SignalHandler(int) + 564
2  libsystem_c.dylib 0x00007fff9257c8ea _sigtramp + 26
3  libsystem_c.dylib 0x00007fff5fbf7f60 _sigtramp + 18446744072860710544
4  clang             0x000000010004faf6 abort + 22
5  clang             0x000000010004fad1 __assert_rtn + 81
6  clang             0x0000000100143bad
clang::ASTReader::ReadASTBlock(clang::serialization::ModuleFile&) + 18733
7  clang             0x00000001001458af clang::ASTReader::ReadAST(std::string
const&, clang::serialization::ModuleKind, unsigned int) + 191
8  clang             0x000000010009227f
clang::CompilerInstance::createPCHExternalASTSource(llvm::StringRef,
std::string const&, bool, bool, clang::Preprocessor&, clang::ASTContext&,
void*, bool) + 223
9  clang             0x00000001000920f4
clang::CompilerInstance::createPCHExternalASTSource(llvm::StringRef, bool,
bool, void*) + 148
10 clang             0x00000001000b26d7
clang::FrontendAction::BeginSourceFile(clang::CompilerInstance&,
clang::FrontendInputFile const&) + 3767
11 clang             0x0000000100094461
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 929
12 clang             0x000000010005a61a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3450
13 clang             0x0000000100052c48 cc1_main(char const**, char const**,
char const*, void*) + 840
14 clang             0x0000000100056e75 main + 3077
15 clang             0x00000001000528d4 start + 52
16 clang             0x00000000000002f1 start + 18446744069414246993


I thought gch files should have a version header to just error out in this
case?

(Sorry, no 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  Wed Nov  7 11:08:28 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 19:08:28 +0000
Subject: [LLVMbugs] [Bug 12713] Unbalanced decltype crashes the frontend
In-Reply-To: <bug-12713-206@http.llvm.org/bugs/>
References: <bug-12713-206@http.llvm.org/bugs/>
Message-ID: <bug-12713-206-zSIqXQiJEM@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #2 from David Blaikie <dblaikie at gmail.com> 2012-11-07 13:08:28 CST ---
Fixed in r167547

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 13:11:05 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 21:11:05 +0000
Subject: [LLVMbugs] [Bug 14283] New: assertion fail:
 VMCore/Instructions.cpp:1080 "Ptr must be a pointer to Val type!"
 [powerpc-darwin8]
Message-ID: <bug-14283-206@http.llvm.org/bugs/>

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

             Bug #: 14283
           Summary: assertion fail: VMCore/Instructions.cpp:1080 "Ptr must
                    be a pointer to Val type!" [powerpc-darwin8]
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Among the remaining powerpc-darwin8 test failures, I see several with this
assertion failure.

******************** TEST 'Clang :: CodeGen/2004-06-17-UnorderedBuiltins.c'
FAILED ********************
Script:
--
gtimeout 5m  /Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./clang -cc1
-internal-isystem
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/../lib/clang/3.2/include
-emit-llvm
/Volumes/Isolde/sources/LLVM-svn/clang/test/CodeGen/2004-06-17-UnorderedBuiltins.c
 -o /dev/null
--
Exit Code: 134
Command Output (stderr):
--
/Users/fang/local/src/LLVM-svn/llvm/lib/VMCore/Instructions.cpp:1080: failed
assertion `getOperand(0)->getType() ==
cast<PointerType>(getOperand(1)->getType())->getElementType() && "Ptr must be a
pointer to Val type!"'
Stack dump:
0.    Program arguments:
/Users/fang/local/src/LLVM-svn/gcc40-cmake-build/bin/./clang -cc1
-internal-isystem
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/../lib/clang/3.2/include
-emit-llvm
/Volumes/Isolde/sources/LLVM-svn/clang/test/CodeGen/2004-06-17-UnorderedBuiltins.c
-o /dev/null 
1.   
/Volumes/Isolde/sources/LLVM-svn/clang/test/CodeGen/2004-06-17-UnorderedBuiltins.c:15:1:
current parser token 'void'
2.   
/Volumes/Isolde/sources/LLVM-svn/clang/test/CodeGen/2004-06-17-UnorderedBuiltins.c:5:6:
LLVM IR generation of declaration 'TestF'
3.   
/Volumes/Isolde/sources/LLVM-svn/clang/test/CodeGen/2004-06-17-UnorderedBuiltins.c:5:6:
Generating code for declaration 'TestF'
4.   
/Volumes/Isolde/sources/LLVM-svn/clang/test/CodeGen/2004-06-17-UnorderedBuiltins.c:5:30:
LLVM IR generation of compound statement ('{}')
--

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

Anyone have a hunch on what might have gone wrong?

complete test log:
http://www.csl.cornell.edu/~fang/sw/llvm/logs/clang-r167261.1-powerpc-darwin8-g++-4.0.1-debug-check.log

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 13:30:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 21:30:09 +0000
Subject: [LLVMbugs] [Bug 14284] New: Returning NULL from void-returning
 function crashes fixit in getScalarZeroExpressionForType()
Message-ID: <bug-14284-206@http.llvm.org/bugs/>

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

             Bug #: 14284
           Summary: Returning NULL from void-returning function crashes
                    fixit in getScalarZeroExpressionForType()
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: avi at drissman.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang version 3.2 (trunk 167488)
Target: i386-apple-darwin12.2.0
Thread model: posix

I altered a base class function TabStripModelDelegate::AddBlankTabAt to return
void, and altered the overriding class's function declaration to return void.
In the definition I forgot to remove the "return null". Clang crashed.

I'm attaching the pre-processed source and run script as instructed.

---8<---

box-o-bits:src$ ninja -C out/Debug all
ninja: Entering directory `out/Debug'
[152/17/116] CXX obj/chrome/browser/ui..._tests.test_tab_strip_model_delegate.o
FAILED: ../../third_party/llvm-build/Release+Asserts/bin/clang++ -MMD -MF
obj/chrome/browser/ui/tabs/unit_tests.test_tab_strip_model_delegate.o.d
-DCHROMIUM_BUILD -DUSE_LIBJPEG_TURBO=1 -DENABLE_ONE_CLICK_SIGNIN
-DENABLE_REMOTING=1 -DENABLE_WEBRTC=1 -DENABLE_CONFIGURATION_POLICY
-DENABLE_INPUT_SPEECH -DENABLE_NOTIFICATIONS -DENABLE_HIDPI=1 -DENABLE_GPU=1
-DENABLE_EGLIMAGE=1 -DUSE_SKIA=1 -DENABLE_TASK_MANAGER=1 -DENABLE_WEB_INTENTS=1
-DENABLE_EXTENSIONS=1 -DENABLE_PLUGIN_INSTALLATION=1
-DENABLE_PROTECTOR_SERVICE=1 -DENABLE_SESSION_SERVICE=1 -DENABLE_THEMES=1
-DENABLE_BACKGROUND=1 -DENABLE_AUTOMATION=1 -DENABLE_LANGUAGE_DETECTION=1
-DENABLE_PRINTING=1 -DENABLE_CAPTIVE_PORTAL_DETECTION=1 -DCLD_WINDOWS
-DENABLE_SAFE_BROWSING -DUSE_OFFICIAL_GOOGLE_API_KEYS=1
-DGOOGLE_PROTOBUF_NO_RTTI -DGOOGLE_PROTOBUF_NO_STATIC_INITIALIZER
-DNACL_WINDOWS=0 -DNACL_LINUX=0 -DNACL_OSX=1 -DNACL_TARGET_SUBARCH=32
-DNACL_TARGET_ARCH=x86 -DNACL_BUILD_SUBARCH=32 -DNACL_BUILD_ARCH=x86
-DUNIT_TEST -DGTEST_HAS_RTTI=0 -DSK_BUILD_NO_IMAGE_ENCODE
-DSK_DEFERRED_CANVAS_USES_GPIPE=1
'-DGR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h"'
-DGR_AGGRESSIVE_SHADER_OPTS=1 -DSK_USE_POSIX_THREADS -DCOMPILER_GCC
-DU_USING_ICU_NAMESPACE=0 -DU_STATIC_IMPLEMENTATION -DFEATURE_ENABLE_SSL
-DFEATURE_ENABLE_VOICEMAIL -DEXPAT_RELATIVE_PATH -DGTEST_RELATIVE_PATH
-DJSONCPP_RELATIVE_PATH -DNO_MAIN_THREAD_WRAPPING -DNO_SOUND_SYSTEM -DOSX
-DPOSIX -DXML_STATIC -DLIBXML_STATIC -D__STDC_FORMAT_MACROS
-DDYNAMIC_ANNOTATIONS_ENABLED=1 -DWTF_USE_DYNAMIC_ANNOTATIONS=1 -D_DEBUG
-I../../third_party/icu/public/common -I../../third_party/icu/public/i18n
-I../.. -I../../third_party/GTM -I../../third_party/GTM/AppKit
-I../../third_party/khronos -Igen/protoc_out -I../../third_party/protobuf
-I../../third_party/protobuf/src -I../../testing/gmock/include
-I../../testing/gtest/include -Igen/policy
-I../../third_party/cacheinvalidation/google/cacheinvalidation
-I../../skia/config -I../../third_party/skia/src/core
-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/gpu/gl
-I../../third_party/skia/include/pipe -I../../third_party/skia/include/ports
-I../../third_party/skia/include/utils -I../../skia/ext
-I../../third_party/skia/include/utils/mac -I../../third_party/bzip2
-I../../third_party/cacheinvalidation/overrides
-I../../third_party/cacheinvalidation/src -I../../third_party/cld
-I../../third_party/leveldatabase/src/include
-I../../third_party/leveldatabase/src -I../../third_party/libjingle/overrides
-I../../third_party/libjingle/source -I../../third_party
-I../../third_party/webrtc -I../../third_party/expat/files/lib
-I../../third_party/jsoncpp/overrides/include
-I../../third_party/jsoncpp/source/include
-I../../third_party/libxml/mac/include -I../../third_party/libxml/src/include
-Igen -I../../third_party/mesa/MesaLib/include -Igen/ui/gl
-Igen/ui/ui_resources -I../../v8/include -Igen/chrome
-I../../third_party/ocmock -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
-O0 -gdwarf-2 -fvisibility=hidden -Werror -Wnewline-eof
-mmacosx-version-min=10.6 -arch i386 -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++11-extensions -Wno-covered-switch-default -fno-rtti -fno-exceptions
-fvisibility-inlines-hidden -fno-threadsafe-statics -Xclang -load -Xclang
/Users/avi/Source/chrome-git/src/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib
-Xclang -add-plugin -Xclang find-bad-constructs -Xclang
-plugin-arg-find-bad-constructs -Xclang skip-virtuals-in-implementations
-fcolor-diagnostics -fno-strict-aliasing -fstack-protector-all  -c
../../chrome/browser/ui/tabs/test_tab_strip_model_delegate.cc -o
obj/chrome/browser/ui/tabs/unit_tests.test_tab_strip_model_delegate.o
../../chrome/browser/ui/tabs/test_tab_strip_model_delegate.cc:21:3: error: void
function 'AddBlankTabAt' should not return a value [-Wreturn-type]
  return NULL;
  ^      ~~~~
Assertion failed: (T.isScalarType() && "use scalar types only"), function
getScalarZeroExpressionForType, file
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/lib/Sema/SemaFixItUtils.cpp,
line 168.
0  clang             0x00000001016d4b45 PrintStackTrace(void*) + 37
1  clang             0x00000001016d4f54 SignalHandler(int) + 564
2  libsystem_c.dylib 0x00007fff871778ea _sigtramp + 26
3  clang             0x0000000101d62728 llvm::errs()::S + 0
4  clang             0x000000010004faf6 abort + 22
5  clang             0x000000010004fad1 __assert_rtn + 81
6  clang             0x0000000100533ef5
getScalarZeroExpressionForType(clang::Type const&, clang::Sema const&) + 597
7  clang             0x00000001005340c4
clang::Sema::getFixItZeroLiteralForType(clang::QualType) const + 36
8  clang             0x00000001003d1445 (anonymous
namespace)::CheckImplicitConversion(clang::Sema&, clang::Expr*,
clang::QualType, clang::SourceLocation, bool*) + 2309
9  clang             0x00000001003cc24f (anonymous
namespace)::AnalyzeImplicitConversions(clang::Sema&, clang::Expr*,
clang::SourceLocation) + 703
10 clang             0x00000001005a9f8c
clang::Sema::ActOnReturnStmt(clang::SourceLocation, clang::Expr*) + 1884
11 clang             0x000000010035ca59 clang::Parser::ParseReturnStatement() +
505
12 clang             0x0000000100357ea6
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&)
+ 2838
13 clang             0x00000001003572fa
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*) + 154
14 clang             0x000000010035e7ac
clang::Parser::ParseCompoundStatementBody(bool) + 1628
15 clang             0x000000010036055b
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 171
16 clang             0x000000010036ff20
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
2064
17 clang             0x000000010030e0bc
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 1388
18 clang             0x000000010036f5b6
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 678
19 clang             0x000000010036f011
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 353
20 clang             0x000000010036e553
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 2835
21 clang             0x000000010036d9c4
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 308
22 clang             0x0000000100300e86 clang::ParseAST(clang::Sema&, bool,
bool) + 438
23 clang             0x00000001002c29ea clang::CodeGenAction::ExecuteAction() +
458
24 clang             0x00000001000b2938 clang::FrontendAction::Execute() + 104
25 clang             0x000000010009446d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 941
26 clang             0x000000010005a61a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3450
27 clang             0x0000000100052c48 cc1_main(char const**, char const**,
char const*, void*) + 840
28 clang             0x0000000100056e75 main + 3077
29 clang             0x00000001000528d4 start + 52
Stack dump:
0.    Program arguments:
/Users/avi/Source/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang
-cc1 -triple i386-apple-macosx10.6.0 -emit-obj -mrelax-all -disable-free
-main-file-name test_tab_strip_model_delegate.cc -pic-level 2 -mdisable-fp-elim
-relaxed-aliasing -masm-verbose -target-cpu yonah -target-linker-version 97.17
-g -coverage-file
/Users/avi/Source/chrome-git/src/out/Debug/obj/chrome/browser/ui/tabs/unit_tests.test_tab_strip_model_delegate.o
-resource-dir
/Users/avi/Source/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.2
-dependency-file
obj/chrome/browser/ui/tabs/unit_tests.test_tab_strip_model_delegate.o.d -MT
obj/chrome/browser/ui/tabs/unit_tests.test_tab_strip_model_delegate.o -isysroot
/Applications/Xcode.app/Contents/Developer/Platforms/MacOSX.platform/Developer/SDKs/MacOSX10.7.sdk
-D CHROMIUM_BUILD -D USE_LIBJPEG_TURBO=1 -D ENABLE_ONE_CLICK_SIGNIN -D
ENABLE_REMOTING=1 -D ENABLE_WEBRTC=1 -D ENABLE_CONFIGURATION_POLICY -D
ENABLE_INPUT_SPEECH -D ENABLE_NOTIFICATIONS -D ENABLE_HIDPI=1 -D ENABLE_GPU=1
-D ENABLE_EGLIMAGE=1 -D USE_SKIA=1 -D ENABLE_TASK_MANAGER=1 -D
ENABLE_WEB_INTENTS=1 -D ENABLE_EXTENSIONS=1 -D ENABLE_PLUGIN_INSTALLATION=1 -D
ENABLE_PROTECTOR_SERVICE=1 -D ENABLE_SESSION_SERVICE=1 -D ENABLE_THEMES=1 -D
ENABLE_BACKGROUND=1 -D ENABLE_AUTOMATION=1 -D ENABLE_LANGUAGE_DETECTION=1 -D
ENABLE_PRINTING=1 -D ENABLE_CAPTIVE_PORTAL_DETECTION=1 -D CLD_WINDOWS -D
ENABLE_SAFE_BROWSING -D USE_OFFICIAL_GOOGLE_API_KEYS=1 -D
GOOGLE_PROTOBUF_NO_RTTI -D GOOGLE_PROTOBUF_NO_STATIC_INITIALIZER -D
NACL_WINDOWS=0 -D NACL_LINUX=0 -D NACL_OSX=1 -D NACL_TARGET_SUBARCH=32 -D
NACL_TARGET_ARCH=x86 -D NACL_BUILD_SUBARCH=32 -D NACL_BUILD_ARCH=x86 -D
UNIT_TEST -D GTEST_HAS_RTTI=0 -D SK_BUILD_NO_IMAGE_ENCODE -D
SK_DEFERRED_CANVAS_USES_GPIPE=1 -D
GR_GL_CUSTOM_SETUP_HEADER="GrGLConfig_chrome.h" -D GR_AGGRESSIVE_SHADER_OPTS=1
-D SK_USE_POSIX_THREADS -D COMPILER_GCC -D U_USING_ICU_NAMESPACE=0 -D
U_STATIC_IMPLEMENTATION -D FEATURE_ENABLE_SSL -D FEATURE_ENABLE_VOICEMAIL -D
EXPAT_RELATIVE_PATH -D GTEST_RELATIVE_PATH -D JSONCPP_RELATIVE_PATH -D
NO_MAIN_THREAD_WRAPPING -D NO_SOUND_SYSTEM -D OSX -D POSIX -D XML_STATIC -D
LIBXML_STATIC -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 ../../third_party/GTM -I
../../third_party/GTM/AppKit -I ../../third_party/khronos -I gen/protoc_out -I
../../third_party/protobuf -I ../../third_party/protobuf/src -I
../../testing/gmock/include -I ../../testing/gtest/include -I gen/policy -I
../../third_party/cacheinvalidation/google/cacheinvalidation -I
../../skia/config -I ../../third_party/skia/src/core -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/gpu/gl -I
../../third_party/skia/include/pipe -I ../../third_party/skia/include/ports -I
../../third_party/skia/include/utils -I ../../skia/ext -I
../../third_party/skia/include/utils/mac -I ../../third_party/bzip2 -I
../../third_party/cacheinvalidation/overrides -I
../../third_party/cacheinvalidation/src -I ../../third_party/cld -I
../../third_party/leveldatabase/src/include -I
../../third_party/leveldatabase/src -I ../../third_party/libjingle/overrides -I
../../third_party/libjingle/source -I ../../third_party -I
../../third_party/webrtc -I ../../third_party/expat/files/lib -I
../../third_party/jsoncpp/overrides/include -I
../../third_party/jsoncpp/source/include -I
../../third_party/libxml/mac/include -I ../../third_party/libxml/src/include -I
gen -I ../../third_party/mesa/MesaLib/include -I gen/ui/gl -I
gen/ui/ui_resources -I ../../v8/include -I gen/chrome -I
../../third_party/ocmock -fmodule-cache-path
/var/folders/zt/1mcf1bjn2mddfxl1r3gx9hr8000mw2/T/clang-module-cache -O0 -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++11-extensions
-Wno-covered-switch-default -fdeprecated-macro -fdebug-compilation-dir
/Users/avi/Source/chrome-git/src/out/Debug -ferror-limit 19 -fmessage-length 0
-fvisibility hidden -fvisibility-inlines-hidden -stack-protector 2
-mstackrealign -fblocks -fno-rtti -fno-threadsafe-statics
-fobjc-runtime=macosx-fragile-10.6.0 -fobjc-default-synthesize-properties
-fdiagnostics-show-option -fcolor-diagnostics -load
/Users/avi/Source/chrome-git/src/tools/clang/scripts/../../../third_party/llvm-build/Release+Asserts/lib/libFindBadConstructs.dylib
-add-plugin find-bad-constructs -plugin-arg-find-bad-constructs
skip-virtuals-in-implementations -o
obj/chrome/browser/ui/tabs/unit_tests.test_tab_strip_model_delegate.o -x c++
../../chrome/browser/ui/tabs/test_tab_strip_model_delegate.cc 
1.    ../../chrome/browser/ui/tabs/test_tab_strip_model_delegate.cc:21:14:
current parser token ';'
2.    ../../chrome/browser/ui/tabs/test_tab_strip_model_delegate.cc:20:75:
parsing function body 'AddBlankTabAt'
3.    ../../chrome/browser/ui/tabs/test_tab_strip_model_delegate.cc:20:75: in
compound statement ('{}')
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk 167488)
Target: i386-apple-darwin12.2.0
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 14:09:43 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 22:09:43 +0000
Subject: [LLVMbugs] [Bug 14285] New: Bad __DBL_MIN__, __LDBL_MIN__,
	...  generated
Message-ID: <bug-14285-206@http.llvm.org/bugs/>

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

             Bug #: 14285
           Summary: Bad __DBL_MIN__, __LDBL_MIN__, ...  generated
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jeroen.dobbelaere at synopsys.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


When a backend wants to map a 'double' type to a float instance, it indicates
this with setting the 'DoubleFormat' to &llvm::APFloat::IEEESingle
Same thing can be done for 'LongDobleFormat'.

This is mostly fine (the C 'double' type will result in 'f32' llvm-ir type,
but some of the internal generated min/max numbers (__FLT_MIN__, __DBL_MIN__,
...)
contain the wrong suffix, such that __DBL_MIN__ will be interpreted as a float
type, in stead of a double 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  Wed Nov  7 14:29:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 22:29:20 +0000
Subject: [LLVMbugs] [Bug 14286] New: hello-world codegen fails: EmitRawText
 called on MCStreamer unsupported [powerpc-darwin8]
Message-ID: <bug-14286-206@http.llvm.org/bugs/>

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

             Bug #: 14286
           Summary: hello-world codegen fails: EmitRawText called on
                    MCStreamer unsupported [powerpc-darwin8]
           Product: new-bugs
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


[fangism:~/temp/clang] fang% make hello.o
~/local/src/LLVM-svn/gcc40-cmake-build/bin/clang++  -c hello.cc -o hello.o
EmitRawText called on an MCStreamer that doesn't support it,  something must
not be fully mc'ized
Stack dump:
0.    Program arguments:
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/clang-3.1 -cc1 -triple
powerpc-apple-macosx10.4.0 -emit-obj -mrelax-all -disable-free -main-file-name
hello.cc -pic-level 2 -mdisable-fp-elim -masm-verbose -target-cpu ppc
-coverage-file /Users/fang/temp/clang/hello.o -resource-dir
/Volumes/Isolde/builds/LLVM/gcc40-cmake-build/bin/../lib/clang/3.2
-fmodule-cache-path /var/tmp/clang-module-cache -fdeprecated-macro
-fdebug-compilation-dir /Users/fang/temp/clang -ferror-limit 19
-fmessage-length 80 -mstackrealign -fblocks -fblocks-runtime-optional
-fobjc-runtime=macosx-10.4.0 -fobjc-default-synthesize-properties
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
hello.o -x c++ hello.cc 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'hello.cc'.
clang-3: error: unable to execute command: Trace/BPT trap
clang-3: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk)
Target: powerpc-apple-darwin8.11.0
Thread model: posix
clang-3: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang-3: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang-3: note: diagnostic msg: /tmp/hello-MBXpuH.cpp
clang-3: note: diagnostic msg: /tmp/hello-MBXpuH.sh
clang-3: note: diagnostic msg: 

********************
make: *** [hello.o] Error 254


hello.cc:
#include <iostream>

int
main(int argc, char* argv[]) {
    std::cout << "Hello, world!" << std::endl;
    int x = 0;
    int y = x+2;
    std::cout << "y = " << y << std::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  Wed Nov  7 15:37:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 07 Nov 2012 23:37:44 +0000
Subject: [LLVMbugs] [Bug 13959] Clang can't recognize -Wp,-MMD
In-Reply-To: <bug-13959-206@http.llvm.org/bugs/>
References: <bug-13959-206@http.llvm.org/bugs/>
Message-ID: <bug-13959-206-cnrg0TVDid@http.llvm.org/bugs/>

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

Michael Spencer <bigcheesegs at gmail.com> changed:

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

--- Comment #2 from Michael Spencer <bigcheesegs at gmail.com> 2012-11-07 17:37:44 CST ---
Fixed in r167559.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 16:27:47 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 00:27:47 +0000
Subject: [LLVMbugs] [Bug 14287] New: fixit to insert "template<>" is in the
	wrong place
Message-ID: <bug-14287-206@http.llvm.org/bugs/>

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

             Bug #: 14287
           Summary: fixit to insert "template<>" is in the wrong place
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Nicos-MacBook-Pro:clang thakis$ cat tmpl.cc 
template <class T>
void myFunctionTemplate(T t) { }

void myFunctionTemplate<char>();

Nicos-MacBook-Pro:clang thakis$ ../../Release+Asserts/bin/clang -c tmpl.cc 
ActOnStartOfFunctionTemplateDef
tmpl.cc:4:6: error: template specialization requires 'template<>'
void myFunctionTemplate<char>();
     ^                 ~~~~~~
template<> 


Note that clang suggests inserting template<> after void instead of before 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  Wed Nov  7 16:41:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 00:41:49 +0000
Subject: [LLVMbugs] [Bug 14284] Returning NULL from void-returning function
 crashes fixit in getScalarZeroExpressionForType()
In-Reply-To: <bug-14284-206@http.llvm.org/bugs/>
References: <bug-14284-206@http.llvm.org/bugs/>
Message-ID: <bug-14284-206-LoR3Rb2d3A@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #3 from David Blaikie <dblaikie at gmail.com> 2012-11-07 18:41:49 CST ---
Thanks for the report.

Fixed in r167565

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 17:19:52 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 01:19:52 +0000
Subject: [LLVMbugs] [Bug 14288] New: Document sema in the internals manual
Message-ID: <bug-14288-206@http.llvm.org/bugs/>

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

             Bug #: 14288
           Summary: Document sema in the internals manual
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The internals manual is missing sema documentation. I started writing some, but
it's not yet publishable. This bug is for snapshotting what I have until
someone (likely me) can pick this up later.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  7 18:32:21 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 02:32:21 +0000
Subject: [LLVMbugs] [Bug 11854] floating point division by 0.0 vs -ftrapv vs
 IEEE floating point semantics
In-Reply-To: <bug-11854-206@http.llvm.org/bugs/>
References: <bug-11854-206@http.llvm.org/bugs/>
Message-ID: <bug-11854-206-nEMScxfldC@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Sean McBride <sean at rogue-research.com> 2012-11-07 20:32:21 CST ---
If I understand UsersManual.html, -fno-sanitize=divide-by-zero would let me
keep everything except the divide by zero check.  That's great!

But really it's only *floating point* div-by-zero that I don't want to be
warned about, since it's semantics are *well defined* by IEEE.

Can we have:

-fsanitize=divide-by-zero-integer
-fsanitize=divide-by-zero-floating-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  Thu Nov  8 01:53:07 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 09:53:07 +0000
Subject: [LLVMbugs] [Bug 14289] New: Silly error message: instruction
 expected to be numbered ''
Message-ID: <bug-14289-206@http.llvm.org/bugs/>

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

             Bug #: 14289
           Summary: Silly error message: instruction expected to be
                    numbered ''
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dirkjan at ochtman.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


djc at djc-mbp lang $ clang str.ll
str.ll:10:2: error: instruction expected to be numbered ''
        %1 = getelementptr %str* %self, i32 0, i32 0
        ^
1 error generated.

djc at djc-mbp lang $ clang -v
Apple clang version 4.0 (tags/Apple/clang-421.0.57) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

>From trial and error, I deduced that it was actually expected to be numbered
'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  Thu Nov  8 02:14:41 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 10:14:41 +0000
Subject: [LLVMbugs] [Bug 14290] New: Incorrectly typed ret instruction
 crashes clang frontend
Message-ID: <bug-14290-206@http.llvm.org/bugs/>

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

             Bug #: 14290
           Summary: Incorrectly typed ret instruction crashes clang
                    frontend
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dirkjan at ochtman.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is enough to make clang go down in flames:

target triple = "x86_64-apple-darwin11.0.0"
%str = type { i32, i8* }
define %str* @test(%str* %self) {
    ret %str %self
}

0  clang             0x0000000101053712 main + 17107202
1  clang             0x0000000101053b99 main + 17108361
2  libsystem_c.dylib 0x00007fff9186d8ea _sigtramp + 26
3  libsystem_c.dylib 0x00007fff6eeb8b58 _sigtramp + 18446744073128948360
4  clang             0x0000000100761a7e main + 7728238
5  clang             0x00000001000efd6a main + 970586
6  clang             0x00000001000efb76 main + 970086
7  clang             0x0000000100045cfb main + 274155
8  clang             0x0000000100044e01 main + 270321
9  clang             0x0000000100019ce2 main + 93906
10 clang             0x0000000100018948 main + 88888
11 clang             0x0000000100006638 main + 14376
12 clang             0x0000000100003097 main + 647
13 clang             0x0000000100002e04
14 clang             0x000000000000002b
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-apple-macosx10.8.0
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
add-q1.ll -pic-level 1 -mdisable-fp-elim -relaxed-aliasing -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 133.3 -resource-dir
/usr/bin/../lib/clang/4.0 -fdebug-compilation-dir /Users/djc/src/lang
-ferror-limit 19 -fmessage-length 100 -stack-protector 1 -mstackrealign
-fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak
-fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/kx/r0q_5lzx0jj0v8rkt8xq1qd40000gn/T/add-q1-hbipHU.o -x ir
add-q1.ll 
clang: error: unable to execute command: Segmentation fault: 11
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang: note: diagnostic msg: Please submit a bug report to
http://developer.apple.com/bugreporter/ and include command line arguments and
all diagnostic information.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.

djc at djc-mbp lang $ clang -v
Apple clang version 4.0 (tags/Apple/clang-421.0.57) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.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 Nov  8 04:56:18 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 12:56:18 +0000
Subject: [LLVMbugs] [Bug 14289] Silly error message: instruction expected to
 be numbered ''
In-Reply-To: <bug-14289-206@http.llvm.org/bugs/>
References: <bug-14289-206@http.llvm.org/bugs/>
Message-ID: <bug-14289-206-9qX3fP0lNh@http.llvm.org/bugs/>

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

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> 2012-11-08 06:56:18 CST ---
This was fixed back in March (r152956).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  8 05:45:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 13:45:01 +0000
Subject: [LLVMbugs] [Bug 14291] New: Issues found by building clang with
 -fsanitize=undefined
Message-ID: <bug-14291-206@http.llvm.org/bugs/>

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

             Bug #: 14291
           Summary: Issues found by building clang with
                    -fsanitize=undefined
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: markus at trippelsdorf.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Building clang with:
CC="clang
-fsanitize=alignment,divide-by-zero,float-cast-overflow,null,object-size,return,shift,signed-integer-overflow,unreachable,vla-bound
-w" CXX="clang++
-fsanitize=alignment,divide-by-zero,float-cast-overflow,null,object-size,return,shift,signed-integer-overflow,unreachable,vla-bound
-w" ../llvm/llvm/configure --enable-keep-symbols --enable-optimized
--enable-targets=host
--with-binutils-include=/usr/lib/binutils/x86_64-pc-linux-gnu/git/include
--with-cxx-include-arch=/x86_64-pc-linux-gnu --disable-assertions
--with-extra-options="-march=native"
--with-extra-ld-options="-Wl,-O1,--hash-style=gnu,--as-needed,--gc-sections,--icf=all,--icf-iterations=3"
make

leads to the following two issues:

llvm/lib/Analysis/ValueTracking.cpp:436:19: fatal error: member call on null
pointer of type 'llvm::DataLayout' 

llvm/tools/clang/lib/Sema/../../include/clang/AST/TypeLoc.h:1525:27: fatal
error: member access within misaligned address 0x4c149b4 for type
'clang::Elabor
atedLocInfo', which requires 8 byte alignment

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  8 06:25:57 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 14:25:57 +0000
Subject: [LLVMbugs] [Bug 14290] Incorrectly typed ret instruction crashes
	clang frontend
In-Reply-To: <bug-14290-206@http.llvm.org/bugs/>
References: <bug-14290-206@http.llvm.org/bugs/>
Message-ID: <bug-14290-206-u7ATczVObJ@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-08 08:25:57 CST ---
Please update your clang or go to bugreporter.apple.com for bugs in Apple's
clang. Apple clang 4.0 is ancient and not supported by llvm.org.

This was fixed ages ago in clang 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  Thu Nov  8 08:35:05 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 16:35:05 +0000
Subject: [LLVMbugs] [Bug 14292] New: Crash -- illegal instruction
Message-ID: <bug-14292-206@http.llvm.org/bugs/>

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

             Bug #: 14292
           Summary: Crash -- illegal instruction
           Product: clang
           Version: 3.1
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: norman-k-williams at uiowa.edu
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Perhaps related to 8-bit ascii found in one file from DCMTK library (
http://dicom.offis.de/dcmtk.php.en ).

As per instructions script + cpp file 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  Thu Nov  8 09:44:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 17:44:01 +0000
Subject: [LLVMbugs] [Bug 14293] New: register pinned variables are not
 pinned to the register
Message-ID: <bug-14293-206@http.llvm.org/bugs/>

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

             Bug #: 14293
           Summary: register pinned variables are not pinned to the
                    register
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


[rdivacky at anacreon ~]$ cat rtld.c 
void *foo() {
  register void *tp __asm__("r2");

  return tp;
}
[rdivacky at anacreon ~]$ ./llvm/Release+Asserts/bin/clang -O2 -S -o - rtld.c
    .file    "rtld.c"
    .text
    .globl    foo
    .align    2
    .type    foo, at function
    .section    .opd,"aw", at progbits
foo:
    .align    3
    .quad    .L.foo
    .quad    .TOC. at tocbase
    .quad    0
    .text
.L.foo:
    blr 
    .long    0
    .quad    0
.Ltmp0:
    .size    foo, .Ltmp0-.L.foo


No mention of "r2" in foo at all. The code at O0 is


    ld 3, -8(1)
    blr 

whicih seems wrong to me 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  Thu Nov  8 09:56:50 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 17:56:50 +0000
Subject: [LLVMbugs] [Bug 14293] register pinned variables are not pinned to
	the register
In-Reply-To: <bug-14293-206@http.llvm.org/bugs/>
References: <bug-14293-206@http.llvm.org/bugs/>
Message-ID: <bug-14293-206-1fFHZCt77X@http.llvm.org/bugs/>

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

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> 2012-11-08 11:56:50 CST ---
__asm__ markings on local register variables only affect inline asm statements.
 (There's a bug somewhere to give a better warning, but -Wuninitialized should
already catch this 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  Thu Nov  8 10:17:55 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 18:17:55 +0000
Subject: [LLVMbugs] [Bug 14294] New: std::deque clear() (and destructor too)
 segfaults because begin() > end()
Message-ID: <bug-14294-206@http.llvm.org/bugs/>

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

             Bug #: 14294
           Summary: std::deque clear() (and destructor too) segfaults
                    because begin() > end()
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: dan.eloff at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


It seems to me looking at it under the debugger, that the problem is somehow _i
(begin) starts further than _e (end) therefore _i is never equal to _e and the
loop continues until it segfaults. This is the problematic loop in file deque,
but obviously the problem is somewhere else.

template <class _Tp, class _Allocator>
void
__deque_base<_Tp, _Allocator>::clear() _NOEXCEPT
{
    allocator_type& __a = __alloc();
    for (iterator __i = begin(), __e = end(); __i != __e; ++__i)

This is for a deque of pointers, so the problem is not in a user destructor.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  8 10:39:58 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 18:39:58 +0000
Subject: [LLVMbugs] [Bug 14295] New: -Wdocumentation warns on duplicate
 \return comments, but the doxygen docs allow that
Message-ID: <bug-14295-206@http.llvm.org/bugs/>

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

             Bug #: 14295
           Summary: -Wdocumentation warns on duplicate \return comments,
                    but the doxygen docs allow that
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I just tried -Wdocumentation on a project that had a comment like this:

/// @return the number of processors on the machine.  Useful for an initial
/// guess for how many jobs to run in parallel.  @return 0 on error.
int GetProcessorCount();

http://www.stack.nl/~dimitri/doxygen/commands.html#cmdreturn says "Multiple
adjacent \return commands will be joined into a single paragraph.", but
-Wdocumentation says:

src/util.h:61:51: warning: duplicated command '\return' [-Wdocumentation]
/// guess for how many jobs to run in parallel.  @return 0 on error.
                                                 ~^~~~~~~~~~~~~~~~~~
src/util.h:60:6: note: previous command '\return' here
/// @return the number of processors on the machine.  Useful for an initial
    ~^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1 warning generated.


It seems like clang shouldn't warn about this.

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


From bugzilla-daemon at llvm.org  Thu Nov  8 11:22:43 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 19:22:43 +0000
Subject: [LLVMbugs] [Bug 14292] Crash -- illegal instruction
In-Reply-To: <bug-14292-206@http.llvm.org/bugs/>
References: <bug-14292-206@http.llvm.org/bugs/>
Message-ID: <bug-14292-206-Sxqtrkipfg@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-08 13:22:43 CST ---
Fixed in r167594.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  8 13:28:13 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 08 Nov 2012 21:28:13 +0000
Subject: [LLVMbugs] [Bug 14294] std::deque clear() (and destructor too)
 segfaults because begin() > end()
In-Reply-To: <bug-14294-206@http.llvm.org/bugs/>
References: <bug-14294-206@http.llvm.org/bugs/>
Message-ID: <bug-14294-206-z6cCSqN9e2@http.llvm.org/bugs/>

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

Dan Eloff <dan.eloff at gmail.com> changed:

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

--- Comment #3 from Dan Eloff <dan.eloff at gmail.com> 2012-11-08 15:28:13 CST ---
Sorry this does seem to be my fault somehow, I can't reproduce it with a
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  Thu Nov  8 20:39:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 04:39:30 +0000
Subject: [LLVMbugs] [Bug 14296] New: function parameter name redeclarations
	not detected
Message-ID: <bug-14296-206@http.llvm.org/bugs/>

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

             Bug #: 14296
           Summary: function parameter name redeclarations not detected
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: a.bataev at gmx.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


According to c++11 3.3.3/2 "A parameter name shall not be redeclared in the
outermost block of the function definition nor in the outermost block of any
handler associated with a function-try-block."
Here is the code.

void foo(int ii) try {
}
catch (...) {
    int ii;
}

int main() {
    foo(1);
    return (0);
}

clang++ -std=c++0x test.cpp

Compiles it without any diagnostics.

Alexey Bataev
Software Engineer
Intel Compiler Team
Intel Corp.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  8 21:06:47 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 05:06:47 +0000
Subject: [LLVMbugs] [Bug 14297] New: clang allows looser exception
 specification in explicit template instantiation
Message-ID: <bug-14297-206@http.llvm.org/bugs/>

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

             Bug #: 14297
           Summary: clang allows looser exception specification in
                    explicit template instantiation
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: a.bataev at gmx.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


According to 15.4p3 "If any declaration of a function has an
exception-specification, all declarations, including the definition and an
explicit
specialization, of that function shall have an exception-specification with the
same set of type-ids".

Clang does not generate error message for the following example

struct SomeStruct{};
template <class T> void Foo(T i) throw(T) { throw i; }
template void Foo(int a) throw (char);  // explicit instantiation, argument is
deduced. Wrong exception specification is provided

int main() {
    try {
   SomeStruct slawa;
   Foo(slawa);
    }
   catch(...) { ;}
   return(0);
}

clang++ -c test.cpp

Alexey Bataev
Software Engineer
Intel Compiler Team
Intel Corp.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  8 22:20:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 06:20:09 +0000
Subject: [LLVMbugs] [Bug 14298] New: Incorrect processing of private
	inheritance
Message-ID: <bug-14298-206@http.llvm.org/bugs/>

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

             Bug #: 14298
           Summary: Incorrect processing of private inheritance
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: a.bataev at gmx.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Here is the small code

  1 struct class_2 {
  2 };
  3
  4 struct class_1 : private class_2 {
  5     struct class_2 var_2;
  6 };
  7
  8 struct class_0 : private class_1 {
  9     struct class_2 var_4;
 10 };

Clang unable to compile it with the following error message:
test.cpp:9:12: error: 'class_2' is a private member of 'class_2'
    struct class_2 var_4;
           ^
test.cpp:4:18: note: constrained by private inheritance here
struct class_1 : private class_2 {
                 ^~~~~~~~~~~~~~~
test.cpp:1:8: note: member is declared here
struct class_2 {
       ^
1 error generated.

gcc compiles this code without any messages.

Alexey Bataev
Software Engineer
Intel Compiler Team
Intel Corp.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  8 22:52:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 06:52:17 +0000
Subject: [LLVMbugs] [Bug 14299] New: Incorrect codegen for static local with
 address of local label in constructor
Message-ID: <bug-14299-206@http.llvm.org/bugs/>

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

             Bug #: 14299
           Summary: Incorrect codegen for static local with address of
                    local label in constructor
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: a.bataev at gmx.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang generates incorrect code for the following code:

struct VirtualBase {
  VirtualBase() {}
};

struct Mike : virtual VirtualBase {
  Mike();
};

Mike::Mike() {
    static void *ouch =&&x;
    goto *ouch;
     x:;
}

struct Dave : virtual Mike {
  Dave() {}
};

int main()
{
  Mike *m = new Mike();
  VirtualBase *v = new Dave;
  Mike *m2 = new Mike();
  return 0;
}

clang++ -S -emit-llvm -o - test.cpp

Some excerpts from the generated code:
...
@_ZZN4MikeC1EvE4ouch = internal global i8* blockaddress(@_ZN4MikeC2Ev, %x),
align 8
...
define void @_ZN4MikeC1Ev(%struct.Mike* %this) unnamed_addr uwtable ssp align 2
{
...

  %2 = load i8** @_ZZN4MikeC1EvE4ouch, align 8
  br label %indirectgoto

x:                                                ; preds = %indirectgoto
  ret void

indirectgoto:                                     ; preds = %entry
  %indirect.goto.dest = phi i8* [ %2, %entry ]
  indirectbr i8* %indirect.goto.dest, [label %x]
}
...
define void @_ZN4MikeC2Ev(%struct.Mike* %this, i8** %vtt) unnamed_addr nounwind
uwtable ssp align 2 {
...

  %2 = load i8** @_ZZN4MikeC1EvE4ouch, align 8
  br label %indirectgoto

x:                                                ; preds = %indirectgoto
  ret void

indirectgoto:                                     ; preds = %entry
  %indirect.goto.dest = phi i8* [ %2, %entry ]
  indirectbr i8* %indirect.goto.dest, [label %x]
}

There is a branch to the code in @_ZN4MikeC2Ev from @_ZN4MikeC1Ev happens.

Building an executable and running the test
clang++ test.cpp
./a.out
Bus error: 10

Alexey Bataev
Software Engineer
Intel Compiler Team
Intel Corp.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 06:07:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 14:07:49 +0000
Subject: [LLVMbugs] [Bug 14300] New: stack alignment leading to corrupt
 values of variables
Message-ID: <bug-14300-206@http.llvm.org/bugs/>

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

             Bug #: 14300
           Summary: stack alignment leading to corrupt values of variables
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rahul.s1 at samsung.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


For the below Test Case with O1 optimization , the value of m and n has got
corrupted after call to foo() function which is leading to garbage value for LL
variable . 



#include <stddef.h>
#ifdef DEBUG
#include <stdio.h>
#endif

#ifdef  __cplusplus
extern "C" void abort (void);
#else
extern void abort (void);
#endif

int
check_int (int *i, int align)
{
  *i = 20;
  if ((((ptrdiff_t) i) & (align - 1)) != 0)
    {
#ifdef DEBUG
      printf ("\nUnalign address (%d): %p!\n", align, i);
#endif
      abort ();
    }
  return *i;
}

void
check (void *p, int align)
{
  if ((((ptrdiff_t) p) & (align - 1)) != 0)
    {
#ifdef DEBUG
      printf ("\nUnalign address (%d): %p!\n", align, p);
#endif
      abort ();
    }
}

#ifndef ALIGNMENT
#define ALIGNMENT       64
#endif

typedef int t_align __attribute__((aligned(ALIGNMENT)));


int global, global2;
void bar()
{
    volatile t_align a = 1;
        int i,j,k,l,m,n;
        i=j=k=0;
      for (i=0; i < global; i++)
      for (j=0; j < i; j++)
      for (k=0; k < j; k++)
      for (l=0; l < k; l++)
      for (m=0; m < l; m++)
      for (n=0; n < m; n++)
             global2 = k;
    if (check_int ((int *) &a,  __alignof__(a)) != a)
      abort ();
    throw 0;
}

void foo()
{
    bar();
}

int main()
{
    int ll = 1;
        int i = 0,j = 1,k = 2,l = 3,m = 4,n = 5;
    try {
        for (; i < global; i++)
      for (; j < i; j++)
      for (; k < j; k++)
      for (; l < k; l++)
      for (; m < l; m++)
      for (; n < m; n++)
             global2 = k;
      foo();
    }
    catch (...)
    {
    }
    ll = i+j+k+l+m+n;
    if (ll != 15)
    {
#ifdef DEBUG
        printf("FAIL: sum %d != 15\n", ll);
#endif
        abort();
    }
    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  Fri Nov  9 06:09:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 14:09:44 +0000
Subject: [LLVMbugs] [Bug 14301] New: Add __CYGWIN__ in
 llvm/projects/compiler-rt/lib/int_endianness.h
Message-ID: <bug-14301-206@http.llvm.org/bugs/>

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

             Bug #: 14301
           Summary: Add __CYGWIN__ in
                    llvm/projects/compiler-rt/lib/int_endianness.h
           Product: compiler-rt
           Version: unspecified
          Platform: PC
        OS/Version: other
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: llvm-acone at gmx.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


CMake did not set the _WIN32 macro in the used version by default. That is why
I suggest to include the __CYGWIN__ definition in int_endianness.h. I know that
I could switch in the legacy mode with CMAKE_LEGACY_CYGWIN_WIN32 to add the
_WIN32 preprocessor statement. But it was my intention to use a pure POSIX
system without direct dependencies from WIN32.

###################
--- system info ---
###################

OS: Windows 7 64 Bit

$ cmake --version
cmake version 2.8.9

$ uname -a
CYGWIN_NT-6.1-WOW64 Gamer 1.7.17(0.262/5/3) 2012-10-19 14:39 i686 Cygwin

$ gcc --version
gcc (GCC) 4.5.3

SVN Revision: 167612

####################
--- build script ---
####################

MYSELF=`readlink -f $0`
MYPATH=`dirname $MYSELF`

export WORK_PATH=/c/temp
export SOURCE_DIR=llvm_sources
export BUILD_DIR=llvm_build

export SOURCE_PATH=$WORK_PATH/$SOURCE_DIR
export BUILD_PATH=$WORK_PATH/$BUILD_DIR
export INSTALL_PATH=$MYPATH/cygwin

if [ -d $SOURCE_PATH ]; then
  rm -r $SOURCE_PATH
fi

if [ ! -d $SOURCE_PATH ]; then
  mkdir -p $SOURCE_PATH
fi

# Checkout LLVM
cd $SOURCE_PATH
svn co http://llvm.org/svn/llvm-project/llvm/trunk llvm

# Checkout Clang
cd llvm/tools
svn co http://llvm.org/svn/llvm-project/cfe/trunk clang
cd ../..

# Checkout extra Clang Tools (optional)
cd llvm/tools/clang/tools
svn co http://llvm.org/svn/llvm-project/clang-tools-extra/trunk extra
cd ../../../..

# Checkout Compiler-RT
cd llvm/projects
svn co http://llvm.org/svn/llvm-project/compiler-rt/trunk compiler-rt
cd ../..

# Get the Test Suite Source Code (optional)
cd llvm/projects
svn co http://llvm.org/svn/llvm-project/test-suite/trunk test-suite
cd ../..

if [ -d $BUILD_PATH ]; then
  rm -r $BUILD_PATH
fi

if [ ! -d $BUILD_PATH ]; then
  mkdir -p $BUILD_PATH
fi

cd $BUILD_PATH

cmake -DLLVM_TARGETS_TO_BUILD=X86 -DCMAKE_INSTALL_PREFIX=$INSTALL_PATH
$SOURCE_PATH/llvm

cd $BUILD_PATH

make

#####################
--- compile error ---
#####################

[ 49%] Built target llvm-symbolizer
[ 49%] Building C object
projects/compiler-rt/lib/CMakeFiles/clang_rt.i386.dir/a
bsvdi2.c.o
In file included from
/c/temp/llvm_sources/llvm/projects/compiler-rt/lib/int_typ
es.h:21:0,
                 from
/c/temp/llvm_sources/llvm/projects/compiler-rt/lib/int_lib
.h:41,
                 from
/c/temp/llvm_sources/llvm/projects/compiler-rt/lib/absvdi2
.c:15:
/c/temp/llvm_sources/llvm/projects/compiler-rt/lib/int_endianness.h:106:2:
error
: #error Unable to determine endian
projects/compiler-rt/lib/CMakeFiles/clang_rt.i386.dir/build.make:57: recipe for
target `projects/compiler-rt/lib/CMakeFiles/clang_rt.i386.dir/absvdi2.c.o'
faile
d
make[2]: ***
[projects/compiler-rt/lib/CMakeFiles/clang_rt.i386.dir/absvdi2.c.o]
 Error 1
CMakeFiles/Makefile2:2916: recipe for target
`projects/compiler-rt/lib/CMakeFile
s/clang_rt.i386.dir/all' failed
make[1]: *** [projects/compiler-rt/lib/CMakeFiles/clang_rt.i386.dir/all] Error
2

Makefile:136: recipe for target `all' failed
make: *** [all] Error 2

###################
--- workaround ---
###################

<llvm/projects/compiler-rt/lib/int_endianness.h
96c96
< #if defined(_WIN32)
---
> #if defined(_WIN32) || defined(__CYGWIN__)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 06:50:07 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 14:50:07 +0000
Subject: [LLVMbugs] [Bug 14120] compiler crash on invalid code
In-Reply-To: <bug-14120-206@http.llvm.org/bugs/>
References: <bug-14120-206@http.llvm.org/bugs/>
Message-ID: <bug-14120-206-zpEcGQaiay@http.llvm.org/bugs/>

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

Brian Brooks <brooks.brian 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  Fri Nov  9 07:09:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 15:09:51 +0000
Subject: [LLVMbugs] [Bug 9864] crash after error using sizeof on class with
 incomplete array member
In-Reply-To: <bug-9864-206@http.llvm.org/bugs/>
References: <bug-9864-206@http.llvm.org/bugs/>
Message-ID: <bug-9864-206-rO4YXITMyi@http.llvm.org/bugs/>

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

Brian Brooks <brooks.brian at gmail.com> changed:

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

--- Comment #1 from Brian Brooks <brooks.brian at gmail.com> 2012-11-09 09:09:51 CST ---
No crash as of r167598.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 07:11:52 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 15:11:52 +0000
Subject: [LLVMbugs] [Bug 9852] Assertion failure with invalid C++ code
In-Reply-To: <bug-9852-206@http.llvm.org/bugs/>
References: <bug-9852-206@http.llvm.org/bugs/>
Message-ID: <bug-9852-206-7tiaL42cfZ@http.llvm.org/bugs/>

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

Brian Brooks <brooks.brian at gmail.com> changed:

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

--- Comment #1 from Brian Brooks <brooks.brian at gmail.com> 2012-11-09 09:11:52 CST ---
No crash as of r167598.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 08:58:50 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 16:58:50 +0000
Subject: [LLVMbugs] [Bug 14302] New: misched asserts on powerpc: problems
	with regmasks
Message-ID: <bug-14302-206@http.llvm.org/bugs/>

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

             Bug #: 14302
           Summary: misched asserts on powerpc: problems with regmasks
           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: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9511
  --> http://llvm.org/bugs/attachment.cgi?id=9511
bugpoint reduced test case

The new machine-instruction scheduling infrastructure currently does not work
with the PowerPC backend; Something about the way the register masks are
handled is not quite right.

I've attached a small test case. This asserts with:
/src/llvm-trunk-writable/lib/CodeGen/LiveIntervalAnalysis.cpp:1260: void
llvm::LiveIntervals::HMEditor::updateRegMaskSlots(): Assertion `*RI == OldIdx
&& "No RegMask at OldIdx."' failed.
...
8  llc             0x0000000000ba92a8
llvm::LiveIntervals::handleMove(llvm::MachineInstr*, bool) + 632
9  llc             0x0000000000c1fabb
llvm::ScheduleDAGMI::moveInstruction(llvm::MachineInstr*,
llvm::MachineBasicBlock::bundle_iterator<llvm::MachineInstr,
llvm::ilist_iterator<llvm::MachineInstr> >) + 91
10 llc             0x0000000000c2006e
llvm::ScheduleDAGMI::scheduleMI(llvm::SUnit*, bool) + 510
11 llc             0x0000000000c23029 llvm::ScheduleDAGMI::schedule() + 121

This is r167618 running: llc -enable-misched

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 09:20:54 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 17:20:54 +0000
Subject: [LLVMbugs] [Bug 5975] [GVN/Instcombine] Missed removal of loads
 after undef stores
In-Reply-To: <bug-5975-206@http.llvm.org/bugs/>
References: <bug-5975-206@http.llvm.org/bugs/>
Message-ID: <bug-5975-206-fte0kXVeKg@http.llvm.org/bugs/>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #6 from Chris Lattner <clattner at apple.com> 2012-11-09 11:20:54 CST ---
Yeah, this is now handled, 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 Nov  9 11:07:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 19:07:26 +0000
Subject: [LLVMbugs] [Bug 14303] New: clang's --help output regressed from
 ~60 lines of output to ~470 lines,
 and most of the flags printed by it are not understood by the driver
Message-ID: <bug-14303-206@http.llvm.org/bugs/>

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

             Bug #: 14303
           Summary: clang's --help output regressed from ~60 lines of
                    output to ~470 lines, and most of the flags printed by
                    it are not understood by the driver
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


At r155835:
$ ../../Release+Asserts/bin/clang --help | wc -l
     58


At r157931:
$ ../../Release+Asserts/bin/clang --help | wc -l
     451


Likely caused by r155916; the driver seems to print all the cc1 options too,
even though it doesn't understand 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  Fri Nov  9 11:19:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 19:19:51 +0000
Subject: [LLVMbugs] [Bug 14302] misched asserts on powerpc: problems with
	regmasks
In-Reply-To: <bug-14302-206@http.llvm.org/bugs/>
References: <bug-14302-206@http.llvm.org/bugs/>
Message-ID: <bug-14302-206-fdqFvIPGCU@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |stoklund at 2pi.dk
         Resolution|                            |FIXED

--- Comment #1 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2012-11-09 13:19:51 CST ---
Fixed updateRegMaskSlots() assertions in r167625.

This hasn't come up before because other targets consider calls to be
scheduling barriers. I don't know if it is worthwhile to schedule across calls
on PowerPC?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 11:46:47 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 19:46:47 +0000
Subject: [LLVMbugs] [Bug 14282] crash when reading a gch file produced by an
	older clang
In-Reply-To: <bug-14282-206@http.llvm.org/bugs/>
References: <bug-14282-206@http.llvm.org/bugs/>
Message-ID: <bug-14282-206-hGGWkIE96t@http.llvm.org/bugs/>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2012-11-09 13:46:47 CST ---
I fixed this in r167539.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 12:26:57 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 20:26:57 +0000
Subject: [LLVMbugs] [Bug 14304] New: -Winvalid-constexpr fails to warn on
 non-const array used in constexpr function
Message-ID: <bug-14304-206@http.llvm.org/bugs/>

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

             Bug #: 14304
           Summary: -Winvalid-constexpr fails to warn on non-const array
                    used in constexpr function
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: arthur.j.odwyer at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


cat >test.cc <<EOF
extern int global_array[1];

constexpr int true_positive(int i) {
    return global_array[0];
}

constexpr int false_negative(int i) {
    return global_array[i];
}
EOF
clang -std=c++11 -c test.cc

Clang gives the correct diagnostic ("constexpr function never produces a
constant expression") for "true_positive", but silently accepts
"false_negative".

The Standard says "the program is ill-formed; no diagnostic required"
(dcl.constexpr#5), but clearly Clang is making an effort to diagnose the issue
and is failing. So I'm calling this a bug, even though technically (per
dcl.constexpr#5) it's just a quality-of-implementation issue, i.e. an
enhancement request.

(Personally, I'd like to see Clang diagnose any constexpr function that is
*ever* uncomputable at compile time. I don't have a ton of experience with
constexpr yet, but I see huge disadvantages to permitting "non-const constexpr"
functions — and no correspondingly huge advantages — no matter what the
Standard says on the topic.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 14:00:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 22:00:01 +0000
Subject: [LLVMbugs] [Bug 14304] -Winvalid-constexpr fails to warn on
 non-const array used in constexpr function
In-Reply-To: <bug-14304-206@http.llvm.org/bugs/>
References: <bug-14304-206@http.llvm.org/bugs/>
Message-ID: <bug-14304-206-4f6sE5Cl7c@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |WONTFIX

--- Comment #4 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-09 16:00:01 CST ---
Note that this slightly different case can produce constant expressions:

constexpr int *foo(int i) {
    return &global_array[i];
}

Due to the non-local analysis required, it's not trivial to detect that your
original case can't ever produce a constant expression (the lvalue-to-rvalue
conversion could be quite far from the point where we perform the array
indexing).

This warning is only a best-effort check for a no-diagnostic-required rule. If
you want this fixed, patches would be welcome -- though a patch which makes the
constant expression evaluator more complex just to catch this would probably
not be accepted.

(In reply to comment #2)
> I assume the Committee was worried about the technicalities of undefined
> behavior; e.g. in your example f(0x7fffffff, 1) would technically not have a
> compile-time value, because it wouldn't have any value. But the cure they
> adopted — silently permitting constexpr functions to be evaluated at runtime —
> was worse than the disease.

I don't agree with this at all. There are many cases where you want a constexpr
function to only sometimes produce a constant expression. For instance,
std::array::at (which sometimes throws), or any function which asserts that
preconditions hold for its inputs, any function which conditionally logs or
allocates memory (for instance, std::string(const char*) could be constexpr and
handle just those cases where its small string optimization kicks in), etc.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 14:13:38 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 22:13:38 +0000
Subject: [LLVMbugs] [Bug 5928] GVN pass going crazy taking 99% of compile
	time
In-Reply-To: <bug-5928-206@http.llvm.org/bugs/>
References: <bug-5928-206@http.llvm.org/bugs/>
Message-ID: <bug-5928-206-46VvcaR5Z6@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #9 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-09 16:13:38 CST ---
Okay, 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 Nov  9 14:16:28 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 22:16:28 +0000
Subject: [LLVMbugs] [Bug 14305] New: thumb2 bit test optimization opportunity
Message-ID: <bug-14305-206@http.llvm.org/bugs/>

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

             Bug #: 14305
           Summary: thumb2 bit test optimization opportunity
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bagel99 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9515
  --> http://llvm.org/bugs/attachment.cgi?id=9515
bit test example

This is a missing optimization for Thumb2 code.
A bit test on a dead variable is now done with a "tst.w reg,#bit", with
conditions EQ,NE.  It could be done with a "lsls reg,#shf" to shift the bit
into the sign bit, with conditions PL,MI.

The test program generates (on the trunk):

bittest:
    mov     r1, r0
    movs    r0, #0
    tst.w    r1, #128
    it          eq
    moveq    r0, #42
    bx        lr

It could generate, 2 bytes smaller:

bittest:
    mov     r1, r0
    movs    r0, #0
    lsls       r1, #24
    it          pl
    movpl    r0, #42
    bx        lr

Even better would be, 4 bytes smaller:

bittest:
    lsls       r0, #24
    ite        pl
    movpl    r0, #42
    movmi    r0, #0
    bx        lr

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 14:54:32 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 22:54:32 +0000
Subject: [LLVMbugs] [Bug 14306] New: -fbounds-checking should be a
 -fsanitize= option and should use sanitizer infrastructure
Message-ID: <bug-14306-206@http.llvm.org/bugs/>

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

             Bug #: 14306
           Summary: -fbounds-checking should be a -fsanitize= option and
                    should use sanitizer infrastructure
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


-fbounds-checking should live under the -fsanitize= umbrella. Instead of just
creating an @llvm.trap call, it should call into a sanitizer runtime library to
produce an explanatory message.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 15:35:28 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 23:35:28 +0000
Subject: [LLVMbugs] [Bug 14303] clang's --help output regressed from ~60
 lines of output to ~470 lines,
 and most of the flags printed by it are not understood by the driver
In-Reply-To: <bug-14303-206@http.llvm.org/bugs/>
References: <bug-14303-206@http.llvm.org/bugs/>
Message-ID: <bug-14303-206-2ipNtUgHa8@http.llvm.org/bugs/>

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

Richard Smith <richard-llvm at metafoo.co.uk> 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 Nov  9 15:52:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 23:52:30 +0000
Subject: [LLVMbugs] [Bug 13354] NVPTX intrinsics table misses __nvvm_*
	buitins
In-Reply-To: <bug-13354-206@http.llvm.org/bugs/>
References: <bug-13354-206@http.llvm.org/bugs/>
Message-ID: <bug-13354-206-i3OJ0KYSVa@http.llvm.org/bugs/>

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

Justin Holewinski <justin.holewinski at gmail.com> changed:

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

--- Comment #1 from Justin Holewinski <justin.holewinski at gmail.com> 2012-11-09 17:52:30 CST ---
Fix committed in r167647.

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  Fri Nov  9 15:53:36 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 09 Nov 2012 23:53:36 +0000
Subject: [LLVMbugs] [Bug 13324] [NVPTX] llc -march=nvptx64 -mcpu=sm_20
 generates invalid zero align for device function params
In-Reply-To: <bug-13324-206@http.llvm.org/bugs/>
References: <bug-13324-206@http.llvm.org/bugs/>
Message-ID: <bug-13324-206-55TH8V9Dj0@http.llvm.org/bugs/>

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

Justin Holewinski <justin.holewinski at gmail.com> changed:

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

--- Comment #1 from Justin Holewinski <justin.holewinski at gmail.com> 2012-11-09 17:53:36 CST ---
Fix committed in r167646.

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  Fri Nov  9 16:20:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 00:20:09 +0000
Subject: [LLVMbugs] [Bug 14307] New: Accurate GC documentation code examples
	obsolete
Message-ID: <bug-14307-206@http.llvm.org/bugs/>

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

             Bug #: 14307
           Summary: Accurate GC documentation code examples obsolete
           Product: Documentation
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ralith at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The C++ code examples in docs/GarbageCollection.html have fallen out of sync
with the APIs in question. For example, GCMetadataPrinter::beginAssembly and
finishAssembly now take only one argument.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 16:20:48 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 00:20:48 +0000
Subject: [LLVMbugs] [Bug 14285] Bad __DBL_MIN__, __LDBL_MIN__, ...  generated
In-Reply-To: <bug-14285-206@http.llvm.org/bugs/>
References: <bug-14285-206@http.llvm.org/bugs/>
Message-ID: <bug-14285-206-9T8KxtZVLW@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-09 18:20:48 CST ---
r167649.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 17:04:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 01:04:35 +0000
Subject: [LLVMbugs] [Bug 14296] function parameter name redeclarations not
	detected
In-Reply-To: <bug-14296-206@http.llvm.org/bugs/>
References: <bug-14296-206@http.llvm.org/bugs/>
Message-ID: <bug-14296-206-wQJH01i4gF@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #3 from David Blaikie <dblaikie at gmail.com> 2012-11-09 19:04:35 CST ---
Fixed in r167650.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 17:32:53 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 01:32:53 +0000
Subject: [LLVMbugs] [Bug 14308] New: clang frontend command failed due to
 signal on crosscompile
Message-ID: <bug-14308-206@http.llvm.org/bugs/>

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

             Bug #: 14308
           Summary: clang frontend command failed due to signal on
                    crosscompile
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: erik at arawix.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


1>  clang version 3.2 (trunk)
1>  Target: arm-apple-darwin9

See attached files. I am crosscompiling (host=win, target=iphone)

Can do a debug dump if needed.

Called:
Clang.exe -x c++ -o iOS/Debug/grgfx.o -DSPEEDTREERT_DYNAMIC_LIB -D_DEBUG -Wall
-marm -fno-strict-aliasing -fomit-frame-pointer -fno-exceptions -msoft-float
-fpic -fstack-protector -fno-rtti -fno-short-enums
-Ie:/OSX/Platform/iPhoneOS4.3.sdk/usr/include
-Ie:/OSX/Platform/iPhoneOS4.3.sdk/usr/gcc_include
-Ie:/OSX/Platform/iPhoneOS4.3.sdk/usr/include/c++/4.2.1
-Ie:/OSX/Platform/iPhoneOS4.3.sdk/usr/include/arm
-Ie:/OSX/Platform/iPhoneOS4.3.sdk/usr/include/c++/4.2.1/armv7-apple-darwin10
-DAPPLE -D__APPLE__ -D__APPLE_CPP__ -D__arm__ -D__ARM_ARCH_7A__ -D__ARM_EABI__
-target arm-apple-darwin9 -O0 -g -IE:/work/ionix/libs/ExoLib
-IE:/work/ionix/libs/ExoLib/src -IE:/work/ionix/libs/bullet/src
-IE:/work/ionix/libs/libsdl/include -fapple-pragma-pack 
-miphoneos-version-min=3.0.0  -c -MD ../graphics/grgfx.cpp

Final:
Clang.exe -cc1 -triple armv4t-apple-ios3.0.0 -emit-obj -mrelax-all
-disable-free -disable-llvm-verifier -main-file-name grgfx.cpp -pic-level 2
-relaxed-aliasing -masm-verbose -target-abi apcs-gnu -target-cpu arm7tdmi
-msoft-float -mfloat-abi soft -target-feature +soft-float -target-feature
+soft-float-abi -target-feature -neon -g -coverage-file
E:\work\ionix\libs\ExoLib\VC10Prj\iOS/Debug/grgfx.o -resource-dir
e:/OSX/Compiler/bin\..\lib\clang\3.2 -dependency-file iOS/Debug/grgfx.d -MT
iOS/Debug/grgfx.o -sys-header-deps -D SPEEDTREERT_DYNAMIC_LIB -D _DEBUG -D
APPLE -D __APPLE__ -D __APPLE_CPP__ -D __arm__ -D __ARM_ARCH_7A__ -D
__ARM_EABI__ -I e:/OSX/Platform/iPhoneOS4.3.sdk/usr/include -I
e:/OSX/Platform/iPhoneOS4.3.sdk/usr/gcc_include -I
e:/OSX/Platform/iPhoneOS4.3.sdk/usr/include/c++/4.2.1 -I
e:/OSX/Platform/iPhoneOS4.3.sdk/usr/include/arm -I
e:/OSX/Platform/iPhoneOS4.3.sdk/usr/include/c++/4.2.1/armv7-apple-darwin10 -I
E:/work/ionix/libs/ExoLib -I E:/work/ionix/libs/ExoLib/src -I
E:/work/ionix/libs/bullet/src -I E:/work/ionix/libs/libsdl/include
-fmodule-cache-path C:\Users\evangrun\AppData\Local\Temp\clang-module-cache
-IC:\Program Files (x86)\Intel\Compiler\11.0\061\cpp\mkl\include -O0 -Wall
-fdeprecated-macro -ferror-limit 19 -fmessage-length 0 -stack-protector 1
-mstackrealign -fblocks -fblocks-runtime-optional -fno-rtti
-fobjc-runtime=ios-3.0.0 -fobjc-default-synthesize-properties -fsjlj-exceptions
-fdiagnostics-show-option -fapple-pragma-pack -o iOS/Debug/grgfx.o -x c++
../graphics/grgfx.cpp

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


From bugzilla-daemon at llvm.org  Fri Nov  9 17:54:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 01:54:46 +0000
Subject: [LLVMbugs] [Bug 14309] New: Incorrect optimization of thread_local
	variables
Message-ID: <bug-14309-206@http.llvm.org/bugs/>

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

             Bug #: 14309
           Summary: Incorrect optimization of thread_local variables
           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: tbergan at cs.washington.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9516
  --> http://llvm.org/bugs/attachment.cgi?id=9516
Minimal C program that demonstrates the bug

I believe there is a bug in the way the optimizer deals with thread_local
variables.  The attached program, test.c, has a thread-local variable "int Foo"
and a global variable "int *Ptr".  The program takes the following steps:

1) The main thread spawns a new thread and waits
2) The new thread writes Foo = 50 and Ptr = &Foo, then signals the main thread
and waits
3) The main thread prints *Ptr, releases the new thread, and exits

The crux of this example is that the main thread obtains a pointer to the new
thread's TLS via "Ptr".  When I compile with gcc, the program prints "50" as
expected.  When I compile with LLVM, the program prints "0".  To demonstrate
the bug, run the following commands with the attached "test.c" (verified with
revision 167568):
$ clang -O3 -lpthread test.c -o test
$ ./test   # prints "Foo: 0"

I'm attaching the following files:
* test.c
* test.0.ll, which was built with "clang -emit-llvm -S -O0 test.c -o test.0.ll"
* test.3.ll, which was built with "clang -emit-llvm -S -O3 test.c -o test.3.ll"

It is pretty clear that "test.3.ll" is an incorrect optimization of
"test.0.ll".  You can see the bug in main(), where LLVM has optimized the load
"*Ptr" into the following instructions:

  %.b = load i1* @Foo.b, align 1   ; main() loads its own @Foo.b, not the
@Foo.b written by run()
  %0 = select i1 %.b, i32 50, i32 0

My guess is that the optimizer does not realize that thread_local addresses are
not constant in the same way that global addresses are constant, since each
thread_local variable actually names N variables, one for each of N running
threads.  Thus, it's not safe to optimize across two accesses of a thread_local
variable unless it can be proven that both accesses will be performed by the
same thread.

In terms of LLVM's design, I've noticed that thread_local variables are
represented in the same way as ordinary global variables (via
llvm::GlobalVariable) except that the "isThreadLocal" flag is true.  This
strikes me as a potential for confusion, because you have this one corner case
-- thread_locals -- in which an "llvm::Constant" is not really a "constant" in
the same way as other constants.  This might be related to
http://llvm.org/bugs/show_bug.cgi?id=13720, and perhaps a few other bugs.

-Tom

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 18:39:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 02:39:39 +0000
Subject: [LLVMbugs] [Bug 14310] New: Upgrade NVPTX to use PTX 3.1
Message-ID: <bug-14310-206@http.llvm.org/bugs/>

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

             Bug #: 14310
           Summary: Upgrade NVPTX to use PTX 3.1
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: justin.holewinski at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Add a PTX 3.1 target to NVPTX back-end (or just upgrade the relevant parts of
the back-end).  This will make the resulting PTX compatible with the CUDA 5.0
linker.

Added here as a post-3.2 task.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov  9 20:28:42 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 04:28:42 +0000
Subject: [LLVMbugs] [Bug 14311] New: Change introduced in r164241 broke
 std::stringstream
Message-ID: <bug-14311-206@http.llvm.org/bugs/>

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

             Bug #: 14311
           Summary: Change introduced in r164241 broke std::stringstream
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: oneill+llvmbugs at cs.hmc.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9519
  --> http://llvm.org/bugs/attachment.cgi?id=9519
Code that generates an assert fail.

The enclosed code works prior to r164241 and generates the following assert
fail thereafter.

Assertion failed:
(stringFrom("aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\xFF")
==
"aaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaaa\xFF"),
function main, file /tmp/bug.cpp, line 26.
Abort

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 05:03:34 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 13:03:34 +0000
Subject: [LLVMbugs] [Bug 12010] BranchProbabilityInfo::getSumForBlock asserts
In-Reply-To: <bug-12010-206@http.llvm.org/bugs/>
References: <bug-12010-206@http.llvm.org/bugs/>
Message-ID: <bug-12010-206-oePQjwSFxI@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-10 07:03:34 CST ---
OK, closing 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  Sat Nov 10 05:05:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 13:05:15 +0000
Subject: [LLVMbugs] [Bug 12242] Build failure on NetBSD
In-Reply-To: <bug-12242-206@http.llvm.org/bugs/>
References: <bug-12242-206@http.llvm.org/bugs/>
Message-ID: <bug-12242-206-WtVJFZ9ier@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-10 07:05:15 CST ---
Not really an LLVM bug, closing this now as it's fixed in upstream libstdc++.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 05:30:28 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 13:30:28 +0000
Subject: [LLVMbugs] [Bug 11251] lshr of character vector inefficient on x86
In-Reply-To: <bug-11251-206@http.llvm.org/bugs/>
References: <bug-11251-206@http.llvm.org/bugs/>
Message-ID: <bug-11251-206-WsxdEkODLK@http.llvm.org/bugs/>

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

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> 2012-11-10 07:30:28 CST ---
This was fixed a while ago. llc emits:

LCPI0_0:
    .space    16,63
    .section    __TEXT,__text,regular,pure_instructions
    .globl    _shift_vec16x8
    .align    4, 0x90
_shift_vec16x8:                         ## @shift_vec16x8
    .cfi_startproc
## BB#0:                                ## %entry
    psrlw    $2, %xmm0
    pand    LCPI0_0(%rip), %xmm0
    ret
    .cfi_endproc

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 05:34:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 13:34:16 +0000
Subject: [LLVMbugs] [Bug 11115] Many warnings when building with -Weffc++
In-Reply-To: <bug-11115-206@http.llvm.org/bugs/>
References: <bug-11115-206@http.llvm.org/bugs/>
Message-ID: <bug-11115-206-16kP80tge9@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-10 07:34:16 CST ---
-Weffc++ is very noisy and most of the warnings are useless. For example it
wants that every constructor initializes all members via an initializer list,
even though it's unnecessary if the member is POD or the default ctor is used.

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


From bugzilla-daemon at llvm.org  Sat Nov 10 05:38:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 13:38:01 +0000
Subject: [LLVMbugs] [Bug 10425] clang --help is missing many options
In-Reply-To: <bug-10425-206@http.llvm.org/bugs/>
References: <bug-10425-206@http.llvm.org/bugs/>
Message-ID: <bug-10425-206-h78fE2uTD4@http.llvm.org/bugs/>

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

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> 2012-11-10 07:38:01 CST ---
clang trunk lists a lot more options.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 05:43:18 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 13:43:18 +0000
Subject: [LLVMbugs] [Bug 9742] LLVM 2.9 won't compile on Solaris
In-Reply-To: <bug-9742-206@http.llvm.org/bugs/>
References: <bug-9742-206@http.llvm.org/bugs/>
Message-ID: <bug-9742-206-0gmjNk7TzZ@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-10 07:43:18 CST ---
Closing then.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 08:10:27 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 16:10:27 +0000
Subject: [LLVMbugs] [Bug 13477] AlignOfTest.cpp build failure with Intel
	Compiler
In-Reply-To: <bug-13477-206@http.llvm.org/bugs/>
References: <bug-13477-206@http.llvm.org/bugs/>
Message-ID: <bug-13477-206-nOX3J9sf0i@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-10 10:10:27 CST ---
Fixed in r167676.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 08:52:12 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 16:52:12 +0000
Subject: [LLVMbugs] [Bug 11011] MCJIT does not support ELF ("Unknown Object
	Format")
In-Reply-To: <bug-11011-206@http.llvm.org/bugs/>
References: <bug-11011-206@http.llvm.org/bugs/>
Message-ID: <bug-11011-206-SUIjCeVEsN@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-10 10:52:12 CST ---
trunk MCJIT also works on ELF platforms.

It also supports ELF on windows, which seems to be sufficient to get the JIT
running.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 09:27:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 17:27:20 +0000
Subject: [LLVMbugs] [Bug 10614] Redundant load of address of array
In-Reply-To: <bug-10614-206@http.llvm.org/bugs/>
References: <bug-10614-206@http.llvm.org/bugs/>
Message-ID: <bug-10614-206-0Xa79PunaB@http.llvm.org/bugs/>

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

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

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

--- Comment #6 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-10 11:27:20 CST ---
MachineCSE gets this in trunk:

    movl    %esi, %eax
    leaq    __ZL10PowersOf10(%rip), %rcx
    movl    (%rcx,%rax,4), %eax
    cmpl    %edi, %eax
    jbe    LBB0_2
## BB#1:                                ## %if.then
    decl    %esi
    movl    (%rcx,%rsi,4), %eax
LBB0_2:                                 ## %return
    popq    %rbp
    ret

(Probably due to the fix for PR13578)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 11:37:28 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 19:37:28 +0000
Subject: [LLVMbugs] [Bug 14313] New: Custom project configuration error
Message-ID: <bug-14313-206@http.llvm.org/bugs/>

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

             Bug #: 14313
           Summary: Custom project configuration error
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: llvm-config
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: wojtek.danilo at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


According to http://llvm.org/docs/Projects.html setting custom project based on
LLVM should be easy, but it does not. The bundled makefiles and llvm-config
does not work properly.

STEPS TO REPRODUCE:
1) compile LLVM as described here:
http://llvm.org/docs/GettingStarted.html#getting-started
lets LLVM src folder = $LLVMSRC
2) cd $LLVMSRC/projects 
cp -R sample sample2
3) cd sample2/tools/sample
4) add to Makefile (before include $(LEVEL)/Makefile.common) following line:
LINK_COMPONENTS = all
5) cd $LLVMSRC/projects/sample2
6) mkdir build
7) cd build
8) ../configure (what is strange i see the first line of configure as:
"llvm-config .... no" - it is related to this bug)
9) make VERBOSE=1

as a result we should get our porgram compiled, but we get error, that
llvm-config could not be found. If I type llvm-config in terminal it works.

full verbose output:
 make VERBOSE=1
for dir in lib tools; do \
  if ([ ! -f $dir/Makefile ] || \
      command test $dir/Makefile -ot
/home/wdanilo/dev/llvm/src/projects/sample2/$dir/Makefile ); then \
    /home/wdanilo/dev/llvm/src/projects/sample2/build/../autoconf/mkinstalldirs
$dir; \
    /usr/bin/cp /home/wdanilo/dev/llvm/src/projects/sample2/$dir/Makefile
$dir/Makefile; \
  fi; \
  (make -C $dir all ) || exit 1; \
done
make[1]: Entering directory
`/home/wdanilo/dev/llvm/src/projects/sample2/build/lib'
for dir in sample; do \
  if ([ ! -f $dir/Makefile ] || \
      command test $dir/Makefile -ot
/home/wdanilo/dev/llvm/src/projects/sample2/lib/$dir/Makefile ); then \
    /home/wdanilo/dev/llvm/src/projects/sample2/build/../autoconf/mkinstalldirs
$dir; \
    /usr/bin/cp /home/wdanilo/dev/llvm/src/projects/sample2/lib/$dir/Makefile
$dir/Makefile; \
  fi; \
  (make -C $dir all ) || exit 1; \
done
make[2]: Entering directory
`/home/wdanilo/dev/llvm/src/projects/sample2/build/lib/sample'
make[2]: Nothing to be done for `all'.
make[2]: Leaving directory
`/home/wdanilo/dev/llvm/src/projects/sample2/build/lib/sample'
make[1]: Leaving directory
`/home/wdanilo/dev/llvm/src/projects/sample2/build/lib'
make[1]: Entering directory
`/home/wdanilo/dev/llvm/src/projects/sample2/build/tools'
for dir in sample; do \
  if ([ ! -f $dir/Makefile ] || \
      command test $dir/Makefile -ot
/home/wdanilo/dev/llvm/src/projects/sample2/tools/$dir/Makefile ); then \
    /home/wdanilo/dev/llvm/src/projects/sample2/build/../autoconf/mkinstalldirs
$dir; \
    /usr/bin/cp /home/wdanilo/dev/llvm/src/projects/sample2/tools/$dir/Makefile
$dir/Makefile; \
  fi; \
  (make -C $dir all ) || exit 1; \
done
/bin/sh: /home/wdanilo/dev/llvm/src/projects/Debug+Asserts/bin/llvm-config: No
such file or directory
make[2]: Entering directory
`/home/wdanilo/dev/llvm/src/projects/sample2/build/tools/sample'
/home/wdanilo/dev/llvm/src/projects/sample2/build/../Makefile.llvm.rules:963:
*** llvm-config --libs failed.  Stop.
make[2]: Leaving directory
`/home/wdanilo/dev/llvm/src/projects/sample2/build/tools/sample'
make[1]: *** [all] Error 1
make[1]: Leaving directory
`/home/wdanilo/dev/llvm/src/projects/sample2/build/tools'
make: *** [all] Error 1

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


From bugzilla-daemon at llvm.org  Sat Nov 10 15:14:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 10 Nov 2012 23:14:26 +0000
Subject: [LLVMbugs] [Bug 14311] Change introduced in r164241 broke
	std::stringstream
In-Reply-To: <bug-14311-206@http.llvm.org/bugs/>
References: <bug-14311-206@http.llvm.org/bugs/>
Message-ID: <bug-14311-206-M62RaPAgoH@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #5 from Howard Hinnant <hhinnant at apple.com> 2012-11-10 17:14:26 CST ---
I've recently updated the instructions for running tip-of-trunk on OS X:

http://libcxx.llvm.org

using
export DYLD_LIBRARY_PATH=<path-to-libcxx>/lib
clang++ -std=c++11 -stdlib=libc++ -nostdinc++ -I<path-to-libcxx>/include
-L<path-to-libcxx>/lib test.cpp

I think this is a safer route to go instead of changing your system.  I've seen
people crash their Mac by replacing the dylib (I've done it myself too).  So
the above is a less intrusive (though awkward) way to experiment with 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 Nov 10 17:14:21 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Nov 2012 01:14:21 +0000
Subject: [LLVMbugs] [Bug 14314] New: Codegen for atomicrmw sub i64 is broken
	for x86-32
Message-ID: <bug-14314-206@http.llvm.org/bugs/>

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

             Bug #: 14314
           Summary: Codegen for atomicrmw sub i64 is broken for x86-32
           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 gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9522
  --> http://llvm.org/bugs/attachment.cgi?id=9522
Testcase

The following program should should print -1.

#include <stdio.h>
#include <stdint.h>

int64_t atomicSub(int64_t *a, int64_t b) {
  return __sync_fetch_and_sub(a, b);
}

int main(int argc, char **argv) {
  int64_t a = 0;
  atomicSub(&a, 1);
  printf("a = %lli\n", a);
  return 0;
}

clang on x86-64 and gcc on all architectures compile the program correctly.
clang on x86-32 prints 1. The last working revision of clang was 164820. The
bug first appears in 164821 after a checkin from Michael Liao titled, "Re-work
X86 code generation of atomic ops with spin-loop."

I have attached LLVM IR for the test case. The LLVM IR is generated correctly
in both 164820 and 164821.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 21:22:06 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Nov 2012 05:22:06 +0000
Subject: [LLVMbugs] [Bug 14315] New: Register regmask dependency problem
	with misched
Message-ID: <bug-14315-206@http.llvm.org/bugs/>

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

             Bug #: 14315
           Summary: Register regmask dependency problem with misched
           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: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9523
  --> http://llvm.org/bugs/attachment.cgi?id=9523
bugpoint reduced test case

Now that PR14302 has been fixed, there seems to be another similar issue.

For this input block:
BB#0: derived from LLVM BB %entry
    Live Ins: %F1
        %vreg2<def> = COPY %F1; F8RC:%vreg2
        %vreg8<def> = LI -1; GPRC:%vreg8
        ADJCALLSTACKDOWN 112, %R1<imp-def>, %R1<imp-use>
        BL8_NOP_ELF <ga:@init>, <regmask>, %RM<imp-use>, %R1<imp-def>, ...
        ADJCALLSTACKUP 112, 0, %R1<imp-def>, %R1<imp-use>
        ADJCALLSTACKDOWN 112, %R1<imp-def>, %R1<imp-use>
        BL8_NOP_ELF <ga:@clock>, <regmask>, %RM<imp-use>, %R1<imp-def>, ...
        ADJCALLSTACKUP 112, 0, %R1<imp-def>, %R1<imp-use>
    Successors according to CFG: BB#1

The copy is not constrained to come before the call:

SU(0):   %vreg2<def> = COPY %F1; F8RC:%vreg2
  # preds left       : 0
  # succs left       : 0
  # rdefs left       : 0
  Latency            : 0
  Depth              : 0
  Height             : 0

(there is no dependency on the later call)

SU(3):   BL8_NOP_ELF <ga:@init>, <regmask>, %RM<imp-use>, %R1<imp-def>, ...
  # preds left       : 1
  # succs left       : 4
  # rdefs left       : 0
  Latency            : 1
  Depth              : 0
  Height             : 0
  Predecessors:
   out SU(2): Latency=1
  Successors:
   out SU(6): Latency=1
   out SU(4): Latency=1
   val SU(4): Latency=1
   ch  SU(6): Latency=0

and this leads to the copy being moved after the call. This asserts:

*** Bad machine code: Using an undefined physical register ***
- function:    s332
- basic block: BB#0 entry (0x23f4970)
- instruction: %F31<def> = COPY %F1
- operand 1:   %F1
LLVM ERROR: Found 1 machine code errors.

Test case attached. Run with llc -enable-misched

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 10 22:39:57 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Nov 2012 06:39:57 +0000
Subject: [LLVMbugs] [Bug 14260] Invalid write of size 1
In-Reply-To: <bug-14260-206@http.llvm.org/bugs/>
References: <bug-14260-206@http.llvm.org/bugs/>
Message-ID: <bug-14260-206-5DIB51spHF@http.llvm.org/bugs/>

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

Seth <seth.cantrell at gmail.com> changed:

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

--- Comment #2 from Seth <seth.cantrell at gmail.com> 2012-11-11 00:39:57 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 11 03:07:42 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Nov 2012 11:07:42 +0000
Subject: [LLVMbugs] [Bug 14316] New: [patch] pretty print for anonymous
 structure dereference is buggy
Message-ID: <bug-14316-206@http.llvm.org/bugs/>

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

             Bug #: 14316
           Summary: [patch] pretty print for anonymous structure
                    dereference is buggy
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: florent.bruneau_llvm at m4x.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9524
  --> http://llvm.org/bugs/attachment.cgi?id=9524
Patch for the issue

When I have an expression of the form

 struct blah {
   struct {
     struct {
       int b;
     };
   };
 };

 int foo(const struct blah *b) {
   return b->b;
 }

The expression 'b->b' has the following (correct) AST:
 (ImplicitCastExpr 0x44bc968 'int' <LValueToRValue>
   (MemberExpr 0x44bc8f0 'int' lvalue .b 0x44899b0
     (MemberExpr 0x44bc8c0 'struct blah::<anonymous at blah.blk:3:9>' lvalue .
0x4489a50
       (MemberExpr 0x44bc890 'struct blah::<anonymous at blah.blk:2:5>' lvalue
-> 0x44bc2f0
         (ImplicitCastExpr 0x44bc878 'union blah *' <LValueToRValue>
           (DeclRefExpr 0x44bc850 'union blah *' lvalue ParmVar 0x44bc440 'b'
'union blah *'))))))

Put the pretty printer badly print this as 'b.b' because all the MemberExpr
targeting anonymous types are simply ignored. The patch fix that behavior: the
arrow/dot notation is printed if the base of the expression is not anonymous.

The patch is based on the 3.1 release branch of the git mirror.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 11 10:35:47 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 11 Nov 2012 18:35:47 +0000
Subject: [LLVMbugs] [Bug 14317] New: Clang crashes during Blocks rewrite
	(-rewrite-objc)
Message-ID: <bug-14317-206@http.llvm.org/bugs/>

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

             Bug #: 14317
           Summary: Clang crashes during Blocks rewrite (-rewrite-objc)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bugzilla-clang at sogetthis.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9525
  --> http://llvm.org/bugs/attachment.cgi?id=9525
Preprocessed source as requested in Clang debug output

I'm trying to use Clang's blocks support on Linux and therefore I got the pure
BlocksRuntime [https://github.com/mackyle/blocksruntime/] and compiled it. Next
I learned that blocks are rewritten into normal C++ by Clang and that
"-rewrite-objc" will show the rewritten code. This worked fine until I tried it
with one of the test cases
[https://github.com/mackyle/blocksruntime/blob/master/BlocksRuntime/tests/recursive-block.c].

Clang crashes on this one:

0  clang 0x099ac558
Stack dump:
0.    Program arguments: /home/me/Compiler/llvm/bin/bin/clang -cc1 -triple
i386-pc-linux-gnu -rewrite-objc -disable-free -disable-llvm-verifier
-main-file-name recursive-block.c -mrelocation-model static -mdisable-fp-elim
-fmath-errno -masm-verbose -mconstructor-aliases -target-cpu pentium4
-target-linker-version 2.21.0.20110327 -momit-leaf-frame-pointer -resource-dir
/home/me/Compiler/llvm/bin/bin/../lib/clang/3.2 -fdebug-compilation-dir
/home/me/Compiler/blocksruntime/BlocksRuntime/tests -ferror-limit 19
-fmessage-length 143 -mstackrealign -fblocks -fobjc-runtime=macosx
-fno-objc-infer-related-result-type -fdiagnostics-show-option
-fcolor-diagnostics -o recursive-block.cpp -x objective-c++-cpp-output
/tmp/recursive-block-HLHu6R.i 
1.    recursive-block.c:46:1: current parser token 'int'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk 167691)
Target: i386-pc-linux-gnu
Thread model: posix

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


From bugzilla-daemon at llvm.org  Sun Nov 11 16:43:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 00:43:49 +0000
Subject: [LLVMbugs] [Bug 14318] New: Objective-C properties of types with no
 trivial special members leads to assert
Message-ID: <bug-14318-206@http.llvm.org/bugs/>

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

             Bug #: 14318
           Summary: Objective-C properties of types with no trivial
                    special members leads to assert
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Modified from test/CodeGenObjCXX/property-objects.mm:

class S {
public:
        S& operator = (const S&);
        S& operator = (S&&);
        S (const S&);
        S (S&&);
        S ();
};

@interface I {
  S position;
}
@property(assign, nonatomic) S position;
@end

void f(I *i) {
  S s;
  i.position = s;
}

clang-3.2: lib/CodeGen/CGExprAgg.cpp:1289: void
clang::CodeGen::CodeGenFunction::EmitAggregateCopy(llvm::Value *, llvm::Value
*, clang::QualType, bool, clang::CharUnits, bool): Assertion
`(Record->hasTrivialCopyConstructor() || Record->hasTrivialCopyAssignment() ||
Record->hasTrivialMoveConstructor() || Record->hasTrivialMoveAssignment()) &&
"Trying to aggregate-copy a type without a trivial copy " "constructor or
assignment operator"' failed.

It appears that the @property mechanism is completely broken for properties of
non-trivially-copyable class type -- it always uses a memcpy -- but this assert
usually doesn't manage to catch it. For instance, we currently generate wrong
code for CodeGenObjCXX/property-objects.mm; look at 'main', note that the
instance of 'class S' passed to objc_msgSend has not had a constructor called
for it (or add a data member to 'S' and note that we emit a memcpy rather than
a copy constructor call).

Fixing release-blocker PR14279 causes three unit tests to fail this way
(because we consider fewer classes to have trivial move operations), and it
seems pretty important, so I'm marking it release-blocker 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 Nov 11 22:11:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 06:11:39 +0000
Subject: [LLVMbugs] [Bug 14319] New: ICE on const ref initialization
Message-ID: <bug-14319-206@http.llvm.org/bugs/>

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

             Bug #: 14319
           Summary: ICE on const ref initialization
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: leonid at volnitsky.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


GCC-4.8 is ok.  File main.i is attached. Original source at
https://github.com/lvv/scc/tree/clang-ice . 
If line 24 at https://github.com/lvv/scc/blob/clang-ice/mapped_range.h, is
uncommented - CLANG will ICE.  This line declare unused var, so this line can
be commented out. 

The line:

parent_t * const & parent_p = (parent_t*)(b::parent_p);


Clang ICE msg:

0  libLLVM-3.2svn.so 0x00007f381b728dff
1  libLLVM-3.2svn.so 0x00007f381b729359
2  libpthread.so.0   0x00007f381aef5410
3  clang             0x00000000006e9773
clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef,
llvm::Type*, clang::GlobalDecl, bool, llvm::Attributes) + 627
4  clang             0x00000000006e99b5
clang::CodeGen::CodeGenModule::GetAddrOfFunction(clang::GlobalDecl,
llvm::Type*, bool) + 101
5  clang             0x000000000075238e
6  clang             0x000000000075b99f
clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(clang::DeclRefExpr const*) +
415
7  clang             0x000000000075c4c8
clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) + 552
8  clang             0x0000000000760909
clang::CodeGen::CodeGenFunction::EmitCheckedLValue(clang::Expr const*,
clang::CodeGen::CodeGenFunction::TypeCheckKind) + 41
9  clang             0x0000000000787440
10 clang             0x000000000078eed2
11 clang             0x000000000078d37f
12 clang             0x000000000079124b
13 clang             0x000000000078dbc9
14 clang             0x0000000000791a5c
15 clang             0x000000000078dacf
16 clang             0x0000000000792bfd
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 61
17 clang             0x00000000007509c7
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 423
18 clang             0x000000000075cbcf
19 clang             0x000000000075d52b
clang::CodeGen::CodeGenFunction::EmitReferenceBindingToExpr(clang::Expr const*,
clang::NamedDecl const*) + 91
20 clang             0x000000000073de2e
clang::CodeGen::CodeGenFunction::EmitExprAsInit(clang::Expr const*,
clang::ValueDecl const*, clang::CodeGen::LValue, bool) + 302
21 clang             0x00000000007255ff
clang::CodeGen::CodeGenFunction::EmitInitializerForField(clang::FieldDecl*,
clang::CodeGen::LValue, clang::Expr*, llvm::ArrayRef<clang::VarDecl*>) + 879
22 clang             0x00000000007260d7
clang::CodeGen::CodeGenFunction::EmitCtorPrologue(clang::CXXConstructorDecl
const*, clang::CXXCtorType, clang::CodeGen::FunctionArgList&) + 1991
23 clang             0x00000000007278cc
clang::CodeGen::CodeGenFunction::EmitConstructorBody(clang::CodeGen::FunctionArgList&)
+ 124
24 clang             0x00000000007fa20b
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 955
25 clang             0x000000000070bc11
clang::CodeGen::CodeGenModule::EmitCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType) + 177
26 clang             0x00000000006ead41
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 433
27 clang             0x00000000006ec53e
clang::CodeGen::CodeGenModule::EmitDeferred() + 142
28 clang             0x00000000006ec5a9
clang::CodeGen::CodeGenModule::Release() + 9
29 clang             0x00000000006d10a5
30 clang             0x00000000008184fe clang::ParseAST(clang::Sema&, bool,
bool) + 334
31 clang             0x00000000006d00b3 clang::CodeGenAction::ExecuteAction() +
51
32 clang             0x0000000000598a41 clang::FrontendAction::Execute() + 97
33 clang             0x0000000000579fef
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 271
34 clang             0x0000000000560788
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1560
35 clang             0x0000000000556b92 cc1_main(char const**, char const**,
char const*, void*) + 6706
36 clang             0x000000000055f4ab main + 5915
37 libc.so.6         0x00007f381a63d4bd __libc_start_main + 253
38 clang             0x0000000000554fb9
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S
-disable-free -disable-llvm-verifier -main-file-name main.cc -mrelocation-model
static -mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version 2.22
-momit-leaf-frame-pointer -g -resource-dir /usr/bin/../lib/clang/3.2 -O0 -Wall
-Wno-sign-compare -Wno-unused-function -std=gnu++11 -fdeprecated-macro
-fdebug-compilation-dir /home/lvv/p/scc -ferror-limit 19 -fmessage-length 127
-ftrapv -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o main.s -x c++-cpp-output
main.ii 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    /home/lvv/p/scc/mapped_range.h:52:2: Generating code for declaration
'sto::mapped_range_iterator<std::__debug::vector<std::tuple<int,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > >,
std::allocator<std::tuple<int, std::basic_string<char, std::char_traits<char>,
std::allocator<char> > > > > &, const int &(*)(const std::tuple<int,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > > &),
int, true>::mapped_range_iterator'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk)
Target: x86_64-pc-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/main-cfCCJJ.cpp
clang: note: diagnostic msg: /tmp/main-cfCCJJ.sh
clang: note: diagnostic msg:

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 11 22:49:56 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 06:49:56 +0000
Subject: [LLVMbugs] [Bug 14314] Codegen for atomicrmw sub i64 is broken for
	x86-32
In-Reply-To: <bug-14314-206@http.llvm.org/bugs/>
References: <bug-14314-206@http.llvm.org/bugs/>
Message-ID: <bug-14314-206-E0oiYUfX4E@http.llvm.org/bugs/>

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

Michael Liao <michael.liao at intel.com> changed:

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

--- Comment #1 from Michael Liao <michael.liao at intel.com> 2012-11-12 00:49:56 CST ---
Fixed in r167718.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 11 23:37:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 07:37:20 +0000
Subject: [LLVMbugs] [Bug 14319] ICE on const ref initialization
In-Reply-To: <bug-14319-206@http.llvm.org/bugs/>
References: <bug-14319-206@http.llvm.org/bugs/>
Message-ID: <bug-14319-206-vFdknKfz2P@http.llvm.org/bugs/>

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

Leonid Volnitsky <leonid at volnitsky.com> changed:

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

--- Comment #3 from Leonid Volnitsky <leonid at volnitsky.com> 2012-11-12 01:37:20 CST ---
I could not compile CLANG TOT yesterday, I was getting (on gentoo) this error: 

------------------------------------------------------------------------
llvm[2]: Compiling llvm-nm.cpp for Release build
if  x86_64-pc-linux-gnu-g++
-I/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include
-I/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-nm  -DNDEBUG
-D_GNU_SOURCE -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS
-D__STDC_LIMIT_MACROS   -fvisibility-inlines-hidden -fno-exceptions -fPIC
-Woverloaded-virtual -Wcast-qual  -O2 -march=native -pipe  
-I/usr/lib64/libffi-3.0.11/include    -pedantic -Wno-long-long -Wall -W
-Wno-unused-parameter -Wwrite-strings   -c -MMD -MP -MF
"/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-nm/Release/llvm-nm.d.tmp"
-MT
"/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-nm/Release/llvm-nm.o"
-MT
"/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-nm/Release/llvm-nm.d"
llvm-nm.cpp -o
/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-nm/Release/llvm-nm.o
; \
        then /bin/mv -f
"/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-nm/Release/llvm-nm.d.tmp"
"/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-nm/Release/llvm-nm.d";
else /bin/rm
"/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/tools/llvm-nm/Release/llvm-nm.d.tmp";
exit 1; fi
In file included from
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre9999/include/g++-v4/algorithm:63:0,
                 from
/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include/llvm/ADT/StringRef.h:15,
                 from
/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include/llvm/Support/ErrorHandling.h:19,
                 from
/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include/llvm/User.h:22,
                 from
/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include/llvm/Constant.h:17,
                 from
/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include/llvm/GlobalValue.h:21,
                 from
/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include/llvm/Function.h:21,
                 from
/var/tmp/portage/sys-devel/llvm-9999/work/llvm-9999/include/llvm/Module.h:18,
                 from llvm-nm.cpp:20:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre9999/include/g++-v4/bits/stl_algo.h:
In function ‘int main(int, char**)’:
/usr/lib/gcc/x86_64-pc-linux-gnu/4.8.0-pre9999/include/g++-v4/bits/stl_algo.h:4442:2:
internal compiler error: in remap_gimple_stmt, at tree-inline.c:1468
  __f(*__first);
-------------------------------------------------------------------------

But I will trust you that it is was resolved in TOT, I am closing 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 Nov 12 00:18:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 08:18:02 +0000
Subject: [LLVMbugs] [Bug 13898] Results of bind on sub-matchers of
 forEachDescendant aren't updated
In-Reply-To: <bug-13898-206@http.llvm.org/bugs/>
References: <bug-13898-206@http.llvm.org/bugs/>
Message-ID: <bug-13898-206-jQZ7qqg7aL@http.llvm.org/bugs/>

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

Magnus Reftel <magnus.reftel at gmail.com> changed:

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

--- Comment #1 from Magnus Reftel <magnus.reftel at gmail.com> 2012-11-12 02:18:02 CST ---
This seems to have been fixed, starting with r167665.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 12 02:05:48 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 10:05:48 +0000
Subject: [LLVMbugs] [Bug 14320] New: SROA increases stack usage when used
	with ASan
Message-ID: <bug-14320-206@http.llvm.org/bugs/>

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

             Bug #: 14320
           Summary: SROA increases stack usage when used with ASan
           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: samsonov at google.com
                CC: chandlerc at gmail.com, kcc at google.com,
                    llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ cat sroa.cc 
void f(volatile int *arg) {}

int main() {
  volatile int b[20] = {0, 1};
  f(b);
}
$ clang++ -O2 -fsanitize=address sroa.cc -S -emit-llvm -mllvm -print-after-all
-o sroa.ll 2>log.ll
$ cat sroa.ll
<...>
define i32 @main() nounwind uwtable address_safety {
  %MyAlloca = alloca [288 x i8], align 32
  %1 = ptrtoint [288 x i8]* %MyAlloca to i64
  %2 = add i64 %1, 32
  %3 = inttoptr i64 %2 to i32*  <---------- int
  %4 = add i64 %1, 96
  %5 = inttoptr i64 %4 to i32*  <---------- int
  %6 = add i64 %1, 160
  %7 = inttoptr i64 %6 to [18 x i32]* <---- int[18]
  %8 = inttoptr i64 %1 to i64*

Looks like SROA changes this:
  %b = alloca [20 x i32], align 16
to this:
  %b.sroa.0 = alloca i32, align 16
  %b.sroa.1 = alloca i32
  %b.sroa.2 = alloca [18 x i32], align 8
and ASan inserts large redzones between this fake "different" local variables.

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


From bugzilla-daemon at llvm.org  Mon Nov 12 05:17:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 13:17:30 +0000
Subject: [LLVMbugs] [Bug 14321] New: r167602 'make check-all' fails in
 CodeGenCXX/mangle-ms-templates.cpp, built with gcc-4.7.1 for x86_64
Message-ID: <bug-14321-206@http.llvm.org/bugs/>

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

             Bug #: 14321
           Summary: r167602 'make check-all' fails in
                    CodeGenCXX/mangle-ms-templates.cpp, built with
                    gcc-4.7.1 for x86_64
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: patrik.h.hagglund at ericsson.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Building a Release+Asserts build with gcc-4.7.1 (but not clang-3.1) on Linux
x86_64 makes make check-all to fail in CodeGenCXX/mangle-ms-templates.cpp.

> valgrind --track-origins=yes /dev/shm/uabpath/master/build-gcc471/Release+Debug+Asserts/bin/clang -cc1 -internal-isystem /dev/shm/uabpath/master/build-gcc471/Release+Debug+Asserts/bin/../lib/clang/3.2/include -fms-extensions -emit-llvm /dev/shm/uabpath/master/tools/clang/test/CodeGenCXX/mangle-ms-templates.cpp -o - -cxx-abi microsoft -triple=i386-pc-win32

==2398== Memcheck, a memory error detector
==2398== Copyright (C) 2002-2012, and GNU GPL'd, by Julian Seward et al.
==2398== Using Valgrind-3.8.0 and LibVEX; rerun with -h for copyright info
==2398== Command:
/dev/shm/uabpath/master/build-gcc471/Release+Debug+Asserts/bin/clang -cc1
-internal-isystem
/dev/shm/uabpath/master/build-gcc471/Release+Debug+Asserts/bin/../lib/clang/3.2/include
-fms-extensions -emit-llvm
/dev/shm/uabpath/master/tools/clang/test/CodeGenCXX/mangle-ms-templates.cpp -o
- -cxx-abi microsoft -triple=i386-pc-win32
==2398==
==2398== Conditional jump or move depends on uninitialised value(s)
==2398==    at 0x1235E0B: (anonymous
namespace)::MicrosoftCXXNameMangler::mangleUnqualifiedName(clang::NamedDecl
const*, clang::DeclarationName) (Casting.h:208)
==2398==    by 0x1239DBA: (anonymous
namespace)::MicrosoftCXXNameMangler::manglePostfix(clang::DeclContext const*,
bool) (MicrosoftMangle.cpp:65)
==2398==    by 0x1236F2C: (anonymous
namespace)::MicrosoftCXXNameMangler::mangleName(clang::NamedDecl const*)
(MicrosoftMangle.cpp:303)
==2398==    by 0x1239066: (anonymous
namespace)::MicrosoftCXXNameMangler::mangle(clang::NamedDecl const*,
llvm::StringRef) (MicrosoftMangle.cpp:206)
==2398==    by 0x1239EA2: (anonymous
namespace)::MicrosoftMangleContext::mangleCXXCtor(clang::CXXConstructorDecl
const*, clang::CXXCtorType, llvm::raw_ostream&) (MicrosoftMangle.cpp:1695)
==2398==    by 0x91639E:
clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl)
(CodeGenModule.cpp:390)
==2398==    by 0x948395:
clang::CodeGen::CodeGenModule::GetAddrOfCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType, clang::CodeGen::CGFunctionInfo const*)
(CGCXX.cpp:218)
==2398==    by 0x95FD18:
clang::CodeGen::CodeGenFunction::EmitCXXConstructorCall(clang::CXXConstructorDecl
const*, clang::CXXCtorType, bool, llvm::Value*, clang::ConstExprIterator,
clang::ConstExprIterator) (CGClass.cpp:1262)
==2398==    by 0x9A9D3F:
clang::CodeGen::CodeGenFunction::EmitCXXConstructExpr(clang::CXXConstructExpr
const*, clang::CodeGen::AggValueSlot) (CGExprCXX.cpp:509)
==2398==    by 0x9A24D8: (anonymous
namespace)::AggExprEmitter::VisitCXXConstructExpr(clang::CXXConstructExpr
const*) (CGExprAgg.cpp:872)
==2398==    by 0x9A562F: clang::StmtVisitorBase<clang::make_ptr, (anonymous
namespace)::AggExprEmitter, void>::Visit(clang::Stmt*) (StmtNodes.inc:181)
==2398==    by 0x9A61BA:
clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot) (CGExprAgg.cpp:1261)
==2398==  Uninitialised value was created by a stack allocation
==2398==    at 0x12357DD: (anonymous
namespace)::MicrosoftCXXNameMangler::mangleUnqualifiedName(clang::NamedDecl
const*, clang::DeclarationName) (MicrosoftMangle.cpp:397)
==2398==
clang: /dev/shm/uabpath/master/include/llvm/Support/Casting.h:208: typename
llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
clang::TemplateSpecializationType; Y = const clang::Type*; typename
llvm::cast_retty<To, From>::ret_type = const
clang::TemplateSpecializationType*]: Assertion `isa<X>(Val) && "cast<Ty>()
argument of inco
mpatible type!"' failed.
0  clang           0x0000000001fe565f
1  clang           0x0000000001fe5b59
2  libpthread.so.0 0x0000000004e3e6a0
3  libc.so.6       0x00000000059fc945 gsignal + 53
4  libc.so.6       0x00000000059fdf21 abort + 385
5  libc.so.6       0x00000000059f5810 __assert_fail + 240
6  clang           0x000000000072fbdc
7  clang           0x00000000012369dc
8  clang           0x0000000001239dbb
9  clang           0x0000000001236f2d
10 clang           0x0000000001239067
11 clang           0x0000000001239ea3
12 clang           0x000000000091639f
clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl) + 1599
13 clang           0x0000000000948396
clang::CodeGen::CodeGenModule::GetAddrOfCXXConstructor(clang::CXXConstructorDecl
const*, clang::CXXCtorType, clang::CodeGen::CGFunctionInfo const*) + 86
14 clang           0x000000000095fd19
clang::CodeGen::CodeGenFunction::EmitCXXConstructorCall(clang::CXXConstructorDecl
const*, clang::CXXCtorType, bool, llvm::Value*, clang::ConstExprIterator,
clang::ConstExprIterator) + 377
15 clang           0x00000000009a9d40
clang::CodeGen::CodeGenFunction::EmitCXXConstructExpr(clang::CXXConstructExpr
const*, clang::CodeGen::AggValueSlot) + 576
16 clang           0x00000000009a24d9
17 clang           0x00000000009a5630
18 clang           0x00000000009a61bb
clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot) + 587
19 clang           0x000000000097d088
clang::CodeGen::CodeGenFunction::EmitExprAsInit(clang::Expr const*,
clang::ValueDecl const*, clang::CodeGen::LValue, bool) + 760
20 clang           0x000000000097e839
clang::CodeGen::CodeGenFunction::EmitAutoVarInit(clang::CodeGen::CodeGenFunction::AutoVarEmission
const&) + 1401
21 clang           0x0000000000980181
clang::CodeGen::CodeGenFunction::EmitAutoVarDecl(clang::VarDecl const&) + 33
22 clang           0x0000000000a1f847
clang::CodeGen::CodeGenFunction::EmitDeclStmt(clang::DeclStmt const&) + 71
23 clang           0x0000000000a26775
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 245
24 clang           0x0000000000a23be7
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 39
25 clang           0x0000000000a2408f
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 239
26 clang           0x0000000000a26752
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 210
27 clang           0x0000000000a23be7
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 39
28 clang           0x0000000000a34c99
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 777
29 clang           0x0000000000916a89
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 745
30 clang           0x00000000009232c3
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 467
31 clang           0x00000000009236fa
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 778
32 clang           0x0000000000924734
33 clang           0x00000000009087ec
34 clang           0x0000000000907db6
35 clang           0x0000000000a50559 clang::ParseAST(clang::Sema&, bool, bool)
+ 297
36 clang           0x0000000000907024 clang::CodeGenAction::ExecuteAction() +
68
37 clang           0x00000000007abb33 clang::FrontendAction::Execute() + 131
38 clang           0x000000000078f2b9
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 329
39 clang           0x0000000000776a55
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1413
40 clang           0x000000000076eac8 cc1_main(char const**, char const**, char
const*, void*) + 1176
41 clang           0x0000000000775e52 main + 4834
42 libc.so.6       0x00000000059e8bc6 __libc_start_main + 230
43 clang           0x000000000076d991
Stack dump:
0.      Program arguments:
/dev/shm/uabpath/master/build-gcc471/Release+Debug+Asserts/bin/clang -cc1
-internal-isystem
/dev/shm/uabpath/master/build-gcc471/Release+Debug+Asserts/bin/../lib/clang/3.2/include
-fms-extensions -emit-llvm
/dev/shm/uabpath/master/tools/clang/test/CodeGenCXX/mangle-ms-templates.cpp -o
- -cxx-abi microsoft -triple=i386-p
c-win32
1.     
/dev/shm/uabpath/master/tools/clang/test/CodeGenCXX/mangle-ms-templates.cpp:73:1:
current parser token 'namespace'
2.     
/dev/shm/uabpath/master/tools/clang/test/CodeGenCXX/mangle-ms-templates.cpp:33:6:
LLVM IR generation of declaration 'template_mangling'
3.     
/dev/shm/uabpath/master/tools/clang/test/CodeGenCXX/mangle-ms-templates.cpp:33:6:
Generating code for declaration 'template_mangling'
4.     
/dev/shm/uabpath/master/tools/clang/test/CodeGenCXX/mangle-ms-templates.cpp:33:26:
LLVM IR generation of compound statement ('{}')

(gdb) bt
#0  0x00007ffff6f17945 in raise () from /lib64/libc.so.6
#1  0x00007ffff6f18f21 in abort () from /lib64/libc.so.6
#2  0x00007ffff6f10810 in __assert_fail () from /lib64/libc.so.6
#3  0x000000000072fbdc in llvm::cast<clang::TemplateSpecializationType,
clang::Type const*> (Val=<optimized out>) at
/dev/shm/uabpath/master/include/llvm/Support/Casting.h:208
#4  0x00000000012369dc in doit (Val=<optimized out>) at
/dev/shm/uabpath/master/include/llvm/Support/Casting.h:86
#5  doit (Val=<optimized out>) at
/dev/shm/uabpath/master/include/llvm/Support/Casting.h:113
#6  isa<clang::TemplateSpecializationType, clang::Type const*> (Val=<optimized
out>) at /dev/shm/uabpath/master/include/llvm/Support/Casting.h:124
#7  cast<clang::TemplateSpecializationType, clang::Type const*> (Val=<optimized
out>) at /dev/shm/uabpath/master/include/llvm/Support/Casting.h:208
#8  getTypePtr (this=0x7fffffff9860) at
/dev/shm/uabpath/master/tools/clang/lib/AST/../../include/clang/AST/TypeLoc.h:308
#9  getNumArgs (this=0x7fffffff9860) at
/dev/shm/uabpath/master/tools/clang/lib/AST/../../include/clang/AST/TypeLoc.h:1270
#10 isTemplate (TemplateArgs=..., ND=0x325af00) at
/dev/shm/uabpath/master/tools/clang/lib/AST/MicrosoftMangle.cpp:379
#11 (anonymous namespace)::MicrosoftCXXNameMangler::mangleUnqualifiedName
(this=this at entry=0x7fffffff9d30, ND=0x325af00, Name=...) at
/dev/shm/uabpath/master/tools/clang/lib/AST/MicrosoftMangle.cpp:404
#12 0x0000000001239dbb in mangleUnqualifiedName (ND=<optimized out>,
this=0x7fffffff9d30) at
/dev/shm/uabpath/master/tools/clang/lib/AST/MicrosoftMangle.cpp:65
#13 (anonymous namespace)::MicrosoftCXXNameMangler::manglePostfix
(this=0x7fffffff9d30, DC=0x325af38, NoFunction=false) at
/dev/shm/uabpath/master/tools/clang/lib/AST/MicrosoftMangle.cpp:541
#14 0x0000000001236f2d in (anonymous
namespace)::MicrosoftCXXNameMangler::mangleName (this=0x7fffffff9d30,
ND=0x325b260) at
/dev/shm/uabpath/master/tools/clang/lib/AST/MicrosoftMangle.cpp:303
#15 0x0000000001239067 in (anonymous
namespace)::MicrosoftCXXNameMangler::mangle (this=this at entry=0x7fffffff9d30,
D=0x325b260, Prefix=...) at
/dev/shm/uabpath/master/tools/clang/lib/AST/MicrosoftMangle.cpp:206
#16 0x0000000001239ea3 in (anonymous
namespace)::MicrosoftMangleContext::mangleCXXCtor (this=<optimized out>,
D=<optimized out>, Type=<optimized out>, Out=...) at
/dev/shm/uabpath/master/tools/clang/lib/AST/MicrosoftMangle.cpp:1695
#17 0x000000000091639f in clang::CodeGen::CodeGenModule::getMangledName
(this=0x3242a10, GD=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CodeGenModule.cpp:390
#18 0x0000000000948396 in
clang::CodeGen::CodeGenModule::GetAddrOfCXXConstructor (this=0x3242a10,
ctor=0x325b260, ctorType=clang::Ctor_Complete, fnInfo=0x0) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGCXX.cpp:218
#19 0x000000000095fd19 in
clang::CodeGen::CodeGenFunction::EmitCXXConstructorCall (this=0x7fffffffac20,
D=0x325b260, Type=clang::Ctor_Complete, ForVirtualBase=false, This=0x32690a8,
ArgBeg=..., ArgEnd=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGClass.cpp:1262
#20 0x00000000009a9d40 in clang::CodeGen::CodeGenFunction::EmitCXXConstructExpr
(this=0x7fffffffac20, E=0x325f7c0, Dest=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGExprCXX.cpp:509
#21 0x00000000009a24d9 in (anonymous
namespace)::AggExprEmitter::VisitCXXConstructExpr
(this=this at entry=0x7fffffffa520, E=E at entry=0x325f7c0) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGExprAgg.cpp:872
#22 0x00000000009a5630 in Visit (S=0x325f7c0, this=0x7fffffffa520) at
/dev/shm/uabpath/master/build-gcc471/tools/clang/lib/CodeGen/../../include/clang/AST/StmtNodes.inc:181
#23 clang::StmtVisitorBase<clang::make_ptr, {anonymous}::AggExprEmitter,
void>::Visit(clang::make_ptr<clang::Stmt>::type) (this=0x7fffffffa520,
S=0x325f7c0) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/../../include/clang/AST/StmtVisitor.h:38
#24 0x00000000009a61bb in clang::CodeGen::CodeGenFunction::EmitAggExpr
(this=0x7fffffffac20, E=0x325f7c0, Slot=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGExprAgg.cpp:1261
#25 0x000000000097d088 in clang::CodeGen::CodeGenFunction::EmitExprAsInit
(this=this at entry=0x7fffffffac20, init=init at entry=0x325f7c0,
D=D at entry=0x325f590, lvalue=..., capturedByInit=capturedByInit at entry=false) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGDecl.cpp:1127
#26 0x000000000097e839 in clang::CodeGen::CodeGenFunction::EmitAutoVarInit
(this=this at entry=0x7fffffffac20, emission=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGDecl.cpp:1046
#27 0x0000000000980181 in clang::CodeGen::CodeGenFunction::EmitAutoVarDecl
(this=0x7fffffffac20, D=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGDecl.cpp:773
#28 0x0000000000a1f847 in clang::CodeGen::CodeGenFunction::EmitDeclStmt
(this=0x7fffffffac20, S=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGStmt.cpp:809
#29 0x0000000000a26775 in clang::CodeGen::CodeGenFunction::EmitSimpleStmt
(this=<optimized out>, S=<optimized out>) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGStmt.cpp:176
#30 0x0000000000a23be7 in clang::CodeGen::CodeGenFunction::EmitStmt
(this=0x7fffffffac20, S=0x325f7f0) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGStmt.cpp:47
#31 0x0000000000a2408f in clang::CodeGen::CodeGenFunction::EmitCompoundStmt
(this=0x7fffffffac20, S=..., GetLast=GetLast at entry=false, AggSlot=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGStmt.cpp:203
#32 0x0000000000a26752 in clang::CodeGen::CodeGenFunction::EmitSimpleStmt
(this=<optimized out>, S=<optimized out>) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGStmt.cpp:175
#33 0x0000000000a23be7 in clang::CodeGen::CodeGenFunction::EmitStmt
(this=0x7fffffffac20, S=0x32636b8) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CGStmt.cpp:47
#34 0x0000000000a34c99 in clang::CodeGen::CodeGenFunction::GenerateCode
(this=0x7fffffffac20, GD=..., Fn=0x3262ad0, FnInfo=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CodeGenFunction.cpp:538
#35 0x0000000000916a89 in
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition
(this=this at entry=0x3242a10, GD=GD at entry=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CodeGenModule.cpp:1955
#36 0x00000000009232c3 in clang::CodeGen::CodeGenModule::EmitGlobalDefinition
(this=this at entry=0x3242a10, GD=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CodeGenModule.cpp:1089
#37 0x00000000009236fa in clang::CodeGen::CodeGenModule::EmitGlobal
(this=this at entry=0x3242a10, GD=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CodeGenModule.cpp:965
#38 0x0000000000924734 in clang::CodeGen::CodeGenModule::EmitTopLevelDecl
(this=0x3242a10, D=0x325b620) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CodeGenModule.cpp:2626
#39 0x00000000009087ec in (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl (this=0x3225820, DG=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/ModuleBuilder.cpp:69
#40 0x0000000000907db6 in clang::BackendConsumer::HandleTopLevelDecl
(this=0x32256b0, D=...) at
/dev/shm/uabpath/master/tools/clang/lib/CodeGen/CodeGenAction.cpp:105
#41 0x0000000000a50559 in clang::ParseAST (S=..., PrintStats=false,
SkipFunctionBodies=<optimized out>) at
/dev/shm/uabpath/master/tools/clang/lib/Parse/ParseAST.cpp:99
#42 0x0000000000907024 in clang::CodeGenAction::ExecuteAction (this=0x31f69b0)
at /dev/shm/uabpath/master/tools/clang/lib/CodeGen/CodeGenAction.cpp:423
#43 0x00000000007abb33 in clang::FrontendAction::Execute (this=0x31f69b0) at
/dev/shm/uabpath/master/tools/clang/lib/Frontend/FrontendAction.cpp:383
#44 0x000000000078f2b9 in clang::CompilerInstance::ExecuteAction
(this=0x31f5cb0, Act=...) at
/dev/shm/uabpath/master/tools/clang/lib/Frontend/CompilerInstance.cpp:688
#45 0x0000000000776a55 in clang::ExecuteCompilerInvocation (Clang=0x31f5cb0) at
/dev/shm/uabpath/master/tools/clang/lib/FrontendTool/ExecuteCompilerInvocation.cpp:189
#46 0x000000000076eac8 in cc1_main (ArgBegin=0x7fffffffc968,
ArgEnd=0x7fffffffc9b8, Argv0=0x31f5698
"/dev/shm/uabpath/master/build-gcc471/Release+Debug+Asserts/bin/clang",
MainAddr=0x771f80 <GetExecutablePath(char const*, bool)>) at
/dev/shm/uabpath/master/tools/clang/tools/driver/cc1_main.cpp:91
#47 0x0000000000775e52 in main (argc_=<optimized out>, argv_=<optimized out>)
at /dev/shm/uabpath/master/tools/clang/tools/driver/driver.cpp:358


The error report from valgrind seems to be related to stack item 10 above, i.e.
TSTL at MicrosoftMangle.cpp:379 seems to be unitilialized.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 12 07:59:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 15:59:17 +0000
Subject: [LLVMbugs] [Bug 14322] New: add warning for invalid code when
 -fdelayed-template-parsing is used
Message-ID: <bug-14322-206@http.llvm.org/bugs/>

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

             Bug #: 14322
           Summary: add warning for invalid code when
                    -fdelayed-template-parsing is used
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: seth.cantrell at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


-fdelayed-template-parsing is offered for compatibility with code that depends
on two-phase name lookup not being performed correctly. This functionality is
enabled by default for some platforms.

This means that invalid code can compile silently without the user requesting,
intending to use, or even being aware of delayed template parsing.

It would be nice if -fdelayed-template-parsing simply caused the error to decay
into a warning, which could be disabled for legacy code bases which truly
desire the functionality.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 12 11:26:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 19:26:15 +0000
Subject: [LLVMbugs] [Bug 14316] [patch] pretty print for anonymous structure
 dereference is buggy
In-Reply-To: <bug-14316-206@http.llvm.org/bugs/>
References: <bug-14316-206@http.llvm.org/bugs/>
Message-ID: <bug-14316-206-xXjWeZ1iea@http.llvm.org/bugs/>

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

Florent Bruneau <florent.bruneau_llvm at m4x.org> changed:

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

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


From bugzilla-daemon at llvm.org  Mon Nov 12 12:55:22 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 12 Nov 2012 20:55:22 +0000
Subject: [LLVMbugs] [Bug 14283] assertion fail: VMCore/Instructions.cpp:1080
 "Ptr must be a pointer to Val type!" [powerpc-darwin8]
In-Reply-To: <bug-14283-206@http.llvm.org/bugs/>
References: <bug-14283-206@http.llvm.org/bugs/>
Message-ID: <bug-14283-206-hvx1QnGPZx@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #6 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-12 14:55:22 CST ---
Found it.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 12 18:05:19 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 02:05:19 +0000
Subject: [LLVMbugs] [Bug 14324] New: LLVM fails to build if both NDEBUG and
 LLVM_ENABLE_DUMP are defined
Message-ID: <bug-14324-206@http.llvm.org/bugs/>

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

             Bug #: 14324
           Summary: LLVM fails to build if both NDEBUG and
                    LLVM_ENABLE_DUMP are defined
           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: chithanh at gentoo.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9528
  --> http://llvm.org/bugs/attachment.cgi?id=9528
llvm-dump-defines.patch

This is because in one place in include/llvm/CodeGen/MachineScheduler.h and two
places in lib/Transforms/Scalar/SROA.cpp it is only checked for NDEBUG, and not
for LLVM_ENABLE_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  Mon Nov 12 18:05:33 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 02:05:33 +0000
Subject: [LLVMbugs] [Bug 11777] ppc "Ptr must be a pointer to Val type!"
In-Reply-To: <bug-11777-206@http.llvm.org/bugs/>
References: <bug-11777-206@http.llvm.org/bugs/>
Message-ID: <bug-11777-206-s9TkuKIYqG@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #4 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-12 20:05:33 CST ---
r167802.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 00:12:23 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 08:12:23 +0000
Subject: [LLVMbugs] [Bug 14325] New: Crash after aborting module compilation
Message-ID: <bug-14325-206@http.llvm.org/bugs/>

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

             Bug #: 14325
           Summary: Crash after aborting module compilation
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dirkjan at ochtman.nl
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


djc at djc-mbp lang $ cat test.ll 
target triple = "x86_64-apple-darwin11.0.0"
declare void @llvm.memcpy.p0i8.p0i8.i32(i8*, i8*, i32, i32, i1)
define void @test(i8* %a, i8* %b, i32 %len) {
    %i = alloca i1
    store i1 0, i1* %i
    %al = load i1* %i
    call void @llvm.memcpy.p0i8.p0i8.i32(i8* %a, i8* %b, i32 %len, i32 1, i1
%al)
    ret void
}
djc at djc-mbp lang $ clang test.ll 
isvolatile argument of memory intrinsics must be a constant int
  call void @llvm.memcpy.p0i8.p0i8.i32(i8* %a, i8* %b, i32 %len, i32 1, i1 %al)
Broken module found, compilation aborted!
0  clang             0x000000010b9f03c1
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
769
1  clang             0x000000010b9f0753
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
1683
2  libsystem_c.dylib 0x00007fff9186d8ea _sigtramp + 26
3  libstdc++.6.dylib 0x00007fff9502c347 operator new(unsigned long) + 34
4  clang             0x000000010b9f05d6
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
1302
5  clang             0x000000010b9bb608 std::basic_string<char,
std::char_traits<char>, std::allocator<char> > std::operator+<char,
std::char_traits<char>, std::allocator<char> >(char const*,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
+ 6032
6  clang             0x000000010b9ba4aa std::basic_string<char,
std::char_traits<char>, std::allocator<char> > std::operator+<char,
std::char_traits<char>, std::allocator<char> >(char const*,
std::basic_string<char, std::char_traits<char>, std::allocator<char> > const&)
+ 1586
7  clang             0x000000010b9abaaf std::vector<llvm::StructType*,
std::allocator<llvm::StructType*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::StructType**,
std::vector<llvm::StructType*, std::allocator<llvm::StructType*> > >,
llvm::StructType* const&) + 16861
8  clang             0x000000010b9ab5b6 std::vector<llvm::StructType*,
std::allocator<llvm::StructType*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::StructType**,
std::vector<llvm::StructType*, std::allocator<llvm::StructType*> > >,
llvm::StructType* const&) + 15588
9  clang             0x000000010b9ab503 std::vector<llvm::StructType*,
std::allocator<llvm::StructType*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::StructType**,
std::vector<llvm::StructType*, std::allocator<llvm::StructType*> > >,
llvm::StructType* const&) + 15409
10 clang             0x000000010ada84c8
std::vector<clang::serialization::ModuleFile*,
std::allocator<clang::serialization::ModuleFile*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::serialization::ModuleFile**,
std::vector<clang::serialization::ModuleFile*,
std::allocator<clang::serialization::ModuleFile*> > >,
clang::serialization::ModuleFile* const&) + 5878
11 clang             0x000000010ae578f8 std::vector<clang::CXXRecordDecl
const*, std::allocator<clang::CXXRecordDecl const*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::CXXRecordDecl const**,
std::vector<clang::CXXRecordDecl const*, std::allocator<clang::CXXRecordDecl
const*> > >, clang::CXXRecordDecl const* const&) + 5592
12 clang             0x000000010acd26c4 std::vector<clang::CompilerInstance*,
std::allocator<clang::CompilerInstance*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<clang::CompilerInstance**,
std::vector<clang::CompilerInstance*, std::allocator<clang::CompilerInstance*>
> >, clang::CompilerInstance* const&) + 11042
13 clang             0x000000010acc0137 std::basic_string<char,
std::char_traits<char>, std::allocator<char> > std::operator+<char,
std::char_traits<char>, std::allocator<char> >(char, std::basic_string<char,
std::char_traits<char>, std::allocator<char> > const&) + 3151
14 clang             0x000000010acb9444
15 clang             0x000000010acbd4a4 std::vector<std::string,
std::allocator<std::string>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<std::string*,
std::vector<std::string, std::allocator<std::string> > >, std::string const&) +
1350
16 libdyld.dylib     0x00007fff920d17e1 start + 0
Stack dump:
0.    Program arguments: /usr/local/Cellar/llvm/3.1/bin/clang -cc1 -triple
x86_64-apple-macosx10.8.0 -emit-obj -mrelax-all -disable-free -main-file-name
test.ll -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 134.9 -resource-dir
/usr/local/Cellar/llvm/3.1/bin/../lib/clang/3.1 -fdebug-compilation-dir
/Users/djc/src/lang -ferror-limit 19 -fmessage-length 100 -stack-protector 1
-mstackrealign -fblocks -fobjc-runtime-has-arc -fobjc-runtime-has-weak
-fobjc-dispatch-method=mixed -fobjc-default-synthesize-properties
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/kx/r0q_5lzx0jj0v8rkt8xq1qd40000gn/T/test-HxkypX.o -x ir test.ll 
1.    Per-function optimization
2.    Running pass 'Module Verifier' on function '@test'
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (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.
djc at djc-mbp lang $ clang -v
clang version 3.1 (branches/release_31)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

No need to add a stacktrace after the error message. (Also, the LangRef fails
to clarify the need for constant arguments.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 05:31:22 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 13:31:22 +0000
Subject: [LLVMbugs] [Bug 14326] New: Call __cxa_end_cleanup instead of
 _Unwind_Resume by ARM EHABI
Message-ID: <bug-14326-206@http.llvm.org/bugs/>

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

             Bug #: 14326
           Summary: Call __cxa_end_cleanup instead of _Unwind_Resume by
                    ARM EHABI
           Product: libraries
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: wenhan.gu at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hi all,

According to ARM EHABI, we should call __cxa_end_cleanup but not _Unwind_Resume
directly on not SjLj environment.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 07:40:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 15:40:11 +0000
Subject: [LLVMbugs] [Bug 13221] __PIC__ no longer defined when -fPIE is used
In-Reply-To: <bug-13221-206@http.llvm.org/bugs/>
References: <bug-13221-206@http.llvm.org/bugs/>
Message-ID: <bug-13221-206-dNOv2UlrBV@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-13 09:40:11 CST ---
Fixed in r167846.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 09:53:13 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 17:53:13 +0000
Subject: [LLVMbugs] [Bug 13532] Assert on expanded UINT_TO_FP on backends
 without native f64 support (e.g. Mips and MBlaze)
In-Reply-To: <bug-13532-206@http.llvm.org/bugs/>
References: <bug-13532-206@http.llvm.org/bugs/>
Message-ID: <bug-13532-206-jIAm0uGcP7@http.llvm.org/bugs/>

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

Akira Hatanaka <ahatanak at gmail.com> changed:

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

--- Comment #2 from Akira Hatanaka <ahatanak at gmail.com> 2012-11-13 11:53:13 CST ---
Fixed in r162728.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 11:29:45 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 19:29:45 +0000
Subject: [LLVMbugs] [Bug 14327] New:
 MultiSource/Benchmarks/MiBench/network-patricia/patricia_test including
 soon to be obsolete rpc/rpc.h
Message-ID: <bug-14327-206@http.llvm.org/bugs/>

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

             Bug #: 14327
           Summary: MultiSource/Benchmarks/MiBench/network-patricia/patric
                    ia_test including soon to be obsolete rpc/rpc.h
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Programs Tests
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bkirby at mips.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9531
  --> http://llvm.org/bugs/attachment.cgi?id=9531
Patch to fix network-partricia

I'm testing LLVM with a recent version of glibc and GCC which wasn't configured
with the --enable-obsolete-rpc option and I found that the
MultiSource/Benchmarks/MiBench/network-patricia/patricia_test wouldn't pass. 
It is trying to include rpc/rpc.h, and fails to build the control binary with
GCC when it can't find it.  It doesn't look like it needs it for the test to
pass, though.  

I've attached a simple patch to fix the test case which just removes the
include line.  I compared the output with the reference data and it still
matches.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 15:10:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 23:10:20 +0000
Subject: [LLVMbugs] [Bug 14328] New: Rewriter::overwriteChangedFiles()
 extremely dangerous when running as root.
Message-ID: <bug-14328-206@http.llvm.org/bugs/>

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

             Bug #: 14328
           Summary: Rewriter::overwriteChangedFiles() extremely dangerous
                    when running as root.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: morgon.kanter at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I've been using clang's Rewriter to perform source-to-source transforms on
specific source files. If a rewrite changes (accidentally or otherwise) a
system include file, and you call overwriteChangedFiles(), and you have write
permission, the include file will be modified. I believe this is rarely desired
behavior, and it is performed silently.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 15:17:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 13 Nov 2012 23:17:02 +0000
Subject: [LLVMbugs] [Bug 14318] Objective-C properties of types with
 non-trivial special members leads to wrong code and sometimes assert
In-Reply-To: <bug-14318-206@http.llvm.org/bugs/>
References: <bug-14318-206@http.llvm.org/bugs/>
Message-ID: <bug-14318-206-GgrsBEkt3h@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-13 17:17:02 CST ---
r167884.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 16:05:43 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 00:05:43 +0000
Subject: [LLVMbugs] [Bug 14328] Rewriter::overwriteChangedFiles() extremely
 dangerous when running as root.
In-Reply-To: <bug-14328-206@http.llvm.org/bugs/>
References: <bug-14328-206@http.llvm.org/bugs/>
Message-ID: <bug-14328-206-WNoWWk1SVy@http.llvm.org/bugs/>

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

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nlewycky at google.com
         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  Tue Nov 13 16:10:14 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 00:10:14 +0000
Subject: [LLVMbugs] [Bug 14329] New: Docutils documentation lacks.
Message-ID: <bug-14329-206@http.llvm.org/bugs/>

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

             Bug #: 14329
           Summary: Docutils documentation lacks.
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: alexfh at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


There's no (at least no easily discoverable) information on how to write/update
RST documentation files. One has to figure out what tools to use in order to
check syntax, then to find and install a compatible version of the docutils,
etc.

FYI: Ubuntu 12.04 has docutils version 0.8.1, which doesn't handle the
code-block construct. So the setup process isn't straightforward.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 16:15:48 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 00:15:48 +0000
Subject: [LLVMbugs] [Bug 14330] New: Clang does not pass the GDB 7.5 test
	suite
Message-ID: <bug-14330-206@http.llvm.org/bugs/>

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

             Bug #: 14330
           Summary: Clang does not pass the GDB 7.5 test suite
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: echristo at gmail.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is to track all work to validate & clean up the GDB 7.5 test suite results
for Clang. Any bugs representing Clang failures on the test suite should be
marked as blocking 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  Tue Nov 13 16:18:33 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 00:18:33 +0000
Subject: [LLVMbugs] [Bug 14331] New: Clang does not support -gdwarf-4
Message-ID: <bug-14331-206@http.llvm.org/bugs/>

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

             Bug #: 14331
           Summary: Clang does not support -gdwarf-4
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: echristo at gmail.com, llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


gdb/testsuite/gdb.dwarf2/dw4-sig-types.exp

Implement support (possibly just as an accept-and-ignore-for-gcc-compat) for
the dwarf-4 debug type flag (-gdwarf-4) for compatibility with gcc 4.7 & to
help pass the GDB 7.5 test suite which requires 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 Nov 13 16:20:24 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 00:20:24 +0000
Subject: [LLVMbugs] [Bug 14332] New: Implement -fsplit-stack
Message-ID: <bug-14332-206@http.llvm.org/bugs/>

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

             Bug #: 14332
           Summary: Implement -fsplit-stack
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


gdb/testsuite/gdb.base/morestack.exp

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 16:20:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 00:20:26 +0000
Subject: [LLVMbugs] [Bug 3830] clang-driver 32 bit pcc arch name incorrect
In-Reply-To: <bug-3830-206@http.llvm.org/bugs/>
References: <bug-3830-206@http.llvm.org/bugs/>
Message-ID: <bug-3830-206-Z2tVOgp1ZT@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |fang at csl.cornell.edu
         Resolution|FIXED                       |

--- Comment #2 from David Fang <fang at csl.cornell.edu> 2012-11-13 18:20:26 CST ---
This currently fails for me, as of r167855.

[fangism:~/temp/clang] fang% make bool.o
~/local/src/LLVM-svn/gcc40-cmake-build/bin/clang++  -c bool.cc -o bool.o

[fangism:~/temp/clang] fang% cat hello.cc 
#include <iostream>

int
main(int argc, char* argv[]) {
        std::cout << "Hello, world!" << std::endl;
        int x = 0;
        int y = x+2;
        std::cout << "y = " << y << std::endl;
        return 0;
}


[fangism:~/temp/clang] fang% ~/local/src/LLVM-svn/gcc40-cmake-build/bin/clang++
bool.o -o bool
/usr/bin/ld: unknown architecture specification flag: -arch powerpc
/usr/bin/ld: Usage: /usr/bin/ld [options] file [...]
clang-3: error: linker command failed with exit code 1 (use -v to see
invocation)

[fangism:~/temp/clang] fang% ~/local/src/LLVM-svn/gcc40-cmake-build/bin/clang++
bool.o -arch ppc -o bool
/usr/bin/ld: unknown architecture specification flag: -arch powerpc
/usr/bin/ld: Usage: /usr/bin/ld [options] file [...]
clang-3: error: linker command failed with exit code 1 (use -v to see
invocation)

My host is a powerpc7400 on darwin8.11.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 Nov 13 16:49:57 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 00:49:57 +0000
Subject: [LLVMbugs] [Bug 14333] New: assertion fail: Cannot delete a node
 that is not dead
Message-ID: <bug-14333-206@http.llvm.org/bugs/>

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

             Bug #: 14333
           Summary: assertion fail: Cannot delete a node that is not dead
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


llc crashes on:

%foo = type { i64, i64 }
define void @bar(%foo* %zed) {
  %tmp = getelementptr inbounds %foo* %zed, i64 0, i32 0
  store i64 0, i64* %tmp, align 8
  %tmp2 = getelementptr inbounds %foo* %zed, i64 0, i32 1
  store i64 0, i64* %tmp2, align 8
  %tmp3 = bitcast %foo* %zed to i8*
  call void @llvm.memset.p0i8.i64(i8* %tmp3, i8 0, i64 16, i32 8, i1 false)
  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 Nov 13 18:10:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 02:10:30 +0000
Subject: [LLVMbugs] [Bug 14334] New: [-Wdocumentation] Could we handle "<u"
 more relaxed?
Message-ID: <bug-14334-206@http.llvm.org/bugs/>

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

             Bug #: 14334
           Summary: [-Wdocumentation] Could we handle "<u" more relaxed?
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: ASSIGNED
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: gribozavr at gmail.com
        ReportedBy: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


llvm/lib/Transforms/InstCombine/InstCombineAndOrXor.cpp:272:17: error:
      HTML start tag prematurely ended, expected attribute name or '>'
      [-Werror,-Wdocumentation]
/// (V-Lo) <u Hi-Lo.  This method expects that Lo <= Hi. isSigned indicates
                ^
1 error generated.

--

"<u" is generally used in llvm.

Although I have no idea for Doxygen how to handle open "<u",
Could we handle brackets more relaxed, if they didn't look like tags?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 18:17:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 02:17:44 +0000
Subject: [LLVMbugs] [Bug 14335] New: [-Wdocumentation] Multiple identifiers
 (comma, separated) are not recognized on \param
Message-ID: <bug-14335-206@http.llvm.org/bugs/>

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

             Bug #: 14335
           Summary: [-Wdocumentation] Multiple identifiers
                    (comma,separated) are not recognized on \param
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: ASSIGNED
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: gribozavr at gmail.com
        ReportedBy: geek4civic at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang/lib/CodeGen/CGClass.cpp:1092:12: error:
      parameter 'argBegin,argEnd' not found in the function declaration
      [-Werror,-Wdocumentation]
/// \param argBegin,argEnd the arguments to evaluate and pass to the
           ^~~~~~~~~~~~~~~
IMO it is well-known description.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 18:29:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 02:29:46 +0000
Subject: [LLVMbugs] [Bug 14336] New: clang++ segfaults when compiling code
 that composes functors (c++11)
Message-ID: <bug-14336-206@http.llvm.org/bugs/>

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

             Bug #: 14336
           Summary: clang++ segfaults when compiling code that composes
                    functors (c++11)
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: brunonery+bugzilla at brunonery.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9532
  --> http://llvm.org/bugs/attachment.cgi?id=9532
Output of clang++ bug.cpp -std=c++11 -O0 -emit-llvm -save-temps

clang++-3.1 (obtained from dr-graef's ppa:
http://ppa.launchpad.net/dr-graef/llvm-3.1.precise/ubuntu) segfaults when
compiling code that composes functors (c++11).

clang++ was run as:

clang++ bug.cpp -std=c++11 -O0 -emit-llvm -save-temps

g++-4.7 compiles it correctly.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 21:10:19 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 05:10:19 +0000
Subject: [LLVMbugs] [Bug 14333] assertion fail: Cannot delete a node that is
	not dead
In-Reply-To: <bug-14333-206@http.llvm.org/bugs/>
References: <bug-14333-206@http.llvm.org/bugs/>
Message-ID: <bug-14333-206-IsjlviM9cn@http.llvm.org/bugs/>

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

Rafael Ávila de Espíndola <rafael.espindola at gmail.com> changed:

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

--- Comment #2 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> 2012-11-13 23:10:19 CST ---
Turns out that r165267 just found the bug, it didn't introduce it. Fixed in
r167912.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 13 22:07:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 06:07:03 +0000
Subject: [LLVMbugs] [Bug 14337] New: UNREACHABLE executed at
 CallingConvLower.cpp:111 when returning v4f64 on ARM
Message-ID: <bug-14337-206@http.llvm.org/bugs/>

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

             Bug #: 14337
           Summary: UNREACHABLE executed at CallingConvLower.cpp:111 when
                    returning v4f64 on ARM
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: craig.topper at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9533
  --> http://llvm.org/bugs/attachment.cgi?id=9533
Test case

Trying to return a v4f64 or v8f32 and probably other larger vectors causes an
UNREACHABLE to be executed in CallingConvLower.cpp when compiling for ARM.

Stack trace

Return operand #4 has unhandled type i32
UNREACHABLE executed at lib/CodeGen/CallingConvLower.cpp:111!
0  llc               0x000000010da5a08e PrintStackTrace(void*) + 46
1  llc               0x000000010da5a6a8 SignalHandler(int) + 408
2  libsystem_c.dylib 0x00007fff8ee898ea _sigtramp + 26
3  libsystem_c.dylib 0x00007fa0634104b0 _sigtramp + 18446743664955255776
4  llc               0x000000010da5a35b raise + 27
5  llc               0x000000010da5a412 abort + 18
6  llc               0x000000010da2f076 llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 198
7  llc               0x000000010d2b29e7
llvm::CCState::AnalyzeReturn(llvm::SmallVectorImpl<llvm::ISD::OutputArg>
const&, bool (*)(unsigned int, llvm::MVT, llvm::MVT,
llvm::CCValAssign::LocInfo, llvm::ISD::ArgFlagsTy, llvm::CCState&)) + 327
8  llc               0x000000010ccf68df
llvm::ARMTargetLowering::LowerReturn(llvm::SDValue, llvm::CallingConv::ID,
bool, llvm::SmallVectorImpl<llvm::ISD::OutputArg> const&,
llvm::SmallVectorImpl<llvm::SDValue> const&, llvm::DebugLoc,
llvm::SelectionDAG&) const + 335
9  llc               0x000000010d117814
llvm::SelectionDAGBuilder::visitRet(llvm::ReturnInst const&) + 3572
10 llc               0x000000010d1162ae
llvm::SelectionDAGBuilder::visit(unsigned int, llvm::User const&) + 110
11 llc               0x000000010d1157e4
llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 132
12 llc               0x000000010d186e5c
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 140
13 llc               0x000000010d186c2b
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 3979
14 llc               0x000000010d184ec6
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 998
15 llc               0x000000010d399b1e
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 110
16 llc               0x000000010d99e81f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 431
17 llc               0x000000010d99eb1d
llvm::FPPassManager::runOnModule(llvm::Module&) + 125
18 llc               0x000000010d99f021
llvm::MPPassManager::runOnModule(llvm::Module&) + 1185
19 llc               0x000000010d99f9ad
llvm::PassManagerImpl::run(llvm::Module&) + 157
20 llc               0x000000010d99fbc1 llvm::PassManager::run(llvm::Module&) +
33
21 llc               0x000000010c9439c1 main + 7809
22 libdyld.dylib     0x00007fff9469e7e1 start + 0
23 libdyld.dylib     0x0000000000000005 start + 18446603338026194980


Test case is attached.

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


From bugzilla-daemon at llvm.org  Tue Nov 13 23:29:21 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 07:29:21 +0000
Subject: [LLVMbugs] [Bug 14338] New: clang tries to compile fortran itself
Message-ID: <bug-14338-206@http.llvm.org/bugs/>

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

             Bug #: 14338
           Summary: clang tries to compile fortran itself
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: bob.wilson at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This is a recent regression:

$ clang -x f95 foo.f
error: invalid value 'f95' in '-x f95'
$ clang -x f94 foo.f
clang: error: language not recognized: 'f94'

The second error is emitted by clang. The first one is emitted by clang -cc1,
which really shouldn't happen. We ought to run gcc on fortran files.

Bob, I'm suspicious of your r167567 and thought you might like to take a look.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 02:59:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 10:59:11 +0000
Subject: [LLVMbugs] [Bug 14327]
 MultiSource/Benchmarks/MiBench/network-patricia/patricia_test including
 soon to be obsolete rpc/rpc.h
In-Reply-To: <bug-14327-206@http.llvm.org/bugs/>
References: <bug-14327-206@http.llvm.org/bugs/>
Message-ID: <bug-14327-206-BFy81XYmqg@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2012-11-14 04:59:11 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155815.html
Thanks for 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  Wed Nov 14 08:31:58 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 16:31:58 +0000
Subject: [LLVMbugs] [Bug 12745] Documentation needs minor update: C++11
 standard is no longer draft
In-Reply-To: <bug-12745-206@http.llvm.org/bugs/>
References: <bug-12745-206@http.llvm.org/bugs/>
Message-ID: <bug-12745-206-Ajmy1XfZmC@http.llvm.org/bugs/>

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

Marshall Clow (home) <mtclow at gmail.com> changed:

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

--- Comment #1 from Marshall Clow (home) <mtclow at gmail.com> 2012-11-14 10:31:58 CST ---
Updated the documentation to remove all "C++0x" references in r167930.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 11:16:53 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 19:16:53 +0000
Subject: [LLVMbugs] [Bug 14252] crash when parsing invalid c++11 code
 involving lambdas and PCH
In-Reply-To: <bug-14252-206@http.llvm.org/bugs/>
References: <bug-14252-206@http.llvm.org/bugs/>
Message-ID: <bug-14252-206-r0rJebA9vR@http.llvm.org/bugs/>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #9 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2012-11-14 13:16:53 CST ---
Fixed in r167946

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 11:21:52 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 19:21:52 +0000
Subject: [LLVMbugs] [Bug 13291] NVPTX backend does not implement store on i1
In-Reply-To: <bug-13291-206@http.llvm.org/bugs/>
References: <bug-13291-206@http.llvm.org/bugs/>
Message-ID: <bug-13291-206-oIN0RFg04Y@http.llvm.org/bugs/>

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

Justin Holewinski <justin.holewinski at gmail.com> changed:

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

--- Comment #1 from Justin Holewinski <justin.holewinski at gmail.com> 2012-11-14 13:21:52 CST ---
Fixed in r167948.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 12:16:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 20:16:11 +0000
Subject: [LLVMbugs] [Bug 14339] New: Virtual methods allowed to have
 mismatching calling convention
Message-ID: <bug-14339-206@http.llvm.org/bugs/>

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

             Bug #: 14339
           Summary: Virtual methods allowed to have mismatching calling
                    convention
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: daniel.c.klauer at web.de
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9537
  --> http://llvm.org/bugs/attachment.cgi?id=9537
virtual override with mismatching calling conventions

clang++ does not show an error (nor a warning) when an overriding method uses a
different calling convention than the overridden virtual, for example:

    class A {
        public:
            __attribute__((stdcall)) virtual void f();
    };

    class B : public A {
        public:
            __attribute__((cdecl)) void f();
    };

This code should trigger an error though, because the functions are
incompatible, similar to the following example:

    void (__attribute__((stdcall)) *p1)();
    void (__attribute__((cdecl)) *p2)();
    p1 = p2;

which triggers an "assigning to '...' from incompatible type '...'" error.

Looking at the LLVM IR output of -S -emit-llvm shows that the stdcall method is
emitted with x86_stdcallcc, and the call following the vtable lookup also uses
x86_stdcallcc, even though the loaded address points to a cdecl function.

A full example is attached. Compiling it with GCC's g++ shows a "conflicting
type attributes specified ..." error as expected; see also gcc bug 14688 [1].

Tested with:

    $ clang++ --version
    Ubuntu clang version 3.0-6ubuntu3 (tags/RELEASE_30/final) (based on LLVM
3.0)
    Target: i386-pc-linux-gnu
    Thread model: posix

    $ build/Debug+Asserts/bin/clang++ --version
    clang version 3.2 (trunk 167930)
    Target: i386-pc-linux-gnu
    Thread model: posix

but presumably all x86 targets are affected.

[1] http://gcc.gnu.org/bugzilla/show_bug.cgi?id=14688

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 12:17:04 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 20:17:04 +0000
Subject: [LLVMbugs] [Bug 2962] stack realignment code does not work with
 alloca in function
In-Reply-To: <bug-2962-206@http.llvm.org/bugs/>
References: <bug-2962-206@http.llvm.org/bugs/>
Message-ID: <bug-2962-206-25GUPypeYe@http.llvm.org/bugs/>

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

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

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

--- Comment #12 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-14 14:17:04 CST ---
Reverted r58317 in r167967.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 12:40:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 20:40:30 +0000
Subject: [LLVMbugs] [Bug 14340] New: constexpr related compiler error after
	r167514
Message-ID: <bug-14340-206@http.llvm.org/bugs/>

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

             Bug #: 14340
           Summary: constexpr related compiler error after r167514
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: akyrtzi at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9538
  --> http://llvm.org/bugs/attachment.cgi?id=9538
preprocessed file

The attached preprocessed file would parse without compiler errors, but after
r167514 it gives this error:
error: no matching constructor for initialization of 'duration'

Run on clang like this:
$ clang -fsyntax-only main.cpp -std=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  Wed Nov 14 14:02:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 22:02:03 +0000
Subject: [LLVMbugs] [Bug 14341] New: clang -fsanitize=undefined fails to
 link files correctly
Message-ID: <bug-14341-206@http.llvm.org/bugs/>

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

             Bug #: 14341
           Summary: clang -fsanitize=undefined fails to link files
                    correctly
           Product: compiler-rt
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: compiler-rt
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: lostphifunction at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I've built trunk LLVM (r167974), clang, and compiler-rt on Ubuntu 12.10 i386
using the configure script and make.

When I try to compile files with "clang -fsanitize=address" everything works as
expected, but when I do "clang -fsanitize=undefined" I get a linking error
saying

/usr/bin/ld: cannot find
/usr/local/bin/../lib/clang/3.2/lib/linux/libclang_rt.ubsan-i386.a: No such
file or directory

In that directory exists libclang_rt.asan-i386.a, libclang_rt.full-i386.a, and
libclang_rt.profile-i386.a, but there is no ubsan library.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 14:10:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 22:10:30 +0000
Subject: [LLVMbugs] [Bug 9559] post-increment in formal argument list ignored
In-Reply-To: <bug-9559-206@http.llvm.org/bugs/>
References: <bug-9559-206@http.llvm.org/bugs/>
Message-ID: <bug-9559-206-VpDZyGRgbo@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #9 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-14 16:10:30 CST ---
r167985.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 14:46:14 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 22:46:14 +0000
Subject: [LLVMbugs] [Bug 14342] New: Assertion `IsUnsigned ==
 RHS.IsUnsigned` APSInt.h:139 (r167157)
Message-ID: <bug-14342-206@http.llvm.org/bugs/>

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

             Bug #: 14342
           Summary: Assertion `IsUnsigned == RHS.IsUnsigned` APSInt.h:139
                    (r167157)
           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: gasper.azman at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Clang asked me to submit this so I am. I checked other signedness mismatch
reports and they looked similar, but not quite the same, so I'm still
submitting.

This was the backtrace:

Assertion failed: (IsUnsigned == RHS.IsUnsigned && "Signedness mismatch!"),
function operator==, file
/Volumes/work/macports/var/macports/build/_Volumes_work_mports_dports_lang_llvm-3.2/clang-3.2/work/trunk/include/llvm/ADT/APSInt.h,
line 139.
0  libLLVM-3.2svn.dylib 0x0000000111d4be52 _ZL15PrintStackTracePv + 34
1  libLLVM-3.2svn.dylib 0x0000000111d4c379 _ZL13SignalHandleri + 713
2  libsystem_c.dylib    0x00007fff9a8bbcfa _sigtramp + 26
3  clang                0x000000011049f50d
clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity
const&, clang::InitializationKind const&, llvm::MutableArrayRef<clang::Expr*>,
clang::QualType*) + 4845
4  libLLVM-3.2svn.dylib 0x0000000111d4c096 abort + 22
5  libLLVM-3.2svn.dylib 0x0000000111d4c055 __assert_rtn + 53
6  clang                0x0000000110955f90 (anonymous
namespace)::TemplateDiff::DiffTemplate(clang::TemplateSpecializationType
const*, clang::TemplateSpecializationType const*) + 4208
7  clang                0x0000000110951b46
clang::FormatASTNodeDiagnosticArgument(clang::DiagnosticsEngine::ArgumentKind,
long, char const*, unsigned int, char const*, unsigned int,
std::pair<clang::DiagnosticsEngine::ArgumentKind, long> const*, unsigned int,
llvm::SmallVectorImpl<char>&, void*, llvm::ArrayRef<long>) + 1558
8  clang                0x0000000110acf8ea
clang::Diagnostic::FormatDiagnostic(char const*, char const*,
llvm::SmallVectorImpl<char>&) const + 2378
9  clang                0x000000011004d189
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&) + 121
10 clang                0x0000000110ad3a68
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const + 504
11 clang                0x0000000110acee39
clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) + 89
12 clang                0x0000000110312107
clang::Sema::EmitCurrentDiagnostic(unsigned int) + 1543
13 clang                0x00000001104a1471
clang::InitializationSequence::Diagnose(clang::Sema&, clang::InitializedEntity
const&, clang::InitializationKind const&, clang::Expr**, unsigned int) + 1713
14 clang                0x000000011049e282
clang::InitializationSequence::Perform(clang::Sema&, clang::InitializedEntity
const&, clang::InitializationKind const&, llvm::MutableArrayRef<clang::Expr*>,
clang::QualType*) + 98
15 clang                0x000000011039922b
clang::Sema::AddInitializerToDecl(clang::Decl*, clang::Expr*, bool, bool) +
3067
16 clang                0x00000001105a0387
clang::TemplateDeclInstantiator::VisitVarDecl(clang::VarDecl*) + 1479
17 clang                0x00000001105ac11c
clang::DeclVisitor<clang::TemplateDeclInstantiator,
clang::Decl*>::Visit(clang::Decl*) + 796
18 clang                0x00000001105a844b clang::Sema::SubstDecl(clang::Decl*,
clang::DeclContext*, clang::MultiLevelTemplateArgumentList const&) + 107
19 clang                0x00000001105882ad clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 3021
20 clang                0x00000001105993d3 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformCompoundStmt(clang::CompoundStmt*,
bool) + 211
21 clang                0x00000001105881e4 clang::TreeTransform<(anonymous
namespace)::TemplateInstantiator>::TransformStmt(clang::Stmt*) + 2820
22 clang                0x00000001105876a7 clang::Sema::SubstStmt(clang::Stmt*,
clang::MultiLevelTemplateArgumentList const&) + 71
23 clang                0x00000001105a9841
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 1921
24 clang                0x00000001105aa753
clang::Sema::PerformPendingInstantiations(bool) + 483
25 clang                0x0000000110310417
clang::Sema::ActOnEndOfTranslationUnit() + 439
26 clang                0x00000001102db1e0
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 176
27 clang                0x000000011026f2c6 clang::ParseAST(clang::Sema&, bool,
bool) + 342
28 clang                0x00000001102321cd
clang::CodeGenAction::ExecuteAction() + 1277
29 clang                0x000000011002826b clang::FrontendAction::Execute() +
107
30 clang                0x0000000110007cef
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 991
31 clang                0x000000010ffcfcd9
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3385
32 clang                0x000000010ffc655c cc1_main(char const**, char const**,
char const*, void*) + 3004
33 clang                0x000000010ffcbd5b main + 683
34 clang                0x000000010ffc5994 start + 52
Stack dump:
0.    Program arguments: /opt/local/libexec/llvm-3.2/bin/clang -cc1 -triple
x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free -main-file-name
libnb_main.cpp -pic-level 2 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 134.9 -g -coverage-file
/Users/atomicity/work/berkeley/neuroblaze/nb/CMakeFiles/nbtest.dir/libnb_main.cpp.o
-resource-dir /opt/local/libexec/llvm-3.2/bin/../lib/clang/3.2 -I
/opt/local/include -I /opt/local/include/matio.h -fmodule-cache-path
/var/folders/m_/3_5ql04s76d72m5n787y6cxh0000gn/T/clang-module-cache
-stdlib=libc++ -Wall -Wshadow -Wextra -pedantic -std=c++11 -fdeprecated-macro
-fdebug-compilation-dir /Users/atomicity/work/berkeley/neuroblaze/nb
-ferror-limit 19 -fmessage-length 202 -stack-protector 1 -mstackrealign
-fblocks -fobjc-runtime=macosx-10.7.0 -fobjc-dispatch-method=mixed
-fobjc-default-synthesize-properties -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
CMakeFiles/nbtest.dir/libnb_main.cpp.o -x c++
/Users/atomicity/work/berkeley/neuroblaze/nb/libnb_main.cpp 
1.    <eof> parser at end of file
2.    /Users/atomicity/work/berkeley/neuroblaze/nb/libnb.hpp:1261:9:
instantiating function definition 'operator()'
clang: error: unable to execute command: Illegal instruction: 4
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (trunk 167157)
Target: x86_64-apple-darwin11.4.1
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg:
/var/folders/m_/3_5ql04s76d72m5n787y6cxh0000gn/T/libnb_main-UJSFp3.cpp
clang: note: diagnostic msg:
/var/folders/m_/3_5ql04s76d72m5n787y6cxh0000gn/T/libnb_main-UJSFp3.sh
clang: note: diagnostic msg:

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 15:34:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 23:34:44 +0000
Subject: [LLVMbugs] [Bug 14343] New: grammatical error in comments
Message-ID: <bug-14343-206@http.llvm.org/bugs/>

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

             Bug #: 14343
           Summary: grammatical error in comments
           Product: Documentation
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: humbug at deeptown.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


grep "Return whether information about whether" * -R

include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for call sites) -
Return whether information about whether
include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for calls) - Return
whether information about whether
include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for invokes) -
Return whether information about whether
include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for loads) - Return
whether information about whether
include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for stores) - Return
whether information about whether
include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for fences) - Return
whether information about whether
include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for cmpxchges) -
Return whether information about whether
include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for atomicrmws) -
Return whether information about whether
include/llvm/Analysis/AliasAnalysis.h:  /// getModRefInfo (for va_args) -
Return whether information about whether

I will tell everybody LLVM can prove weather forecasts.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 15:38:47 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 23:38:47 +0000
Subject: [LLVMbugs] [Bug 14344] New: Clean up and fix X86 CPU features
Message-ID: <bug-14344-206@http.llvm.org/bugs/>

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

             Bug #: 14344
           Summary: Clean up and fix X86 CPU features
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jkim at FreeBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9541
  --> http://llvm.org/bugs/attachment.cgi?id=9541
Improve X86 CPU features

I have an AMD Family 10h processor and I realized that LZCNT and POPCNT are not
enabled by default.  Then, I looked at lib/Basic/Targets.cpp and found it needs
some love. :-)

Please see the attached patch.

- AMD SSE4A capable processors have LZCNT, POPCNT, and SSE3 instructions.
- AMD Piledriver("bdver2") processors have BMI and FMA instructions.
- All SSE levels enable MMX by default.
- All AVX capable processors have PCLMUL instruction.
- Sync. F16C feature with LLVM's X86.td.

Jung-uk Kim

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 15:57:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 14 Nov 2012 23:57:46 +0000
Subject: [LLVMbugs] [Bug 14342] Assertion `IsUnsigned == RHS.IsUnsigned`
 APSInt.h:139 (r167157)
In-Reply-To: <bug-14342-206@http.llvm.org/bugs/>
References: <bug-14342-206@http.llvm.org/bugs/>
Message-ID: <bug-14342-206-RYLxRZQFfc@http.llvm.org/bugs/>

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

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> 2012-11-14 17:57:46 CST ---
r168005.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 16:33:22 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 00:33:22 +0000
Subject: [LLVMbugs] [Bug 14345] New: clang assert fails with noreturn
	attribute
Message-ID: <bug-14345-206@http.llvm.org/bugs/>

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

             Bug #: 14345
           Summary: clang assert fails with noreturn attribute
           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: boulos at cs.stanford.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Compiling a simple test case with ToT as:

clang -emit-llvm -c a.c

[a.c]
__attribute__((noreturn)) void foo();

void other() {
   foo();
}

Produces an overly protective assert.  I believe this used to work in
clang-3.1:


Assertion failed: (Attrs[i].Attrs.hasAttributes() && "Pointless attribute!"),
function get, file Attributes.cpp, line 421.
0  libLLVM-3.2svn.dylib 0x00000001019c5a82 PrintStackTrace(void*) + 34
1  libLLVM-3.2svn.dylib 0x00000001019c6079 SignalHandler(int) + 761
2  libSystem.B.dylib    0x00007fff852401ba _sigtramp + 26
3  libSystem.B.dylib    000000000000000000 _sigtramp + 2061237856
4  libLLVM-3.2svn.dylib 0x00000001019c5cd6 abort + 22
5  libLLVM-3.2svn.dylib 0x00000001019c5c98 __assert_rtn + 56
6  libLLVM-3.2svn.dylib 0x00000001014bcd00
llvm::AttrListPtr::get(llvm::ArrayRef<llvm::AttributeWithIndex>) + 992
7  clang                0x00000001002a67a0
clang::CodeGen::CodeGenModule::SetLLVMFunctionAttributes(clang::Decl const*,
clang::CodeGen::CGFunctionInfo const&, llvm::Function*) + 112
8  clang                0x00000001002a6ee1
clang::CodeGen::CodeGenModule::SetFunctionAttributes(clang::GlobalDecl,
llvm::Function*, bool) + 161
9  clang                0x00000001002a883e
clang::CodeGen::CodeGenModule::GetOrCreateLLVMFunction(llvm::StringRef,
llvm::Type*, clang::GlobalDecl, bool, llvm::Attributes) + 350
....

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 16:37:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 00:37:35 +0000
Subject: [LLVMbugs] [Bug 14334] [-Wdocumentation] Could we handle "<u" more
	relaxed?
In-Reply-To: <bug-14334-206@http.llvm.org/bugs/>
References: <bug-14334-206@http.llvm.org/bugs/>
Message-ID: <bug-14334-206-5gYGcaHzLf@http.llvm.org/bugs/>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #5 from NAKAMURA Takumi <geek4civic at gmail.com> 2012-11-14 18:37:35 CST ---
Fixed as "\<u" in llvm r168013.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 16:38:38 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 00:38:38 +0000
Subject: [LLVMbugs] [Bug 14346] New: BBVectorize can enter infinite loop in
	x86
Message-ID: <bug-14346-206@http.llvm.org/bugs/>

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

             Bug #: 14346
           Summary: BBVectorize can enter infinite loop in x86
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


When using the x86 code model, BBVectorize can enter an infinite loop
vectorizing its own shuffle chains (the ones it had created as part of previous
vectorization steps).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 16:38:55 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 00:38:55 +0000
Subject: [LLVMbugs] [Bug 14346] BBVectorize can enter infinite loop in x86
In-Reply-To: <bug-14346-206@http.llvm.org/bugs/>
References: <bug-14346-206@http.llvm.org/bugs/>
Message-ID: <bug-14346-206-moUOMu1LT0@http.llvm.org/bugs/>

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

Hal Finkel <hfinkel at anl.gov> changed:

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

--- Comment #1 from Hal Finkel <hfinkel at anl.gov> 2012-11-14 18:38:55 CST ---
Fixed in r167817.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 16:42:22 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 00:42:22 +0000
Subject: [LLVMbugs] [Bug 14347] New: BBVectorize is non-deterministic
Message-ID: <bug-14347-206@http.llvm.org/bugs/>

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

             Bug #: 14347
           Summary: BBVectorize is non-deterministic
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The vectorization plan selection phase iterated over the children of the
current node using a DenseMap. Unfortunately, the order of the iteration
mattered (because given two children of the same weight, the first one would be
chosen).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 16:42:45 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 00:42:45 +0000
Subject: [LLVMbugs] [Bug 14347] BBVectorize is non-deterministic
In-Reply-To: <bug-14347-206@http.llvm.org/bugs/>
References: <bug-14347-206@http.llvm.org/bugs/>
Message-ID: <bug-14347-206-hBJKwkTYDx@http.llvm.org/bugs/>

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

Hal Finkel <hfinkel at anl.gov> changed:

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

--- Comment #1 from Hal Finkel <hfinkel at anl.gov> 2012-11-14 18:42:45 CST ---
Fixed in r167942, r167966.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 17:26:57 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 01:26:57 +0000
Subject: [LLVMbugs] [Bug 14349] New: Assertion in SROA around rewriting
 store instruction implicitly using a vector data type
Message-ID: <bug-14349-206@http.llvm.org/bugs/>

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

             Bug #: 14349
           Summary: Assertion in SROA around rewriting store instruction
                    implicitly using a vector data type
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: liujiangning1 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hi,

For the following case,

$ cat bad1.ll
target datalayout =
"e-p:32:32:32-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:64:128-a0:0:64-n32-S64"

define internal void @test(i32 %v) {
entry:
  %tmp = alloca i32, align 4
  store i32 %v, i32* %tmp, align 4
  %0 = bitcast i32* %tmp to <2 x i8>*
  %1 = load <2 x i8>* %0, align 4
  ret void
}

I have the following failure message for command line "opt -sroa bad.ll -o
bad.bc".

$ opt -sroa bad.ll -o bad.bc
opt: llvm/lib/Transforms/Scalar/SROA.cpp:2063: llvm::Value* convertValue(const
llvm::DataLayout&, llvm::IRBuilder<>&, llvm::Value*, llvm::Type*): Assertion
`canConvertValue(DL, V->getType(), Ty) && "Value not convertable to type"'
failed.
0  opt       0x08f44f52
1  opt       0x08f44bac
2            0xb7736400 __kernel_sigreturn + 0
3            0xb7736424 __kernel_vsyscall + 16
4  libc.so.6 0xb7482c8f gsignal + 79
5  libc.so.6 0xb74862b5 abort + 373
6  libc.so.6 0xb747b826 __assert_fail + 246
7  opt       0x08b109d7
8  opt       0x08b135ef
9  opt       0x08b13b15
10 opt       0x08b1fea4
11 opt       0x08b1d7e1
12 opt       0x08b1adbc
13 opt       0x08b11ec8
14 opt       0x08b18177
15 opt       0x08b182c5
16 opt       0x08b186fc
17 opt       0x08b19142
18 opt       0x08e62c4a llvm::FPPassManager::runOnFunction(llvm::Function&) +
306
19 opt       0x08e62dfe llvm::FPPassManager::runOnModule(llvm::Module&) + 114
20 opt       0x08e630cc llvm::MPPassManager::runOnModule(llvm::Module&) + 400
21 opt       0x08e635b6 llvm::PassManagerImpl::run(llvm::Module&) + 122
22 opt       0x08e63749 llvm::PassManager::run(llvm::Module&) + 39
23 opt       0x084556a5 main + 5635
24 libc.so.6 0xb746e113 __libc_start_main + 243
25 opt       0x08445bf1
Stack dump:
0.    Program arguments: opt -sroa bad.ll -o bad.bc 
1.    Running pass 'Function Pass Manager' on module 'bad.ll'.
2.    Running pass 'SROA' on function '@_Z7vstore2Dv2_cjPU10AS16776960c'
Aborted

Is it a bug in SROA?

With the following patch, it seems the problem can be fixed. Any idea?

diff --git a/lib/Transforms/Scalar/SROA.cpp b/lib/Transforms/Scalar/SROA.cpp
index d95c855..696107a 100644
--- a/lib/Transforms/Scalar/SROA.cpp
+++ b/lib/Transforms/Scalar/SROA.cpp
@@ -2608,8 +2608,6 @@ private:
     assert(OldOp == OldPtr);
     IRBuilder<> IRB(&SI);

-    if (VecTy)
-      return rewriteVectorizedStoreInst(IRB, SI, OldOp);
     Type *ValueTy = SI.getValueOperand()->getType();

     uint64_t Size = EndOffset - BeginOffset;
@@ -2644,6 +2642,9 @@ private:
       return IsConvertable;
     }

+    if (VecTy)
+      return rewriteVectorizedStoreInst(IRB, SI, OldOp);
+
     if (IntTy && ValueTy->isIntegerTy())
       return rewriteIntegerStore(IRB, SI);

Thanks,
-Jiangning

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 17:46:14 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 01:46:14 +0000
Subject: [LLVMbugs] [Bug 13982] Assertion `ReadingKind == Read_Stmt &&
 "Should be called only during statement reading!"' failed
In-Reply-To: <bug-13982-206@http.llvm.org/bugs/>
References: <bug-13982-206@http.llvm.org/bugs/>
Message-ID: <bug-13982-206-YUnMILcOpq@http.llvm.org/bugs/>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #3 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2012-11-14 19:46:14 CST ---
Fixed in r168017.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 14 22:35:40 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 06:35:40 +0000
Subject: [LLVMbugs] [Bug 13827] clang allows non-deleted virtual function to
 be overridden by a deleted function
In-Reply-To: <bug-13827-206@http.llvm.org/bugs/>
References: <bug-13827-206@http.llvm.org/bugs/>
Message-ID: <bug-13827-206-CACnXQ4phk@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-15 00:35:40 CST ---
This was fixed a little while 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  Wed Nov 14 23:32:21 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 07:32:21 +0000
Subject: [LLVMbugs] [Bug 14350] New: class passing itself as a template
 template parameter errors in initializer list
Message-ID: <bug-14350-206@http.llvm.org/bugs/>

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

             Bug #: 14350
           Summary: class passing itself as a template template parameter
                    errors in initializer list
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: trick at icculus.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In the following code, clang accepts the first instance of A<B>, but rejects
the second one (in the initializer list) with "template argument for template
template parameter must be a class template or type alias template":

template <template <typename> class D> struct A
{
    A () {}
};

template <typename T> struct B : A<B>
{
    B () : A<B>() {}
};

typedef also fails with the same error. g++ compiles this without 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  Wed Nov 14 23:51:45 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 07:51:45 +0000
Subject: [LLVMbugs] [Bug 14350] class passing itself as a template template
 parameter errors in initializer list
In-Reply-To: <bug-14350-206@http.llvm.org/bugs/>
References: <bug-14350-206@http.llvm.org/bugs/>
Message-ID: <bug-14350-206-pMojhOUAdV@http.llvm.org/bugs/>

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

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> 2012-11-15 01:51:45 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 00:19:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 08:19:39 +0000
Subject: [LLVMbugs] [Bug 14073] Missing -Wuninitialized warning for
 self-initialization of anonymous union member
In-Reply-To: <bug-14073-206@http.llvm.org/bugs/>
References: <bug-14073-206@http.llvm.org/bugs/>
Message-ID: <bug-14073-206-mOPPfQGP4W@http.llvm.org/bugs/>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2012-11-15 02:19:39 CST ---
Fixed in r168031.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 01:14:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 09:14:02 +0000
Subject: [LLVMbugs] [Bug 9061] -Wuninitialized false positive due to for
 loop always executing at least once
In-Reply-To: <bug-9061-206@http.llvm.org/bugs/>
References: <bug-9061-206@http.llvm.org/bugs/>
Message-ID: <bug-9061-206-qpLoHkD1H0@http.llvm.org/bugs/>

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

Nick Lewycky <nlewycky at google.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nlewycky at google.com
         Resolution|                            |FIXED

--- Comment #2 from Nick Lewycky <nlewycky at google.com> 2012-11-15 03:14:02 CST ---
Closing bug since Ted says it's 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 Nov 15 01:43:24 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 09:43:24 +0000
Subject: [LLVMbugs] [Bug 14313] Custom project configuration error
In-Reply-To: <bug-14313-206@http.llvm.org/bugs/>
References: <bug-14313-206@http.llvm.org/bugs/>
Message-ID: <bug-14313-206-Lko9cu5ExT@http.llvm.org/bugs/>

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

wojtek.danilo at gmail.com changed:

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

--- Comment #5 from wojtek.danilo at gmail.com 2012-11-15 03:43:24 CST ---
I found out that this bug is easly solvable, the only thing needed is to change
the LLVM_OBJ_ROOT variable in autoconf/configure.ac file.
This should be added to the LLVM custom project setting manual.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 03:00:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 11:00:02 +0000
Subject: [LLVMbugs] [Bug 14351] New: BasicAA confused after LSR
Message-ID: <bug-14351-206@http.llvm.org/bugs/>

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

             Bug #: 14351
           Summary: BasicAA confused after LSR
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hfinkel at anl.gov
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9545
  --> http://llvm.org/bugs/attachment.cgi?id=9545
Post-LSR IR

BasicAA is confused by LSR, and this causes aliasing-analysis based dependency
breaking to be ineffective on unrolled loops.

After LSR, the basic form of the loop is:
for.body4:                                        ; preds = %for.body4,
%for.cond2.preheader
  %lsr.iv4 = phi [16000 x double]* [ %11, %for.body4 ], [ bitcast (double*
getelementptr inbounds ([16000 x double]* @Y, i64 0, i64 8)
 to [16000 x double]*), %for.cond2.preheader ]
  %lsr.iv1 = phi [16000 x double]* [ %10, %for.body4 ], [ @X,
%for.cond2.preheader ]
  %lsr.iv = phi i32 [ %lsr.iv.next, %for.body4 ], [ 16000, %for.cond2.preheader
]
  %lsr.iv46 = bitcast [16000 x double]* %lsr.iv4 to <4 x double>*
  %lsr.iv12 = bitcast [16000 x double]* %lsr.iv1 to <4 x double>*
...
 %scevgep11 = getelementptr <4 x double>* %lsr.iv46, i64 -2
  %6 = load <4 x double>* %scevgep11, align 32, !tbaa !0
...
  store <4 x double> %add, <4 x double>* %lsr.iv12, align 32, !tbaa !0
...
  %scevgep = getelementptr [16000 x double]* %lsr.iv1, i64 0, i64 16
  %10 = bitcast double* %scevgep to [16000 x double]*
  %scevgep5 = getelementptr [16000 x double]* %lsr.iv4, i64 0, i64 16
  %11 = bitcast double* %scevgep5 to [16000 x double]*

pointers derived from %lsr.iv4 and %lsr.iv1 come from different underlying
objects, but BasicAA does not see this.

  MayAlias:     <4 x double>* %lsr.iv12, <4 x double>* %scevgep11

The full test case is attached.

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


From bugzilla-daemon at llvm.org  Thu Nov 15 03:27:59 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 11:27:59 +0000
Subject: [LLVMbugs] [Bug 14352] New: -Wuninitialized on partially
 uninitialized value in union
Message-ID: <bug-14352-206@http.llvm.org/bugs/>

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

             Bug #: 14352
           Summary: -Wuninitialized on partially uninitialized value in
                    union
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I was recently bitten by this code:

  float f();

  int foo() {
    union {
      float a;
      int b;
    } x = { f() };
    return x.b;
  }

On a 64-bit system, the int is 64-bits and the float is 32-bits, there's no
zero-initialization of the padding, and so 'x.b' has the top-half uninitialized
bits and the bottom-half initialized. I would like a -Wuninitialized warning on
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  Thu Nov 15 04:10:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 12:10:39 +0000
Subject: [LLVMbugs] [Bug 14353] New: TLS variables should not be Constant
Message-ID: <bug-14353-206@http.llvm.org/bugs/>

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

             Bug #: 14353
           Summary: TLS variables should not be Constant
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


TLS variables are a special case of GlobalVariable, which inherit from
Constant.

But a TLS variable is not really Constant, it is different for different
threads. This can cause subtle bugs, such as Bug 14309, if the optimizers fail
to take it into account.

Some discussion here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/155805.html

It would be good if we could find a way so that TLS variables were not Constant
to avoid optimizers getting this wrong.

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


From bugzilla-daemon at llvm.org  Thu Nov 15 04:12:55 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 12:12:55 +0000
Subject: [LLVMbugs] [Bug 13720] Clang allows global initializers to take the
 address of __thread (TLS) variables
In-Reply-To: <bug-13720-206@http.llvm.org/bugs/>
References: <bug-13720-206@http.llvm.org/bugs/>
Message-ID: <bug-13720-206-BV10BanlgM@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #3 from Hans Wennborg <hans at chromium.org> 2012-11-15 06:12:55 CST ---
(In reply to comment #2)
> Leaving the bug open as I guess LLVM might need an update too.

Closing this and tracking the LLVM issue in Bug 14353.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 07:19:00 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 15:19:00 +0000
Subject: [LLVMbugs] [Bug 14336] clang++ segfaults when compiling code that
 composes functors (c++11)
In-Reply-To: <bug-14336-206@http.llvm.org/bugs/>
References: <bug-14336-206@http.llvm.org/bugs/>
Message-ID: <bug-14336-206-Zz0vvx8roH@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-15 09:19:00 CST ---
Fixed in r168045.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 07:51:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 15:51:03 +0000
Subject: [LLVMbugs] [Bug 14354] New: operator overloading fails while
 debugging with gdb for i386.
Message-ID: <bug-14354-206@http.llvm.org/bugs/>

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

             Bug #: 14354
           Summary: operator overloading fails while debugging with gdb
                    for i386.
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mayur.p at samsung.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9547
  --> http://llvm.org/bugs/attachment.cgi?id=9547
assembly file for the code

For the given test: 

class A1 {
  int x;
  int y;

  public:

  A1(int a, int b)
  {
   x=a;
   y=b;
  }

A1 operator+(const A1&);
};


A1 A1::operator+(const A1& second)
{
 A1 sum(0,0);
 sum.x = x + second.x;
 sum.y = y + second.y;

 return (sum);
}


int main (void)
{
 A1 one(2,3);
 A1 two(4,5);

 return 0;
}


when the exectable of this code is debugged in gdb for i386, we dont get the
expected results.

when we break at return 0; and give the command: print one + two, the result
should be $1 = {x = 6, y = 8}, but the result obtained is $1 = {x = 2, y = 3}.

This is related to debug information generated, as normally the overloading is
occuring.
eg: A1 three = one + two results {x = 6, y = 8}.


On checking the assembly, a suspicious entry is found which may be related for
the failure:

    #DEBUG_VALUE: operator+:this <- undef
    #DEBUG_VALUE: operator+:second <- undef

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 08:01:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 16:01:35 +0000
Subject: [LLVMbugs] [Bug 14274] double free or corruption with lamba
 expression in template using libstdc++
In-Reply-To: <bug-14274-206@http.llvm.org/bugs/>
References: <bug-14274-206@http.llvm.org/bugs/>
Message-ID: <bug-14274-206-NJAqEBVXT5@http.llvm.org/bugs/>

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

Markus Trippelsdorf <markus at trippelsdorf.de> changed:

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

--- Comment #4 from Markus Trippelsdorf <markus at trippelsdorf.de> 2012-11-15 10:01:35 CST ---
(In reply to comment #3)
> Is this still an issue? I can't reproduce the bug and valgrind is silent.

Yes. The issue is gone on todays 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  Thu Nov 15 08:43:56 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 16:43:56 +0000
Subject: [LLVMbugs] [Bug 14355] New: crash in IR generation
Message-ID: <bug-14355-206@http.llvm.org/bugs/>

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

             Bug #: 14355
           Summary: crash in IR generation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: markus at trippelsdorf.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


arkus at x4 /tmp % cat test.ii
template<typename = int>struct B;
struct A
{};
template<typename>struct B : A
{};
namespace tools {
template<class F, class T>
void foo(F p1, T, T, T, int, int&)
{
  p1(0);
}
}
int a;
void
bar()
{
  typedef B<>F3 (double);
  F3 b;
  tools::foo(&b, 0, 0, 0, 0, a);
}

markus at x4 /tmp % clang++ -c test.ii
0  clang           0x0000000001a1727f
1  clang           0x0000000001a175d0
2  libpthread.so.0 0x00007f13ca5e4220
3  clang           0x0000000001930240
llvm::ConstantFoldCastInstruction(unsigned int, llvm::Constant*, llvm::Type*) +
96
4  clang           0x0000000001937979
5  clang           0x0000000000787244
6  clang           0x000000000078f4aa
clang::CodeGen::CodeGenFunction::EmitCall(clang::CodeGen::CGFunctionInfo
const&, llvm::Value*, clang::CodeGen::ReturnValueSlot,
clang::CodeGen::CallArgList const&, clang::Decl const*, llvm::Instruction**) +
6282
7  clang           0x00000000007c7592
clang::CodeGen::CodeGenFunction::EmitCall(clang::QualType, llvm::Value*,
clang::CodeGen::ReturnValueSlot, clang::ConstExprIterator,
clang::ConstExprIterator, clang::Decl const*) + 306
8  clang           0x00000000007d1e1d
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 285
9  clang           0x00000000007db44b
10 clang           0x00000000007d66e7
clang::CodeGen::CodeGenFunction::EmitAggExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot) + 4071
11 clang           0x00000000007c3a81
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 129
12 clang           0x00000000007ced8f
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 47
13 clang           0x00000000008545f7
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 87
14 clang           0x0000000000854870
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 240
15 clang           0x0000000000856d8c
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 172
16 clang           0x00000000008545b5
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 21
17 clang           0x000000000086664e
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 526
18 clang           0x000000000074fc8d
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 397
19 clang           0x00000000007599e3
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 291
20 clang           0x0000000000759b59
clang::CodeGen::CodeGenModule::EmitDeferred() + 153
21 clang           0x0000000000759b89 clang::CodeGen::CodeGenModule::Release()
+ 9
22 clang           0x0000000000744d40
23 clang           0x0000000000882843 clang::ParseAST(clang::Sema&, bool, bool)
+ 547
24 clang           0x0000000000606511 clang::FrontendAction::Execute() + 81
25 clang           0x00000000005e9022
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 290
26 clang           0x00000000005d2c86
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1478
27 clang           0x00000000005caf88 cc1_main(char const**, char const**, char
const*, void*) + 904
28 clang           0x00000000005d212f main + 7567
29 libc.so.6       0x00007f13c9cf3895 __libc_start_main + 245
30 clang           0x00000000005caa89
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name test.ii -mrelocation-model static
-mdisable-fp-elim -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version
2.23.51.20121113 -momit-leaf-frame-pointer -coverage-file /var/tmp/tmp/test.o
-resource-dir /usr/local/bin/../lib/clang/3.2 -fdeprecated-macro
-fdebug-compilation-dir /tmp -ferror-limit 19 -fmessage-length 174
-mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o test.o -x c++-cpp-output
test.ii 
1.      <eof> parser at end of file
2.      Per-file LLVM IR generation
3.      test.ii:8:6: Generating code for declaration 'tools::foo'
4.      test.ii:9:1: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: Error generating preprocessed source(s) - no
preprocessable inputs.


This testcase was obtained by further reducing the on of Bug 12774.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 11:05:04 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 19:05:04 +0000
Subject: [LLVMbugs] [Bug 14356] New: ARM setExecutionDomain causes "Bad
 machine code: Using an undefined physical register"
Message-ID: <bug-14356-206@http.llvm.org/bugs/>

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

             Bug #: 14356
           Summary: ARM setExecutionDomain causes "Bad machine code: Using
                    an undefined physical register"
           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: atrick at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9549
  --> http://llvm.org/bugs/attachment.cgi?id=9549
read_arch.ll

The attached test case (read_arch.ll) is from CINT2000/175.vpr. Reproduce the
assert with:
llc read_arch.ll -verify-machineinstrs -march=thumb -mcpu=cortex-a9

The problem is that ARM's setExecuction marks the high half of the D register
as an implicit use (%S1<imp-use>). S1 is actually clobbered by the previous
call, so this is incorrect w.r.t. liveness. It looks to me like it should be
marked <undef> instead, but I may be missing something. I'd like the original
author to fix it.

In isolation this doesn't look like a terrible bug. However it can currently
lead to assertions inside the PostRAscheduler which runs after ExecutionDomain.
So even though the attached test requires -verify-machineinstr, it is a real
bug that can show up in default clang invocation.

Ideally, no late passes would rely on implicit operands for precise liveness,
but in the near term, this bug still needs 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  Thu Nov 15 13:17:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 21:17:35 +0000
Subject: [LLVMbugs] [Bug 14357] New: Need SPIR64 target for release 3.2
Message-ID: <bug-14357-206@http.llvm.org/bugs/>

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

             Bug #: 14357
           Summary: Need SPIR64 target for release 3.2
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: guy.benyei at intel.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


In the OpenCL SPIR working group, we are aimed at creating a generic portable
intermediate representation for OpenCL (or probably some other uses), based on
LLVM. We targeted LLVM 3.2 as foundation for SPIR, and we also got the SPIR
target triple and two new calling convention committed to the LLVM mainline and
hence to the 3.2 branch.
Due to some discussions at the LLVM developers’ conference, we decided to add
an additional target for 64 bit architectures. . It is committed already to the
main trunk, but we managed to commit it after the creation of the 3.2 branch.
It would be very important for us to get this patch committed to the 3.2 branch
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  Thu Nov 15 13:42:41 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 21:42:41 +0000
Subject: [LLVMbugs] [Bug 14331] Clang does not support -gdwarf-4
In-Reply-To: <bug-14331-206@http.llvm.org/bugs/>
References: <bug-14331-206@http.llvm.org/bugs/>
Message-ID: <bug-14331-206-C3Zkjhuutt@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #4 from David Blaikie <dblaikie at gmail.com> 2012-11-15 15:42:41 CST ---
I think this is no-repro. May've been caused by my own problems/uncertainties
running the 7.5 test suite. Will reopen if I find it again with more precise
repro steps.

Thanks for the pointer, Chad.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 14:44:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 22:44:49 +0000
Subject: [LLVMbugs] [Bug 13964] [ARM,
	NEON] "cannot select v2f32 = fp_round" crash
In-Reply-To: <bug-13964-206@http.llvm.org/bugs/>
References: <bug-13964-206@http.llvm.org/bugs/>
Message-ID: <bug-13964-206-Z6Fi9sQ0tK@http.llvm.org/bugs/>

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

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> 2012-11-15 16:44:49 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 14:45:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 22:45:11 +0000
Subject: [LLVMbugs] [Bug 12540] ARM backend fails with: Cannot select: v2f32
	= fp_round
In-Reply-To: <bug-12540-206@http.llvm.org/bugs/>
References: <bug-12540-206@http.llvm.org/bugs/>
Message-ID: <bug-12540-206-umkPA14SR3@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #6 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-15 16:45:11 CST ---
r168107.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 15:24:04 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 23:24:04 +0000
Subject: [LLVMbugs] [Bug 14358] New: implementation problem with
 istreambuf_iterator operator++
Message-ID: <bug-14358-206@http.llvm.org/bugs/>

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

             Bug #: 14358
           Summary: implementation problem with istreambuf_iterator
                    operator++
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: kdt3rd at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9550
  --> http://llvm.org/bugs/attachment.cgi?id=9550
proposed patch to fix

per 24.6.3.4, the effect of operator++ should only be to call sbumpc on the
streambuf, not to actually trigger a sgetc which will cause underflow to
happen.

per 24.6.3.5, the effect of operator++(int) is similarly not currently correct

Attached is a patch which I believe fixes 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  Thu Nov 15 15:41:02 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 15 Nov 2012 23:41:02 +0000
Subject: [LLVMbugs] [Bug 14355] crash in IR generation
In-Reply-To: <bug-14355-206@http.llvm.org/bugs/>
References: <bug-14355-206@http.llvm.org/bugs/>
Message-ID: <bug-14355-206-1QKtbJGwZw@http.llvm.org/bugs/>

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

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> 2012-11-15 17:41:02 CST ---
r168112.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 16:08:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 00:08:39 +0000
Subject: [LLVMbugs] [Bug 9903] Member function typedef on weird declaration
	crash
In-Reply-To: <bug-9903-206@http.llvm.org/bugs/>
References: <bug-9903-206@http.llvm.org/bugs/>
Message-ID: <bug-9903-206-ggmyM9boYI@http.llvm.org/bugs/>

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

Brian Brooks <brooks.brian at gmail.com> changed:

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

--- Comment #2 from Brian Brooks <brooks.brian at gmail.com> 2012-11-15 18:08:39 CST ---
http://lists.cs.uiuc.edu/pipermail/cfe-commits/Week-of-Mon-20121112/068279.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  Thu Nov 15 17:16:19 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 01:16:19 +0000
Subject: [LLVMbugs] [Bug 14321] r167602 'make check-all' fails in
 CodeGenCXX/mangle-ms-templates.cpp, built with gcc-4.7.1 for x86_64
In-Reply-To: <bug-14321-206@http.llvm.org/bugs/>
References: <bug-14321-206@http.llvm.org/bugs/>
Message-ID: <bug-14321-206-h8nilj7QZ9@http.llvm.org/bugs/>

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

Matt Beaumont-Gay <matthewbg at google.com> changed:

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

--- Comment #1 from Matt Beaumont-Gay <matthewbg at google.com> 2012-11-15 19:16:19 CST ---
Fixed in r168124.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 15 18:59:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 02:59:39 +0000
Subject: [LLVMbugs] [Bug 14359] New: ARM backend should generate vabs q,
 q for v4f32 vector type
Message-ID: <bug-14359-206@http.llvm.org/bugs/>

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

             Bug #: 14359
           Summary: ARM backend should generate vabs q, q for v4f32 vector
                    type
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dpeixott at codeaurora.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Currently, the ARM backend marks the FABS as EXPAND for the v4f32 type. For the
following bitcode:

define <4 x float> @test(<4 x float> %a) {
  %foo = call <4 x float> @llvm.fabs.v4f32(<4 x float> %a)
  ret <4 x float> %foo
}
declare <4 x float> @llvm.fabs.v4f32(<4 x float> %a)

We will generate:

        vmov    d1, r2, r3
        vmov    d0, r0, r1
        vabs.f32        s7, s3
        vabs.f32        s6, s2
        vabs.f32        s5, s1
        vabs.f32        s4, s0
        vmov    r0, r1, d2
        vmov    r2, r3, d3

It would be better to generate the vector version of vabs.f32 using a Q
register. Something like:

        vmov    d1, r2, r3
        vmov    d0, r0, r1
        vabs.f32        q1, q0
        vmov    r0, r1, d2
        vmov    r2, r3, d3


We need to improve the instruction selector to generate these instructions.
Without the EXPAND directive for v4f32, the instruction selector crashes. See
more discussion at:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156031.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  Thu Nov 15 22:02:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 06:02:49 +0000
Subject: [LLVMbugs] [Bug 12774] Assertion failure in clang codegen
In-Reply-To: <bug-12774-206@http.llvm.org/bugs/>
References: <bug-12774-206@http.llvm.org/bugs/>
Message-ID: <bug-12774-206-lvlgsnqd65@http.llvm.org/bugs/>

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

Markus Trippelsdorf <markus at trippelsdorf.de> changed:

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

--- Comment #3 from Markus Trippelsdorf <markus at trippelsdorf.de> 2012-11-16 00:02:49 CST ---
Fixed by r168112

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 07:10:43 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 15:10:43 +0000
Subject: [LLVMbugs] [Bug 14360] New: Clang with -fprofile-arcs uses lots of
	memory
Message-ID: <bug-14360-206@http.llvm.org/bugs/>

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

             Bug #: 14360
           Summary: Clang with -fprofile-arcs uses lots of memory
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mathias.demare at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9554
  --> http://llvm.org/bugs/attachment.cgi?id=9554
Test case resulting in the memory issue

I noticed a memory issue when compiling our code base using Clang. The machine
running the build goes down due to excessive memory usage (with 2 GB free
memory before starting the build).

I've narrowed it down to the attached test case (it uses Google Test).

The error occurs when compiling with the following arguments:
clang -fprofile-arcs -I../gtest/include -c test.cpp -o test.o

Adding one pair of asserts adds 3 MB to the memory usage of Clang:
        ASSERT_TRUE(true);
        ASSERT_FALSE(false);

This is on an 64-bit Linux (Ubuntu 12.04):
clang version 3.1 (tags/RELEASE_31/final)
Target: x86_64-unknown-linux-gnu
Thread model: posix


Compiling the same test case using gcc with the same arguments: 800 MB RAM.
Compiling the same test case using gcc with '-fprofile-arcs' removed: 600 MB
RAM.
Compiling the same test case using clang with '-fprofile-arcs' removed: 300 MB
RAM.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 07:24:27 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 15:24:27 +0000
Subject: [LLVMbugs] [Bug 14361] New: optimizer produces incorrect code for
 simple arithmetic with i64 types
Message-ID: <bug-14361-206@http.llvm.org/bugs/>

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

             Bug #: 14361
           Summary: optimizer produces incorrect code for simple
                    arithmetic with i64 types
           Product: new-bugs
           Version: 3.1
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: vtjnash at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The LLVM optimizer (createInstructionCombiningPass?) incorrectly transforms 
a+b == b+a
into
a == b
when a and b are i64 types. I am on a x86_64 machine.
(it correctly transforms that statement into true with smaller types)

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

$ clang -O0 opt-test.c 
$ ./a.out 
commutative? true
$ clang -O1 opt-test.c 
$ ./a.out 
commutative? false
$ cat opt-test.c
#include <stdio.h>
#include <stdint.h>

int __attribute__ ((noinline)) f(long long a, long long b) {
    return a+b == b+a;
}

int main() {
    printf("commutative? %s\n", (f(2,3) ? "true" : "false"));
}
$ clang --version
Apple clang version 3.1 (tags/Apple/clang-318.0.61) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin11.3.0
Thread model: posix


--------------
(as mentioned in
https://github.com/JuliaLang/julia/issues/1555#issuecomment-10438267)
Before optimization:

define i1 @f(i64, i64) {
top:
  %a = alloca i64, !dbg !5697
  %b = alloca i64, !dbg !5697
  store i64 %0, i64* %a, !dbg !5697
  store i64 %1, i64* %b, !dbg !5697
  %2 = load i64* %a, !dbg !5704
  %3 = load i64* %b, !dbg !5704
  %4 = add i64 %2, %3, !dbg !5704
  %5 = load i64* %b, !dbg !5704
  %6 = load i64* %a, !dbg !5704
  %7 = add i64 %5, %6, !dbg !5704
  %8 = icmp eq i64 %4, %7, !dbg !5704
  ret i1 %8, !dbg !5704
}


After optimization:

define i1 @f(i64, i64) {
top:
  %2 = icmp eq i64 %1, %0, !dbg !5697
  ret i1 %2, !dbg !5697
}

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 09:33:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 17:33:01 +0000
Subject: [LLVMbugs] [Bug 13632] Missing lib dependence between libTarget and
 libCodeGen at -O0
In-Reply-To: <bug-13632-206@http.llvm.org/bugs/>
References: <bug-13632-206@http.llvm.org/bugs/>
Message-ID: <bug-13632-206-4PyAXjZkcl@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-16 11:33:01 CST ---
Worked around in r168173.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 09:47:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 17:47:15 +0000
Subject: [LLVMbugs] [Bug 13632] Missing lib dependence between libTarget and
 libCodeGen at -O0
In-Reply-To: <bug-13632-206@http.llvm.org/bugs/>
References: <bug-13632-206@http.llvm.org/bugs/>
Message-ID: <bug-13632-206-OpbiO4fgig@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |chandlerc at gmail.com,
                   |                            |nadav256 at gmail.com
         Resolution|FIXED                       |

--- Comment #4 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-16 11:47:15 CST ---
Reopening per Chandler's request. There still is a layering violation around
but it doesn't cause linker errors anymore.

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


From bugzilla-daemon at llvm.org  Fri Nov 16 09:53:48 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 17:53:48 +0000
Subject: [LLVMbugs] [Bug 14362] New: MC Disassembler C interface violates
 layering by pulling all targets into libLLVMMCDisassembler
Message-ID: <bug-14362-206@http.llvm.org/bugs/>

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

             Bug #: 14362
           Summary: MC Disassembler C interface violates layering by
                    pulling all targets into libLLVMMCDisassembler
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Target Description Classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: chandlerc at gmail.com, enderby at apple.com,
                    llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This breaks a shared library CMake build.

See lib/MC/MCDisassembler/Disassembler.cpp:41

The code is there because otool(1) can't call the initializations routines from
libLTO.

Possible fixes include:
- Call the inintialization routines for the targets supported by otool
manually, it's only X86 and ARM so this could be hardcoded.
- Add an initialization wrapper at the libLTO level and call that from otool.
libLTO is allowed to depend on this stuff.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 10:38:29 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 18:38:29 +0000
Subject: [LLVMbugs] [Bug 14363] New: Inline heuristic does not account for
 the number of callers
Message-ID: <bug-14363-206@http.llvm.org/bugs/>

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

             Bug #: 14363
           Summary: Inline heuristic does not account for the number of
                    callers
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: spop at codeaurora.org
                CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hi,

LLVM inlines functions without looking at how many call sites the inline
function has.

$ cat test.c
#define M D D
#define D C C C C C
#define C L L
#define L X X X X X
#define X V V
#define V I I I I I
#define I b();

extern void c(void);

static void b(void) {
  const int N = 20;
  int B[N];

  for (int i = 0; i < N; i++)
    B[i] = (10 - i) * ((i == 2) ? -i : i);

  int A[N + 5];
  for (int i = 1; i < N; i++)
    A[i] = B[i] - B[i-1];

  for (int i = 1; i < N; i++)
    if (A[i] < B[i])
      c();
}

void a(void) {
  M;
}

$ clang -O3 test.c -emit-llvm -S -o test.ll
$ wc -l test.ll
54030 test.ll

A possible solution is to add another threshold to bound the overall code size
increase due to inlining a 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  Fri Nov 16 11:47:24 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 19:47:24 +0000
Subject: [LLVMbugs] [Bug 14364] New: Remove const_cast hack from
 PPCRegisterInfo::hasReservedSpillSlot
Message-ID: <bug-14364-206@http.llvm.org/bugs/>

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

             Bug #: 14364
           Summary: Remove const_cast hack from
                    PPCRegisterInfo::hasReservedSpillSlot
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-cleanup
          Severity: enhancement
          Priority: P
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


PPCRegisterInfo::hasReservedSpillSlot contains this line:

MachineFrameInfo *MFI = (const_cast<MachineFunction &>(MF)).getFrameInfo();

it shouldn't modify the frame info in a const 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  Fri Nov 16 12:21:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 20:21:39 +0000
Subject: [LLVMbugs] [Bug 14365] New: Missed optimization for a simple bit
	twiddling
Message-ID: <bug-14365-206@http.llvm.org/bugs/>

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

             Bug #: 14365
           Summary: Missed optimization for a simple bit twiddling
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jkim at FreeBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I've been bit twiddling lately and found this:

% cat test.c
int test(int a) { return (a + (~(a & 0x55555555) + 1)); }
% clang -O2 -c test.c
% objdump -d test.o

test.o:     file format elf64-x86-64-freebsd

Disassembly of section .text:

0000000000000000 <test>:
   0:   89 f8                   mov    %edi,%eax
   2:   0d aa aa aa aa          or     $0xaaaaaaaa,%eax
   7:   35 55 55 55 55          xor    $0x55555555,%eax
   c:   8d 44 07 01             lea    0x1(%rdi,%rax,1),%eax
  10:   c3                      retq   

FYI, GCC nicely folded it into just one instruction:

% gcc48 -O2 -c test.c
% objdump -d test.o

test.o:     file format elf64-x86-64-freebsd

Disassembly of section .text:

0000000000000000 <test>:
   0:   89 f8                   mov    %edi,%eax
   2:   25 aa aa aa aa          and    $0xaaaaaaaa,%eax
   7:   c3                      retq

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 12:31:54 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 20:31:54 +0000
Subject: [LLVMbugs] [Bug 14309] Incorrect optimization of thread_local
	variables
In-Reply-To: <bug-14309-206@http.llvm.org/bugs/>
References: <bug-14309-206@http.llvm.org/bugs/>
Message-ID: <bug-14309-206-RZNjVwXzkW@http.llvm.org/bugs/>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #4 from Hans Wennborg <hans at chromium.org> 2012-11-16 14:31:54 CST ---
Fixed in r168037 and merged to the 3.2 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  Fri Nov 16 12:39:31 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 20:39:31 +0000
Subject: [LLVMbugs] [Bug 14366] New: Poor code generation for a simple
	inline assembly
Message-ID: <bug-14366-206@http.llvm.org/bugs/>

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

             Bug #: 14366
           Summary: Poor code generation for a simple inline assembly
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jkim at FreeBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Consider this:

% cat test.c
static __inline unsigned long
bsfq(unsigned long x)
{
        unsigned long r;

        __asm __volatile("bsfq %1,%0" : "=r" (r) : "rm" (x));
        return (r);
}

int
ffsl(long x)
{
        return (x == 0 ? x : (int)bsfq((unsigned long)x) + 1);
}

Clang generates really poor code:

% clang -O2 -c test.c
% objdump -d test.o

test.o:     file format elf64-x86-64-freebsd

Disassembly of section .text:

0000000000000000 <ffsl>:
   0:   48 85 ff                test   %rdi,%rdi
   3:   74 21                   je     26 <ffsl+0x26>
   5:   48 89 7c 24 f8          mov    %rdi,-0x8(%rsp)
   a:   48 0f bc 4c 24 f8       bsf    -0x8(%rsp),%rcx
  10:   48 c1 e1 20             shl    $0x20,%rcx
  14:   48 b8 00 00 00 00 01    mov    $0x100000000,%rax
  1b:   00 00 00 
  1e:   48 01 c8                add    %rcx,%rax
  21:   48 c1 e8 20             shr    $0x20,%rax
  25:   c3                      retq   
  26:   31 c0                   xor    %eax,%eax
  28:   c3                      retq   

Of course, GCC 4.2 does much better job. ;-)

% gcc -O2 -c test.c
% objdump -d test.o

test.o:     file format elf64-x86-64-freebsd

Disassembly of section .text:

0000000000000000 <ffsl>:
   0:   31 c0                   xor    %eax,%eax
   2:   48 85 ff                test   %rdi,%rdi
   5:   74 07                   je     e <ffsl+0xe>
   7:   48 0f bc c7             bsf    %rdi,%rax
   b:   83 c0 01                add    $0x1,%eax
   e:   f3 c3                   repz retq 

FYI, this problem was discussed here (warning: little lengthy):

http://docs.freebsd.org/cgi/mid.cgi?20121116181327.B1135

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 12:55:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 20:55:49 +0000
Subject: [LLVMbugs] [Bug 14361] optimizer produces incorrect code for simple
 arithmetic with i64 types
In-Reply-To: <bug-14361-206@http.llvm.org/bugs/>
References: <bug-14361-206@http.llvm.org/bugs/>
Message-ID: <bug-14361-206-2d7jZDdDDV@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2012-11-16 14:55:49 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156206.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 Nov 16 13:16:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 21:16:01 +0000
Subject: [LLVMbugs] [Bug 14359] ARM backend should generate vabs q,
 q for v4f32 vector type
In-Reply-To: <bug-14359-206@http.llvm.org/bugs/>
References: <bug-14359-206@http.llvm.org/bugs/>
Message-ID: <bug-14359-206-0RqnR7r5oW@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2012-11-16 15:16:01 CST ---
This is really low-hanging fruit :) Fixed in r168200

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 13:42:08 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 21:42:08 +0000
Subject: [LLVMbugs] [Bug 14367] New: [NVPTX] Expose DriverInterface setting
 to subtarget arguments
Message-ID: <bug-14367-206@http.llvm.org/bugs/>

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

             Bug #: 14367
           Summary: [NVPTX] Expose DriverInterface setting to subtarget
                    arguments
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: maemarcus at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


NVPTX backend has an option to switch between NVCL, CUDA and TEST driver
interfaces. But this setting can only be configured over command line:

cl::opt<NVPTX::DrvInterface>
DriverInterface(cl::desc("Choose driver interface:"),
                cl::values(
                    clEnumValN(NVPTX::NVCL, "drvnvcl", "Nvidia OpenCL driver"),
                    clEnumValN(NVPTX::CUDA, "drvcuda", "Nvidia CUDA driver"),
                    clEnumValN(NVPTX::TEST, "drvtest", "Plain Test"),
                    clEnumValEnd),
                    cl::init(NVPTX::NVCL));
}

At KernelGen we invoke backend using TargetMachine interface, i.e. bypassing
command line and need to use CUDA interface (because it's the one not adding
texmode_independent PTX option). It would be nice to extend the current
target/subtarget argument list to have an ability to select Driver Interface
from there.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 14:04:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 22:04:35 +0000
Subject: [LLVMbugs] [Bug 14338] clang tries to compile fortran itself
In-Reply-To: <bug-14338-206@http.llvm.org/bugs/>
References: <bug-14338-206@http.llvm.org/bugs/>
Message-ID: <bug-14338-206-6rRyjiCOVj@http.llvm.org/bugs/>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #6 from Nick Lewycky <nlewycky at google.com> 2012-11-16 16:04:35 CST ---
Yes.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 14:19:40 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 22:19:40 +0000
Subject: [LLVMbugs] [Bug 14358] implementation problem with
 istreambuf_iterator operator++
In-Reply-To: <bug-14358-206@http.llvm.org/bugs/>
References: <bug-14358-206@http.llvm.org/bugs/>
Message-ID: <bug-14358-206-lxq8XpEBRf@http.llvm.org/bugs/>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #10 from Howard Hinnant <hhinnant at apple.com> 2012-11-16 16:19:40 CST ---
Fix Committed revision 168209.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 14:54:37 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 16 Nov 2012 22:54:37 +0000
Subject: [LLVMbugs] [Bug 14078] Assertion in LiveInterval.cpp
In-Reply-To: <bug-14078-206@http.llvm.org/bugs/>
References: <bug-14078-206@http.llvm.org/bugs/>
Message-ID: <bug-14078-206-Akwz7Sh5Xu@http.llvm.org/bugs/>

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

Jakub Staszak <kuba.staszak at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |kuba.staszak at gmail.com
         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 Nov 16 19:36:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 03:36:46 +0000
Subject: [LLVMbugs] [Bug 14315] Register regmask dependency problem with
	misched
In-Reply-To: <bug-14315-206@http.llvm.org/bugs/>
References: <bug-14315-206@http.llvm.org/bugs/>
Message-ID: <bug-14315-206-DKWzBMCZEi@http.llvm.org/bugs/>

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

Andrew Trick <atrick at apple.com> changed:

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

--- Comment #1 from Andrew Trick <atrick at apple.com> 2012-11-16 21:36:46 CST ---
Fixed in r168248.

On PPC the stack pointer is X1, but ADJCALLSTACK writes R1.

Hal, please file another bug for any performance issue related to the
scheduling boundary around calls. I'd like to see a test case for that.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 20:46:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 04:46:49 +0000
Subject: [LLVMbugs] [Bug 14344] Clean up and fix X86 CPU features
In-Reply-To: <bug-14344-206@http.llvm.org/bugs/>
References: <bug-14344-206@http.llvm.org/bugs/>
Message-ID: <bug-14344-206-CFS1m75C5G@http.llvm.org/bugs/>

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

Jung-uk Kim <jkim at FreeBSD.org> changed:

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

--- Comment #11 from Jung-uk Kim <jkim at FreeBSD.org> 2012-11-16 22:46:49 CST ---
http://llvm.org/viewvc/llvm-project?view=rev&revision=168237
http://llvm.org/viewvc/llvm-project?view=rev&revision=168239

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 16 21:55:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 05:55:16 +0000
Subject: [LLVMbugs] [Bug 14326] Call __cxa_end_cleanup instead of
 _Unwind_Resume by ARM EHABI
In-Reply-To: <bug-14326-206@http.llvm.org/bugs/>
References: <bug-14326-206@http.llvm.org/bugs/>
Message-ID: <bug-14326-206-c5mq7afD0c@http.llvm.org/bugs/>

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

Wen-Han Gu <wenhan.gu at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |wenhan.gu at gmail.com
         Resolution|                            |INVALID

--- Comment #4 from Wen-Han Gu <wenhan.gu at gmail.com> 2012-11-16 23:55:16 CST ---
Thanks to your comment.

I cannot find a test case to make the original code fail
although spec says that.

I invalid this bug for now, and I will submit the complete patch once
I found a testcase.

Thanks!

(In reply to comment #3)
> Can you send it to  cfe-commits? We normally do code review over email.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 17 02:28:38 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 10:28:38 +0000
Subject: [LLVMbugs] [Bug 14195] Miscompilation when optimizing OpenSSL GOST
	R 34.11-94
In-Reply-To: <bug-14195-206@http.llvm.org/bugs/>
References: <bug-14195-206@http.llvm.org/bugs/>
Message-ID: <bug-14195-206-kDjmVwYZgh@http.llvm.org/bugs/>

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

Serguei E. Leontiev <leo at sai.msu.ru> changed:

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

--- Comment #1 from Serguei E. Leontiev <leo at sai.msu.ru> 2012-11-17 04:28:38 CST ---
Sorry, this OpenSSL bug, the function circle_xor8() use memcpy() for
overlapping buffers.

[openssl.org #2858] bug in gosthash.c circle_xor8() routine
http://rt.openssl.org/Ticket/Display.html?id=2858&user=guest&pass=guest

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 17 08:33:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 16:33:17 +0000
Subject: [LLVMbugs] [Bug 14368] New: opt -memdep -gvn crash
Message-ID: <bug-14368-206@http.llvm.org/bugs/>

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

             Bug #: 14368
           Summary: opt -memdep -gvn crash
           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: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9558
  --> http://llvm.org/bugs/attachment.cgi?id=9558
Testcase

$ opt --version
LLVM (http://llvm.org/):
  LLVM version 3.2svn
  DEBUG build with assertions.
  Built Nov 17 2012 (17:58:08).
  Default target: x86_64-unknown-linux-gnu
  Host CPU: penryn

$ opt -memdep -gvn < bugpoint-reduced-simplified.ll -S
0  opt             0x00000000012dffce
1  opt             0x00000000012e04ca
2  libpthread.so.0 0x00007fc175ca21a0
3  opt             0x0000000000a844f4
4  opt             0x0000000000f784dd
llvm::MemoryDependenceAnalysis::getNonLocalPointerDepFromBB(llvm::PHITransAddr
const&, llvm::AliasAnalysis::Location const&, bool, llvm::BasicBlock*,
llvm::SmallVectorImpl<llvm::NonLocalDepResult>&,
llvm::DenseMap<llvm::BasicBlock*, llvm::Value*,
llvm::DenseMapInfo<llvm::BasicBlock*> >&, bool) + 2765
5  opt             0x0000000000f77954
llvm::MemoryDependenceAnalysis::getNonLocalPointerDependency(llvm::AliasAnalysis::Location
const&, bool, llvm::BasicBlock*,
llvm::SmallVectorImpl<llvm::NonLocalDepResult>&) + 260
6  opt             0x0000000000c7eff6
7  opt             0x0000000000c7aa99
8  opt             0x0000000000c79e37
9  opt             0x0000000000c79ad8
10 opt             0x0000000000c768a3
11 opt             0x0000000000c76680
12 opt             0x000000000125a10f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 431
13 opt             0x000000000125a40d
llvm::FPPassManager::runOnModule(llvm::Module&) + 125
14 opt             0x000000000125a655
llvm::MPPassManager::runOnModule(llvm::Module&) + 485
15 opt             0x000000000125af7d llvm::PassManagerImpl::run(llvm::Module&)
+ 157
16 opt             0x000000000125b161 llvm::PassManager::run(llvm::Module&) +
33
17 opt             0x00000000005f52cb main + 6715
18 libc.so.6       0x00007fc174ef7725 __libc_start_main + 245
19 opt             0x00000000005e4139
Stack dump:
0.    Program arguments: opt -memdep -gvn -S 
1.    Running pass 'Function Pass Manager' on module '<stdin>'.
2.    Running pass 'Global Value Numbering' on function '@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  Sat Nov 17 10:00:42 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 18:00:42 +0000
Subject: [LLVMbugs] [Bug 14369] New: crash when lexing a file ending in
	'\<eof>
Message-ID: <bug-14369-206@http.llvm.org/bugs/>

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

             Bug #: 14369
           Summary: crash when lexing a file ending in '\<eof>
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9559
  --> http://llvm.org/bugs/attachment.cgi?id=9559
repro

Nicos-MacBook-Pro:gong thakis$ cat test.c
// RUN: %gong_cc1 %s -verify -fsyntax-only
// vim: set binary noeol

char c = '\Nicos-MacBook-Pro:gong thakis$ ../../Release+Asserts/bin/clang -c
test.c
test.c:4:10: warning: missing terminating ' character [-Winvalid-pp-token]
char c = '\
         ^
test.c:4:10: error: expected expression
Assertion failed: (Loc >= BufferStart && Loc <= BufferEnd && "Location out of
range for this buffer!"), function getSourceLocation, file Lexer.cpp, line
1170.
0  clang             0x000000010531fb82 PrintStackTrace(void*) + 34
1  clang             0x00000001053200a9 SignalHandler(int) + 713
2  libsystem_c.dylib 0x00007fff8b7f58ea _sigtramp + 26
3  clang             0x00000001053453de
llvm::_system_error_category::~_system_error_category() + 32254
4  clang             0x000000010531fdc6 abort + 22
5  clang             0x000000010531fd85 __assert_rtn + 53
6  clang             0x000000010472d7c1 clang::Lexer::getSourceLocation(char
const*, unsigned int) const + 97
7  clang             0x000000010473197f
clang::Lexer::LexTokenInternal(clang::Token&) + 783
8  clang             0x0000000103f832c7
clang::Parser::SkipUntil(llvm::ArrayRef<clang::tok::TokenKind>, bool, bool,
bool) + 663
9  clang             0x0000000103f26bb7
clang::Parser::ParseDeclarationAfterDeclaratorAndAttributes(clang::Declarator&,
clang::Parser::ParsedTemplateInfo const&) + 1639
10 clang             0x0000000103f25607
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2039
11 clang             0x0000000103f8673c
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 908
12 clang             0x0000000103f8606f
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 239
13 clang             0x0000000103f856d7
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 2903
14 clang             0x0000000103f84af7
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 311
15 clang             0x0000000103f182f4 clang::ParseAST(clang::Sema&, bool,
bool) + 276
16 clang             0x0000000103edd1e2 clang::CodeGenAction::ExecuteAction() +
1298
17 clang             0x0000000103cddd1d clang::FrontendAction::Execute() + 109
18 clang             0x0000000103cc0ccf
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 1007
19 clang             0x0000000103c89c01
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3569
20 clang             0x0000000103c81868 cc1_main(char const**, char const**,
char const*, void*) + 872
21 clang             0x0000000103c85b24 main + 708
22 libdyld.dylib     0x00007fff8de2e7e1 start + 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  Sat Nov 17 10:43:07 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 18:43:07 +0000
Subject: [LLVMbugs] [Bug 14370] New: bugpoint crashes when undoing loop
	extraction
Message-ID: <bug-14370-206@http.llvm.org/bugs/>

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

             Bug #: 14370
           Summary: bugpoint crashes when undoing loop extraction
           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: matti.niemenmaa+llvmbugs at iki.fi
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9560
  --> http://llvm.org/bugs/attachment.cgi?id=9560
Testcase

Tested with trunk, SVN r168259 / git 9e6ee16b1814268897965b81e82a74ef39173ee1.

$ bugpoint --version
LLVM (http://llvm.org/):
  LLVM version 3.2svn
  DEBUG build with assertions.
  Built Nov 17 2012 (20:27:33).
  Default target: x86_64-unknown-linux-gnu
  Host CPU: penryn

$ bugpoint -llc-safe linked.bc -sroa
Read input file      : 'linked.bc'
*** All input ok
Running selected passes on program to test for crash: Success!
Initializing execution environment: Found gcc: /home/deewiant/bin/gcc
Running the code generator to test for a crash: <llc>
Generating reference output from raw program: <llc><llc><gcc><program>
Reference output is: bugpoint.reference.out-ASQh2h

*** Checking the code generator...
<llc><gcc><program>
*** Output matches: Debugging miscompilation!
Checking to see if '' compiles correctly: <llc><gcc><program> yup.
Checking to see if '-sroa' compiles correctly: <llc><gcc><program> nope.

*** Found miscompiling pass: -sroa
Emitted bitcode to 'bugpoint-passinput.bc'

*** You can reproduce the problem with: opt bugpoint-passinput.bc -sroa
Checking to see if the program is misoptimized when these functions are run
through the pass: main r_split_node r_flatten_node
  Optimizing functions being tested: done.
  Checking to see if the merged program executes correctly: <llc><gcc><program>
nope.
Checking to see if the program is misoptimized when these functions are run
through the pass: r_split_node r_flatten_node
  Optimizing functions being tested: done.
  Checking to see if the merged program executes correctly: <llc><gcc><program>
nope.
Checking to see if the program is misoptimized when this function is run
through the pass: r_flatten_node
  Optimizing functions being tested: done.
  Checking to see if the merged program executes correctly: <llc><gcc><program>
yup.
Checking to see if the program is misoptimized when this function is run
through the pass: r_split_node
  Optimizing functions being tested: done.
  Checking to see if the merged program executes correctly: <llc><gcc><program>
nope.

*** The following function is being miscompiled:  r_split_node
Extracted a loop from the breaking portion of the program.
<llc><gcc><program>  Testing after loop extraction:
  Optimizing functions being tested: done.
  Checking to see if the merged program executes correctly: <llc><gcc><program>
yup.
*** Loop extraction masked the problem.  Undoing.
0  bugpoint        0x0000000000c7c20e
1  bugpoint        0x0000000000c7c70a
2  libpthread.so.0 0x00007f22362941a0
3  bugpoint        0x0000000000542dca
4  bugpoint        0x0000000000542dac
5  bugpoint        0x000000000053ffef
6  bugpoint        0x000000000056600b
7  bugpoint        0x000000000056309d
8  bugpoint        0x0000000000562ae2
llvm::BugDriver::debugMiscompilation(std::string*) + 514
9  bugpoint        0x00000000005325ae llvm::BugDriver::run(std::string&) + 1246
10 bugpoint        0x0000000000578708 main + 1576
11 libc.so.6       0x00007f22354e9725 __libc_start_main + 245
12 bugpoint        0x00000000005318d9
Stack dump:
0.    Program arguments: bugpoint -llc-safe linked.bc -sroa

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 17 10:54:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 18:54:17 +0000
Subject: [LLVMbugs] [Bug 14371] New: Regression: InstCombine alloca->global
 optimization crashes on opaque types
Message-ID: <bug-14371-206@http.llvm.org/bugs/>

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

             Bug #: 14371
           Summary: Regression: InstCombine alloca->global optimization
                    crashes on opaque types
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: code at klickverbot.at
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9561
  --> http://llvm.org/bugs/attachment.cgi?id=9561
test case

Please see the attached test case: In getPointeeAlignment(), InstCombine
assumes that DataLayout::getABITypeAlignment always works on
PT->getElementType(). However, if the type is opaque, this is not the case.

I marked the report as »release blocker« since this is a regression from 3.1
and breaks the LDC compiler. Sorry if this is not the intended use 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  Sat Nov 17 12:26:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 17 Nov 2012 20:26:09 +0000
Subject: [LLVMbugs] [Bug 14369] crash when lexing a file ending in '\<eof>
In-Reply-To: <bug-14369-206@http.llvm.org/bugs/>
References: <bug-14369-206@http.llvm.org/bugs/>
Message-ID: <bug-14369-206-Qszt6TcJzt@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #2 from Nico Weber <nicolasweber at gmx.de> 2012-11-17 14:26:09 CST ---
168269

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 17 17:42:14 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Nov 2012 01:42:14 +0000
Subject: [LLVMbugs] [Bug 14372] New: Partial ordering of variadic function
	template
Message-ID: <bug-14372-206@http.llvm.org/bugs/>

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

             Bug #: 14372
           Summary: Partial ordering of variadic function template
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zeratul976 at hotmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


According to the last example in temp.func.order (14.5.6.2), the call to f
below should be ambiguous, but clang compiles the code and the calls #2:


template <class T, class... U> void f(T, U...);    // #1
template <class T            > void f(T);          // #2

void h(int i)
{
    f(&i);  // should be ambiguous, but calls #2
}

Test with trunk revision 168277.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 17 21:40:24 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Nov 2012 05:40:24 +0000
Subject: [LLVMbugs] [Bug 14371] Regression: InstCombine alloca->global
 optimization crashes on opaque types
In-Reply-To: <bug-14371-206@http.llvm.org/bugs/>
References: <bug-14371-206@http.llvm.org/bugs/>
Message-ID: <bug-14371-206-EIJGTbWHVK@http.llvm.org/bugs/>

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

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 #3 from Nick Lewycky <nlewycky at google.com> 2012-11-17 23:40:24 CST ---
Fixed in r168280. 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  Sun Nov 18 06:47:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Nov 2012 14:47:17 +0000
Subject: [LLVMbugs] [Bug 14373] New: Segfault in
 CodeGenFunction::GetAddrOfBlockDecl when accessing automatic variable from
 local class
Message-ID: <bug-14373-206@http.llvm.org/bugs/>

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

             Bug #: 14373
           Summary: Segfault in CodeGenFunction::GetAddrOfBlockDecl when
                    accessing automatic variable from local class
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: amanieu at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9562
  --> http://llvm.org/bugs/attachment.cgi?id=9562
Preprocessed source

$ cat a.cpp
#include <utility>
#include <functional>

template<typename Func>
std::function<void()> exec_func(Func&& f)
{
    struct functor {
        explicit functor(Func&& f): func(std::forward<Func>(f)) {}
        void operator()() const
        {
            f(); // <- error here, should be func() instead. f is a parameter
to exec_func
        }
        Func func;
    };
    return functor(std::forward<Func>(f));
}

int main()
{
    exec_func([]{});
}
$ clang++ -std=c++11 -c a.cpp
0  libLLVM-3.1.so  0x00007ff728e2663f
1  libLLVM-3.1.so  0x00007ff728e26aa9
2  libpthread.so.0 0x00007ff7281651a0
3  clang           0x00000000008167c6
clang::CodeGen::CodeGenFunction::GetAddrOfBlockDecl(clang::VarDecl const*,
bool) + 38
4  clang           0x000000000077dacc
clang::CodeGen::CodeGenFunction::EmitDeclRefLValue(clang::DeclRefExpr const*) +
1484
5  clang           0x000000000077deda
clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) + 522
6  clang           0x000000000077f66b
clang::CodeGen::CodeGenFunction::EmitCastLValue(clang::CastExpr const*) + 155
7  clang           0x000000000077df25
clang::CodeGen::CodeGenFunction::EmitLValue(clang::Expr const*) + 597
8  clang           0x0000000000791dcb
clang::CodeGen::CodeGenFunction::EmitCXXOperatorMemberCallExpr(clang::CXXOperatorCallExpr
const*, clang::CXXMethodDecl const*, clang::CodeGen::ReturnValueSlot) + 75
9  clang           0x000000000077f364
clang::CodeGen::CodeGenFunction::EmitCallExpr(clang::CallExpr const*,
clang::CodeGen::ReturnValueSlot) + 500
10 clang           0x0000000000541cc5
11 clang           0x00000000007a8e00
12 clang           0x00000000007ab32d
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 61
13 clang           0x00000000007737bf
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 191
14 clang           0x0000000000781086
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 70
15 clang           0x00000000007fb01f
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 303
16 clang           0x00000000007fb1ef
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 239
17 clang           0x00000000007fd822
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 210
18 clang           0x00000000007faf13
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 35
19 clang           0x000000000080a9ac
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 492
20 clang           0x0000000000710ca9
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 377
21 clang           0x00000000007115dd
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 189
22 clang           0x00000000007137c1
clang::CodeGen::CodeGenModule::EmitDeferred() + 241
23 clang           0x00000000007137d9 clang::CodeGen::CodeGenModule::Release()
+ 9
24 clang           0x000000000070019b
25 clang           0x0000000000827f1d clang::ParseAST(clang::Sema&, bool, bool)
+ 461
26 clang           0x00000000005d7096
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 262
27 clang           0x00000000005c0402
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1042
28 clang           0x00000000005b9a23 cc1_main(char const**, char const**, char
const*, void*) + 9091
29 clang           0x00000000005b6b61 main + 7009
30 libc.so.6       0x00007ff7278b8725 __libc_start_main + 245
31 clang           0x00000000005b753d
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-unknown-linux-gnu
-emit-obj -mrelax-all -disable-free -disable-llvm-verifier -main-file-name
a.cpp -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.23.1 -momit-leaf-frame-pointer -coverage-file a.o -resource-dir
/usr/bin/../lib/clang/3.1 -fmodule-cache-path /var/tmp/clang-module-cache
-internal-isystem
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2
-internal-isystem
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/x86_64-unknown-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/backward
-internal-isystem /usr/local/include -internal-isystem
/usr/bin/../lib/clang/3.1/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro
-fdebug-compilation-dir /home/amanieu -ferror-limit 19 -fmessage-length 237
-mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak
-fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o a.o -x c++ a.cpp 
1.    <eof> parser at end of file
2.    Per-file LLVM IR generation
3.    a.cpp:9:8: Generating code for declaration 'exec_func(<lambda at
a.cpp:20:12> &&)::functor::operator()'
4.    a.cpp:10:3: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal (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) and associated run
script(s) are located at:
clang: note: diagnostic msg: /tmp/a-WfH3dy.ii
clang: note: diagnostic msg: /tmp/a-WfH3dy.sh

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 18 06:56:23 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Nov 2012 14:56:23 +0000
Subject: [LLVMbugs] [Bug 14374] New: Local class can't access its members
Message-ID: <bug-14374-206@http.llvm.org/bugs/>

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

             Bug #: 14374
           Summary: Local class can't access its members
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: amanieu at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ cat a.cpp
#include <utility>
#include <functional>

template<typename Func>
std::function<void()> exec_func(Func&& f)
{
    struct functor {
        explicit functor(Func&& f): func(std::forward<Func>(f)) {}
        void operator()() const
        {
            func();
        }
        Func func;
    };
    return functor(std::forward<Func>(f));
}

int main()
{
    exec_func([]{});
}
$ clang++ -std=c++11 -c a.cpp
a.cpp:11:4: error: 'exec_func(<lambda at a.cpp:20:12>
&&)::functor::operator()()::functor::func' is not a member of class 'const
functor'
                        func();
                        ^
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/functional:1925:2:
note: in instantiation of member function 'exec_func(<lambda at a.cpp:20:12>
&&)::functor::operator()' requested here
        (*_Base::_M_get_pointer(__functor))(
        ^
/usr/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/functional:2297:33:
note: in instantiation of member function 'std::_Function_handler<void (),
functor>::_M_invoke' requested here
            _M_invoker = &_My_handler::_M_invoke;
                                       ^
a.cpp:15:9: note: in instantiation of function template specialization
'std::function<void ()>::function<functor>' requested here
        return functor(std::forward<Func>(f));
               ^
a.cpp:20:2: note: in instantiation of function template specialization
'exec_func<<lambda at a.cpp:20:12> >' requested here
        exec_func([]{});
        ^
1 error generated.

This was compiled using libstdc++ but the same error occurs with libc++.
Using this->func() instead of func() 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  Sun Nov 18 10:30:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Nov 2012 18:30:11 +0000
Subject: [LLVMbugs] [Bug 14375] New: clang doesn't diagnose some invalid code
Message-ID: <bug-14375-206@http.llvm.org/bugs/>

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

             Bug #: 14375
           Summary: clang doesn't diagnose some invalid code
           Product: clang
           Version: trunk
          Platform: PC
               URL: http://gcc.gnu.org/ml/gcc/2012-11/msg00210.html
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: lionel_debroux at yahoo.fr
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


http://gcc.gnu.org/ml/gcc/2012-11/msg00210.html and followups: GCC produces an
error with diagnostic for the invalid code snippets posted below, while clang
3.0 and ToT (tested with r168286) don't, even with e.g. -Weverything.

According to the followups, compilers are not required to produce diagnostics
for that situation, but it would nevertheless be nice for users to have them :)
The followups mention 3.3.6/1 and [dcl.typedef]/6.

===== begin snippet 1 (original testcase) =====
class A {};
class B : public A {

typedef A super;

public:

    class X {};
};



class C : public B {

typedef B super;

class X : public super::X {

       typedef super::X super;
    };
};
===== end snippet 1 =====


===== begin snippet 2 (reduced testcase in first followup) =====
typedef struct { typedef int type; } s1;
struct S2 { s1::type s1; };
===== end snippet 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 Nov 18 11:28:04 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Nov 2012 19:28:04 +0000
Subject: [LLVMbugs] [Bug 14060] Infinite Loop in Reassociate
In-Reply-To: <bug-14060-206@http.llvm.org/bugs/>
References: <bug-14060-206@http.llvm.org/bugs/>
Message-ID: <bug-14060-206-49h2DavVYa@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2012-11-18 13:28:04 CST ---
Fixed here:

http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121112/156364.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 Nov 18 11:50:42 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Nov 2012 19:50:42 +0000
Subject: [LLVMbugs] [Bug 14376] New: Regression: Crash in llc with asm
Message-ID: <bug-14376-206@http.llvm.org/bugs/>

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

             Bug #: 14376
           Summary: Regression: Crash in llc with asm
           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: kai at redstar.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9563
  --> http://llvm.org/bugs/attachment.cgi?id=9563
test case

The attached .ll file crashes llc when the -O3 option is used.
Message is:
llc: LiveInterval.cpp:62: llvm::VNInfo
*llvm::LiveInterval::createDeadDef(llvm::SlotIndex, VNInfo::Allocator &):
Assertion `I->start == Def && "Cannot insert def, already live"' failed.

Happens with 3.2rc1 and 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  Sun Nov 18 13:58:59 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 18 Nov 2012 21:58:59 +0000
Subject: [LLVMbugs] [Bug 14372] Partial ordering of variadic function
	template
In-Reply-To: <bug-14372-206@http.llvm.org/bugs/>
References: <bug-14372-206@http.llvm.org/bugs/>
Message-ID: <bug-14372-206-kqOoyFN4cz@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |INVALID

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-18 15:58:59 CST ---
This was determined to be a defect in C++ (core issue 1395), and Clang
implements the resolution to that defect.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 18 18:09:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 02:09:01 +0000
Subject: [LLVMbugs] [Bug 14349] Assertion in SROA around rewriting store
 instruction implicitly using a vector data type
In-Reply-To: <bug-14349-206@http.llvm.org/bugs/>
References: <bug-14349-206@http.llvm.org/bugs/>
Message-ID: <bug-14349-206-MCQE7HYldW@http.llvm.org/bugs/>

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

Jiangning Liu <liujiangning1 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  Sun Nov 18 18:21:41 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 02:21:41 +0000
Subject: [LLVMbugs] [Bug 14377] New: Running pass 'Greedy Register
 Allocator' leads to Segmentation fault (core dumped)
Message-ID: <bug-14377-206@http.llvm.org/bugs/>

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

             Bug #: 14377
           Summary: Running pass 'Greedy Register Allocator' leads to
                    Segmentation fault (core dumped)
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: seb at boisvert.info
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hi,

I want to use LLVM 3.1 (with clang for the frontend) for compiling Open-MPI
1.6.3,
which is a message-passing library. But I get a segmentation fault by the
"Greedy
Register Allocator".

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 18 18:26:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 02:26:44 +0000
Subject: [LLVMbugs] [Bug 14378] New: vfork() should not be a builtin that
	returns int
Message-ID: <bug-14378-206@http.llvm.org/bugs/>

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

             Bug #: 14378
           Summary: vfork() should not be a builtin that returns int
           Product: clang
           Version: 3.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: js-llvm-bugzilla at webkeks.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


According to POSIX, vfork() should return a pid_t. A pid_t is only defined to
be of a signed integer type.

However, Clang forces this to be int:
LIBBUILTIN(vfork, "i",            "fj",    "unistd.h", ALL_LANGUAGES)

This actually causes trouble: Clang refuses to compile programs on for example
Haiku that try to use vfork(), complaining about an incompatible redefinition
because the header defines it to return pid_t, which on e.g. Haiku is a signed
long.

Please remove the line before the 3.2 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  Sun Nov 18 18:30:05 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 02:30:05 +0000
Subject: [LLVMbugs] [Bug 14349] Assertion in SROA around rewriting store
 instruction implicitly using a vector data type
In-Reply-To: <bug-14349-206@http.llvm.org/bugs/>
References: <bug-14349-206@http.llvm.org/bugs/>
Message-ID: <bug-14349-206-e0DsKyvuBw@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|RESOLVED                    |REOPENED
                 CC|                            |chandlerc at gmail.com
         Resolution|FIXED                       |

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> 2012-11-18 20:30:05 CST ---
This is not actually fixed. The particular crash has been papered over, but I'm
still working on and testing the proper fix for the underlying 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  Sun Nov 18 18:46:56 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 02:46:56 +0000
Subject: [LLVMbugs] [Bug 13996] Debug info causes linker error -- reloc
 against `.debug_str': error 2
In-Reply-To: <bug-13996-206@http.llvm.org/bugs/>
References: <bug-13996-206@http.llvm.org/bugs/>
Message-ID: <bug-13996-206-sxinjxJJQ2@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #4 from Chandler Carruth <chandlerc at gmail.com> 2012-11-18 20:46:56 CST ---
I now think it's a bug in the linker, or ar, or my filesystem.

Essentially, there is a single bit-flip in one object inside the archive, and
this is the error that results. I'm a little terrified about how its happening,
but I've now reproduced it where the .o file that went into the archive did
*not* have the bit flipped, but the archive did. Rebuilding the archive 'fixed'
it.

Anyways, seems less and less likely any part of Clang is responsible so I'm
closing 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 Nov 18 22:51:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 06:51:39 +0000
Subject: [LLVMbugs] [Bug 14329] Docutils documentation lacks.
In-Reply-To: <bug-14329-206@http.llvm.org/bugs/>
References: <bug-14329-206@http.llvm.org/bugs/>
Message-ID: <bug-14329-206-tNjZNiV59t@http.llvm.org/bugs/>

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

Alexander Kornienko <alexfh at google.com> changed:

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

--- Comment #7 from Alexander Kornienko <alexfh at google.com> 2012-11-19 00:51:39 CST ---
r168088 seems to be ok 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 Nov 19 01:01:13 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 09:01:13 +0000
Subject: [LLVMbugs] [Bug 14379] New: Buggy phi instruction crashes opt, lli,
 llc, but not llvm-as.
Message-ID: <bug-14379-206@http.llvm.org/bugs/>

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

             Bug #: 14379
           Summary: Buggy phi instruction crashes opt, lli, llc, but not
                    llvm-as.
           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: kunshan.wang at anu.edu.au
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9567
  --> http://llvm.org/bugs/attachment.cgi?id=9567
Crasher code.

LLVM version: SVN trunk version. Cloned from the git mirror.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 168294
91177308-0d34-0410-b5e6-96231b3b80d8

The attached crasher.ll has a bug, but will crash some llvm command-line tools.

How to reproduce:

1. Download the attached crasher.ll

2. Compile the SVN version of llvm.

3. Go to the generated bin directory.

./opt -S /path/to/crasher.ll

Then opt prints:

============================================= FROM opt ======
PHI node entries do not match predecessors!
  %x = phi i32 [ 1, %entry ], [ 2, %lab2 ]
label %lab2
label %lab3
Broken module found, compilation aborted!
0  opt             0x0000000001655c71
1  opt             0x000000000165594a
2  libpthread.so.0 0x00007fc53f303cb0
3  libc.so.6       0x00007fc53e756425 gsignal + 53
4  libc.so.6       0x00007fc53e759b8b abort + 379
5  opt             0x0000000001581def
6  opt             0x0000000001581b33
7  opt             0x000000000155fb62
llvm::FPPassManager::runOnFunction(llvm::Function&) + 380
8  opt             0x000000000155fd62
llvm::FPPassManager::runOnModule(llvm::Module&) + 102
9  opt             0x0000000001560045
llvm::MPPassManager::runOnModule(llvm::Module&) + 397
10 opt             0x00000000015606e8 llvm::PassManagerImpl::run(llvm::Module&)
+ 120
11 opt             0x000000000156088f llvm::PassManager::run(llvm::Module&) +
39
12 opt             0x000000000088a578 main + 5614
13 libc.so.6       0x00007fc53e74176d __libc_start_main + 237
14 opt             0x000000000087a0e9
Stack dump:
0.      Program arguments: ./opt -S /home/wks/code/llvm-junks/crasher.ll 
1.      Running pass 'Function Pass Manager' on module
'/home/wks/code/llvm-junks/crasher.ll'.
2.      Running pass 'Module Verifier' on function '@crasher'
Aborted (core dumped)
============================================= END FROM opt ==

Using llc and lli also results in core-dump. But llvm-as can indicate the error
in crasher.ll without crashing itself.

./llvm-as /path/to/crasher.ll -o crasher.bc

============================================= FROM llvm-as ======
./llvm-as: assembly parsed, but does not verify as correct!
PHI node entries do not match predecessors!
  %x = phi i32 [ 1, %entry ], [ 2, %lab2 ]
label %lab2
label %lab3
Broken module found, compilation terminated.
Broken module found, compilation terminated.
Broken module found, compilation terminated.
============================================= END FROM llvm-as ==

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 05:44:59 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 13:44:59 +0000
Subject: [LLVMbugs] [Bug 14380] New: Possible bug in the code-gen
	documentation
Message-ID: <bug-14380-206@http.llvm.org/bugs/>

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

             Bug #: 14380
           Summary: Possible bug in the code-gen documentation
           Product: Documentation
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: General docs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: eliben at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


http://llvm.org/docs/CodeGenerator.html#selectiondag-select-phase

At some point the doc shows a piece of TableGen definition file and says:

"The portion of the instruction definition in bold indicates the pattern used
to match the instruction. The DAG operators (like fmul/fadd) are defined in the
include/llvm/Target/TargetSelectionDAG.td file. ” F4RC” is the register class
of the input and result values."

However, I can't discern anything bold in that code.

[I hope it's not just my poor eyesight...]

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 08:29:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 16:29:44 +0000
Subject: [LLVMbugs] [Bug 14381] New: Compile error only when running code
	completer
Message-ID: <bug-14381-206@http.llvm.org/bugs/>

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

             Bug #: 14381
           Summary: Compile error only when running code completer
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mustrumr97 at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I ran at a compile error only when invoking clang++ with
-code-completion-at=...
bug.cpp:
struct A{
    constexpr A(){}
};
constexpr A x;

When completing at bug.cpp:5:1 there is an error:
bug.cpp:4:13: error: constexpr variable 'x' must be initialized by a constant
expression
bug.cpp:4:13: note: undefined constructor 'A' cannot be used in a constant
expression
bug.cpp:2:15: note: declared 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  Mon Nov 19 10:28:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 18:28:03 +0000
Subject: [LLVMbugs] [Bug 14382] New: fPIC error for LTOCodeGenerator.o (SUSE
 Linux Enterprise Server 10 SP4 (x86_64))
Message-ID: <bug-14382-206@http.llvm.org/bugs/>

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

             Bug #: 14382
           Summary: fPIC error for LTOCodeGenerator.o (SUSE Linux
                    Enterprise Server 10 SP4 (x86_64))
           Product: Build scripts
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: peeter.joot at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Get build error in link stage building clang from the trunk as described in:

http://clang.llvm.org/get_started.html

Build output claims that the object in question (LTOCodeGenerator.o) is built
with PIC options, but the linker disagrees:

llvm[2]: Compiling LTOCodeGenerator.cpp for Debug+Asserts build (PIC)
/home/hotellnx99/peeterj/tmp/clang/llvm/include/llvm/ADT/DenseMap.h: In copy
constructor 'llvm::DenseMap<KeyT, ValueT, KeyInfoT>::DenseMap(const
llvm::DenseMap<KeyT, ValueT, KeyInfoT>&) [with KeyT = unsigned int, ValueT =
llvm::PointerAlignElem, KeyInfoT = llvm::DenseMapInfo<unsigned int>]':
/home/hotellnx99/peeterj/tmp/clang/llvm/include/llvm/DataLayout.h:177:  
instantiated from here
/home/hotellnx99/peeterj/tmp/clang/llvm/include/llvm/ADT/DenseMap.h:534:
warning: base class 'class llvm::DenseMapBase<llvm::DenseMap<unsigned int,
llvm::PointerAlignElem, llvm::DenseMapInfo<unsigned int> >, unsigned int,
llvm::PointerAlignElem, llvm::DenseMapInfo<unsigned int> >' should be
explicitly initialized in the copy constructor
llvm[2]: Linking Debug+Asserts Shared Library libLTO.so
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
/home/hotellnx99/peeterj/tmp/clang/build/tools/lto/Debug+Asserts/LTOCodeGenerator.o:
relocation R_X86_64_PC32 against `std::basic_string<char,
std::char_traits<char>, std::allocator<char> >::c_str() const@@GLIBCXX_3.4' can
not be used when making a shared object; recompile with -fPIC
/usr/lib64/gcc/x86_64-suse-linux/4.1.2/../../../../x86_64-suse-linux/bin/ld:
final link failed: Bad value
collect2: ld returned 1 exit status
make[2]: ***
[/home/hotellnx99/peeterj/tmp/clang/build/Debug+Asserts/lib/libLTO.so] Error 1
make[2]: Leaving directory `/home/hotellnx99/peeterj/tmp/clang/build/tools/lto'
make[1]: *** [lto/.makeall] Error 2
make[1]: Leaving directory `/home/hotellnx99/peeterj/tmp/clang/build/tools'
make: *** [all] Error 1

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


From bugzilla-daemon at llvm.org  Mon Nov 19 10:53:13 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 18:53:13 +0000
Subject: [LLVMbugs] [Bug 13387] Strange typo-correction suggestion with
 inheritance+using
In-Reply-To: <bug-13387-206@http.llvm.org/bugs/>
References: <bug-13387-206@http.llvm.org/bugs/>
Message-ID: <bug-13387-206-kGT1ycAm6v@http.llvm.org/bugs/>

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

Kaelyn Uhrain <rikka at google.com> changed:

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

--- Comment #2 from Kaelyn Uhrain <rikka at google.com> 2012-11-19 12:53:13 CST ---
Found the problem (UsingDecls weren't being handled properly) and submitted a
fix as r168317.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 11:31:27 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 19:31:27 +0000
Subject: [LLVMbugs] [Bug 14376] Regression: Crash in llc with asm
In-Reply-To: <bug-14376-206@http.llvm.org/bugs/>
References: <bug-14376-206@http.llvm.org/bugs/>
Message-ID: <bug-14376-206-ADNBtcipvs@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2012-11-19 13:31:27 CST ---
Fixed in r168320.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 13:11:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 21:11:01 +0000
Subject: [LLVMbugs] [Bug 14386] New: UNREACHABLE executed at
 ../llvm/tools/clang/lib/AST/StmtPrinter.cpp:730!
Message-ID: <bug-14386-206@http.llvm.org/bugs/>

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

             Bug #: 14386
           Summary: UNREACHABLE executed at
                    ../llvm/tools/clang/lib/AST/StmtPrinter.cpp:730!
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: salvatore.benedetto at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9571
  --> http://llvm.org/bugs/attachment.cgi?id=9571
test case

Unexpected type for integer literal!
UNREACHABLE executed at
/home/emitrax/programming/llvm/tools/clang/lib/AST/StmtPrinter.cpp:730!
0  clang           0x0000000001bfc122
1  clang           0x0000000001bfc594
2  libpthread.so.0 0x00007f1ea9e23060
3  libc.so.6       0x00007f1ea91033a5 gsignal + 53
4  libc.so.6       0x00007f1ea9106b0b abort + 379
5  clang           0x0000000001bea8ef llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 463
6  clang           0x00000000010fed18
7  clang           0x0000000001103a15
Stack dump:
0.    Program arguments: /home/emitrax/bin/llvm/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
test_template_enum.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64
-target-linker-version 2.21.53.20110810 -momit-leaf-frame-pointer
-coverage-file /home/emitrax/programming/clang_crash/test_template_enum.o
-resource-dir /home/emitrax/bin/llvm/bin/../lib/clang/3.2 -fmodule-cache-path
/var/tmp/clang-module-cache -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6 -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward
-internal-isystem /usr/local/include -internal-isystem
/home/emitrax/bin/llvm/bin/../lib/clang/3.2/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -std=c++11 -fdeprecated-macro
-fdebug-compilation-dir /home/emitrax/programming/clang_crash -ferror-limit 19
-fmessage-length 213 -mstackrealign -fobjc-runtime=gcc -fcxx-exceptions
-fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
test_template_enum.o -x c++ test_template_enum.cpp 
1.    test_template_enum.cpp:53:3: at annotation token 
2.    test_template_enum.cpp:49:1: parsing function body 'main'
3.    test_template_enum.cpp:49:1: in compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (http://llvm.org/git/clang.git
c10a3281350129c12ceb670ac813f826aa6712d4) (http://llvm.org/git/llvm.git
3c13c3ebdd545d0fafd24f60315641c0e033a4d9)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/test_template_enum-5qSO8W.cpp
clang: note: diagnostic msg: /tmp/test_template_enum-5qSO8W.sh
clang: note: diagnostic msg: 

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 13:13:50 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 21:13:50 +0000
Subject: [LLVMbugs] [Bug 14381] Compile error only when running code
	completer
In-Reply-To: <bug-14381-206@http.llvm.org/bugs/>
References: <bug-14381-206@http.llvm.org/bugs/>
Message-ID: <bug-14381-206-B1ilDdC2Cz@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |FIXED

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-19 15:13:50 CST ---
Right, we can't skip parsing 'constexpr' function bodies. Fixed in r168327.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 13:21:32 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 21:21:32 +0000
Subject: [LLVMbugs] [Bug 14380] Possible bug in the code-gen documentation
In-Reply-To: <bug-14380-206@http.llvm.org/bugs/>
References: <bug-14380-206@http.llvm.org/bugs/>
Message-ID: <bug-14380-206-egvpPNmDXf@http.llvm.org/bugs/>

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

Sean Silva <silvas at purdue.edu> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |silvas at purdue.edu
         Resolution|                            |FIXED

--- Comment #1 from Sean Silva <silvas at purdue.edu> 2012-11-19 15:21:32 CST ---
It's not your eyesight :)

Fixed in r168329. Thankfully there was a way to hack around it this time (more
details in the commit message, if you're interested).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 13:22:18 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 21:22:18 +0000
Subject: [LLVMbugs] [Bug 10349] clang crashes when using template return type
In-Reply-To: <bug-10349-206@http.llvm.org/bugs/>
References: <bug-10349-206@http.llvm.org/bugs/>
Message-ID: <bug-10349-206-Us5RCsVB53@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |FIXED

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-19 15:22:18 CST ---
Right, we are now properly rejecting this.

template_foo.cpp:31:15: error: no matching function for call to
'type_constructor'
    decltype( type_constructor( &Y::bar ) ) x(y);
              ^~~~~~~~~~~~~~~~
template_foo.cpp:18:6: note: candidate template ignored: substitution failure
[with T = Y]: non-type template
      argument of type 'void (Y::*const)()' is not a constant expression
auto type_constructor( void (T::* const f)() ) -> X< T, f >;
     ^                                                  ~

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


From bugzilla-daemon at llvm.org  Mon Nov 19 13:22:42 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 21:22:42 +0000
Subject: [LLVMbugs] [Bug 14374] Local class can't access its members
In-Reply-To: <bug-14374-206@http.llvm.org/bugs/>
References: <bug-14374-206@http.llvm.org/bugs/>
Message-ID: <bug-14374-206-2EdxOyq8zp@http.llvm.org/bugs/>

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

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 #2 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-19 15:22:42 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 13:22:55 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 19 Nov 2012 21:22:55 +0000
Subject: [LLVMbugs] [Bug 14373] Segfault in
 CodeGenFunction::GetAddrOfBlockDecl when accessing automatic variable from
 local class
In-Reply-To: <bug-14373-206@http.llvm.org/bugs/>
References: <bug-14373-206@http.llvm.org/bugs/>
Message-ID: <bug-14373-206-biIdjG1T54@http.llvm.org/bugs/>

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

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 #2 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-19 15:22:55 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 17:01:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 01:01:16 +0000
Subject: [LLVMbugs] [Bug 14275] clang tests fail: unknown target triple
 'unknown-apple-darwin8.11.0', expect 'powerpc'
In-Reply-To: <bug-14275-206@http.llvm.org/bugs/>
References: <bug-14275-206@http.llvm.org/bugs/>
Message-ID: <bug-14275-206-T98axBIQvW@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

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

--- Comment #14 from David Fang <fang at csl.cornell.edu> 2012-11-19 19:01:16 CST ---
For the record~\cite{IRC}, echristo recommends going with the
Darwin_Generic_GCC route, so I will continue with that.  I would consider this
bug fixed.  (Thanks again, Daniel.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 17:06:45 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 01:06:45 +0000
Subject: [LLVMbugs] [Bug 14286] hello-world codegen fails: EmitRawText
 called on MCStreamer unsupported [powerpc-darwin8]
In-Reply-To: <bug-14286-206@http.llvm.org/bugs/>
References: <bug-14286-206@http.llvm.org/bugs/>
Message-ID: <bug-14286-206-RudHgHGsqh@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

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

--- Comment #4 from David Fang <fang at csl.cornell.edu> 2012-11-19 19:06:45 CST ---
I locally reverted Driver/Driver.cpp to let ppc/darwin use the
Darwin_Generic_GCC toolchain instead of DarwinClang.
In that case, -no-integrated-as is not needed at all, and this issue is
completely skirted.
With that, I am able to compile and run this hello-world example on
powerpc-darwin8.

(I can still wish for integrated ppc32 assembly and MC, can't 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  Mon Nov 19 17:12:24 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 01:12:24 +0000
Subject: [LLVMbugs] [Bug 3830] clang-driver 32 bit ppc arch name incorrect
In-Reply-To: <bug-3830-206@http.llvm.org/bugs/>
References: <bug-3830-206@http.llvm.org/bugs/>
Message-ID: <bug-3830-206-HXBpyczUxW@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

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

--- Comment #5 from David Fang <fang at csl.cornell.edu> 2012-11-19 19:12:24 CST ---
The problem I reported was attempting to use DarwinClang in the driver for
powerpc-darwin8 (required -no-integrated-as), which was not the recommended way
to compile.  Instead, falling back to Darwin_Generic_GCC avoids this entire
call path altogether.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 17:15:54 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 01:15:54 +0000
Subject: [LLVMbugs] [Bug 14349] Assertion in SROA around rewriting store
 instruction implicitly using a vector data type
In-Reply-To: <bug-14349-206@http.llvm.org/bugs/>
References: <bug-14349-206@http.llvm.org/bugs/>
Message-ID: <bug-14349-206-f0wv8aXscu@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2012-11-19 19:15:54 CST ---
Underlying issues should be fixed in r168346. Thanks for the reports 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  Mon Nov 19 17:17:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 01:17:49 +0000
Subject: [LLVMbugs] [Bug 13392] SROA of doubles confuses ARM codegen
In-Reply-To: <bug-13392-206@http.llvm.org/bugs/>
References: <bug-13392-206@http.llvm.org/bugs/>
Message-ID: <bug-13392-206-1fhnHNzAxX@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #4 from Chandler Carruth <chandlerc at gmail.com> 2012-11-19 19:17:49 CST ---
The core issue here (SROA doing bad things to matmul) was fixed by the SROA
rewrite.

Note that it in turn exposed some register allocation bugs that caused the
benchmark to *slow down* in some rare cases. ;] Anyways, I think this bug is
done.

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


From bugzilla-daemon at llvm.org  Mon Nov 19 17:26:47 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 01:26:47 +0000
Subject: [LLVMbugs] [Bug 11892] generated code crashes powerpc-darwin8
In-Reply-To: <bug-11892-206@http.llvm.org/bugs/>
References: <bug-11892-206@http.llvm.org/bugs/>
Message-ID: <bug-11892-206-GSAJkIove6@http.llvm.org/bugs/>

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

David Fang <fang at csl.cornell.edu> changed:

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

--- Comment #2 from David Fang <fang at csl.cornell.edu> 2012-11-19 19:26:47 CST ---
This test case now passes for me (and runs!) at r167855, using the
Darwin_Generic_GCC driver toolchain.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 18:03:59 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 02:03:59 +0000
Subject: [LLVMbugs] [Bug 14387] New: stage 2 powerpc-darwin8 compile error
 without proper diagnostic
Message-ID: <bug-14387-206@http.llvm.org/bugs/>

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

             Bug #: 14387
           Summary: stage 2 powerpc-darwin8 compile error without proper
                    diagnostic
           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: fang at csl.cornell.edu
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


After a successfully built (with g++-4.0.1) powerpc-darwin8 llvm and clang
(r167855), and showing that hello-world compiled and ran successfully, I
embarked on stage 2 of self-hosting/bootstrap.
A few translation units in, I get compile failures with no diagnostic except
10000s of lines of assembler errors:

/Volumes/Mercedes2/sw/bin/cmake -H/Users/fang/local/src/LLVM-svn/llvm
-B/Users/f
ang/local/src/LLVM-svn/gcc40-stage2-build --check-build-system
CMakeFiles/Makefi
le.cmake 0
/Volumes/Mercedes2/sw/bin/cmake -E cmake_progress_start
/Users/fang/local/src/LL
VM-svn/gcc40-stage2-build/CMakeFiles
/Users/fang/local/src/LLVM-svn/gcc40-stage2
-build/CMakeFiles/progress.marks
make -f CMakeFiles/Makefile2 all
make[1]: Entering directory `/Volumes/Isolde/builds/LLVM/gcc40-stage2-build'
make -f lib/Support/CMakeFiles/LLVMSupport.dir/build.make
lib/Support/CMakeFiles
/LLVMSupport.dir/depend
make[2]: Entering directory `/Volumes/Isolde/builds/LLVM/gcc40-stage2-build'
cd /Users/fang/local/src/LLVM-svn/gcc40-stage2-build &&
/Volumes/Mercedes2/sw/bi
n/cmake -E cmake_depends "Unix Makefiles" /Users/fang/local/src/LLVM-svn/llvm
/U
sers/fang/local/src/LLVM-svn/llvm/lib/Support
/Users/fang/local/src/LLVM-svn/gcc
40-stage2-build /Users/fang/local/src/LLVM-svn/gcc40-stage2-build/lib/Support
/U
sers/fang/local/src/LLVM-svn/gcc40-stage2-build/lib/Support/CMakeFiles/LLVMSuppo
rt.dir/DependInfo.cmake --color=
make[2]: Leaving directory `/Volumes/Isolde/builds/LLVM/gcc40-stage2-build'
make -f lib/Support/CMakeFiles/LLVMSupport.dir/build.make
lib/Support/CMakeFiles
/LLVMSupport.dir/build
make[2]: Entering directory `/Volumes/Isolde/builds/LLVM/gcc40-stage2-build'
/Volumes/Mercedes2/sw/bin/cmake -E cmake_progress_report
/Users/fang/local/src/L
LVM-svn/gcc40-stage2-build/CMakeFiles 
[  0%] Building CXX object lib/Support/CMakeFiles/LLVMSupport.dir/APFloat.cpp.o
cd /Users/fang/local/src/LLVM-svn/gcc40-stage2-build/lib/Support &&
/Volumes/Iso
lde/sources/LLVM-svn/gcc40-cmake-build/bin/clang++   -DLLVMSupport_EXPORTS
-D_DE
BUG -D__STDC_CONSTANT_MACROS -D__STDC_FORMAT_MACROS -D__STDC_LIMIT_MACROS
-fno-c
ommon -fPIC -fvisibility-inlines-hidden -fno-rtti -O2 -g -fPIC
-I/Users/fang/loc
al/src/LLVM-svn/gcc40-stage2-build/lib/Support
-I/Users/fang/local/src/LLVM-svn/
llvm/lib/Support -I/Users/fang/local/src/LLVM-svn/gcc40-stage2-build/include
-I/
Users/fang/local/src/LLVM-svn/llvm/include    -Wall -W -Wno-unused-parameter
-Ww
rite-strings -pedantic -Wno-long-long -Wcovered-switch-default -fno-exceptions
-
o CMakeFiles/LLVMSupport.dir/APFloat.cpp.o -c
/Users/fang/local/src/LLVM-svn/llv
m/lib/Support/APFloat.cpp
/tmp/APFloat-CRRODx.s:5:Missing string
/tmp/APFloat-CRRODx.s:5:Rest of line ignored. 1st junk character valued 49 (1).
/tmp/APFloat-CRRODx.s:6:Missing string
/tmp/APFloat-CRRODx.s:6:Rest of line ignored. 1st junk character valued 50 (2).
/tmp/APFloat-CRRODx.s:7:Missing string
/tmp/APFloat-CRRODx.s:7:Rest of line ignored. 1st junk character valued 51 (3).
/tmp/APFloat-CRRODx.s:8:Missing string
/tmp/APFloat-CRRODx.s:8:Rest of line ignored. 1st junk character valued 52 (4).
/tmp/APFloat-CRRODx.s:9:Missing string
/tmp/APFloat-CRRODx.s:9:Rest of line ignored. 1st junk character valued 53 (5).
/tmp/APFloat-CRRODx.s:10:Missing string
/tmp/APFloat-CRRODx.s:10:Rest of line ignored. 1st junk character valued 54
(6).
/tmp/APFloat-CRRODx.s:11:Missing string
/tmp/APFloat-CRRODx.s:11:Rest of line ignored. 1st junk character valued 55
(7).
/tmp/APFloat-CRRODx.s:12:Missing string
/tmp/APFloat-CRRODx.s:12:Rest of line ignored. 1st junk character valued 56
(8).
/tmp/APFloat-CRRODx.s:13:Missing string
/tmp/APFloat-CRRODx.s:13:Rest of line ignored. 1st junk character valued 57
(9).
/tmp/APFloat-CRRODx.s:14:Missing string
/tmp/APFloat-CRRODx.s:14:Rest of line ignored. 1st junk character valued 49
(1).
/tmp/APFloat-CRRODx.s:15:Missing string
/tmp/APFloat-CRRODx.s:15:Rest of line ignored. 1st junk character valued 49
(1).
/tmp/APFloat-CRRODx.s:16:Missing string
/tmp/APFloat-CRRODx.s:16:Rest of line ignored. 1st junk character valued 49
(1).

I don't know what is actually wrong, but certainly there needs to be some
meaningful diagnostic message.
Will post more details as find out more...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 19 18:35:41 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 02:35:41 +0000
Subject: [LLVMbugs] [Bug 14388] New: Array exception type should be decayed
 to pointer automatically
Message-ID: <bug-14388-206@http.llvm.org/bugs/>

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

             Bug #: 14388
           Summary: Array exception type should be decayed to pointer
                    automatically
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: wenhan.gu at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9572
  --> http://llvm.org/bugs/attachment.cgi?id=9572
source code

Hi all,

By exception handling spec, Array or Function should be decayed to Pointer
automatically.
In x86, it works fine on both TypeInfo and TypeFilter.
However, in ARM, it works only on TypeInfo. Function exception specification
list doesn't encode correctly.

Here's my command: 
clang++ -target armv7-unknown-linux-gnueabi test.cpp -emit-llvm -S -o test.ll


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 Nov 20 02:12:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 10:12:09 +0000
Subject: [LLVMbugs] [Bug 14132] SROA.cpp : Assertion
 `DL.getTypeStoreSize(Ty) + Offset <= DL.getTypeStoreSize(IntTy) && "Element
 extends past full value"' failed.
In-Reply-To: <bug-14132-206@http.llvm.org/bugs/>
References: <bug-14132-206@http.llvm.org/bugs/>
Message-ID: <bug-14132-206-bNhffcHmEX@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2012-11-20 04:12:09 CST ---
Fixed in r168361. Thanks for the repro, and sorry for taking a while to get to
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  Tue Nov 20 02:14:31 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 10:14:31 +0000
Subject: [LLVMbugs] [Bug 14248] SROA.cpp:2506: Assertion `[...] && "Only
 alloca-wide loads can be split and recomposed"' failed.
In-Reply-To: <bug-14248-206@http.llvm.org/bugs/>
References: <bug-14248-206@http.llvm.org/bugs/>
Message-ID: <bug-14248-206-g9oJYdcMe4@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #1 from Chandler Carruth <chandlerc at gmail.com> 2012-11-20 04:14:31 CST ---
This got fixed in passing. Not sure exactly which revision fixed it 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 Nov 20 02:24:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 10:24:26 +0000
Subject: [LLVMbugs] [Bug 14324] LLVM fails to build if both NDEBUG and
 LLVM_ENABLE_DUMP are defined
In-Reply-To: <bug-14324-206@http.llvm.org/bugs/>
References: <bug-14324-206@http.llvm.org/bugs/>
Message-ID: <bug-14324-206-qTtxqBV8ke@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2012-11-20 04:24:26 CST ---
Anyways, fixed in r168362 and r168363.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 20 02:28:08 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 10:28:08 +0000
Subject: [LLVMbugs] [Bug 14224] Clang asserts in SROA pass with ARM
In-Reply-To: <bug-14224-206@http.llvm.org/bugs/>
References: <bug-14224-206@http.llvm.org/bugs/>
Message-ID: <bug-14224-206-JCxbNHBbMT@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2012-11-20 04:28:08 CST ---
Fairly certain that this is a dup of PR14349. Either way, it is fixed on trunk.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 20 05:41:55 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 13:41:55 +0000
Subject: [LLVMbugs] [Bug 14390] New: Make X86CommonTableGen tablegenning
	parallel
Message-ID: <bug-14390-206@http.llvm.org/bugs/>

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

             Bug #: 14390
           Summary: Make X86CommonTableGen tablegenning parallel
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: cmake
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: timurrrr at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I'm using CMake + Microsoft Visual Studio and it takes a few minutes to compile
X86CommonTableGen as a part of Clang, even for a one line .td change!
Only one core of my 12-VCore CPU is used, so this looks to be easily
parallizable.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 20 07:00:36 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 15:00:36 +0000
Subject: [LLVMbugs] [Bug 14391] New: Python scripts assume that env is in
	/usr/bin/env
Message-ID: <bug-14391-206@http.llvm.org/bugs/>

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

             Bug #: 14391
           Summary: Python scripts assume that env is in /usr/bin/env
           Product: Build scripts
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kallisti5 at unixzen.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The python scripts assume that env is located in /usr/bin/env. This isn't
always the case and if env is in /bin the build fails.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 20 11:31:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 19:31:49 +0000
Subject: [LLVMbugs] [Bug 14392] New: Multiple consecutive
 __builtin_popcount()'s may be combined to a bigger type
Message-ID: <bug-14392-206@http.llvm.org/bugs/>

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

             Bug #: 14392
           Summary: Multiple consecutive __builtin_popcount()'s may be
                    combined to a bigger type
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jkim at FreeBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Please consider the following example:

% cat popcount.c
int
popcount(unsigned long x)
{
        unsigned *p;
        int c, i;

        for (c = i = 0, p = (void *)&x; i < sizeof(x) / sizeof(*p); i++)
                c += __builtin_popcount(*p++);
        return (c);
}
% clang -O2 -mpopcnt -S popcount.c
% cat popcount.s
        .file   "popcount.c"
        .text
        .globl  popcount
        .align  16, 0x90
        .type   popcount, at function
popcount:                               # @popcount
        .cfi_startproc
# BB#0:                                 # %entry
        popcntl %edi, %ecx
        shrq    $32, %rdi
        popcntl %edi, %eax
        addl    %ecx, %eax
        ret
.Ltmp0:
        .size   popcount, .Ltmp0-popcount
        .cfi_endproc


        .section        ".note.GNU-stack","", at progbits

Ideally, it should be folded into "return (__builtin_popcountl(x));" and
generate "popcntq %rdi, %rax; ret".

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


From bugzilla-daemon at llvm.org  Tue Nov 20 12:28:50 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 20:28:50 +0000
Subject: [LLVMbugs] [Bug 14372] Partial ordering of variadic function
	template
In-Reply-To: <bug-14372-206@http.llvm.org/bugs/>
References: <bug-14372-206@http.llvm.org/bugs/>
Message-ID: <bug-14372-206-NehI92gRsb@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-20 14:28:50 CST ---
Let's reopen this bug for that. Thanks for your persistence!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 20 13:07:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 21:07:35 +0000
Subject: [LLVMbugs] [Bug 14393] New: codegen crash with inline asm
Message-ID: <bug-14393-206@http.llvm.org/bugs/>

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

             Bug #: 14393
           Summary: codegen crash with inline asm
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Reported by rajesh viswabramana on llvmdev, I just converted the test to IL:

-------------------------------------------
target triple = "i386-unknown-linux-gnu"

define double @func1() {
entry:
  %0 = tail call double asm "", "=r,0,~{dirflag},~{fpsr},~{flags}"(double
undef)
  ret double %0
}
--------------------------------------------

$ ./bin/llc test.ll
llc:
/home/espindola/llvm/llvm/lib/CodeGen/SelectionDAG/SelectionDAGBuilder.cpp:383:
void getCopyToParts(llvm::SelectionDAG &, llvm::DebugLoc, llvm::SDValue,
llvm::SDValue *, unsigned int, llvm::EVT, const llvm::Value *, ISD::NodeType):
Assertion `(PartVT.isInteger() || PartVT == MVT::x86mmx) && ValueVT.isInteger()
&& "Unknown mismatch!"' 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  Tue Nov 20 14:00:00 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 22:00:00 +0000
Subject: [LLVMbugs] [Bug 14394] New: listing functions in gdb fails
Message-ID: <bug-14394-206@http.llvm.org/bugs/>

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

             Bug #: 14394
           Summary: listing functions in gdb fails
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


gdb/testsuite/gdb.base/included.exp

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 20 14:29:50 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 22:29:50 +0000
Subject: [LLVMbugs] [Bug 9990] Driver/hello.c failing after svn update
In-Reply-To: <bug-9990-206@http.llvm.org/bugs/>
References: <bug-9990-206@http.llvm.org/bugs/>
Message-ID: <bug-9990-206-Q6VV94E6u1@http.llvm.org/bugs/>

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

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> 2012-11-20 16:29:50 CST ---
I deleted hello.c 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 Nov 20 14:32:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 22:32:51 +0000
Subject: [LLVMbugs] [Bug 14395] New: XFAIL/cleanup failing tests in GDB 7.5
 suite/buildbot
Message-ID: <bug-14395-206@http.llvm.org/bugs/>

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

             Bug #: 14395
           Summary: XFAIL/cleanup failing tests in GDB 7.5 suite/buildbot
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: ASSIGNED
          Keywords: googler
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: dblaikie at gmail.com
        ReportedBy: dblaikie at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


Tracking cleanup work to baseline the GDB 7.5 test suite by xfailing &
otherwise fixing up the tests.

(during & after this is resolved I'll be going back over the xfails & filing
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  Tue Nov 20 15:27:36 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 20 Nov 2012 23:27:36 +0000
Subject: [LLVMbugs] [Bug 14396] New: linux x86_64:
 tools/clang/runtime/compiler-rt/Makefile missing endif :204
Message-ID: <bug-14396-206@http.llvm.org/bugs/>

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

             Bug #: 14396
           Summary: linux x86_64: tools/clang/runtime/compiler-rt/Makefile
                    missing endif :204
           Product: Build scripts
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Makefiles
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: peeter.joot at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Build proceeds without error until:

`/home/hotellnx99/peeterj/tmp/clang/build/tools/clang/runtime'
make[4]: Entering directory
`/home/hotellnx99/peeterj/tmp/clang/build/tools/clang/runtime/compiler-rt'
Makefile:204: *** missing `endif'.  Stop.
make[4]: Leaving directory
`/home/hotellnx99/peeterj/tmp/clang/build/tools/clang/runtime/compiler-rt'
make[3]: *** [compiler-rt/.makeall] Error 2

which is at this point in the Makefile:

    151 # Expand rules for copying/installing each individual library. We can't
use
    152 # implicit rules here because we need to match against multiple things.
    153 define RuntimeLibraryTemplate
    154 $(PROJ_OBJ_DIR)/clang_$1/%/libcompiler_rt.a: BuildRuntimeLibraries
    155    @true
    156 $(PROJ_OBJ_DIR)/clang_$1/%/libcompiler_rt.so: BuildRuntimeLibraries
    157    @true
    158 $(PROJ_OBJ_DIR)/clang_$1/%/libcompiler_rt.dylib: BuildRuntimeLibraries
    159    @true
    160 .PRECIOUS: $(PROJ_OBJ_DIR)/clang_$1/%/libcompiler_rt.a
...
    200 # Rule to install runtime libraries.
    201 RuntimeLibraryInstall.$1: \
    202      
$(RuntimeLibrary.$1.Configs:%=$(PROJ_resources_lib)/$1/libclang_rt.%)
    203 .PHONY: RuntimeLibraryInstall.$1
>>> 204 endef
    205 $(foreach lib,$(RuntimeDirs), $(eval $(call
RuntimeLibraryTemplate,$(lib))))
    206

(after a large define/endef block).  The odd part about the error is that
everything looks matched.  Indenting the output of 

grep -ne '^if' -e '^end' -e '^def' tools/clang/runtime/compiler-rt/Makefile

shows this:

64:ifneq ($(LLVM_CROSS_COMPILING),1)
   65:ifneq ($(CLANG_NO_RUNTIME),1)
      66:ifeq ($(shell test -d $(COMPILERRT_SRC_ROOT) && echo OK),OK)
         74:ifeq ($(OS),Darwin)
         81:endif

         84:ifeq ($(OS),Linux)
            100:ifeq ($(ARCH),x86)
            103:endif

            105:ifeq ($(ARCH),x86_64)
               114:ifeq ($(call
TryCompile,$(ToolDir)/clang,$(test_source),-m32),0)
               116:endif

               117:ifneq ($(LLVM_ANDROID_TOOLCHAIN_DIR),)
               119:endif
            120:endif
         122:endif

         153:define RuntimeLibraryTemplate
         204:endef
      212:endif
   213:endif
214:endif

Similarly, the included Makefile in ../../ also looks okay:

64:ifneq ($(LLVM_CROSS_COMPILING),1)
   65:ifneq ($(CLANG_NO_RUNTIME),1)
      66:ifeq ($(shell test -d $(COMPILERRT_SRC_ROOT) && echo OK),OK)

         74:ifeq ($(OS),Darwin)
         81:endif

         84:ifeq ($(OS),Linux)
            100:ifeq ($(ARCH),x86)
            103:endif

            105:ifeq ($(ARCH),x86_64)

               114:ifeq ($(call
TryCompile,$(ToolDir)/clang,$(test_source),-m32),0)
               116:endif

               117:ifneq ($(LLVM_ANDROID_TOOLCHAIN_DIR),)
               119:endif
            120:endif
         122:endif

         153:define RuntimeLibraryTemplate
         204:endef
      212:endif
   213:endif
214:endif

This is a build of the trunk, configured with:

../llvm/configure --prefix=$HOME/local --enable-optimized
--with-gcc-toolchain=$HOME/local --with-extra-ld-options
-Wl,-R,$HOME/local/lib64

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 20 18:33:34 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 02:33:34 +0000
Subject: [LLVMbugs] [Bug 13844] Repeated extern declaration can overflow the
	stack
In-Reply-To: <bug-13844-206@http.llvm.org/bugs/>
References: <bug-13844-206@http.llvm.org/bugs/>
Message-ID: <bug-13844-206-OLRBK1j8S1@http.llvm.org/bugs/>

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

Rafael Ávila de Espíndola <rafael.espindola at gmail.com> changed:

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

--- Comment #1 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> 2012-11-20 20:33:34 CST ---
The stack problem is fixed with r167703, but clang is still way slower than it
should be for this 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  Tue Nov 20 20:21:10 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 04:21:10 +0000
Subject: [LLVMbugs] [Bug 14397] New: breaking on a function produces
 multiple breakpoints
Message-ID: <bug-14397-206@http.llvm.org/bugs/>

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

             Bug #: 14397
           Summary: breaking on a function produces multiple breakpoints
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: googler
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


Breaking on main in "gdb/testsuite/gdb.base/call-sc.c" produces two
breakpoints.

This breaks at least gdb/testsuite/gdb.base/call-sc.exp (& probably others
too). I've added a small hack to lib/gdb.exp to workaround this for 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 Nov 20 20:43:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 04:43:51 +0000
Subject: [LLVMbugs] [Bug 14398] New: clang bootstrap builds generate
 inefficient code for chained calls to DAG.getNode()
Message-ID: <bug-14398-206@http.llvm.org/bugs/>

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

             Bug #: 14398
           Summary: clang bootstrap builds generate inefficient code for
                    chained calls to DAG.getNode()
           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: craig.topper at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


While looking at generated code for SelectionDAGBuilder.cpp, I noticed that
successive calls to DAG.getNode where each call depends on a previous call to
DAG.getNode() generates pretty inefficient sequences.

The basic sequence containing the problem looks something like this.
1. Copy EDX:RAX containing the returned SDValue to a fixed stack slot as if it
was a local variable.
2. Load from stack slot just written to.
3. Store those registers into stack frame for the next call.

Each return value gets allocated to own unique stack object not shared with any
other calls. This results in a unique stack object for every call to getNode in
a function. These stack objects are short lived, but aren't being reused. But
really there's no reason for it to exist.

Ideally the generated code would put EDX:RAX into the stack frame for the next
call directly. This would save 4 instructions per call to DAG.getNode()


Looking at the IR, I see clang has generated a store to an alloca representing
the local SDValue that the DAG.getNode() result is assigned to. Then a memcpy
into a separate alloca. A pointer to this alloca is passed to the next
DAG.getNode() which has "%"class.llvm::SDValue"* byval align 8" as its argument
type.

If getNode had less arguments the SDValue would be split into its fields to be
passed in separate register arguments. But since getNode has so many arguments
clang decides that after the first 6 registers, the remaining SDValue arguments
need to be passed as byval pointers.

Since the IR passes see this alloca being passed as a pointer they skip
optimizing it. There also no lifetime intrinsics associated with it to track
it.

So it stays all the way to calling convention handling in the backend. At this
point the X86 calling convention handling seems to decide that all byval
arguments should be passed by copying the entire SDValue onto the stack for the
call. Which is completely different than what the IR itself thinks will happen.

So now we're left with the store, the load, and another store and no machine
instruction passes will touch them either.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 20 23:07:52 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 07:07:52 +0000
Subject: [LLVMbugs] [Bug 14399] New: clang assertion since  r167353
Message-ID: <bug-14399-206@http.llvm.org/bugs/>

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

             Bug #: 14399
           Summary: clang assertion since  r167353
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dgilmore at mips.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Typescript for reproducing the problem:

$ cat bar.c
void foo_aa()
{
#define /* */ BARC(c, /* */b, a, ...) (a+b+/* */c + __VA_ARGS__ +0)
    iequals(__LINE__, BARC(4,3,2,6,8), 8);
}
$ clang  -c bar.c  -emit-llvm
bar.c:4:2: warning: implicit declaration of function 'iequals' is invalid in
C99 [-Wimplicit-function-declaration]
        iequals(__LINE__, BARC(4,3,2,6,8), 8);
        ^
bar.c:4:20: warning: expression result unused [-Wunused-value]
clang:
/scratch/bb-slaves/mipssw005/LLVM_optimize_install/source/tools/clang/lib/Frontend/TextDiagnostic.cpp:1086:
void clang::TextDiagnostic::highlightRange(const clang::CharSourceRange&,
unsigned int, clang::FileID, const SourceColumnMap&, std::string&, const
clang::SourceManager&): Assertion `StartColNo <= EndColNo && "Invalid range!"'
failed.
0  clang           0x00000000020b701f
1  clang           0x00000000020b8f9a
2  libpthread.so.0 0x00007f8dd46a88f0
3  libc.so.6       0x00007f8dd3997a75 gsignal + 53
4  libc.so.6       0x00007f8dd399b5c0 abort + 384
5  libc.so.6       0x00007f8dd3990941 __assert_fail + 241
6  clang           0x000000000071c774
clang::TextDiagnostic::highlightRange(clang::CharSourceRange const&, unsigned
int, clang::FileID, SourceColumnMap const&, std::string&, clang::SourceManager
const&) + 1748
7  clang           0x000000000071daea
clang::TextDiagnostic::emitSnippetAndCaret(clang::SourceLocation,
clang::DiagnosticsEngine::Level,
llvm::SmallVectorImpl<clang::CharSourceRange>&,
llvm::ArrayRef<clang::FixItHint>, clang::SourceManager const&) + 2394
8  clang           0x0000000000712893
clang::DiagnosticRenderer::emitMacroExpansionsAndCarets(clang::SourceLocation,
clang::DiagnosticsEngine::Level,
llvm::SmallVectorImpl<clang::CharSourceRange>&,
llvm::ArrayRef<clang::FixItHint>, clang::SourceManager const&, unsigned int&,
unsigned int) + 211
9  clang           0x0000000000712ee6
clang::DiagnosticRenderer::emitMacroExpansionsAndCarets(clang::SourceLocation,
clang::DiagnosticsEngine::Level,
llvm::SmallVectorImpl<clang::CharSourceRange>&,
llvm::ArrayRef<clang::FixItHint>, clang::SourceManager const&, unsigned int&,
unsigned int) + 1830
10 clang           0x0000000000713637
clang::DiagnosticRenderer::emitDiagnostic(clang::SourceLocation,
clang::DiagnosticsEngine::Level, llvm::StringRef,
llvm::ArrayRef<clang::CharSourceRange>, llvm::ArrayRef<clang::FixItHint>,
clang::SourceManager const*, llvm::PointerUnion<clang::Diagnostic const*,
clang::StoredDiagnostic const*>) + 983
11 clang           0x00000000006dba51
clang::TextDiagnosticPrinter::HandleDiagnostic(clang::DiagnosticsEngine::Level,
clang::Diagnostic const&) + 561
12 clang           0x00000000013da8a4
clang::DiagnosticIDs::EmitDiag(clang::DiagnosticsEngine&,
clang::DiagnosticIDs::Level) const + 52
13 clang           0x00000000013dcbde
clang::DiagnosticIDs::ProcessDiag(clang::DiagnosticsEngine&) const + 462
14 clang           0x00000000013d64e4
clang::DiagnosticsEngine::EmitCurrentDiagnostic(bool) + 36
15 clang           0x0000000000a3e99e
clang::Sema::EmitCurrentDiagnostic(unsigned int) + 862
16 clang           0x0000000000a4700f
17 clang           0x0000000000b67d0d
clang::Sema::DiagRuntimeBehavior(clang::SourceLocation, clang::Stmt const*,
clang::PartialDiagnostic const&) + 1565
18 clang           0x0000000000c789e8
clang::Sema::DiagnoseUnusedExprResult(clang::Stmt const*) + 456
19 clang           0x0000000000b8aafe
clang::Sema::CreateBuiltinBinOp(clang::SourceLocation,
clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) + 2862
20 clang           0x0000000000b8aed3 clang::Sema::BuildBinOp(clang::Scope*,
clang::SourceLocation, clang::BinaryOperatorKind, clang::Expr*, clang::Expr*) +
259
21 clang           0x0000000000b8b286 clang::Sema::ActOnBinOp(clang::Scope*,
clang::SourceLocation, clang::tok::TokenKind, clang::Expr*, clang::Expr*) + 278
22 clang           0x00000000009e7dc0
clang::Parser::ParseRHSOfBinaryExpression(clang::ActionResult<clang::Expr*,
true>, clang::prec::Level) + 2400
23 clang           0x00000000009e9349
clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 25
24 clang           0x00000000009ebaa4
clang::Parser::ParseParenExpression(clang::Parser::ParenParseOption&, bool,
bool, clang::OpaquePtr<clang::QualType>&, clang::SourceLocation&) + 2500
25 clang           0x00000000009e5f3a clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::Parser::TypeCastState) + 698
26 clang           0x00000000009e73dd clang::Parser::ParseCastExpression(bool,
bool, clang::Parser::TypeCastState) + 29
27 clang           0x00000000009e8def
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 31
28 clang           0x00000000009e8ec2
clang::Parser::ParseExpressionList(llvm::SmallVectorImpl<clang::Expr*>&,
llvm::SmallVectorImpl<clang::SourceLocation>&, void
(clang::Sema::*)(clang::Scope*, clang::Expr*, llvm::ArrayRef<clang::Expr*>),
clang::Expr*) + 130
29 clang           0x00000000009e96ba
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*,
true>) + 874
30 clang           0x00000000009e5d78 clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::Parser::TypeCastState) + 248
31 clang           0x00000000009e73dd clang::Parser::ParseCastExpression(bool,
bool, clang::Parser::TypeCastState) + 29
32 clang           0x00000000009e8def
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 31
33 clang           0x00000000009e9339
clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 9
34 clang           0x0000000000a191e8 clang::Parser::ParseExprStatement() + 72
35 clang           0x0000000000a14605
clang::Parser::ParseStatementOrDeclarationAfterAttributes(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&)
+ 1909
36 clang           0x0000000000a1479e
clang::Parser::ParseStatementOrDeclaration(llvm::SmallVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*) + 142
37 clang           0x0000000000a15801
clang::Parser::ParseCompoundStatementBody(bool) + 1841
38 clang           0x0000000000a15e6a
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 154
39 clang           0x00000000009b9aa9
clang::Parser::ParseFunctionDefinition(clang::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&, clang::Parser::LateParsedAttrList*) +
2617
40 clang           0x00000000009cc64d
clang::Parser::ParseDeclGroup(clang::ParsingDeclSpec&, unsigned int, bool,
clang::SourceLocation*, clang::Parser::ForRangeInit*) + 3085
41 clang           0x00000000009b5099
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 249
42 clang           0x00000000009b56c4
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 804
43 clang           0x00000000009b70ba
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 1674
44 clang           0x00000000009b7652
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 194
45 clang           0x00000000009ae548 clang::ParseAST(clang::Sema&, bool, bool)
+ 296
46 clang           0x00000000008336fe clang::CodeGenAction::ExecuteAction() +
78
47 clang           0x00000000006ba8b9 clang::FrontendAction::Execute() + 185
48 clang           0x0000000000697655
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 341
49 clang           0x000000000067f20c
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1708
50 clang           0x00000000006767b8 cc1_main(char const**, char const**, char
const*, void*) + 1240
51 clang           0x000000000067d847 main + 7431
52 libc.so.6       0x00007f8dd3982c4d __libc_start_main + 253
53 clang           0x0000000000675749
Stack dump:
0.    Program arguments:
/mips/proj/build-compiler/log.2012-11-19/LLVM-clang/install-master-9eecb35d6b3cd772b57620f37deb065b2f426aae-0c5d005cd383e2d8c2bea388419ac26ace12e0f0/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-llvm-bc -disable-free
-main-file-name bar.c -mrelocation-model static -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64
-target-linker-version 2.20.1 -momit-leaf-frame-pointer -coverage-file
/scratch/dgilmore/delta_bug669/bar.o -resource-dir
/mips/proj/build-compiler/log.2012-11-19/LLVM-clang/install-master-9eecb35d6b3cd772b57620f37deb065b2f426aae-0c5d005cd383e2d8c2bea388419ac26ace12e0f0/bin/../lib/clang/3.3
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/usr/local/include -internal-isystem
/mips/proj/build-compiler/log.2012-11-19/LLVM-clang/install-master-9eecb35d6b3cd772b57620f37deb065b2f426aae-0c5d005cd383e2d8c2bea388419ac26ace12e0f0/bin/../lib/clang/3.3/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include
-fdebug-compilation-dir /scratch/dgilmore/delta_bug669 -ferror-limit 19
-fmessage-length 154 -mstackrealign -fobjc-runtime=gcc
-fdiagnostics-show-option -o bar.o -x c bar.c 
1.    bar.c:4:20 <Spelling=bar.c:3:67>: current parser token ')'
2.    bar.c:2:1: parsing function body 'foo_aa'
3.    bar.c:2:1: in compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (git://dmz-portal.mips.com/clang.git
0c5d005cd383e2d8c2bea388419ac26ace12e0f0) (git://dmz-portal.mips.com/llvm.git
9eecb35d6b3cd772b57620f37deb065b2f426aae)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/bar-3QBo5S.c
clang: note: diagnostic msg: /tmp/bar-3QBo5S.sh
clang: note: diagnostic msg: 

********************
$

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 21 00:18:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 08:18:03 +0000
Subject: [LLVMbugs] [Bug 14055] New SROA regression versus old scalarrepl -
	alloca 3xi8
In-Reply-To: <bug-14055-206@http.llvm.org/bugs/>
References: <bug-14055-206@http.llvm.org/bugs/>
Message-ID: <bug-14055-206-mG8gRAOK4C@http.llvm.org/bugs/>

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

Chandler Carruth <chandlerc at gmail.com> changed:

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

--- Comment #2 from Chandler Carruth <chandlerc at gmail.com> 2012-11-21 02:18:03 CST ---
The fix is somewhat specific to vectors -- we want to create shufflevectors to
expand vector accesses to a subset of elements into accesses to the entire
vector.

I've implemented this in r168418. Let me know if you see any problems or missed
optz 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 Nov 21 02:13:10 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 10:13:10 +0000
Subject: [LLVMbugs] [Bug 14400] New: Crash in analyzer on simple testcase
Message-ID: <bug-14400-206@http.llvm.org/bugs/>

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

             Bug #: 14400
           Summary: Crash in analyzer on simple testcase
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: markus at trippelsdorf.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


markus at x4 failures % cat test.ii
void
print_loop (int p1)
{
    __builtin_alloca (p1);
    print_loop (1);
    print_loop (0);
}

markus at x4 failures % clang++ -cc1 -analyze -analyzer-checker=core test.ii
0  clang++         0x0000000000c3e3a2
1  clang++         0x0000000000c3e723
2  libpthread.so.0 0x00007f350bbdf220
3  clang++         0x0000000001456eaa
clang::ento::ProgramState::BindExpr(clang::Stmt const*, clang::LocationContext
const*, clang::ento::SVal, bool) const + 26
4  clang++         0x00000000013f0d46
5  clang++         0x0000000001422f17
clang::ento::CheckerManager::runCheckersForEvalCall(clang::ento::ExplodedNodeSet&,
clang::ento::ExplodedNodeSet const&, clang::ento::CallEvent const&,
clang::ento::ExprEngine&) + 567
6  clang++         0x000000000143f915
clang::ento::ExprEngine::evalCall(clang::ento::ExplodedNodeSet&,
clang::ento::ExplodedNode*, clang::ento::CallEvent const&) + 581
7  clang++         0x000000000143f613
clang::ento::ExprEngine::VisitCallExpr(clang::CallExpr const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 755
8  clang++         0x000000000143150c
clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*,
clang::ento::ExplodedNodeSet&) + 10108
9  clang++         0x000000000142dc73
clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt,
clang::ento::ExplodedNode*) + 931
10 clang++         0x000000000142d8c1
clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) +
97
11 clang++         0x0000000001426e81
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*,
clang::ProgramPoint, clang::ento::WorkListUnit const&) + 433
12 clang++         0x0000000001426a9f
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>) + 559
13 clang++         0x00000000013708fb
14 clang++         0x00000000013701ce
15 clang++         0x000000000136d0d9
16 clang++         0x0000000000e5d513 clang::ParseAST(clang::Sema&, bool, bool)
+ 531
17 clang++         0x0000000000dd2ca3 clang::FrontendAction::Execute() + 83
18 clang++         0x0000000000db816d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 845
19 clang++         0x0000000000c40d71
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3665
20 clang++         0x00000000005c6f3d cc1_main(char const**, char const**, char
const*, void*) + 621
21 clang++         0x00000000005c3d3c main + 2988
22 libc.so.6       0x00007f350b5fd895 __libc_start_main + 245
23 clang++         0x00000000005c3079
Stack dump:
0.      Program arguments: clang++ -cc1 -analyze -analyzer-checker=core test.ii 
1.      <eof> parser at end of file
2.      test.ii:4:5: Error evaluating statement
3.      test.ii:4:5: Error evaluating statement
[1]    22875 segmentation fault  clang++ -cc1 -analyze -analyzer-checker=core
test.ii
markus at x4 failures %

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 21 09:43:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 17:43:20 +0000
Subject: [LLVMbugs] [Bug 14386] UNREACHABLE executed at
 ../llvm/tools/clang/lib/AST/StmtPrinter.cpp:730!
In-Reply-To: <bug-14386-206@http.llvm.org/bugs/>
References: <bug-14386-206@http.llvm.org/bugs/>
Message-ID: <bug-14386-206-rdcutJYIko@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
           Keywords|                            |crash-on-invalid
             Status|NEW                         |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |FIXED

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-21 11:43:20 CST ---
Fixed in r168441.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 21 11:49:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 19:49:35 +0000
Subject: [LLVMbugs] [Bug 14402] New: incorrect "self" for child class of
 nested class in template class
Message-ID: <bug-14402-206@http.llvm.org/bugs/>

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

             Bug #: 14402
           Summary: incorrect "self" for child class of nested class in
                    template class
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ryan at igglybob.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9581
  --> http://llvm.org/bugs/attachment.cgi?id=9581
reduction of problem to simple test case

The attached file causes the following error:

----
/home/ryan/test.cpp:20:16: error: call to non-static member function 'm' of 'A'
from nested type 'C'
    void x() { m(); }
               ^
1 error generated.
----

GCC does not generate this error and I don't believe it to be correct.  The
problem can be worked around by calling '(*this).m()' instead of 'm()'. 
Without knowing the internals of clang and having slept through my compilers
class (which led to some odd dreams), my three-miles-high assumption is that
the compiler is not properly realizing that it is inside of a child class.

By commenting out the 'template<typename T>' at the top of the definition of
class A, the error does not appear (although you will also have to uncomment
the relevant portions in main()).

I tested the problem on clang 3.1-8 and then compiled from trunk and also
reproduced the behavior there.

It is possible I misunderstood the C++ language spec and this is actually
intended behavior, but that doesn't seem quite right 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  Wed Nov 21 12:02:04 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 20:02:04 +0000
Subject: [LLVMbugs] [Bug 14403] New: Seg fault on complicated template
	metaprogram
Message-ID: <bug-14403-206@http.llvm.org/bugs/>

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

             Bug #: 14403
           Summary: Seg fault on complicated template metaprogram
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: eric at boostpro.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


See attached repro 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 Nov 21 15:27:26 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 21 Nov 2012 23:27:26 +0000
Subject: [LLVMbugs] [Bug 14404] New: DebugInfo: Clang does not encode enum
 values with their truncated value
Message-ID: <bug-14404-206@http.llvm.org/bugs/>

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

             Bug #: 14404
           Summary: DebugInfo: Clang does not encode enum values with
                    their truncated value
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


gdb/testsuite/gdb.base/enumval.exp

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 21 16:59:12 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 00:59:12 +0000
Subject: [LLVMbugs] [Bug 14405] New: Debug info for empty functions does not
 have line information
Message-ID: <bug-14405-206@http.llvm.org/bugs/>

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

             Bug #: 14405
           Summary: Debug info for empty functions does not have line
                    information
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


breaking on main in the trivial program:
int main() {
}
breaks at a location without source code

(gdb) break main
Breakpoint 1 at 0x4004d0
(gdb) r
Starting program: /home/blaikie/Development/scratch/a.out 

Breakpoint 1, 0x00000000004004d0 in main ()

rather than GCC which:
(gdb) break main
Breakpoint 1 at 0x4004d0: file main.c, line 2.
(gdb) r
Starting program: /home/blaikie/Development/scratch/a.out 

Breakpoint 1, main () at main.c:2
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  Wed Nov 21 17:05:29 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 01:05:29 +0000
Subject: [LLVMbugs] [Bug 14405] Debug info for empty functions does not have
 line information
In-Reply-To: <bug-14405-206@http.llvm.org/bugs/>
References: <bug-14405-206@http.llvm.org/bugs/>
Message-ID: <bug-14405-206-R3Sw1ui4EK@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #1 from David Blaikie <dblaikie at gmail.com> 2012-11-21 19:05:29 CST ---
this case requires the same debug info (as PR14394) just for a different
command

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 21 19:00:35 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 03:00:35 +0000
Subject: [LLVMbugs] [Bug 14406] New: expected '(' after 'asm'
Message-ID: <bug-14406-206@http.llvm.org/bugs/>

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

             Bug #: 14406
           Summary: expected '(' after 'asm'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zhenbo1987 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I was trying to use clang to compile linux kernel 3.5.4.

It complains

error: expected '(' after 'asm'
  asm goto("1: jmp %l[t_no]\n"
      ^

 when compiling inline asm code like:

static inline __attribute__((no_instrument_function))
__attribute__((always_inline)) __attribute__((pure)) bool __static_cpu_has(u16
bit)
{

  asm goto("1: jmp %l[t_no]\n"
    "2:\n"
    ".section .altinstructions,\"a\"\n"
    " .long 1b - .\n"
    " .long 0\n"
    " .word %P0\n"
    " .byte 2b - 1b\n"
    " .byte 0\n"
    ".previous\n"

    : : "i" (bit) : : t_no);
  return true;
 t_no:
  return false;
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 21 20:04:48 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 04:04:48 +0000
Subject: [LLVMbugs] [Bug 14406] support "asm goto"
In-Reply-To: <bug-14406-206@http.llvm.org/bugs/>
References: <bug-14406-206@http.llvm.org/bugs/>
Message-ID: <bug-14406-206-IMOFYe6yjH@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |sharparrow1 at yahoo.com
         Resolution|                            |LATER
            Summary|expected '(' after 'asm'    |support "asm goto"

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-21 22:04:48 CST ---
We don't currently support "asm goto", and I don't expect we will anytime in
the near future.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 21 20:48:00 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 04:48:00 +0000
Subject: [LLVMbugs] [Bug 14099] structure pass byval causes data corruption
In-Reply-To: <bug-14099-206@http.llvm.org/bugs/>
References: <bug-14099-206@http.llvm.org/bugs/>
Message-ID: <bug-14099-206-6CLgFpk8oU@http.llvm.org/bugs/>

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

Saleem Abdulrasool <compnerd at compnerd.org> changed:

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

--- Comment #6 from Saleem Abdulrasool <compnerd at compnerd.org> 2012-11-21 22:48:00 CST ---
Yeah, that fixes it for me.  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  Wed Nov 21 23:13:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 07:13:30 +0000
Subject: [LLVMbugs] [Bug 14407] New: Conditional assignment omitted when
 compiling a C program with llvm-gcc
Message-ID: <bug-14407-206@http.llvm.org/bugs/>

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

             Bug #: 14407
           Summary: Conditional assignment omitted when compiling a C
                    program with llvm-gcc
           Product: new-bugs
           Version: 2.7
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: edwardgaoyb at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


When compiling our application, I found that llvm-gcc frontend omitted the
conditional assignment. Please refer to the sample code snippet:

#include <stdio.h>

typedef struct {
        int i1;
        int i2;
        int i3;
        int i4;
} Entry1;

typedef struct {
        int i1;
        int i2;
        int i3;
} Entry2;

int TestEntry1(int bCheck)
{
        void* pEntry1 = 0;
        void* pEntry2 = (bCheck != 0) ? ((void*)(((Entry1*) pEntry1) + 1)) :
((void*)(((Entry2*) pEntry1) + 1));
        return (pEntry2 - pEntry1);
}

int main(int argc, const char * argv[])
{
        printf("TestEntry1(1): %d\n", TestEntry1(1));
        printf("TestEntry1(0): %d\n", TestEntry1(0));
        return 0;
}

$llvm-gcc ca.c
$./a.out
TestEntry1(1): 16
TestEntry1(0): 16

while the expected output is:
TestEntry1(1): 16
TestEntry1(0): 12

After reviewing the assemble code, the "(bCheck != 0)" judgement is missing.
The other frontend "clang" works 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 Nov 21 23:16:21 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 07:16:21 +0000
Subject: [LLVMbugs] [Bug 14407] Conditional assignment omitted when
 compiling a C program with llvm-gcc
In-Reply-To: <bug-14407-206@http.llvm.org/bugs/>
References: <bug-14407-206@http.llvm.org/bugs/>
Message-ID: <bug-14407-206-wK8KeLWgCL@http.llvm.org/bugs/>

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

Eric Christopher <echristo at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |echristo at gmail.com
         Resolution|                            |WONTFIX

--- Comment #1 from Eric Christopher <echristo at gmail.com> 2012-11-22 01:16:21 CST ---
LLVM 2.7 is very old and llvm-gcc is no longer worked on as part of the
project. You should switch to either clang or 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  Wed Nov 21 23:42:59 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 07:42:59 +0000
Subject: [LLVMbugs] [Bug 14408] New: unsupported inline asm: input with type
 'long' matching output with type 'int'
Message-ID: <bug-14408-206@http.llvm.org/bugs/>

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

             Bug #: 14408
           Summary: unsupported inline asm: input with type 'long'
                    matching output with type 'int'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zhenbo1987 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang generate error instead of warning in the following testcase.

TestCase:
static inline __attribute__((no_instrument_function)) int ffs(int x)
{
   int r;
   long tmp = -1;
   asm("bsfl %1,%0"
       : "=r" (r)
       : "rm" (x), "0" (tmp));
   return r + 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  Thu Nov 22 01:00:52 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 09:00:52 +0000
Subject: [LLVMbugs] [Bug 14409] New: 2010-06-14-fast-isel-fs-load.ll is
 failing in llvm 3.2 rc 1
Message-ID: <bug-14409-206@http.llvm.org/bugs/>

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

             Bug #: 14409
           Summary: 2010-06-14-fast-isel-fs-load.ll is failing in llvm 3.2
                    rc 1
           Product: libraries
           Version: 3.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sylvestre at debian.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Running the unitary tests under x86, I get the following error:

FAIL: LLVM :: CodeGen/X86/2010-06-14-fast-isel-fs-load.ll (2383 of 6824)
******************** TEST 'LLVM :: CodeGen/X86/2010-06-14-fast-isel-fs-load.ll'
FAILED ********************
Script:
--
/build/buildd-llvm-3.2_3.2~rc1-1~exp3-i386-QUGJqB/llvm-3.2-3.2~rc1/build-llvm/Release/bin/llc
-fast-isel -march=x86 <
/build/buildd-llvm-3.2_3.2~rc1-1~exp3-i386-QUGJqB/llvm-3.2-3.2~rc1/test/CodeGen/X86/2010-06-14-fast-isel-fs-load.ll
| grep %fs:
/build/buildd-llvm-3.2_3.2~rc1-1~exp3-i386-QUGJqB/llvm-3.2-3.2~rc1/build-llvm/Release/bin/llc
-fast-isel -march=x86 <
/build/buildd-llvm-3.2_3.2~rc1-1~exp3-i386-QUGJqB/llvm-3.2-3.2~rc1/test/CodeGen/X86/2010-06-14-fast-isel-fs-load.ll
| grep %fs:
--
Exit Code: 1
Command Output (stderr):
--
/build/buildd-llvm-3.2_3.2~rc1-1~exp3-i386-QUGJqB/llvm-3.2-3.2~rc1/build-llvm/Release/bin/llc:
<stdin>:9:12: error: invalid redefinition of function 'test1'
define i32 @test1(i32 addrspace(257)* %arg) nounwind {
           ^
--

********************
E: Caught signal 'Terminated': terminating immediately
make[1]: *** [override_dh_auto_test] Terminated

Full log available here:
https://buildd.debian.org/status/fetch.php?pkg=llvm-3.2&arch=i386&ver=3.2%7Erc1-1%7Eexp3&stamp=1353428888

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 01:28:56 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 09:28:56 +0000
Subject: [LLVMbugs] [Bug 14409] 2010-06-14-fast-isel-fs-load.ll is failing
 in llvm 3.2 rc 1
In-Reply-To: <bug-14409-206@http.llvm.org/bugs/>
References: <bug-14409-206@http.llvm.org/bugs/>
Message-ID: <bug-14409-206-s40qsb1vYh@http.llvm.org/bugs/>

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

Sylvestre Ledru <sylvestre at debian.org> changed:

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

--- Comment #1 from Sylvestre Ledru <sylvestre at debian.org> 2012-11-22 03:28:56 CST ---
It might be our fault. I will reopen it if it is not 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  Thu Nov 22 02:18:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 10:18:51 +0000
Subject: [LLVMbugs] [Bug 14402] incorrect "self" for child class of nested
 class in template class
In-Reply-To: <bug-14402-206@http.llvm.org/bugs/>
References: <bug-14402-206@http.llvm.org/bugs/>
Message-ID: <bug-14402-206-ts3jMgdmFu@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-22 04:18:51 CST ---
Oh, and I fixed the Clang bug in r168477. Sorry for giving you headaches! :)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 02:36:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 10:36:44 +0000
Subject: [LLVMbugs] [Bug 14410] New: [-cxx-abi microsoft] Wrong mangling of
 __stdcall functions?
Message-ID: <bug-14410-206@http.llvm.org/bugs/>

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

             Bug #: 14410
           Summary: [-cxx-abi microsoft] Wrong mangling of __stdcall
                    functions?
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: timurrrr at google.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


=== stdcall.cpp ===
extern int cnt;
void __stdcall foo();

#ifdef CONFIG_1
void __stdcall foo() {
  cnt = 42;
}

#else
int cnt = 10;

int main() {
  void (__stdcall *ptr)() = foo;
  (*ptr)();
  return (cnt == 42) ? 0 : 1;
}
#endif
===================

$ cl -c -Fostdcall_1_1.obj -DCONFIG_1 stdcall.cpp
$ clang -Xclang -cxx-abi -Xclang microsoft -c -ostdcall_1_2.o stdcall.cpp
$ link stdcall_1_1.obj stdcall_1_2.o
stdcall_1_2.o : error LNK2019: unresolved external symbol "?foo@@YGXXZ at 0"
(?foo@@YGXXZ at 0) referenced in function _main

$ cl -c -Fostdcall_2_1.o stdcall.cpp
$ clang -Xclang -cxx-abi -Xclang microsoft -c -ostdcall_2_2.obj -DCONFIG_1
stdcall.cpp
$ link stdcall_2_1.o stdcall_2_2.obj
stdcall_2_1.o : error LNK2019: unresolved external symbol "void __stdcall
foo(void)" (?foo@@YGXXZ) referenced in function _main

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 03:11:28 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 11:11:28 +0000
Subject: [LLVMbugs] [Bug 14411] New: "restrict requires a pointer or
 reference" is wrong for C++11
Message-ID: <bug-14411-206@http.llvm.org/bugs/>

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

             Bug #: 14411
           Summary: "restrict requires a pointer or reference" is wrong
                    for C++11
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: i.galic at brainsware.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


If I understand the spec correctly:


    17.2 The C standard library [library.c]

    1 The C++ standard library also makes available the facilities of the C
standard library, suitably adjusted to ensure static type safety.
    2 The descriptions of many library functions rely on the C standard library
for the signatures and semantics of those functions. In all such cases, any use
of the restrict qualifier shall be omitted.


for C++11, restrict should be ignored.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 03:14:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 11:14:03 +0000
Subject: [LLVMbugs] [Bug 14412] New: bool reduction of case values is
	questionable
Message-ID: <bug-14412-206@http.llvm.org/bugs/>

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

             Bug #: 14412
           Summary: bool reduction of case values is questionable
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Test case:

void a (void) {
    _Bool b;
    switch (b) {
    case 2:
    case 0:
    break;
    }
}

This gives a warning: overflow converting case value to switch condition type
(2 to 0)
and later an error for the defined case. I don't think the warning is correct.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 05:22:44 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 13:22:44 +0000
Subject: [LLVMbugs] [Bug 14413] New: [-cxx-abi microsoft] anonymous
 namespaces are mangled incorrectly
Message-ID: <bug-14413-206@http.llvm.org/bugs/>

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

             Bug #: 14413
           Summary: [-cxx-abi microsoft] anonymous namespaces are mangled
                    incorrectly
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: timurrrr at google.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


=== anon.cpp ===
namespace A {
namespace B {
namespace {  // anonymous

void foo();

}
}
}

int main() {
  A::B::foo();
}
================

clang -w -Xclang -cxx-abi -Xclang microsoft anon.cpp
anon-778013.o : error LNK2019: unresolved external symbol "void __cdecl
A::`anonymous namespace'::foo(void)" (?foo@?AB at A@@YAXXZ) referenced in function
_main

-> should be "A::B::`anonymous namespace'..."

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 06:29:19 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 14:29:19 +0000
Subject: [LLVMbugs] [Bug 14414] New: Type cast assertion in
 lib/Sema/SemaOverload.cpp:9545 (clang::DiagnoseTwoPhaseLookup)
Message-ID: <bug-14414-206@http.llvm.org/bugs/>

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

             Bug #: 14414
           Summary: Type cast assertion in lib/Sema/SemaOverload.cpp:9545
                    (clang::DiagnoseTwoPhaseLookup)
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9584
  --> http://llvm.org/bugs/attachment.cgi?id=9584
Test case

Test case is attached.

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


From bugzilla-daemon at llvm.org  Thu Nov 22 06:42:41 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 14:42:41 +0000
Subject: [LLVMbugs] [Bug 14403] Seg fault on complicated template metaprogram
In-Reply-To: <bug-14403-206@http.llvm.org/bugs/>
References: <bug-14403-206@http.llvm.org/bugs/>
Message-ID: <bug-14403-206-QVjHG7vSBu@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-22 08:42:41 CST ---
Probably the same bug as PR14414, which also has a reduced test case.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 08:08:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 16:08:03 +0000
Subject: [LLVMbugs] [Bug 13156] compile-fail: function declared to take a
 pointer to a function involving incomplete types
In-Reply-To: <bug-13156-206@http.llvm.org/bugs/>
References: <bug-13156-206@http.llvm.org/bugs/>
Message-ID: <bug-13156-206-5eQRWqFvjY@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |benny.kra at gmail.com
         Resolution|                            |FIXED

--- Comment #8 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-22 10:08:03 CST ---
Looks like this was fixed, Bug 14355 was the same 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  Thu Nov 22 08:32:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 16:32:17 +0000
Subject: [LLVMbugs] [Bug 14415] New: llc cpp generation out of date (since
	r168354).
Message-ID: <bug-14415-206@http.llvm.org/bugs/>

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

             Bug #: 14415
           Summary: llc cpp generation out of date (since r168354).
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: h.bakiras at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Hello,

I have a problem since revision r168354.
The AttrListPtr object became a part of the LLVMContext but the llc generated
code does not support this yet.

So when compiling vmkit project, which uses AttrListPtr, I get the following
error :

[...]/vmkit/lib/vmkit/Compiler/LLVMRuntime.inc:255:49: error: too few arguments
to function call, expected 2, have 1
 func_llvm_sqrt_f64_PAL = AttrListPtr::get(Attrs);
                          ~~~~~~~~~~~~~~~~      ^
[...]/llvm/include/llvm/Attributes.h:334:3: note: 'get' declared here
  static AttrListPtr get(LLVMContext &C, ArrayRef<AttributeWithIndex> Attrs);
  ^

LLVMRuntime.inc is a generated by using "llc" command with the following
options "-march=cpp -cppgen=contents".
The problem is basically an API update to perform when generating the C++ code.

It will be great if the bug could be corrected.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 08:47:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 16:47:01 +0000
Subject: [LLVMbugs] [Bug 13850] opportunity for small improvement to
 zero-initialization codegen [AVX]
In-Reply-To: <bug-13850-206@http.llvm.org/bugs/>
References: <bug-13850-206@http.llvm.org/bugs/>
Message-ID: <bug-13850-206-UOxDoWAtyZ@http.llvm.org/bugs/>

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

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

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

--- Comment #3 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-22 10:47:01 CST ---
Bug 2962 was finally fixed. We now turn this into:

_orthoBasisUnaligned:                   ## @orthoBasisUnaligned
## BB#0:                                ## %allocas
    pushq    %rbp
    movq    %rsp, %rbp
    vxorps    %ymm0, %ymm0, %ymm0
    vmovups    %ymm0, 64(%rdi)
    vmovups    %ymm0, 32(%rdi)
    vmovups    %ymm0, (%rdi)
    popq    %rbp
    vzeroupper
    ret

    .globl    _orthoBasisAligned
    .align    4, 0x90
_orthoBasisAligned:                     ## @orthoBasisAligned
## BB#0:                                ## %allocas
    pushq    %rbp
    movq    %rsp, %rbp
    vxorps    %ymm0, %ymm0, %ymm0
    vmovups    %ymm0, 64(%rdi)
    vmovups    %ymm0, 32(%rdi)
    vmovups    %ymm0, (%rdi)
    popq    %rbp
    vzeroupper
    ret

not sure if this is actually faster on sandy bridge, but this bug is fixed.

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


From bugzilla-daemon at llvm.org  Thu Nov 22 09:09:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 17:09:01 +0000
Subject: [LLVMbugs] [Bug 13900] crash-on-invalid: Assertion failed:
 (!isNull() && "Cannot retrieve a NULL type pointer"),
 function getCommonPtr when diagnosing deduction failure
In-Reply-To: <bug-13900-206@http.llvm.org/bugs/>
References: <bug-13900-206@http.llvm.org/bugs/>
Message-ID: <bug-13900-206-ezfloKSQGM@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-22 11:09:01 CST ---
Not reproducible anymore.

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


From bugzilla-daemon at llvm.org  Thu Nov 22 09:16:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 17:16:20 +0000
Subject: [LLVMbugs] [Bug 13935] Crash when compiling postgresql 9.1.5
In-Reply-To: <bug-13935-206@http.llvm.org/bugs/>
References: <bug-13935-206@http.llvm.org/bugs/>
Message-ID: <bug-13935-206-MQXra1QrbC@http.llvm.org/bugs/>

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

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

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

--- Comment #5 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-22 11:16:20 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 12:47:33 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 20:47:33 +0000
Subject: [LLVMbugs] [Bug 14411] "restrict requires a pointer or reference"
 is wrong for C++11
In-Reply-To: <bug-14411-206@http.llvm.org/bugs/>
References: <bug-14411-206@http.llvm.org/bugs/>
Message-ID: <bug-14411-206-OBqOFw2Ihw@http.llvm.org/bugs/>

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

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> 2012-11-22 14:47:33 CST ---
The text you cite is a restriction on the way the library is defined, not the
compiler.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 13:14:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 21:14:49 +0000
Subject: [LLVMbugs] [Bug 14412] bool reduction of case values is questionable
In-Reply-To: <bug-14412-206@http.llvm.org/bugs/>
References: <bug-14412-206@http.llvm.org/bugs/>
Message-ID: <bug-14412-206-iAetRYlLby@http.llvm.org/bugs/>

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

Pawel Wodnicki <pawel at 32bitmicro.com> changed:

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

--- Comment #9 from Pawel Wodnicki <pawel at 32bitmicro.com> 2012-11-22 15:14:49 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 22 14:30:07 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 22:30:07 +0000
Subject: [LLVMbugs] [Bug 14417] New: Due to base compiler upgrade,
 clang fails to generate binaries on DragonFly 3.2+
Message-ID: <bug-14417-206@http.llvm.org/bugs/>

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

             Bug #: 14417
           Summary: Due to base compiler upgrade, clang fails to generate
                    binaries on DragonFly 3.2+
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: DragonFly BSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: draco at marino.st
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9585
  --> http://llvm.org/bugs/attachment.cgi?id=9585
Fix search path for clang on latest DragonFly releases

DragonFly is unique in that it has two base compilers.  For a few years, those
compilers were gcc 4.1 and gcc 4.4.  At first gcc 4.1 was the primary compiler,
and now gcc 4.4 is the primary compiler.

For the latest release, gcc 4.7 was brought into base and gcc 4.1 removed.  At
this point, clang stopped working on DragonFly because it had gcc41 in its
internal search path.

The clang driver looks for crt* stuff in /usr/lib/gcc41, which no longer
exists.  The standard c++ library is also located there.

The attached patch changes the driver to first look in /usr/lib/gcc47 and then
fallback to /usr/lib/gcc44.  The fallback should guarantee that the latest
clangs run on several past releases of DragonFly BSD as well as the latest
version.

The patches were generated against clang release 3.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  Thu Nov 22 15:28:31 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 22 Nov 2012 23:28:31 +0000
Subject: [LLVMbugs] [Bug 14418] New: build failure
Message-ID: <bug-14418-206@http.llvm.org/bugs/>

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

             Bug #: 14418
           Summary: build failure
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: max.skaller at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


llvm[4]: Compiling cc1as_main.cpp for Release build
llvm[4]: Compiling driver.cpp for Release build
llvm[4]: Creating clang 'Info.plist' file...
llvm[4]: Linking Release executable clang (without symbols)
ld: in
/Users/johnskaller/llvm/llvm/build/Release/lib/libclangParse.a(ParseObjc.o), in
section __TEXT,__text reloc 481: local relocation for address 0x0000602E in
section __text does not target section __const
clang: error: linker command failed with exit code 1 (use -v to see invocation)
make[4]: *** [/Users/johnskaller/llvm/llvm/build/Release/bin/clang] Error 1
make[3]: *** [all] Error 1
make[2]: *** [all] Error 1
make[1]: *** [clang/.makeall] Error 2
make: *** [all] Error 1

Context: built SVN clang+llvm with Debug+Asserts successfully. Decided to
rebuild for host only, optimise. Result as above. Let me know any other info
required. The build ran for over 10 hours, I think using clang as the compiler,
on my old MacBookPro Core2 Duo. The Debug+Asserts build was completed in around
3 hours.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 23 02:13:25 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 10:13:25 +0000
Subject: [LLVMbugs] [Bug 14419] New: Possible misbehavior with multiple
 variadic template parameter packs
Message-ID: <bug-14419-206@http.llvm.org/bugs/>

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

             Bug #: 14419
           Summary: Possible misbehavior with multiple variadic template
                    parameter packs
           Product: clang
           Version: 3.1
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++11
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: warp.grrr at gmx.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I believe that clang++ either handles the following situation incorrectly or,
at the very least, requires improvements on its analysis of the situation and
subsequent error messages. (I have to admit, however, that I do not know how
the C++11 standard specifies how this should be handled.) Consider the
following function definition:

    template<typename... Pack1, typename... Pack2>
    void func(Pack1... pack1, Pack2... pack2) {}

If the above function is called without parameters, as in "func();", clang++
issues the following error:

  No matching function for call to 'func'
  Candidate function template not viable: requires at least 1 argument, but 0
were provided

However, if it's called with eg. one parameter, like "func(5);", it issues the
(rather contradictory) error:

  No matching function for call to 'func'
  Candidate function not viable: requires 0 arguments, but 1 was provided

(A notable difference is that the first error mentions the function being a
template, while the second does not.)

Note that calling it like "foo<int>(5);" does compile and work ok. (All
parameters given to the function are passed as the 'pack1' parameter.)

Also note that in gcc the function call compiles ok without having to specify
the template parameter types. (Curiously in gcc all parameters are passed as
the 'pack2' parameter. I'm guessing the standard leaves it open to the
implementation.)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 23 03:06:29 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 11:06:29 +0000
Subject: [LLVMbugs] [Bug 14415] llc cpp generation out of date (since
	r168354).
In-Reply-To: <bug-14415-206@http.llvm.org/bugs/>
References: <bug-14415-206@http.llvm.org/bugs/>
Message-ID: <bug-14415-206-5ypEKOnIGx@http.llvm.org/bugs/>

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

Bill Wendling <wendling at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
                 CC|                            |wendling at apple.com
         Resolution|                            |FIXED

--- Comment #4 from Bill Wendling <wendling at apple.com> 2012-11-23 05:06:29 CST ---
Fixed:

Sending        lib/Target/CppBackend/CPPBackend.cpp
Transmitting file data .
Committed revision 168512.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 23 06:32:13 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 14:32:13 +0000
Subject: [LLVMbugs] [Bug 14420] New: Assertion failed: (Loc.isValid() &&
 "point of instantiation must be valid!")
Message-ID: <bug-14420-206@http.llvm.org/bugs/>

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

             Bug #: 14420
           Summary: Assertion failed: (Loc.isValid() && "point of
                    instantiation must be valid!")
           Product: clang
           Version: 3.2
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ambrosehua at wo.com.cn
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


OS verion:
FreeBSD lateaxfreebsd 10.0-CURRENT FreeBSD 10.0-CURRENT #0 r+3d6311e: Sun Nov
18 10:11:12 CST 2012     root at lateaxfreebsd:/usr/obj/usr/src/sys/KTR  amd64

My freebsd box clang was build witht libc++

When I update the ports/devel/binutils with the same new make.conf as I build
the clang from base
/etc/make.conf
................
CFLAGS+=-O2 -fno-omit-frame-pointer -pipe -fno-strict-aliasing
CXXFLAGS+=-stdlib=libc++ -std=c++11

...............

Assertion failed: (Loc.isValid() && "point of instantiation must be valid!"),
function setPointOfI
nstantiation, file
/usr/src/lib/clang/libclangsema/../../../contrib/llvm/tools/clang/include/clang
/AST/DeclTemplate.h, line 1374.
Stack dump:
0.      Program arguments: /usr/bin/clang++ -cc1 -triple
x86_64-unknown-freebsd10.0 -emit-obj -dis
able-free -main-file-name object.cc -mrelocation-model static -mdisable-fp-elim
-relaxed-aliasing 
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu athlon64
-momit-leaf-frame-pointer
 -coverage-file object.o -resource-dir /usr/bin/../lib/clang/3.2
-dependency-file .deps/object.Tpo
 -sys-header-deps -MP -MT object.o -D HAVE_CONFIG_H -D
LOCALEDIR="/usr/local/share/locale" -D BIND
IR="/usr/local/bin" -D TOOLBINDIR="/usr/local/x86_64-portbld-freebsd10.0/bin"
-D _LARGEFILE_SOURCE
 -D _FILE_OFFSET_BITS=64 -I . -I . -I ./../include -I ./../elfcpp -I
/usr/local/include -fmodule-c
ache-path /var/tmp/clang-module-cache -stdlib=libc++ -O2 -W -Wall -std=c++11
-fdeprecated-macro -f
debug-compilation-dir /usr/ports/devel/binutils/work/binutils-2.22/gold
-ferror-limit 19 -fmessage
-length 98 -mstackrealign -fobjc-runtime=gnustep -fcxx-exceptions -fexceptions
-fdiagnostics-show-
option -fcolor-diagnostics -o object.o -x c++ object.cc
1.      <eof> parser at end of file
2.      object.cc:558:1: instantiating function definition
'build_compressed_section_map'
clang++: error: unable to execute command: Abort trap (core dumped)
clang++: error: clang frontend command failed due to signal (use -v to see
invocation)
FreeBSD clang version 3.2 (trunk 162107) 20120817
Target: x86_64-unknown-freebsd10.0
Thread model: posix
clang++: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the
 crash backtrace, preprocessed source, and associated run script.
clang++: note: diagnostic msg:

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 23 07:41:10 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 15:41:10 +0000
Subject: [LLVMbugs] [Bug 14421] New: VS2010 compiler crash when compiling
	'Release'.
Message-ID: <bug-14421-206@http.llvm.org/bugs/>

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

             Bug #: 14421
           Summary: VS2010 compiler crash when compiling 'Release'.
           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: vturbanov at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9591
  --> http://llvm.org/bugs/attachment.cgi?id=9591
RUDE patch to fix compiler crash under VS 2010.

When compiling the x64 'Release' version with VS 2010, the compiler crashes on
two similar cases.
I have attached a RATHER RUDE patch to fix the issue.

Thank 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  Fri Nov 23 07:51:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 15:51:20 +0000
Subject: [LLVMbugs] [Bug 14420] Assertion failed: (Loc.isValid() && "point
 of instantiation must be valid!")
In-Reply-To: <bug-14420-206@http.llvm.org/bugs/>
References: <bug-14420-206@http.llvm.org/bugs/>
Message-ID: <bug-14420-206-mir5L9V0eN@http.llvm.org/bugs/>

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

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

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

--- Comment #4 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-23 09:51:20 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 23 09:05:05 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 17:05:05 +0000
Subject: [LLVMbugs] [Bug 13758] Assertion `Loc.isValid() && "point of
 instantiation must be valid!"' failed.
In-Reply-To: <bug-13758-206@http.llvm.org/bugs/>
References: <bug-13758-206@http.llvm.org/bugs/>
Message-ID: <bug-13758-206-48CDzSrnzx@http.llvm.org/bugs/>

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

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

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

--- Comment #7 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-23 11:05:05 CST ---
Fixed in r168521.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 23 09:59:14 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 17:59:14 +0000
Subject: [LLVMbugs] [Bug 14422] New: -frewrite-includes should rewrite
 __has_include and friends
Message-ID: <bug-14422-206@http.llvm.org/bugs/>

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

             Bug #: 14422
           Summary: -frewrite-includes should rewrite __has_include and
                    friends
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: dblaikie at gmail.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


__has_include makes the compilation host-specific and often fails in a -cc1
environment. This comes up from time to time in clang crash reports because
limits.h makes use of __has_include_next. The resulting file cannot be compiled
with the generated shell script.

I think it's safe to just replace the directive with a constant during
rewriting.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 23 12:01:50 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 20:01:50 +0000
Subject: [LLVMbugs] [Bug 12693] lldb building process fails
In-Reply-To: <bug-12693-206@http.llvm.org/bugs/>
References: <bug-12693-206@http.llvm.org/bugs/>
Message-ID: <bug-12693-206-CfVnBnQIAb@http.llvm.org/bugs/>

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

Daniel Malea <daniel.malea at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |daniel.malea at intel.com
         Resolution|                            |FIXED

--- Comment #2 from Daniel Malea <daniel.malea at intel.com> 2012-11-23 14:01:50 CST ---
The linux build is fixed as of current trunk (r168525) with clang and libstdc++
4.6.

Hence, closing this bug.

BTW, the Linux build instructions have been updated as well since this bug was
filed:

http://lldb.llvm.org/build.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 Nov 23 14:32:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 23 Nov 2012 22:32:09 +0000
Subject: [LLVMbugs] [Bug 14428] New: clang instantiates arguments of all
 constructors in presence of constructor with default argument
Message-ID: <bug-14428-206@http.llvm.org/bugs/>

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

             Bug #: 14428
           Summary: clang instantiates arguments of all constructors in
                    presence of constructor with default argument
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu,
                    richard-llvm at metafoo.co.uk
    Classification: Unclassified


>From r168521:

  template <typename T> struct move_from {
    T invalid;
  };
  template <class K>
  struct unordered_map {
    explicit unordered_map(int n = 42);
    unordered_map(move_from<K> other);
  };
  template<typename T>
  void StripedHashTable() {
    new unordered_map<void>();
  }
  void tt() {
    StripedHashTable<int>();
  }

clang instantiates move_from<void> and emits an error. GCC and EDG accept this
code, so does the clang 3.0 from llvm.org/demo.

r168521 can probably be reverted when this is fixed.

Richard says:
> Looking just at what you needed to change in your patch, my wild guess
> is that we might be trying to initialize an unordered_map object from
> the default argument expression '42', rather than trying to initialize
> the 'n' parameter of the explicit constructor from it. That would
> explain why we instantiate move_from<K>: we'd be trying to use the
> second constructor to convert '42' to an unordered_map, but would be a
> very surprising bug to have...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 24 06:27:19 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 24 Nov 2012 14:27:19 +0000
Subject: [LLVMbugs] [Bug 14429] New: Dragonegg fails to build clang
Message-ID: <bug-14429-206@http.llvm.org/bugs/>

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

             Bug #: 14429
           Summary: Dragonegg fails to build clang
           Product: dragonegg
           Version: 3.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Doing a bootsrap of 3.2 rc1, dragonegg dies while compiling
clang/lib/ASTMatchers/Debug+Asserts/ASTMatchFinder.cpp:

cc1plus: llvm-3.2/64/rc1/dragonegg.src/src/Convert.cpp:3446: llvm::Value*
TreeToLLVM::EmitCallOf(llvm::Value*, gimple, const MemRef*, const
llvm::AttrListPtr&): Assertion `DL.getTypeAllocSize(Call->getType()) ==
DL.getTypeAllocSize(RetTy) && "Size mismatch in scalar to scalar conversion!"'
failed.

This is when doing a Debug build as well as in optimized builds.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 24 07:13:31 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 24 Nov 2012 15:13:31 +0000
Subject: [LLVMbugs] [Bug 14430] New: clang: error: clang frontend command
 failed due to signal: gcc style inline asm
Message-ID: <bug-14430-206@http.llvm.org/bugs/>

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

             Bug #: 14430
           Summary: clang: error: clang frontend command failed due to
                    signal: gcc style inline asm
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: peeter.joot at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9592
  --> http://llvm.org/bugs/attachment.cgi?id=9592
first attachment: preprocessed source

clang:
/home/hotellnx99/peeterj/tmp/clang/llvm/lib/CodeGen/TwoAddressInstructionPass.cpp:1261:
void {anonymous}::TwoAddressInstructionPass::processTiedPairs(l
lvm::MachineInstr*, {anonymous}::TwoAddressInstructionPass::TiedPairList&,
unsigned int&): Assertion `i == DstIdx || !MI->getOperand(i).isReg() ||
MI->getOper
and(i).getReg() != RegA' failed.
0  clang           0x0000000001fae83f
1  clang           0x0000000001faed39
2  libpthread.so.0 0x00002b3ad2e8ee00
3  libc.so.6       0x00002b3ad3541f45 gsignal + 53
4  libc.so.6       0x00002b3ad3543340 abort + 272
5  libc.so.6       0x00002b3ad353b486 __assert_fail + 246
6  clang           0x0000000001a7d235
7  clang           0x0000000001a81fca
8  clang           0x0000000001f45c1f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 655
9  clang           0x0000000001f45c73
llvm::FPPassManager::runOnModule(llvm::Module&) + 51
10 clang           0x0000000001f4591f
llvm::MPPassManager::runOnModule(llvm::Module&) + 575
11 clang           0x0000000001f4900f llvm::PassManagerImpl::run(llvm::Module&)
+ 175
12 clang           0x00000000007ed664
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::La
ngOptions const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) +
3668
13 clang           0x00000000007eb31f
14 clang           0x0000000000940eba clang::ParseAST(clang::Sema&, bool, bool)
+ 554
15 clang           0x00000000007e9f1e clang::CodeGenAction::ExecuteAction() +
78
16 clang           0x000000000067c8c6 clang::FrontendAction::Execute() + 150
17 clang           0x000000000065fae5
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 341
18 clang           0x00000000006471fd
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1421
19 clang           0x000000000063f128 cc1_main(char const**, char const**, char
const*, void*) + 1160
20 clang           0x00000000006465fa main + 4842
21 libc.so.6       0x00002b3ad352f304 __libc_start_main + 244
22 clang           0x000000000063dff9
Stack dump:
0.      Program arguments: /home/hotellnx99/peeterj/local/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name t.C
-mreloca
tion-model static -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -fuse-init-array -target-cpu x86-64 -target-linker-version
2.16.91.0.5 -mom
it-leaf-frame-pointer -resource-dir
/home/hotellnx99/peeterj/local/bin/../lib/clang/3.3 -fmodule-cache-path
/home/hotellnx99/peeterj/tmp/clang-module-cache -i
nternal-isystem
/home/hotellnx99/peeterj/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2
-internal-isystem /home/hotellnx99/peeterj
/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/x86_64-unknown-linux-gnu
-internal-isystem /home/hotellnx99/peeterj/local/lib/gcc/
x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/backward
-internal-isystem /usr/local/include -internal-isystem
/home/hotellnx99/peeterj/local/bi
n/../lib/clang/3.3/include -internal-externc-isystem /include
-internal-externc-isystem /usr/include -O2 -fdeprecated-macro
-fdebug-compilation-dir /vbs/commo
n/osse/core/t -ferror-limit 19 -fmessage-length 0 -mstackrealign
-fobjc-runtime=gcc -fcxx-exceptions -fexceptions -fdiagnostics-show-option -o
/home/hotellnx9
9/peeterj/tmp/t-tYuE1R.o -x c++ t.C
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 't.C'.
4.      Running pass 'Two-Address instruction pass' on function
'@_Z9callcpuidP8cpuidOutl'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 168392)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run scri
pt.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /home/hotellnx99/peeterj/tmp/t-CDxuHx.cpp
clang: note: diagnostic msg: /home/hotellnx99/peeterj/tmp/t-CDxuHx.sh

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 24 11:11:13 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 24 Nov 2012 19:11:13 +0000
Subject: [LLVMbugs] [Bug 14431] New: Missed opportunity for dead store
	elimination
Message-ID: <bug-14431-206@http.llvm.org/bugs/>

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

             Bug #: 14431
           Summary: Missed opportunity for dead store elimination
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Global Analyses
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: craig.topper at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


While looking at some generated code from a bootstrap build.

I noticed this sequence of code
    SDValue Ops[6];
    Ops[0] = getRoot();
    Ops[1] = getValue(I.getArgOperand(0));
    Ops[2] = getValue(I.getArgOperand(1));
    Ops[3] = getValue(I.getArgOperand(2));
    Ops[4] = DAG.getSrcValue(I.getArgOperand(0));
    Ops[5] = DAG.getSrcValue(F);

    Res = DAG.getNode(ISD::INIT_TRAMPOLINE, dl, MVT::Other, Ops, 6);

Generated this assembly:
    movq    $0, -2272(%rbp)
    movl    $0, -2264(%rbp)
    movq    $0, -2256(%rbp)
    movl    $0, -2248(%rbp)
    movq    $0, -2240(%rbp)
    movl    $0, -2232(%rbp)
    movq    $0, -2224(%rbp)
    movl    $0, -2216(%rbp)
    movq    $0, -2208(%rbp)
    movl    $0, -2200(%rbp)
    movq    $0, -2192(%rbp)
    movl    $0, -2184(%rbp)
    movq    %r12, %rdi
    callq    __ZN4llvm19SelectionDAGBuilder7getRootEv
    movq    %rax, -2272(%rbp)
    movl    %edx, -2264(%rbp)
    movl    48(%rbx), %eax
    negq    %rax
    leaq    (%rax,%rax,2), %rax
    movq    (%rbx,%rax,8), %rsi
    movq    %r12, %rdi
    callq    __ZN4llvm19SelectionDAGBuilder8getValueEPKNS_5ValueE
    movq    %rax, -2256(%rbp)
    movl    %edx, -2248(%rbp)
    movl    48(%rbx), %eax
    subq    %rax, %r15
    leaq    (%r15,%r15,2), %rax
    movq    (%rbx,%rax,8), %rsi
    movq    %r12, %rdi
    callq    __ZN4llvm19SelectionDAGBuilder8getValueEPKNS_5ValueE
    movl    $2, %ecx
    movq    %rax, -2240(%rbp)
    movl    %edx, -2232(%rbp)
    movl    48(%rbx), %eax
    subq    %rax, %rcx
    leaq    (%rcx,%rcx,2), %rax
    movq    (%rbx,%rax,8), %rsi
    movq    %r12, %rdi
    callq    __ZN4llvm19SelectionDAGBuilder8getValueEPKNS_5ValueE
    movq    %rax, -2224(%rbp)
    movl    %edx, -2216(%rbp)
    movl    48(%rbx), %eax
    negq    %rax
    leaq    (%rax,%rax,2), %rax
    movq    (%rbx,%rax,8), %rsi
    movq    408(%r12), %rdi
    callq    __ZN4llvm12SelectionDAG11getSrcValueEPKNS_5ValueE
    movq    %rax, -2208(%rbp)
    movl    %edx, -2200(%rbp)
    movq    408(%r12), %rdi
    movq    %r14, %rsi
    callq    __ZN4llvm12SelectionDAG11getSrcValueEPKNS_5ValueE
    movq    $0, -4832(%rbp)         ## 8-byte Folded Spill
    leaq    -2272(%rbp), %r9
    movq    %rax, -2192(%rbp)
    movl    %edx, -2184(%rbp)


You'll see at the start of the assembly there are 12 stores of 0 to initialize
the SDValue array. But each of those values are overwritten by the getRoot,
getValue, getSrcValue calls. Dead store elimination should have been able to
remove the stores of 0.


As far as I can tell this didn't happen because alias analysis thinks that
getRoot, getValue, and getSrcValue could reference this SDValue array.

This seems to be a problem with this code in
BasicAliasAnalysis::getModRefInfo(ImmutableCallSite CS, const Location &Loc)

  // If the pointer is to a locally allocated object that does not escape,
  // then the call can not mod/ref the pointer unless the call takes the
pointer
  // as an argument, and itself doesn't capture it.
  if (!isa<Constant>(Object) && CS.getInstruction() != Object &&
      isNonEscapingLocalObject(Object)) {


In this case the alloca for the SDValue array does escape through the call to
DAG.getNode so the isNonEscapingLocalObject returns false. But the CallSites in
question here are for getRoot, getValue, getSrcValue which it doesn't into.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 25 00:53:43 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 25 Nov 2012 08:53:43 +0000
Subject: [LLVMbugs] [Bug 10552] Struct Allocation / Return Bug
In-Reply-To: <bug-10552-206@http.llvm.org/bugs/>
References: <bug-10552-206@http.llvm.org/bugs/>
Message-ID: <bug-10552-206-hmLD6AZARp@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2012-11-25 02:53:43 CST ---
This was fixed at some point.  What now happens at -O0 is that 6 bytes are
copied out of the alloca using memcpy into a larger 8 byte alloca, and the
larger alloca is used for returning.  (You may object that the original alloca
only holds 5 bytes of memory, but because it has an alignment of 2 it actually
holds 5-bytes-rounded-up-to-alignment = 6 bytes).  The optimizers happily turn
this into decent code at -O1 and better.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 25 12:33:42 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 25 Nov 2012 20:33:42 +0000
Subject: [LLVMbugs] [Bug 14432] New: -indvars generates infinite loop
Message-ID: <bug-14432-206@http.llvm.org/bugs/>

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

             Bug #: 14432
           Summary: -indvars generates infinite loop
           Product: libraries
           Version: 3.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: code at klickverbot.at
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9594
  --> http://llvm.org/bugs/attachment.cgi?id=9594
test case, compile with "opt -indvars".

The attached .ll file seems to trigger a bug in -indvars with LLVM 3.1, the 3.2
branch (r168527) and SVN trunk (r168548):

In this loop:
---
forcond38:
  %__key8.0 = phi i32 [ %tmp81, %noassert68 ], [ 2, %forcond38.preheader ]
  %tmp46 = icmp slt i32 %__key8.0, 10
  br i1 %tmp46, label %forbody39, label %unrolledend

forbody39:
  %tmp51 = sdiv i32 32767, %__key8.0
  %tmp57 = sdiv i32 -32768, %__key8.0
  %sext33 = shl i32 %tmp51, 16
  %sext = shl i32 %tmp51, 16
  %tmp66 = icmp eq i32 %sext33, %sext
  br i1 %tmp66, label %noassert68, label %assert67

assert67:
  tail call void @llvm.trap()
  unreachable

noassert68:
  %sext34 = shl i32 %tmp57, 16
  %sext21 = shl i32 %tmp57, 16
  %tmp76 = icmp eq i32 %sext34, %sext21
  %tmp81 = add i32 %__key8.0, 1
  br i1 %tmp76, label %forcond38, label %assert77

assert77:                                         ; preds = %noassert68
  tail call void @llvm.trap()
  unreachable

unrolledend:                                      ; preds = %forcond38
  ret i32 0
---

-indvars replaces the loop condition with an unconditional jump:

---
-  %tmp46 = icmp slt i32 %__key8.0, 10
-  br i1 %tmp46, label %forbody39, label %unrolledend
+  br i1 true, label %forbody39, label %unrolledend
---

It would be great if somebody could have a look at this before the 3.2 release,
because this effectively causes a regression in the LDC test suite compared to
LLVM 3.1.

Sorry for the slightly big test case, but bugpoint crashes and I'm not sure if
I'll be able to have another look at the issue before the end of the first
release testing phase.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 00:33:08 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 08:33:08 +0000
Subject: [LLVMbugs] [Bug 14428] clang instantiates arguments of all
 constructors in presence of constructor with default argument
In-Reply-To: <bug-14428-206@http.llvm.org/bugs/>
References: <bug-14428-206@http.llvm.org/bugs/>
Message-ID: <bug-14428-206-tnm5rBSsx1@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-26 02:33:08 CST ---
Fixed in r168582.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 00:57:29 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 08:57:29 +0000
Subject: [LLVMbugs] [Bug 14413] [-cxx-abi microsoft] anonymous namespaces
 are mangled incorrectly
In-Reply-To: <bug-14413-206@http.llvm.org/bugs/>
References: <bug-14413-206@http.llvm.org/bugs/>
Message-ID: <bug-14413-206-RWz5hX76SO@http.llvm.org/bugs/>

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

Timur Iskhodzhanov <timurrrr at google.com> changed:

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

--- Comment #3 from Timur Iskhodzhanov <timurrrr at google.com> 2012-11-26 02:57:29 CST ---
r168583

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 04:04:48 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 12:04:48 +0000
Subject: [LLVMbugs] [Bug 14433] New: Firefox doesn't build with
	-stdlib=libc++
Message-ID: <bug-14433-206@http.llvm.org/bugs/>

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

             Bug #: 14433
           Summary: Firefox doesn't build with -stdlib=libc++
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: markus at trippelsdorf.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


With CXXFLAGS="-w -stdlib=libc++ -march=native" I get:
...
In file included from /var/tmp/mozilla-central/xpcom/base/nsDebugImpl.cpp:7:
In file included from
/var/tmp/mozilla-central/ipc/chromium/src/base/process_util.h:25:
In file included from ../../dist/stl_wrappers/string:49:
In file included from ../../dist/system_wrappers/string:2:
In file included from /usr/include/c++/v1/string:432:
In file included from ../../dist/stl_wrappers/cstdio:49:
In file included from ../../dist/system_wrappers/cstdio:2:
/usr/include/c++/v1/cstdio:108:8: error: visibility does not match previous
declaration
inline _LIBCPP_INLINE_VISIBILITY int getc(FILE* __stream) {return
__libcpp_getc(__stream);}
       ^
/usr/include/c++/v1/__config:134:51: note: expanded from macro
'_LIBCPP_INLINE_VISIBILITY'
#define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"),
__always_inline__))
                                                  ^
../../dist/system_wrappers/stdio.h:1:13: note: previous attribute is here
#pragma GCC visibility push(default)
            ^

When I add -flto to the CXXFLAGS everything builds just fine 
(,but then it takes ~20 minutes to build libxul on my machine).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 10:16:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 18:16:49 +0000
Subject: [LLVMbugs] [Bug 14433] Firefox doesn't build with -stdlib=libc++
In-Reply-To: <bug-14433-206@http.llvm.org/bugs/>
References: <bug-14433-206@http.llvm.org/bugs/>
Message-ID: <bug-14433-206-CV9CItnn6S@http.llvm.org/bugs/>

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

Markus Trippelsdorf <markus at trippelsdorf.de> changed:

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

--- Comment #2 from Markus Trippelsdorf <markus at trippelsdorf.de> 2012-11-26 12:16:49 CST ---
This is a dup of Bug 12947.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 10:18:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 18:18:01 +0000
Subject: [LLVMbugs] [Bug 12947] Revision 155603 breaks Firefox build with
	libcxx
In-Reply-To: <bug-12947-206@http.llvm.org/bugs/>
References: <bug-12947-206@http.llvm.org/bugs/>
Message-ID: <bug-12947-206-jiiFUclME5@http.llvm.org/bugs/>

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

Markus Trippelsdorf <markus at trippelsdorf.de> changed:

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

--- Comment #15 from Markus Trippelsdorf <markus at trippelsdorf.de> 2012-11-26 12:18:01 CST ---
The issue reappeared.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 11:15:45 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 19:15:45 +0000
Subject: [LLVMbugs] [Bug 14434] New: MCJIT does not honor
 EE::InstallLazyFunctionCreator & EE::DisableSymbolSearching
Message-ID: <bug-14434-206@http.llvm.org/bugs/>

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

             Bug #: 14434
           Summary: MCJIT does not honor EE::InstallLazyFunctionCreator &
                    EE::DisableSymbolSearching
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Generic Execution Engine Support
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ofv at wanadoo.es
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


MyExecutionEngine->DisableSymbolSearching();
MyExecutionEngine->InstallLazyFunctionCreator(&MyLazyFunctionCreator);

has no effect. MCJIT always wants to resolve symbols by searching libraries. It
usually ends by exiting the host application with a message about "could not
resolve <function-name>"

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 13:02:55 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 21:02:55 +0000
Subject: [LLVMbugs] [Bug 14400] Crash in analyzer on simple testcase
In-Reply-To: <bug-14400-206@http.llvm.org/bugs/>
References: <bug-14400-206@http.llvm.org/bugs/>
Message-ID: <bug-14400-206-1GbtxglAAk@http.llvm.org/bugs/>

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

Anna Zaks <ganna at apple.com> changed:

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

--- Comment #4 from Anna Zaks <ganna at apple.com> 2012-11-26 15:02:55 CST ---
Fixed in r168599. Thanks for reporting!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 13:03:54 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 21:03:54 +0000
Subject: [LLVMbugs] [Bug 12947] Revision 155603 breaks Firefox build with
	libcxx
In-Reply-To: <bug-12947-206@http.llvm.org/bugs/>
References: <bug-12947-206@http.llvm.org/bugs/>
Message-ID: <bug-12947-206-zU22v4pE9c@http.llvm.org/bugs/>

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

Markus Trippelsdorf <markus at trippelsdorf.de> changed:

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

--- Comment #22 from Markus Trippelsdorf <markus at trippelsdorf.de> 2012-11-26 15:03:54 CST ---
Let's close this. I'll open a new libc++ 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 Nov 26 13:21:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 21:21:16 +0000
Subject: [LLVMbugs] [Bug 14435] New: Firefox build failure due to hidden
 visibility of getc and putc
Message-ID: <bug-14435-206@http.llvm.org/bugs/>

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

             Bug #: 14435
           Summary: Firefox build failure due to hidden visibility of getc
                    and putc
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: markus at trippelsdorf.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Currently Firefox fails to build with CXXFLAGS="-stdlib=libc++":

In file included from /var/tmp/mozilla-central/xpcom/base/nsDebugImpl.cpp:7:
In file included from
/var/tmp/mozilla-central/ipc/chromium/src/base/process_util.h:25:
In file included from ../../dist/stl_wrappers/string:49:
In file included from ../../dist/system_wrappers/string:2:
In file included from /usr/include/c++/v1/string:432:
In file included from ../../dist/stl_wrappers/cstdio:49:
In file included from ../../dist/system_wrappers/cstdio:2:
/usr/include/c++/v1/cstdio:108:8: error: visibility does not match previous
declaration
inline _LIBCPP_INLINE_VISIBILITY int getc(FILE* __stream) {return
__libcpp_getc(__stream);}
       ^
/usr/include/c++/v1/__config:134:51: note: expanded from macro
'_LIBCPP_INLINE_VISIBILITY'
#define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"),
__always_inline__))
                                                  ^
../../dist/system_wrappers/stdio.h:1:13: note: previous attribute is here
#pragma GCC visibility push(default)
            ^

Where system_wrappers/stdio.h reads:
#pragma GCC system_header
#pragma GCC visibility push(default)
#include_next <stdio.h>
#pragma GCC visibility pop


It turned out that this is caused by:
commit e21cf0ba9e938f0fac8e5f5552531cde51ea243b
Author: Howard Hinnant <hhinnant at apple.com>
Date:   Thu Jul 26 20:01:13 2012 +0000

    Patch by Andrew C. Morrow:  shims to work around macroized getc and putc on
linux.  On my eglibc 2.13 based Debian system 'getc' is a macro defined in
    /usr/include/stdio.h. This decision to make it a macro doesn't seem to
    be guarded by any feature test macro as far as I can see.

diff --git a/libcxx/include/cstdio b/libcxx/include/cstdio
index 2a6ec76..718d2f7 100644
--- a/libcxx/include/cstdio
+++ b/libcxx/include/cstdio
@@ -103,6 +103,18 @@ void perror(const char* s);
 #pragma GCC system_header
 #endif

+#ifdef getc
+inline _LIBCPP_INLINE_VISIBILITY int __libcpp_getc(FILE* __stream) {return
getc(__stream);}
+#undef getc
+inline _LIBCPP_INLINE_VISIBILITY int getc(FILE* __stream) {return
__libcpp_getc(__stream);}
+#endif  // getc
+
+#ifdef putc
+inline _LIBCPP_INLINE_VISIBILITY int __libcpp_putc(int __c, FILE* __stream)
{return putc(__c, __stream);}
+#undef putc
+inline _LIBCPP_INLINE_VISIBILITY int putc(int __c, FILE* __stream) {return
__libcpp_putc(__c, __stream);}
+#endif  // putc
+
 _LIBCPP_BEGIN_NAMESPACE_STD

 using ::FILE;

In include/__config one finds:
135 #define _LIBCPP_INLINE_VISIBILITY __attribute__ ((__visibility__("hidden"),
__always_inline__))


If one replaces _LIBCPP_INLINE_VISIBILITY with  
__attribute__ ((__always_inline__))  in include/cstdio, 
then Firefox builds just fine.


One solution would be to move the use of the redundant _LIBCPP_ALWAYS_INLINE
macro into _LIBCPP_INLINE_VISIBILITY and redefine _LIBCPP_ALWAYS_INLINE 
as __attribute__ ((__always_inline__)). The one could use 
_LIBCPP_ALWAYS_INLINE instead of _LIBCPP_INLINE_VISIBILITY in include/cstdio.

See also bug 12947.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 13:22:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 21:22:46 +0000
Subject: [LLVMbugs] [Bug 14436] New: clang:
 /home/hotellnx99/peeterj/tmp/clang/llvm/include/llvm/Support/Casting.h:208:
 typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X
 = clang::ento::StringRegion; Y = const clang::ento::MemRegion*;
 typename llvm::cast_retty<To, Fro
Message-ID: <bug-14436-206@http.llvm.org/bugs/>

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

             Bug #: 14436
           Summary: clang:
                    /home/hotellnx99/peeterj/tmp/clang/llvm/include/llvm/S
                    upport/Casting.h:208: typename llvm::cast_retty<To,
                    From>::ret_type llvm::cast(const Y&) [with X =
                    clang::ento::StringRegion; Y = const
                    clang::ento::MemRegion*; typename llvm::cast_retty<To,
                    Fro
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: peeter.joot at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9596
  --> http://llvm.org/bugs/attachment.cgi?id=9596
preprocessed source

clang:
/home/hotellnx99/peeterj/tmp/clang/llvm/include/llvm/Support/Casting.h:208:
typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X =
clang::ento::StringRegion; Y = const clang::ento::MemRegion*; typename
llvm::cast_retty<To, From>::ret_type = const clang::ento::StringRegion*]:
Assertion `isa<X>(Val) && "cast<Ty>() argument of incompatible type!"' failed.
0  clang           0x0000000001fae83f
1  clang           0x0000000001faed39
2  libpthread.so.0 0x00002ba7b62ebe00
3  libc.so.6       0x00002ba7b699ef45 gsignal + 53
4  libc.so.6       0x00002ba7b69a0340 abort + 272
5  libc.so.6       0x00002ba7b6998486 __assert_fail + 246
6  clang           0x0000000000ec4034
7  clang           0x0000000000ebf058
8  clang           0x0000000000ebf253
9  clang           0x0000000000ebfbb1
10 clang           0x0000000000ea4eeb
clang::ento::ProgramState::bindLoc(clang::ento::Loc, clang::ento::SVal, bool)
const + 91
11 clang           0x0000000000d46e64
12 clang           0x0000000000e435d0
clang::ento::CheckerManager::runCheckersForBind(clang::ento::ExplodedNodeSet&,
clang::ento::ExplodedNodeSet const&, clang::ento::SVal, clang::ento::SVal,
clang::Stmt const*, clang::ento::ExprEngine&, clang::ProgramPoint const&) +
1216
13 clang           0x0000000000e65e36
clang::ento::ExprEngine::evalBind(clang::ento::ExplodedNodeSet&, clang::Stmt
const*, clang::ento::ExplodedNode*, clang::ento::SVal, clang::ento::SVal, bool,
clang::ProgramPoint const*) + 502
14 clang           0x0000000000e744c1
clang::ento::ExprEngine::VisitDeclStmt(clang::DeclStmt const*,
clang::ento::ExplodedNode*, clang::ento::ExplodedNodeSet&) + 2353
15 clang           0x0000000000e68b83
clang::ento::ExprEngine::Visit(clang::Stmt const*, clang::ento::ExplodedNode*,
clang::ento::ExplodedNodeSet&) + 2499
16 clang           0x0000000000e6ad58
clang::ento::ExprEngine::ProcessStmt(clang::CFGStmt,
clang::ento::ExplodedNode*) + 760
17 clang           0x0000000000e6b09b
clang::ento::ExprEngine::processCFGElement(clang::CFGElement,
clang::ento::ExplodedNode*, unsigned int, clang::ento::NodeBuilderContext*) +
235
18 clang           0x0000000000e50220
clang::ento::CoreEngine::HandlePostStmt(clang::CFGBlock const*, unsigned int,
clang::ento::ExplodedNode*) + 128
19 clang           0x0000000000e5135d
clang::ento::CoreEngine::dispatchWorkItem(clang::ento::ExplodedNode*,
clang::ProgramPoint, clang::ento::WorkListUnit const&) + 109
20 clang           0x0000000000e516a6
clang::ento::CoreEngine::ExecuteWorkList(clang::LocationContext const*,
unsigned int, llvm::IntrusiveRefCntPtr<clang::ento::ProgramState const>) + 278
21 clang           0x0000000000cdb72e
22 clang           0x0000000000cdccb0
23 clang           0x0000000000ce5aa8
24 clang           0x0000000000940eba clang::ParseAST(clang::Sema&, bool, bool)
+ 554
25 clang           0x000000000067c8c6 clang::FrontendAction::Execute() + 150
26 clang           0x000000000065fae5
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 341
27 clang           0x00000000006471fd
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1421
28 clang           0x000000000063f128 cc1_main(char const**, char const**, char
const*, void*) + 1160
29 clang           0x00000000006465fa main + 4842
30 libc.so.6       0x00002ba7b698c304 __libc_start_main + 244
31 clang           0x000000000063dff9
Stack dump:

0.      Program arguments: /home/hotellnx99/peeterj/local/bin/clang -cc1
-triple x86_64-unknown-linux-gnu -analyze -disable-free -main-file-name
sqle_ca_pd_connpool.C -analyzer-store=region
-analyzer-opt-analyze-nested-blocks -analyzer-eagerly-assume
-analyzer-checker=core -analyzer-checker=unix -analyzer-checker=deadcode
-analyzer-checker=security.insecureAPI.UncheckedReturn
-analyzer-checker=security.insecureAPI.getpw
-analyzer-checker=security.insecureAPI.gets
-analyzer-checker=security.insecureAPI.mktemp
-analyzer-checker=security.insecureAPI.mkstemp
-analyzer-checker=security.insecureAPI.vfork -analyzer-output plist -w
-mrelocation-model pic -pic-level 2 -mdisable-fp-elim -fmath-errno
-masm-verbose -mconstructor-aliases -munwind-tables -fuse-init-array
-target-cpu corei7 -target-linker-version 2.16.91.0.5 -momit-leaf-frame-pointer
-g -coverage-file /vbs/engn/sqe/t2/sqle_ca_pd_connpool.plist -resource-dir
/home/hotellnx99/peeterj/local/bin/../lib/clang/3.3 -dependency-file
sqle_ca_pd_connpool.u -MT sqle_ca_pd_connpool.o -sys-header-deps
-fmodule-cache-path /home/hotellnx99/peeterj/tmp/clang-module-cache
-internal-isystem
/home/hotellnx99/peeterj/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2
-internal-isystem
/home/hotellnx99/peeterj/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/x86_64-unknown-linux-gnu
-internal-isystem
/home/hotellnx99/peeterj/local/lib/gcc/x86_64-unknown-linux-gnu/4.7.2/../../../../include/c++/4.7.2/backward
-internal-isystem /usr/local/include -internal-isystem
/home/hotellnx99/peeterj/local/bin/../lib/clang/3.3/include
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O0
-Wno-deprecated -Wno-invalid-offsetof -Wreturn-type
-Wno-unused-command-line-argument -Wno-return-type-c-linkage
-Wno-unused-private-field -Wno-array-bounds -Wno-cast-align -Wno-unused-value
-Wformat -Wparentheses -Wno-write-strings -Wformat -fdebug-compilation-dir
/vbs/engn/sqe/t2 -ferror-limit 19 -fmessage-length 0 -mstackrealign
-fno-threadsafe-statics -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -o sqle_ca_pd_connpool.plist -x c++
sqle_ca_pd_connpool.C
1.      <eof> parser at end of file
2.      sqle_ca_pd_connpool.C:49:4: Error evaluating statement
3.      sqle_ca_pd_connpool.C:49:4: Error evaluating statement
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 168392)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg:
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg:
/home/hotellnx99/peeterj/tmp/sqle_ca_pd_connpool-HONlX0.cpp
clang: note: diagnostic msg:
/home/hotellnx99/peeterj/tmp/sqle_ca_pd_connpool-HONlX0.sh


standalone source was:


#include <unistd.h>

#define Uint64 unsigned long
#define Uint32 unsigned int

typedef Uint64 SQLO_PGRP_FILE_VERSION ;

#define SQLO_PGRP_MAX_HCA 8
#define OSS_NETWORK_DEVICE_NAME_SZ            24
#define SQLO_HCA_NAME_SZ 15
#define SQL_HOSTNAME_SZ        255

struct SQLO_PGRP_HCA_RESOURCE
{
   char   HCANetname[ SQL_HOSTNAME_SZ + 1 ] ;
   char   HCAName[ SQLO_HCA_NAME_SZ + 1] ;
   char   UDAPLDevice[ OSS_NETWORK_DEVICE_NAME_SZ + 1 ] ;
   bool   bAlert ;
} ;

typedef pid_t OSSPID ;

struct SQLO_PGRP_FILE_CONTENTS
{
   SQLO_PGRP_FILE_VERSION    iPgrpFileVersion ;
   OSSPID    iPgrpId ;
   OSSPID    iWdogPgrpId ;
   OSSPID    iSubPgrpId ;
   Uint32    iIndex ;
   Uint32    iNumber ;
   Uint32    iMonitorOverride ;
   Uint32          crashCounter ;
   Uint32          firstCrashTimeSeconds ;
   Uint32          crashTimePad1 ;
   char hostname[ SQL_HOSTNAME_SZ + 1 ] ;
   Uint32          monitorTimeoutCounter ;
   Uint32          firstMonitorTimeoutSeconds ;
   Uint32          crashTimePad2 ;
   Uint32          lastMonitorTimeoutSeconds ;
   Uint32          crashTimePad3 ;
   Uint32                        iNumHCAs ;
   SQLO_PGRP_HCA_RESOURCE        HCAs[ SQLO_PGRP_MAX_HCA ] ;
   char                          explicitPad1[ 4 ] ;
   char                          padForFutureGrowth[ 512 ] ;
} ;

void foo()
{
   SQLO_PGRP_FILE_CONTENTS pgrpContents = { 0x00 };
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 13:43:40 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 21:43:40 +0000
Subject: [LLVMbugs] [Bug 14438] New: $TMPDIR not respected
Message-ID: <bug-14438-206@http.llvm.org/bugs/>

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

             Bug #: 14438
           Summary: $TMPDIR not respected
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: peeter.joot at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


scan-build contains the following:

sub GetHTMLRunDir {
...
  if (!defined $Dir) {
    if (`uname` =~ /Darwin/) {
      $Dir = $ENV{'TMPDIR'};
      if (!defined $Dir) { $Dir = "/tmp"; }
    }
    else {
      $Dir = "/tmp";
    }

$TMPDIR is a standard environment variable on any Unix platform.  I don't see a
good reason that this code isn't just:


sub GetHTMLRunDir {
...
  if (!defined $Dir) {
      $Dir = $ENV{'TMPDIR'};
      if (!defined $Dir) { $Dir = "/tmp"; }

especially since /tmp/ can have limited storage available.

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


From bugzilla-daemon at llvm.org  Mon Nov 26 14:15:50 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 22:15:50 +0000
Subject: [LLVMbugs] [Bug 14439] New: clang 3.1 crashes in
 runOnMachineFunction while running pass 'ARM Instruction Selection'
Message-ID: <bug-14439-206@http.llvm.org/bugs/>

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

             Bug #: 14439
           Summary: clang 3.1 crashes in runOnMachineFunction while
                    running pass 'ARM Instruction Selection'
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bugmail.clang at staktrace.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I'm trying to cross-compile the mozilla-central codebase using a clang
toolchain (taken from the Android NDK version r8c). When trying to compile the
jsapi.cpp file clang dies with the output below. I can provide some steps to
reproduce this if needed but it ain't gonna be pretty. This is cross-compiling
from an x86 linux host to an armv7a/thumb target.


make[5]: Entering directory
`/home/kats/zspace/mozilla-git/obj-android-clang/js/src'
/usr/bin/ccache
/home/kats/android/ndk/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/arm-linux-androideabi-g++
-o jsapi.o -c  -fvisibility=hidden -DENABLE_TYPEDARRAY_MOVE -DENABLE_YARR_JIT=1
-DNO_NSPR_10_SUPPORT -DIMPL_MFBT -DEXPORT_JS_API -DJS_HAS_CTYPES
-DDLL_PREFIX=\"lib\" -DDLL_SUFFIX=\".so\" -DUSE_ZLIB -Ictypes/libffi/include
-I.  -I/home/kats/zspace/mozilla-git/js/src/../../mfbt/double-conversion
-I/home/kats/zspace/mozilla-git/js/src -I. -I./../../dist/include 
-I/home/kats/zspace/mozilla-git/obj-android/dist/include/nspr     
-I/home/kats/zspace/mozilla-git/js/src
-I/home/kats/zspace/mozilla-git/js/src/assembler
-I/home/kats/zspace/mozilla-git/js/src/yarr  -fPIC -Qunused-arguments -isystem
/home/kats/android/ndk/platforms/android-5/arch-arm/usr/include  -pedantic
-Qunused-arguments -Wall -Wpointer-arith -Woverloaded-virtual
-Werror=return-type -Wtype-limits -Wempty-body -Werror=conversion-null
-Wno-ctor-dtor-privacy -Wno-overlength-strings -Wno-invalid-offsetof
-Wno-variadic-macros -Wno-c++0x-extensions -Wno-extended-offsetof
-Wno-unknown-warning-option -Wno-return-type-c-linkage -Wno-mismatched-tags
-Wno-long-long -mandroid -fno-short-enums -fno-exceptions -Wno-psabi
-march=armv7-a -mthumb -mfpu=vfp -mfloat-abi=softfp
-I/home/kats/zspace/mozilla-git/obj-android/build/stlport
-I/home/kats/android/ndk/sources/cxx-stl/stlport/stlport -fno-rtti
-ffunction-sections -fdata-sections -fno-exceptions -pipe  -DDEBUG -D_DEBUG
-DTRACING -g -fno-omit-frame-pointer -funwind-tables -DUSE_SYSTEM_MALLOC=1
-DENABLE_ASSEMBLER=1 -DENABLE_JIT=1  -Qunused-arguments -isystem
/home/kats/android/ndk/platforms/android-5/arch-arm/usr/include 
-DMOZILLA_CLIENT -include ./js-confdefs.h -MD -MF .deps/jsapi.o.pp 
/home/kats/zspace/mozilla-git/js/src/jsapi.cpp

[snip out a bunch of warnings]

15 clang31   0x0935d7b4
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 1204
16 clang31   0x094bfdda
llvm::MachineFunctionPass::runOnFunction(llvm::Function&) + 186
17 clang31   0x09a58d12 llvm::FPPassManager::runOnFunction(llvm::Function&) +
578
18 clang31   0x09a58e0c llvm::FPPassManager::runOnModule(llvm::Module&) + 76
19 clang31   0x09a5886d llvm::MPPassManager::runOnModule(llvm::Module&) + 541
20 clang31   0x09a58a20 llvm::PassManagerImpl::run(llvm::Module&) + 160
21 clang31   0x09a58ac6 llvm::PassManager::run(llvm::Module&) + 38
22 clang31   0x08483367 clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) + 2119
23 clang31   0x084811b9
24 clang31   0x08600bc0 clang::ParseAST(clang::Sema&, bool, bool) + 496
25 clang31   0x0833e35f clang::ASTFrontendAction::ExecuteAction() + 111
26 clang31   0x0847f87b clang::CodeGenAction::ExecuteAction() + 43
27 clang31   0x0833ec88 clang::FrontendAction::Execute() + 168
28 clang31   0x08321e28
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 312
29 clang31   0x083079af
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1103
30 clang31   0x082fd42c cc1_main(char const**, char const**, char const*,
void*) + 732
31 clang31   0x082eb68b main + 779
32 libc.so.6 0x557080f3 __libc_start_main + 243
33 clang31   0x082fd005
Stack dump:
0.    Program arguments:
/home/kats/android/ndk-r8c/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/clang31
-cc1 -triple thumbv7-none-linux-androideabi -S -disable-free -main-file-name
jsapi.cpp -pic-level 2 -mdisable-fp-elim -mconstructor-aliases -munwind-tables
-fuse-init-array -target-abi aapcs-linux -target-cpu cortex-a8 -mfloat-abi soft
-target-feature +soft-float-abi -target-feature +vfp2 -target-feature +d16
-target-feature -neon -backend-option -arm-enable-ehabi -backend-option
-arm-enable-ehabi-descriptors -backend-option -arm-ignore-has-ras
-target-linker-version 2.20.1 -momit-leaf-frame-pointer -g -ffunction-sections
-fdata-sections -coverage-file /tmp/jsapi-sVhOxJ.s -resource-dir
/home/kats/android/ndk-r8c/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../lib/clang/3.1
-isystem /home/kats/android/ndk/platforms/android-5/arch-arm/usr/include
-isystem /home/kats/android/ndk/platforms/android-5/arch-arm/usr/include
-include ./js-confdefs.h -D ENABLE_TYPEDARRAY_MOVE -D ENABLE_YARR_JIT=1 -D
NO_NSPR_10_SUPPORT -D IMPL_MFBT -D EXPORT_JS_API -D JS_HAS_CTYPES -D
DLL_PREFIX="lib" -D DLL_SUFFIX=".so" -D USE_ZLIB -D DEBUG -D _DEBUG -D TRACING
-D USE_SYSTEM_MALLOC=1 -D ENABLE_ASSEMBLER=1 -D ENABLE_JIT=1 -D MOZILLA_CLIENT
-I ctypes/libffi/include -I . -I
/home/kats/zspace/mozilla-git/js/src/../../mfbt/double-conversion -I
/home/kats/zspace/mozilla-git/js/src -I . -I ./../../dist/include -I
/home/kats/zspace/mozilla-git/obj-android/dist/include/nspr -I
/home/kats/zspace/mozilla-git/js/src -I
/home/kats/zspace/mozilla-git/js/src/assembler -I
/home/kats/zspace/mozilla-git/js/src/yarr -I
/home/kats/zspace/mozilla-git/obj-android/build/stlport -I
/home/kats/android/ndk/sources/cxx-stl/stlport/stlport -isysroot
/home/kats/android/ndk-r8c/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../sysroot
-fmodule-cache-path /var/tmp/clang-module-cache -internal-isystem
/home/kats/android/ndk/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../include/c++/4.6
-internal-isystem
/home/kats/android/ndk/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../include/c++/4.6/arm-linux-androideabi/armv7-a/thumb
-internal-isystem
/home/kats/android/ndk/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../lib/gcc/arm-linux-androideabi/4.6/../../../../include/c++/4.6/backward
-internal-isystem
/home/kats/android/ndk-r8c/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../sysroot/usr/local/include
-internal-isystem
/home/kats/android/ndk-r8c/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../lib/clang/3.1/include
-internal-externc-isystem
/home/kats/android/ndk-r8c/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../sysroot/include
-internal-externc-isystem
/home/kats/android/ndk-r8c/toolchains/arm-linux-androideabi-clang3.1/standalone/linux-x86/bin/../sysroot/usr/include
-Wall -Wpointer-arith -Woverloaded-virtual -Werror=return-type -Wtype-limits
-Wempty-body -Werror=conversion-null -Wno-ctor-dtor-privacy
-Wno-overlength-strings -Wno-invalid-offsetof -Wno-variadic-macros
-Wno-c++0x-extensions -Wno-extended-offsetof -Wno-unknown-warning-option
-Wno-return-type-c-linkage -Wno-mismatched-tags -Wno-long-long -Wno-psabi
-pedantic -fdeprecated-macro -fno-dwarf-directory-asm -fdebug-compilation-dir
/home/kats/zspace/mozilla-git/obj-android-clang/js/src -ferror-limit 19
-fmessage-length 0 -fvisibility hidden -mstackrealign -fno-rtti
-fno-signed-char -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak
-fobjc-fragile-abi -fdiagnostics-show-option -o /tmp/jsapi-sVhOxJ.s -x c++
/home/kats/zspace/mozilla-git/js/src/jsapi.cpp 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module
'/home/kats/zspace/mozilla-git/js/src/jsapi.cpp'.
4.    Running pass 'ARM Instruction Selection' on function '@_ZN2js7ToInt32Ed'
clang31: error: unable to execute command: Aborted
clang31: error: clang frontend command failed due to signal (use -v to see
invocation)
clang31: note: diagnostic msg: Please submit a bug report to
http://llvm.org/bugs/ and include command line arguments and all diagnostic
information.
clang31: note: diagnostic msg: Preprocessed source(s) and associated run
script(s) are located at:
clang31: note: diagnostic msg: /tmp/jsapi-CowG8J.ii
clang31: note: diagnostic msg: /tmp/jsapi-CowG8J.sh
make[5]: *** [jsapi.o] Error 254

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 15:00:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 26 Nov 2012 23:00:49 +0000
Subject: [LLVMbugs] [Bug 14440] New: Implement __builtin_fallthrough() to
 suppress false positives from -Wimplicit-fallthrough
Message-ID: <bug-14440-206@http.llvm.org/bugs/>

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

             Bug #: 14440
           Summary: Implement __builtin_fallthrough() to suppress false
                    positives from -Wimplicit-fallthrough
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: arthur.j.odwyer at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


See the corresponding GCC bug (filed long ago, my recent comment near the
bottom):
http://gcc.gnu.org/bugzilla/show_bug.cgi?id=7652

Per this clang-dev mailing-list discussion (which I just unearthed; I didn't
participate):
http://clang-developers.42468.n3.nabble.com/should-Wimplicit-fallthrough-require-C-11-td4028144.html

I think it would be a great idea to implement the builtin function
__builtin_fallthrough(). (It should have exactly that spelling, so that GCC and
Clang receive compatible builtins instead of mutually misspelled ones.)  Then,
either the C++11 attribute [[clang::fallthrough]] should be retired, or else it
should be implemented as a simple call to the builtin.

A call to __builtin_fallthrough() should suppress the warning that would
ordinarily be emitted for the immediately following case label:

    case 1:
        foo();
        __builtin_fallthrough();
    case 2:  /* no warning here, hooray! */

Programmers who don't want to see ugly double-underscores in their code can
"#define FALLS_THROUGH_TO __builtin_fallthrough();" and write

    case 1:
        foo();
    FALLS_THROUGH_TO case 2:  /* hooray! */

Unfortunately I don't have the time or expertise to actually submit a patch for
this, but I've filed the suggestion both here and on GCC's Bugzilla, and I'm
very hopeful that both compilers will eventually implement compatible versions
of this feature. Warning about unintended fallthrough is *VERY* good at
catching bugs, and having a mechanism to eliminate false-positive warnings is
*VERY* important.

(As I said above, I'm aware of [[clang::fallthrough]], but it doesn't work
outside of C++11 mode, and besides that it's not portable to any non-Clang
compiler because it's got the word "clang" hard-coded into 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  Mon Nov 26 16:41:22 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 00:41:22 +0000
Subject: [LLVMbugs] [Bug 14441] New: Warn about unnecessarily nontrivial
	types
Message-ID: <bug-14441-206@http.llvm.org/bugs/>

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

             Bug #: 14441
           Summary: Warn about unnecessarily nontrivial types
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: googler
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


See changes such as r168211 removing unnecessary explicit default ctors that
cause types to lose implicit move semantics. 

We could try to warn on types that do this in a number of ways:

1) warn whenever a type trait is tested that would have a different result if
some explicitly defined members (that are equivalent to their implicit
definitions) were implicitly defined

2) warn whenever a type has its move members implicitly removed due to an
unnecessary explicit member definition

(note that (1) only works if those explicit definitions are inline so we can
see that they are just like the implicit definition - and might need to be
adjusted to reduce spam from every single trait test. (2) could be implemented
even for non-inline definitions but might fire for types that are never used in
a context where they would be moved)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 18:38:12 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 02:38:12 +0000
Subject: [LLVMbugs] [Bug 14438] $TMPDIR not respected
In-Reply-To: <bug-14438-206@http.llvm.org/bugs/>
References: <bug-14438-206@http.llvm.org/bugs/>
Message-ID: <bug-14438-206-G1K1z6dGYN@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

--- Comment #1 from Jordan Rose <jordan_rose at apple.com> 2012-11-26 20:38:12 CST ---
Sounds reasonable, r168672.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 18:59:05 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 02:59:05 +0000
Subject: [LLVMbugs] [Bug 14378] vfork() should not be a builtin that returns
	int
In-Reply-To: <bug-14378-206@http.llvm.org/bugs/>
References: <bug-14378-206@http.llvm.org/bugs/>
Message-ID: <bug-14378-206-A2cmd8Fn9u@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-26 20:59:05 CST ---
r168674.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 26 23:53:59 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 07:53:59 +0000
Subject: [LLVMbugs] [Bug 14442] New: __int128 atomic hangs compiler
Message-ID: <bug-14442-206@http.llvm.org/bugs/>

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

             Bug #: 14442
           Summary: __int128 atomic hangs compiler
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: dvyukov at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ clang++ -v
clang version 3.3 (trunk 168584)
Target: x86_64-unknown-linux-gnu
Thread model: posix

$ cat /tmp/test.cc
int main() {
    __int128 a;
    __sync_fetch_and_add(&a, 1);
}

$ clang++ /tmp/test.cc
[burns 100% CPU and hangs forever in]

#0  0x0000000000b943df in llvm::DAGTypeLegalizer::ExpandAtomic(llvm::SDNode*)
()
#1  0x0000000000bacf42 in
llvm::DAGTypeLegalizer::ExpandIntegerResult(llvm::SDNode*, unsigned int) ()
#2  0x0000000000b3f40c in llvm::SelectionDAG::LegalizeTypes() ()
#3  0x0000000000aee1a9 in llvm::SelectionDAGISel::CodeGenAndEmitDAG() ()
#4  0x0000000000af4e4e in
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) ()
#5  0x0000000000af5fb8 in
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) ()
#6  0x00000000010f024c in llvm::FPPassManager::runOnFunction(llvm::Function&)
()
#7  0x00000000010f02f3 in llvm::FPPassManager::runOnModule(llvm::Module&) ()
#8  0x00000000010efe66 in llvm::MPPassManager::runOnModule(llvm::Module&) ()
#9  0x00000000010effa2 in llvm::PassManagerImpl::run(llvm::Module&) ()
#10 0x00000000011e886a in clang::EmitBackendOutput(clang::DiagnosticsEngine&,
clang::CodeGenOptions const&, clang::TargetOptions const&, clang::LangOptions
const&, llvm::Module*, clang::BackendAction, llvm::raw_ostream*) ()
#11 0x00000000011e61a0 in
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) ()
#12 0x000000000146c5ee in clang::ParseAST(clang::Sema&, bool, bool) ()
#13 0x00000000013b3a81 in clang::FrontendAction::Execute() ()
#14 0x0000000001396aa0 in
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) ()
#15 0x00000000011c8aca in
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) ()
#16 0x0000000000640690 in cc1_main(char const**, char const**, char const*,
void*) ()
#17 0x00000000006274a2 in main ()

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 27 08:04:37 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 16:04:37 +0000
Subject: [LLVMbugs] [Bug 14443] New: scan-build skips C++ files with .C
 suffix (capital C).
Message-ID: <bug-14443-206@http.llvm.org/bugs/>

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

             Bug #: 14443
           Summary: scan-build skips C++ files with .C suffix (capital C).
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: peeter.joot at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Our product uses .C suffixes for C++ code.  The compiler recognizes this
suffix, but the scan-build script does not, and skips such files silently:

A patch to fix:

--- llvm.orig/tools/clang/tools/scan-build/ccc-analyzer   2012-11-20
17:53:14.000000000 -0500
+++ ./ccc-analyzer   2012-11-26 19:19:31.000000000 -0500
@@ -384,6 +388,7 @@ my %IgnoredOptionMap = (

 my %LangMap = (
   'c'   => 'c',
+  'C'   => 'c++',
   'cp'  => 'c++',
   'cpp' => 'c++',
   'cxx' => 'c++',

I'd also suggest that some error handling for unrecognized file types be
implemented (something better than the somewhat confusing message than the "no
reports were generated, deleting directory ..." message.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 27 10:25:05 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 18:25:05 +0000
Subject: [LLVMbugs] [Bug 14432] -indvars generates infinite loop
In-Reply-To: <bug-14432-206@http.llvm.org/bugs/>
References: <bug-14432-206@http.llvm.org/bugs/>
Message-ID: <bug-14432-206-KE2ITvm7Yf@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-27 12:25:05 CST ---
Fixed in r168711.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 27 10:31:43 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 18:31:43 +0000
Subject: [LLVMbugs] [Bug 14026] With large tuple size(60) clang much slower
	than gcc
In-Reply-To: <bug-14026-206@http.llvm.org/bugs/>
References: <bug-14026-206@http.llvm.org/bugs/>
Message-ID: <bug-14026-206-iiHTcDuHAK@http.llvm.org/bugs/>

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

Larry Evans <cppljevans at suddenlink.net> changed:

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

--- Comment #7 from Larry Evans <cppljevans at suddenlink.net> 2012-11-27 12:31:43 CST ---
Additional test code (tuple.benchmark.tree_builder.cpp from here:

http://svn.boost.org/svn/boost/sandbox/variadic_templates/sandbox/slim/test/tuple.benchmark.tree_builder.cpp

) shows clang does much worse than gcc at modest TUPLE_SIZE(15) and
TREE_DEPTH(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  Tue Nov 27 15:06:25 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 23:06:25 +0000
Subject: [LLVMbugs] [Bug 14436] clang:
 /home/hotellnx99/peeterj/tmp/clang/llvm/include/llvm/Support/Casting.h:208:
 typename llvm::cast_retty<To, From>::ret_type llvm::cast(const Y&) [with X
 = clang::ento::StringRegion; Y = const clang::ento::MemRegion*;
 typename llvm::cast_retty<To, Fro
In-Reply-To: <bug-14436-206@http.llvm.org/bugs/>
References: <bug-14436-206@http.llvm.org/bugs/>
Message-ID: <bug-14436-206-jA3i0Z0V0g@http.llvm.org/bugs/>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #3 from Ted Kremenek <kremenek at apple.com> 2012-11-27 17:06:25 CST ---
Crash fixed in r168741.  This is just a stop-gap fix, however.  We need to
properly evaluate how we will handle the CXXTempObjectRegion that gets created
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  Tue Nov 27 15:33:23 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 27 Nov 2012 23:33:23 +0000
Subject: [LLVMbugs] [Bug 14444] New: Poor suggestion from typo correction
Message-ID: <bug-14444-206@http.llvm.org/bugs/>

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

             Bug #: 14444
           Summary: Poor suggestion from typo correction
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


src/tools/clang/lib/Sema/SemaDeclCXX.cpp:532:36: error: no member named
'getParam' in 'clang::FunctionDecl'; did you mean 'setParams'?
      ParmVarDecl *NewParam = New->getParam(New->getMinRequiredArguments());
                                   ^~~~~~~~
                                   setParams

No. I meant getParamDecl. There are a couple of clues to suggest which one I
was looking for:

 1) The correct correction involves only one change (adding 'Decl'). The
incorrect one involves two changes ('g' -> 's', and adding a trailing 's').

 2) We have one correction which adds a missing suffix and another which
'fixes' a typo. The former is more likely to be intended, because it's probably
not a typo if there is another method which starts with that 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 Nov 27 21:10:01 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 05:10:01 +0000
Subject: [LLVMbugs] [Bug 14445] New: clang recovers poorly from missing ';
 ' after an enum
Message-ID: <bug-14445-206@http.llvm.org/bugs/>

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

             Bug #: 14445
           Summary: clang recovers poorly from missing ';' after an enum
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ cat test.cc 
enum A {
  a1,
  a2
}
void f() {}
$ clang -c test.cc
test.cc:5:1: error: cannot combine with previous 'enum' declaration specifier
void f() {}
^
test.cc:1:6: error: 'A' can not be defined in the result type of a function
enum A {
     ^
2 errors generated.



In bigger files, this causes tens of errors. Instead, clang should suggest a
';' after the enum.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 27 21:21:23 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 05:21:23 +0000
Subject: [LLVMbugs] [Bug 14445] clang recovers poorly from missing ';
	' after an enum
In-Reply-To: <bug-14445-206@http.llvm.org/bugs/>
References: <bug-14445-206@http.llvm.org/bugs/>
Message-ID: <bug-14445-206-aZkr8i6aUU@http.llvm.org/bugs/>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #1 from Nico Weber <nicolasweber at gmx.de> 2012-11-27 23:21:23 CST ---
dblaikie points out that this is fixed on trunk, and I can confirm this even
with month-old r167488.

The clang in the newest xcode still has this bug, 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 Nov 27 22:57:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 06:57:49 +0000
Subject: [LLVMbugs] [Bug 14446] New: Code-completion doesn't work inside
 structure initializer
Message-ID: <bug-14446-206@http.llvm.org/bugs/>

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

             Bug #: 14446
           Summary: Code-completion doesn't work inside structure
                    initializer
           Product: clang
           Version: 3.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dubinin2004 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This would be great to make code-completion to work inside structure
initializer.
I mean, like that:

    typedef  struct  {
        int  a;
        int  b;
    } T_MyStruct;

    int  main(void)
    {
        T_MyStruct my_struct = {
           .a =0,
           ./*cursor is here. I want to get list of struct members: [int a, int
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  Wed Nov 28 04:47:40 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 12:47:40 +0000
Subject: [LLVMbugs] [Bug 12664] -O2 -ftree-vectorize
 -fplugin-arg-dragonegg-enable-gcc-optzns on mdbx.f90 confuses dragonegg
In-Reply-To: <bug-12664-206@http.llvm.org/bugs/>
References: <bug-12664-206@http.llvm.org/bugs/>
Message-ID: <bug-12664-206-jmZa5ReNj4@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2012-11-28 06:47:40 CST ---
I wasn't able to reproduce using polyhedron, however the following commit
should
have fixed it:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/157178.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 Nov 28 06:56:09 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 14:56:09 +0000
Subject: [LLVMbugs] [Bug 14447] New: [Windows] Aliasing destructors are not
 handled correctly in COFF?
Message-ID: <bug-14447-206@http.llvm.org/bugs/>

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

             Bug #: 14447
           Summary: [Windows] Aliasing destructors are not handled
                    correctly in COFF?
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: timurrrr at google.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


=== test.cpp ===
struct A { ~A() {} };
template<class T> struct B : A { };
template<class T> struct C : B<T> { };
template<class T> struct D : C<T> { };

namespace {
  struct s {};
}

int main() {
  D<s> d;
}
================

As of r168782 with the following patch (xref bug 13443):
<<<<<<<<<<<<<<<<<<<<<<<<<<<
diff --git lib/CodeGen/CGClass.cpp lib/CodeGen/CGClass.cpp
index b2225e4..fbe433b 100644
--- lib/CodeGen/CGClass.cpp
+++ lib/CodeGen/CGClass.cpp
@@ -1218,7 +1218,7 @@ void CodeGenFunction::destroyCXXObject(CodeGenFunction
&CGF,
   const CXXRecordDecl *record = cast<CXXRecordDecl>(rtype->getDecl());
   const CXXDestructorDecl *dtor = record->getDestructor();
   assert(!dtor->isTrivial());
-  CGF.EmitCXXDestructorCall(dtor, Dtor_Complete, /*for vbase*/ false,
+  CGF.EmitCXXDestructorCall(dtor, Dtor_Base/*Dtor_Complete*/, /*for vbase*/
false,
                             addr);
 }
<<<<<<<<<<<<<<<<<<<<<<<<<<<
I get the following:
$ clang -Xclang -cxx-abi -Xclang microsoft test.cpp
test-492687.o : error LNK2019: unresolved external symbol "public: __thiscall
D<struct `anonymous namespace'::s>::~D<struct `anonymous namespace'::s>(void)"
(??1?$D at Us@?A@@@@QAE at XZ) referenced in function _main

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 28 11:35:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 19:35:39 +0000
Subject: [LLVMbugs] [Bug 14448] New: [loopvectorize] multiple vector loops
 generated from single scalar loop
Message-ID: <bug-14448-206@http.llvm.org/bugs/>

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

             Bug #: 14448
           Summary: [loopvectorize] multiple vector loops generated from
                    single scalar loop
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Keywords: code-quality
          Severity: enhancement
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: paul.redmond at intel.com
                CC: llvmbugs at cs.uiuc.edu, nrotem at apple.com
    Classification: Unclassified


I think this is a known issue but..

If you compile the following program with vectorize-loops enabled multiple
vector loops are generated because the scalar loop is processed by
LoopVectorize twice.

#include <numeric>

int foo(int *A, int n)
{
  return std::accumulate(A, A + n, 0);
}

The generated code is correct but not desirable.

compile with:
clang++ -S -emit-llvm accum.cpp -O2 -mllvm -vectorize-loops -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  Wed Nov 28 12:56:27 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 20:56:27 +0000
Subject: [LLVMbugs] [Bug 14337] UNREACHABLE executed at
 CallingConvLower.cpp:111 when returning v4f64 on ARM
In-Reply-To: <bug-14337-206@http.llvm.org/bugs/>
References: <bug-14337-206@http.llvm.org/bugs/>
Message-ID: <bug-14337-206-FJIEUh6D8H@http.llvm.org/bugs/>

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

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> 2012-11-28 14:56:27 CST ---
Fixed in r168809.

I don't think this is a release blocker, the IR cannot be produced with clang
for ARM.

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


From bugzilla-daemon at llvm.org  Wed Nov 28 13:48:06 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 21:48:06 +0000
Subject: [LLVMbugs] [Bug 13098] inherited operator= ambiguity in template
 function instantiation, but not in non-template function
In-Reply-To: <bug-13098-206@http.llvm.org/bugs/>
References: <bug-13098-206@http.llvm.org/bugs/>
Message-ID: <bug-13098-206-Lry32vhkNC@http.llvm.org/bugs/>

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

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

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

--- Comment #5 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-28 15:48:06 CST ---
Fixed in r168818.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 28 14:10:43 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 22:10:43 +0000
Subject: [LLVMbugs] [Bug 14279] mishandling of implicit move in class with
 copy-only member
In-Reply-To: <bug-14279-206@http.llvm.org/bugs/>
References: <bug-14279-206@http.llvm.org/bugs/>
Message-ID: <bug-14279-206-ALXvY4YXwu@http.llvm.org/bugs/>

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

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

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

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-28 16:10:43 CST ---
I'm going to call the release blocking part of this fixed. Per comment#1,
there's still more to do 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 Nov 28 14:18:30 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 22:18:30 +0000
Subject: [LLVMbugs] [Bug 10618] "addition of default argument makes this a
 special member" warning slightly incorrect with multiple default arguments
In-Reply-To: <bug-10618-206@http.llvm.org/bugs/>
References: <bug-10618-206@http.llvm.org/bugs/>
Message-ID: <bug-10618-206-t1IFlNxbvu@http.llvm.org/bugs/>

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

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

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

--- Comment #1 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-28 16:18:30 CST ---
Fixed in r168769

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 28 14:34:23 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 22:34:23 +0000
Subject: [LLVMbugs] [Bug 14388] Array exception type should be decayed to
 pointer automatically
In-Reply-To: <bug-14388-206@http.llvm.org/bugs/>
References: <bug-14388-206@http.llvm.org/bugs/>
Message-ID: <bug-14388-206-LBcPnZHSbS@http.llvm.org/bugs/>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |richard-llvm at metafoo.co.uk
         Resolution|                            |FIXED

--- Comment #9 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-28 16:34:23 CST ---
Fixed in r168822.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 28 14:39:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 28 Nov 2012 22:39:51 +0000
Subject: [LLVMbugs] [Bug 14449] New: !isNull() && "Cannot retrieve a NULL
	type pointer"
Message-ID: <bug-14449-206@http.llvm.org/bugs/>

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

             Bug #: 14449
           Summary: !isNull() && "Cannot retrieve a NULL type pointer"
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: snubdodecahedron at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang++ crashes when compiling the following program:

template<class T> struct A {};
template<class T> struct B:public A<T> {};
template<class T> void f(B<const T> p);
void g() {f(B<int>());}

How to compile: clang++ -c prog.cpp

$ clang++ -v
clang version 3.2 (trunk 156016) (llvm/trunk 156015)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Diagnostics:
prog.cpp:4:11: error: no matching function for call to 'f'
void g() {f(B<int>());}
          ^
clang:
/home/craig/llvm/projects/llvm/tools/clang/lib/Sema/../../include/clang/AST/Type.h:505:
const clang::ExtQualsTypeCommonBase* clang::QualType::getCommonPtr() const:
Assertion `!isNull() && "Cannot retrieve a NULL type pointer"' failed.
0  clang           0x0000000001f3feef
1  clang           0x0000000001f40a2a
2  libpthread.so.0 0x00007f50b4810cb0
3  libc.so.6       0x00007f50b3a62425 gsignal + 53
4  libc.so.6       0x00007f50b3a65b8b abort + 379
5  libc.so.6       0x00007f50b3a5b0ee
6  libc.so.6       0x00007f50b3a5b192
7  clang           0x0000000000b85142
8  clang           0x0000000000ba3ca0
9  clang           0x0000000000ba571f
clang::OverloadCandidateSet::NoteCandidates(clang::Sema&,
clang::OverloadCandidateDisplayKind, llvm::ArrayRef<clang::Expr*>, char const*,
clang::SourceLocation) + 431
10 clang           0x0000000000baafea
clang::Sema::BuildOverloadedCallExpr(clang::Scope*, clang::Expr*,
clang::UnresolvedLookupExpr*, clang::SourceLocation, clang::Expr**, unsigned
int, clang::SourceLocation, clang::Expr*, bool) + 1722
11 clang           0x0000000000af5124 clang::Sema::ActOnCallExpr(clang::Scope*,
clang::Expr*, clang::SourceLocation, clang::ASTMultiPtr<clang::Expr*>,
clang::SourceLocation, clang::Expr*, bool) + 1412
12 clang           0x00000000009305bd
clang::Parser::ParsePostfixExpressionSuffix(clang::ActionResult<clang::Expr*,
true>) + 2717
13 clang           0x000000000092832b clang::Parser::ParseCastExpression(bool,
bool, bool&, clang::Parser::TypeCastState) + 203
14 clang           0x000000000092b7cd clang::Parser::ParseCastExpression(bool,
bool, clang::Parser::TypeCastState) + 29
15 clang           0x000000000092cb8f
clang::Parser::ParseAssignmentExpression(clang::Parser::TypeCastState) + 31
16 clang           0x000000000092dba9
clang::Parser::ParseExpression(clang::Parser::TypeCastState) + 9
17 clang           0x0000000000966255 clang::Parser::ParseExprStatement() + 69
18 clang           0x0000000000960ef3
clang::Parser::ParseStatementOrDeclarationAfterAttributes(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*, clang::Parser::ParsedAttributesWithRange&)
+ 1075
19 clang           0x0000000000961b1e
clang::Parser::ParseStatementOrDeclaration(clang::ASTOwningVector<clang::Stmt*,
32u>&, bool, clang::SourceLocation*) + 142
20 clang           0x000000000095da2c
clang::Parser::ParseCompoundStatementBody(bool) + 524
21 clang           0x000000000095e85d
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 141
22 clang           0x00000000009005a0
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&,
llvm::SmallVector<clang::Parser::LateParsedAttribute*, 2u>*) + 1680
23 clang           0x000000000090c5cf
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 2623
24 clang           0x00000000008fafd8
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 152
25 clang           0x00000000008fb7ae
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 798
26 clang           0x00000000008fed48
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 3080
27 clang           0x00000000008ff304
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 180
28 clang           0x00000000008f3efd clang::ParseAST(clang::Sema&, bool, bool)
+ 205
29 clang           0x0000000000784c24 clang::CodeGenAction::ExecuteAction() +
68
30 clang           0x0000000000639cd4
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 340
31 clang           0x000000000061ed18
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1240
32 clang           0x00000000006147c9 cc1_main(char const**, char const**, char
const*, void*) + 6905
33 clang           0x000000000061db83 main + 7539
34 libc.so.6       0x00007f50b3a4d76d __libc_start_main + 237
35 clang           0x0000000000612139
Stack dump:
0.    Program arguments: /home/craig/bin/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
prog.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.21.0.20110327 -momit-leaf-frame-pointer -coverage-file prog.o -resource-dir
/home/craig/bin/bin/../lib/clang/3.2 -fmodule-cache-path
/var/tmp/clang-module-cache -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6 -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward
-internal-isystem /usr/local/include -internal-isystem
/home/craig/bin/bin/../lib/clang/3.2/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -fdeprecated-macro
-fdebug-compilation-dir /home/craig/cc -ferror-limit 19 -fmessage-length 159
-mstackrealign -fgnu-runtime -fobjc-runtime-has-arc -fobjc-runtime-has-weak
-fobjc-fragile-abi -fcxx-exceptions -fexceptions -fdiagnostics-show-option
-fcolor-diagnostics -o prog.o -x c++ prog.cpp 
1.    prog.cpp:4:21: current parser token ')'
2.    prog.cpp:4:10: parsing function body 'g'
3.    prog.cpp:4:10: in compound statement ('{}')
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (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 Nov 28 17:42:53 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 01:42:53 +0000
Subject: [LLVMbugs] [Bug 14451] New: build instructions for libc++ on web
 page are out-of-date
Message-ID: <bug-14451-206@http.llvm.org/bugs/>

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

             Bug #: 14451
           Summary: build instructions for libc++ on web page are
                    out-of-date
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: kremenek at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The website says to build libc++, one does the following:

cd libcxx/lib
export TRIPLE=-apple-
./buildit
ln -sf libc++.1.dylib libc++.dylib


This is not true.  One runs make with the appropriate arguments.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 28 17:49:48 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 01:49:48 +0000
Subject: [LLVMbugs] [Bug 14452] New: cannot #include <string> using trunk
 clang and libc++
Message-ID: <bug-14452-206@http.llvm.org/bugs/>

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

             Bug #: 14452
           Summary: cannot #include <string> using trunk clang and libc++
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: kremenek at apple.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ cat test.cpp
#include <string>

$ clang++ -std=c++11 -stdlib=libc++  -nostdinc++  -I/tmp/libcxx/include
-fsyntax-only test.cpp 
In file included from test.cpp:1:
In file included from /tmp/libcxx/include/string:434:
In file included from /tmp/libcxx/include/algorithm:594:
In file included from /tmp/libcxx/include/memory:590:
In file included from /tmp/libcxx/include/typeinfo:61:
/tmp/libcxx/include/exception:145:5: error: an attribute list cannot appear
here
    _LIBCPP_NORETURN friend void rethrow_exception(exception_ptr);
    ^~~~~~~~~~~~~~~~
/tmp/libcxx/include/__config:192:28: note: expanded from macro
'_LIBCPP_NORETURN'
#  define _LIBCPP_NORETURN [[noreturn]]
                           ^~~~~~~~~~~~
1 error generated.


I am using clang svn 168846 and libc++ 168846.

What am I doing wrong?  This seem like something that should just work.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 28 21:18:20 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 05:18:20 +0000
Subject: [LLVMbugs] [Bug 14453] New: Complex data-members passed as variable
 arg gets broken when compiled with -fpic
Message-ID: <bug-14453-206@http.llvm.org/bugs/>

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

             Bug #: 14453
           Summary: Complex data-members passed as variable arg gets
                    broken when compiled with -fpic
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: naveen.c at samsung.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9604
  --> http://llvm.org/bugs/attachment.cgi?id=9604
Reduced code which reproduces the problem

When compiling the attached file with -fpic causes this problem. 
It happens only for 32-bit compilation, 64-bit executables are fine.

Furthermore if we raise the optimation level to O1 or O2 it removes the
redundant assembly and works just fine.

Steps:

clang -m32 -fpic Complex-fpic.c
./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  Thu Nov 29 00:45:55 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 08:45:55 +0000
Subject: [LLVMbugs] [Bug 14454] New: inliner deletes infinite loop
Message-ID: <bug-14454-206@http.llvm.org/bugs/>

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

             Bug #: 14454
           Summary: inliner deletes infinite loop
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: chandlerc at gmail.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


This testcase:

define i32 @main() {
entry:
  %call = call i32 @foo()
  ret i32 undef
}

define internal i32 @foo() readnone nounwind {
entry:
  %call = call i32 @foo()
  ret i32 undef
}

has an infinite loop. If you run opt -inline over it, we delete the infinite
loop producing a main that terminates.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 01:00:27 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 09:00:27 +0000
Subject: [LLVMbugs] [Bug 14454] inliner deletes infinite loop
In-Reply-To: <bug-14454-206@http.llvm.org/bugs/>
References: <bug-14454-206@http.llvm.org/bugs/>
Message-ID: <bug-14454-206-YZwWr73zoz@http.llvm.org/bugs/>

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

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> 2012-11-29 03:00:27 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 02:35:11 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 10:35:11 +0000
Subject: [LLVMbugs] [Bug 14455] New: llc crashes with "UNREACHABLE executed
 at Value.cpp:620!"
Message-ID: <bug-14455-206@http.llvm.org/bugs/>

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

             Bug #: 14455
           Summary: llc crashes with "UNREACHABLE executed at
                    Value.cpp:620!"
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: max at duempel.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I compiled LLVM from trunk r168861. I compile a program with clang to LLVM
bitcode, then llvm-link to build one large bitcode file, opt to optimize the
file, and then llc to generate assembly. llc crashes with the following
message:

llc TestRadixTree-opt.bc 
While deleting: metadata %
An asserting value handle still pointed to this value!
UNREACHABLE executed at Value.cpp:620!
0  llc             0x0000000000eb11e2
1  llc             0x0000000000eb1673
2  libpthread.so.0 0x00007f24916fc030
3  libc.so.6       0x00007f24909f2475 gsignal + 53
4  libc.so.6       0x00007f24909f56f0 abort + 384
5  llc             0x0000000000ea06a9 llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 457
6  llc             0x0000000000e67be6
llvm::ValueHandleBase::ValueIsDeleted(llvm::Value*) + 806
7  llc             0x0000000000e6762e llvm::Value::~Value() + 46
8  llc             0x0000000000e48eae llvm::MDNode::destroy() + 14
9  llc             0x0000000000e453d9 llvm::LLVMContextImpl::~LLVMContextImpl()
+ 3225
10 llc             0x0000000000e43e4c
11 llc             0x0000000000ea39d9 llvm::llvm_shutdown() + 41
12 llc             0x000000000050f063 main + 6323
13 libc.so.6       0x00007f24909deead __libc_start_main + 253
14 llc             0x000000000050d6e9
Stack dump:
0.      Program arguments: llc TestRadixTree-opt.bc 
Aborted

(LLVM bitcode file generated by "opt" is attached)

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


From bugzilla-daemon at llvm.org  Thu Nov 29 03:02:05 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 11:02:05 +0000
Subject: [LLVMbugs] [Bug 13561] LLVM ERROR: Cannot select: 0x14214bb10: i16
 = extract_vector_elt 0x14214b910, 0x142142c10 [ID=30]
In-Reply-To: <bug-13561-206@http.llvm.org/bugs/>
References: <bug-13561-206@http.llvm.org/bugs/>
Message-ID: <bug-13561-206-6Nr7L1pX31@http.llvm.org/bugs/>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #8 from Duncan Sands <baldrick at free.fr> 2012-11-29 05:02:05 CST ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20121126/157294.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  Thu Nov 29 04:08:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 12:08:15 +0000
Subject: [LLVMbugs] [Bug 14456] New: MIPS backend generates wrong reloc info
 for static data
Message-ID: <bug-14456-206@http.llvm.org/bugs/>

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

             Bug #: 14456
           Summary: MIPS backend generates wrong reloc info for static
                    data
           Product: tools
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: llvmc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: frederic.heitzmann at cea.fr
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9607
  --> http://llvm.org/bugs/attachment.cgi?id=9607
test case in C file

I use llvm-clang with a MIPS target, and it seems that the backend generates
wrong reloc info.

Test scenario :
$ clang -integrated-as -g -Wall -Wextra -c test.c -o test.o
$ mips-elf-objdump -S rtos.o > test.s
$ mips-elf-readelf -a test.o > test.readelf

test.s shows some unresolved reference, which seems normal, e.g.
int testvar2(){
  24:   27bdfff8        addiu   sp,sp,-8
  28:   24010000        li      at,0
  return (var2)?1:0;
  2c:   8f820000        lw      v0,0(gp)    << relocation needed for var2
  30:   00401026        xor     v0,v0,zero
  34:   0002102b        sltu    v0,zero,v0
  38:   afa10004        sw      at,4(sp)
  3c:   27bd0008        addiu   sp,sp,8
  40:   03e00008        jr      ra
  44:   00000000        nop
...

var2 is well defined in .symtab
Symbol table '.symtab' contains 31 entries:
   Num:    Value  Size Type    Bind   Vis      Ndx Name
...
    13: 00000000     4 OBJECT  LOCAL  DEFAULT    4 var1
    14: 00000004     4 OBJECT  LOCAL  DEFAULT    4 var2
...

However, section .rel.text in test.readelf looks bad :
Relocation section '.rel.text' at offset 0x9dc contains 4 entries:
 Offset     Info    Type            Sym.Value  Sym. Name
00000008  00001107 R_MIPS_GPREL16    00000000   .bss
0000002c  00001107 R_MIPS_GPREL16    00000000   .bss  << expect address of var2
00000058  00001107 R_MIPS_GPREL16    00000000   .bss
00000060  00001107 R_MIPS_GPREL16    00000000   .bss

In general, all relocations for static data are 0000 ?!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 05:45:03 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 13:45:03 +0000
Subject: [LLVMbugs] [Bug 12306] exception handling failure for several tests
 it the gcc c++ torture test suite under linux
In-Reply-To: <bug-12306-206@http.llvm.org/bugs/>
References: <bug-12306-206@http.llvm.org/bugs/>
Message-ID: <bug-12306-206-V509wykZd5@http.llvm.org/bugs/>

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

Rafael Ávila de Espíndola <rafael.espindola at gmail.com> changed:

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

--- Comment #4 from Rafael Ávila de Espíndola <rafael.espindola at gmail.com> 2012-11-29 07:45:03 CST ---
Marking as fixed per comment 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  Thu Nov 29 13:44:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 21:44:46 +0000
Subject: [LLVMbugs] [Bug 14457] New: Vararg operator, crashes clang
Message-ID: <bug-14457-206@http.llvm.org/bugs/>

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

             Bug #: 14457
           Summary: Vararg operator, crashes clang
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


struct StaticAsserter {
  friend void operator,(StaticAsserter, void*);
private:
  friend void operator,(StaticAsserter, ...);
};

const char *static_assert_failed = (StaticAsserter(), 1 == 1, "hello");

... triggers this:

clang-3.2: src/tools/clang/include/clang/AST/Decl.h:1814: clang::ParmVarDecl
*clang::FunctionDecl::getParamDecl(unsigned int): Assertion `i < getNumParams()
&& "Illegal param #"' failed.

We should have rejected the declaration of that operator,.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 13:49:16 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 21:49:16 +0000
Subject: [LLVMbugs] [Bug 14397] breaking on a function produces multiple
	breakpoints
In-Reply-To: <bug-14397-206@http.llvm.org/bugs/>
References: <bug-14397-206@http.llvm.org/bugs/>
Message-ID: <bug-14397-206-TV7WTAnNGc@http.llvm.org/bugs/>

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

David Blaikie <dblaikie at gmail.com> changed:

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

--- Comment #3 from David Blaikie <dblaikie at gmail.com> 2012-11-29 15:49:16 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 14:23:53 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 22:23:53 +0000
Subject: [LLVMbugs] [Bug 13994] Copy constructor incorrectly implicitly
	deleted
In-Reply-To: <bug-13994-206@http.llvm.org/bugs/>
References: <bug-13994-206@http.llvm.org/bugs/>
Message-ID: <bug-13994-206-cb8m40AjS9@http.llvm.org/bugs/>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2012-11-29 16:23:53 CST ---
WFM with Clang and libc++ 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  Thu Nov 29 15:21:14 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 29 Nov 2012 23:21:14 +0000
Subject: [LLVMbugs] [Bug 14453] Complex data-members passed as variable arg
 gets broken when compiled with -fpic
In-Reply-To: <bug-14453-206@http.llvm.org/bugs/>
References: <bug-14453-206@http.llvm.org/bugs/>
Message-ID: <bug-14453-206-AWxEIDGX4I@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #4 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-29 17:21:14 CST ---
r168959.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 16:18:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 00:18:46 +0000
Subject: [LLVMbugs] [Bug 14458] New: Impossible TemplateArgument UNREACHABLE
 executed at llvm/tools/clang/lib/AST/TypeLoc.cpp:325!
Message-ID: <bug-14458-206@http.llvm.org/bugs/>

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

             Bug #: 14458
           Summary: Impossible TemplateArgument UNREACHABLE executed at
                    llvm/tools/clang/lib/AST/TypeLoc.cpp:325!
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: snubdodecahedron at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


clang++ aborts on the following code:

template<class T,int d> class A {};
template<class T,int d> struct B;
template<class T> struct B<A<T,0>,0> { typedef int C;  };
template<class T> struct B<T,0> {  };
B<A<int,0>,0>::C b;

Compiled like this: clang++ -c prog.cpp

$ clang++ -v
clang version 3.3 (trunk 168824) (llvm/trunk 168819:168824)
Target: x86_64-unknown-linux-gnu
Thread model: posix

Diagnostic:

Impossible TemplateArgument
UNREACHABLE executed at
/home/craig/llvm/llvm/tools/clang/lib/AST/TypeLoc.cpp:325!
0  clang           0x0000000001d7748f
1  clang           0x0000000001d77973
2  libpthread.so.0 0x00007fa3ca391cb0
3  libc.so.6       0x00007fa3c95e3425 gsignal + 53
4  libc.so.6       0x00007fa3c95e6b8b abort + 379
5  clang           0x0000000001d6551f llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 463
6  clang           0x000000000114b6ee
clang::TemplateSpecializationTypeLoc::initializeArgLocs(clang::ASTContext&,
unsigned int, clang::TemplateArgument const*, clang::TemplateArgumentLocInfo*,
clang::SourceLocation) + 430
7  clang           0x000000000114a4fa
clang::TypeLoc::initializeImpl(clang::ASTContext&, clang::TypeLoc,
clang::SourceLocation) + 1002
8  clang           0x000000000100aca2
clang::ASTContext::getTrivialTypeSourceInfo(clang::QualType,
clang::SourceLocation) const + 82
9  clang           0x0000000000bdb025
10 clang           0x0000000000bd8ca4
11 clang           0x0000000000be3cfa
clang::Sema::getMoreSpecializedPartialSpecialization(clang::ClassTemplatePartialSpecializationDecl*,
clang::ClassTemplatePartialSpecializationDecl*, clang::SourceLocation) + 1450
12 clang           0x0000000000c0a0b2
clang::Sema::InstantiateClassTemplateSpecialization(clang::SourceLocation,
clang::ClassTemplateSpecializationDecl*, clang::TemplateSpecializationKind,
bool) + 978
13 clang           0x0000000000c52c6f
clang::Sema::RequireCompleteType(clang::SourceLocation, clang::QualType,
clang::Sema::TypeDiagnoser&) + 735
14 clang           0x00000000009797c0
clang::Sema::RequireCompleteDeclContext(clang::CXXScopeSpec&,
clang::DeclContext*) + 256
15 clang           0x00000000009dec8b
clang::Sema::getTypeName(clang::IdentifierInfo&, clang::SourceLocation,
clang::Scope*, clang::CXXScopeSpec*, bool, bool,
clang::OpaquePtr<clang::QualType>, bool, bool, clang::IdentifierInfo**) + 203
16 clang           0x00000000008fd331
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext, clang::Parser::LateParsedAttrList*) + 4721
17 clang           0x00000000008f04b7
clang::Parser::ParseDeclOrFunctionDefInternal(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec&, clang::AccessSpecifier) + 71
18 clang           0x00000000008f018d
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*, clang::AccessSpecifier) + 333
19 clang           0x00000000008ef7ec
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::ParsingDeclSpec*) + 2396
20 clang           0x00000000008eee10
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 304
21 clang           0x00000000008eb166 clang::ParseAST(clang::Sema&, bool, bool)
+ 470
22 clang           0x00000000007b684c clang::CodeGenAction::ExecuteAction() +
204
23 clang           0x000000000065df7a clang::FrontendAction::Execute() + 106
24 clang           0x000000000064040d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 989
25 clang           0x0000000000626fa2
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3618
26 clang           0x000000000061e426 cc1_main(char const**, char const**, char
const*, void*) + 774
27 clang           0x00000000006232fa main + 3482
28 libc.so.6       0x00007fa3c95ce76d __libc_start_main + 237
29 clang           0x000000000061e05d
Stack dump:
0.    Program arguments: /home/craig/bin/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
prog.cpp -mrelocation-model static -mdisable-fp-elim -fmath-errno -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.22 -momit-leaf-frame-pointer -coverage-file /home/craig/cc/prog.o
-resource-dir /home/craig/bin/bin/../lib/clang/3.3 -fmodule-cache-path
/var/tmp/clang-module-cache -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6 -internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/x86_64-linux-gnu
-internal-isystem
/usr/lib/gcc/x86_64-linux-gnu/4.6/../../../../include/c++/4.6/backward
-internal-isystem /usr/local/include -internal-isystem
/home/craig/bin/bin/../lib/clang/3.3/include -internal-externc-isystem
/usr/include/x86_64-linux-gnu -internal-externc-isystem /include
-internal-externc-isystem /usr/include -fdeprecated-macro
-fdebug-compilation-dir /home/craig/cc -ferror-limit 19 -fmessage-length 284
-mstackrealign -fobjc-runtime=gcc -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o prog.o -x c++ prog.cpp 
1.    prog.cpp:5:1: at annotation token 
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 168824) (llvm/trunk 168819:168824)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/prog-KPBtZP.cpp
clang: note: diagnostic msg: /tmp/prog-KPBtZP.sh
clang: note: diagnostic msg: 

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 16:26:15 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 00:26:15 +0000
Subject: [LLVMbugs] [Bug 14459] New: lit cannot run an arbitrary out-of-tree
 test directory
Message-ID: <bug-14459-206@http.llvm.org/bugs/>

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

             Bug #: 14459
           Summary: lit cannot run an arbitrary out-of-tree test directory
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: lit
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jordan_rose at apple.com
                CC: daniel at zuster.org, llvmbugs at cs.uiuc.edu
    Classification: Unclassified


I have a directory of preprocessed files that are set up to be testable with
lit, but which I don't want to run /all/ the time (a few of them take quite a
while). Unfortunately, I can't pass the test directory to lit or llvm-lit -- it
just uses the entire default test suite instead. (I copied in the lit.site.cfg
file from Clang's build tree.)

I'd like to be able to point lit at a config file and an arbitrary directory of
tests and have it run those tests.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 20:26:12 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 04:26:12 +0000
Subject: [LLVMbugs] [Bug 14460] New: 3.2 (and all previous?) hard code $TEMP
 on all platforms except Windows
Message-ID: <bug-14460-206@http.llvm.org/bugs/>

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

             Bug #: 14460
           Summary: 3.2 (and all previous?) hard code $TEMP on all
                    platforms except Windows
           Product: new-bugs
           Version: 3.2
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xxxajk at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


lib/Support/Unix/Path.inc hard codes use of /tmp instead of checking for, and
attempting to use the $TEMP or $TMP environment variable, which is standard on
all platforms, even MSW. Can this be fixed before the next official 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  Thu Nov 29 20:53:12 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 04:53:12 +0000
Subject: [LLVMbugs] [Bug 14461] New: false positive: uninitialised/garbage
	values
Message-ID: <bug-14461-206@http.llvm.org/bugs/>

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

             Bug #: 14461
           Summary: false positive: uninitialised/garbage values
           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: marka at isc.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9612
  --> http://llvm.org/bugs/attachment.cgi?id=9612
pre-processed code.

Multiple versions of clang.

Apple clang version 4.1 (tags/Apple/clang-421.11.66) (based on LLVM 3.1svn)
Target: x86_64-apple-darwin12.2.0
Thread model: posix

clang version 3.1 (branches/release_31)
Target: i386-portbld-freebsd8.3
Thread model: posix

The static analyser fails to remember that it set response to 0 for the
analysis then proceeds to complain about code that will not be reached when
response is 0.

clang --analyze tsig.preprocessed.c
In file included from tsig.c:1:
tsig.c:1337:4: warning: Function call argument is an uninitialized value
   isc__buffer_putuint16(&databuf, querytsig.siglen);
   ^                               ~~~~~~~~~~~~~~~~
tsig.c:1075:26: warning: The right operand of '<' is a garbage value
   if (response && bytes < querytsig.siglen)
                         ^ ~~~~~~~~~~~~~~~~
tsig.c:1024:20: warning: Assigned value is garbage or undefined
   tsig.timesigned = querytsig.timesigned;
                   ^ ~~~~~~~~~~~~~~~~~~~~

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 22:01:41 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 06:01:41 +0000
Subject: [LLVMbugs] [Bug 14452] cannot #include <string> using trunk clang
	and libc++
In-Reply-To: <bug-14452-206@http.llvm.org/bugs/>
References: <bug-14452-206@http.llvm.org/bugs/>
Message-ID: <bug-14452-206-wcQZ2Orqrw@http.llvm.org/bugs/>

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

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

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

--- Comment #6 from Richard Smith <richard-llvm at metafoo.co.uk> 2012-11-30 00:01:41 CST ---
Fixed in r168853.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 29 22:19:58 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 06:19:58 +0000
Subject: [LLVMbugs] [Bug 14399] clang assertion since  r167353
In-Reply-To: <bug-14399-206@http.llvm.org/bugs/>
References: <bug-14399-206@http.llvm.org/bugs/>
Message-ID: <bug-14399-206-0jc0dH94Il@http.llvm.org/bugs/>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #6 from Eli Friedman <sharparrow1 at yahoo.com> 2012-11-30 00:19:58 CST ---
r168984.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 00:39:10 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 08:39:10 +0000
Subject: [LLVMbugs] [Bug 14462] New: false positive: Dereference of null
	pointer
Message-ID: <bug-14462-206@http.llvm.org/bugs/>

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

             Bug #: 14462
           Summary: false positive: Dereference of null pointer
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: marka at isc.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


The static analyser chooses to assign nodep to be NULL despite the caller
passing the address of variable on the stack so it can never be NULL on this
call path.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 02:53:46 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 10:53:46 +0000
Subject: [LLVMbugs] [Bug 14463] New: Assertion failed: (getResultKind() ==
 Found && "getFoundDecl called on non-unique result"), function getFoundDecl,
 file
 /usr/home/rdivacky/llvm/tools/clang/lib/Sema/../../include/clang/Sema/Lookup.h,
 line 432.
Message-ID: <bug-14463-206@http.llvm.org/bugs/>

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

             Bug #: 14463
           Summary: Assertion failed: (getResultKind() == Found &&
                    "getFoundDecl called on non-unique result"), function
                    getFoundDecl, file
                    /usr/home/rdivacky/llvm/tools/clang/lib/Sema/../../inc
                    lude/clang/Sema/Lookup.h, line 432.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


pes delta-2006.08.03$ cat getline.c
    typedef __ssize_t ssize_t;
     ssize_t getdelim(char ** restrict, size_t * restrict, int,      FILE *
restrict);
    ssize_t   getdelim (lineptr, n, delimiter, stream);
    ssize_t   getdelim (lineptr, n, delimiter, stream)      char **lineptr;
  {

pes delta-2006.08.03$ clang -fsyntax-only getline.c
getline.c:1:13: error: unknown type name '__ssize_t'
    typedef __ssize_t ssize_t;
            ^
getline.c:2:41: error: unknown type name 'size_t'
     ssize_t getdelim(char ** restrict, size_t * restrict, int,      FILE *
restrict);
                                        ^
getline.c:2:70: error: unknown type name 'FILE'
     ssize_t getdelim(char ** restrict, size_t * restrict, int,      FILE *
restrict);
                                                                     ^
getline.c:3:25: error: a parameter list without types is only allowed in a
function definition
    ssize_t   getdelim (lineptr, n, delimiter, stream);
                        ^
Assertion failed: (getResultKind() == Found && "getFoundDecl called on
non-unique result"), function getFoundDecl, file
/usr/home/rdivacky/llvm/tools/clang/lib/Sema/../../include/clang/Sema/Lookup.h,
line 432.
Stack dump:
0.      Program arguments: /usr/local/bin/clang -cc1 -triple
x86_64-unknown-freebsd8.2 -fsyntax-only -disable-free -main-file-name getline.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.15
-momit-leaf-frame-pointer -resource-dir /usr/local/bin/../lib/clang/3.3
-fmodule-cache-path /var/tmp/clang-module-cache -fdebug-compilation-dir
/tmp/delta-2006.08.03 -ferror-limit 19 -fmessage-length 115 -mstackrealign
-fobjc-runtime=gnustep -fdiagnostics-show-option -fcolor-diagnostics -x c
getline.c 
1.      getline.c:5:3: current parser token '{'
clang: error: unable to execute command: Abort trap: 6 (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.3 (trunk 168989)
Target: x86_64-unknown-freebsd8.2
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/getline-RjjXam.c
clang: note: diagnostic msg: /tmp/getline-RjjXam.sh
clang: note: diagnostic msg: 

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 05:22:51 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 13:22:51 +0000
Subject: [LLVMbugs] [Bug 14464] New: failed assertion `SS ==
 getCurFunction()->SwitchStack.back() && "switch stack missing push/pop!"'
Message-ID: <bug-14464-206@http.llvm.org/bugs/>

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

             Bug #: 14464
           Summary: failed assertion `SS ==
                    getCurFunction()->SwitchStack.back() && "switch stack
                    missing push/pop!"'
           Product: clang
           Version: 3.2
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: vince at macports.org
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


When I try to compile the ld64 (97.17) linker from Apple cctools on MacOS 10.4
(arch = ppc) I get the following error:


/opt/local/bin/clang++-mp-3.2 -Os -O2 -arch ppc
-I/opt/local/libexec/llvm-3.2/include -DLTO_SUPPORT -Isrc/abstraction -Isrc/ld
-I/opt/local/include  -c -o src/other/ObjectDump.o src/other/ObjectDump.cpp
In file included from src/other/ObjectDump.cpp:31:
In file included from src/ld/MachOReaderRelocatable.hpp:33:
In file included from /usr/include/c++/4.0.0/vector:65:
/usr/include/c++/4.0.0/bits/stl_algobase.h:64:10: fatal error:
'bits/c++config.h' file not found
#include <bits/c++config.h>
         ^
SemaStmt.cpp:625: failed assertion `SS == getCurFunction()->SwitchStack.back()
&& "switch stack missing push/pop!"'
Stack dump:
0.    Program arguments: /opt/local/libexec/llvm-3.2/bin/clang -cc1 -triple
powerpc-apple-darwin8.11.0 -S -disable-free -main-file-name ObjectDump.cpp
-pic-level 2 -mdisable-fp-elim -fmath-errno -target-linker-version 97.17
-coverage-file /tmp/ObjectDump-Jh3aJw.s -resource-dir
/opt/local/libexec/llvm-3.2/bin/../lib/clang/3.2 -D LTO_SUPPORT -I
/opt/local/libexec/llvm-3.2/include -I src/abstraction -I src/ld -I
/opt/local/include -fmodule-cache-path /var/tmp/clang-module-cache
-I/opt/local/include -O2 -fdeprecated-macro -fno-dwarf2-cfi-asm
-fno-dwarf-directory-asm -fdebug-compilation-dir
/opt/local/var/macports/build/_opt_local_var_macports_sources_rsync.macports.org_release_tarballs_ports_devel_ld64/ld64/work/ld64-97.17
-ferror-limit 19 -fmessage-length 0 -mstackrealign -fobjc-runtime=gcc
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -o
/tmp/ObjectDump-Jh3aJw.s -x c++ src/other/ObjectDump.cpp 
1.    src/ld/MachOReaderRelocatable.hpp:2469:4: current parser token '}'
2.    src/ld/MachOReaderRelocatable.hpp:62:1: parsing namespace 'mach_o'
3.    src/ld/MachOReaderRelocatable.hpp:63:1: parsing namespace 'relocatable'
4.    src/ld/MachOReaderRelocatable.hpp:1944:1: parsing function body
5.    src/ld/MachOReaderRelocatable.hpp:1944:1: in compound statement ('{}')
6.    src/ld/MachOReaderRelocatable.hpp:2410:81: in compound statement ('{}')
7.    src/ld/MachOReaderRelocatable.hpp:2415:28: in compound statement ('{}')
8.    src/ld/MachOReaderRelocatable.hpp:2428:9: in compound statement ('{}')
clang: error: unable to execute command: Abort trap
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (branches/release_32 168259)
Target: powerpc-apple-darwin8.11.0
Thread model: posix

Any idea to what it is related to?

TIA,
Vincent

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 09:36:42 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 17:36:42 +0000
Subject: [LLVMbugs] [Bug 14465] New: ICE: "bitwidth too large" assertion in
	SROA pass
Message-ID: <bug-14465-206@http.llvm.org/bugs/>

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

             Bug #: 14465
           Summary: ICE: "bitwidth too large" assertion in SROA pass
           Product: clang
           Version: 3.2
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: llvm-bugs at justinbogner.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9623
  --> http://llvm.org/bugs/attachment.cgi?id=9623
Preprocessed source

I have this function that stomps on the stack in some unit test code:

void
stomp_on_stack(void)
{
    /* I came up with this number through trial and error. */
    int stack[1024*1024];

    memset(stack, 0xFE, sizeof(stack));
}

This causes an assertion in clang with -O1 and -O2. The assertion occurs if the
size of the array is (1<<18) or greater, and this compiles with (1<<17).

Backtrace:

clang: /home/bognej/src/llvm/lib/VMCore/Type.cpp:306: static llvm::IntegerType
*llvm::IntegerType::get(llvm::LLVMContext &, unsigned int): Assertion `NumBits
<= MAX_INT_BITS && "bitwidth too large"' failed.
0  clang           0x0000000001d92a4f
1  clang           0x0000000001d92f33
2  libpthread.so.0 0x00007fe23ba43cb0
3  libc.so.6       0x00007fe23ac99445 gsignal + 53
4  libc.so.6       0x00007fe23ac9cbab abort + 379
5  libc.so.6       0x00007fe23ac9210e
6  libc.so.6       0x00007fe23ac921b2
7  clang           0x0000000001d3f01c
llvm::IntegerType::get(llvm::LLVMContext&, unsigned int) + 460
8  clang           0x0000000001a39f5f
9  clang           0x0000000001a36591
10 clang           0x0000000001d34a7b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 443
11 clang           0x0000000001d33ff8
llvm::FunctionPassManagerImpl::run(llvm::Function&) + 168
12 clang           0x0000000001d33eec
llvm::FunctionPassManager::run(llvm::Function&) + 108
13 clang           0x00000000007a5815
clang::EmitBackendOutput(clang::DiagnosticsEngine&, clang::CodeGenOptions
const&, clang::TargetOptions const&, clang::LangOptions const&, llvm::Module*,
clang::BackendAction, llvm::raw_ostream*) + 5557
14 clang           0x00000000007a342a
15 clang           0x00000000008d7545 clang::ParseAST(clang::Sema&, bool, bool)
+ 549
16 clang           0x00000000007a249c clang::CodeGenAction::ExecuteAction() +
204
17 clang           0x0000000000645b9a clang::FrontendAction::Execute() + 106
18 clang           0x0000000000627eed
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 989
19 clang           0x000000000060ea52
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3618
20 clang           0x0000000000605836 cc1_main(char const**, char const**, char
const*, void*) + 790
21 clang           0x000000000060adaa main + 3498
22 libc.so.6       0x00007fe23ac8476d __libc_start_main + 237
23 clang           0x0000000000605459
Stack dump:
0.      Program arguments: /home/bognej/local/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name ice.c
-mrelocation-model static -fmath-errno -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.22
-momit-leaf-frame-pointer -coverage-file /home/bognej/tmp/ice.o -resource-dir
/home/bognej/local/bin/../lib/clang/3.2 -fmodule-cache-path
/var/tmp/clang-module-cache -internal-isystem /usr/local/include
-internal-isystem /home/bognej/local/bin/../lib/clang/3.2/include
-internal-externc-isystem /usr/include/x86_64-linux-gnu
-internal-externc-isystem /include -internal-externc-isystem /usr/include -O2
-fdebug-compilation-dir /home/bognej/tmp -ferror-limit 19 -fmessage-length 106
-mstackrealign -fobjc-runtime=gcc -fdiagnostics-show-option -fcolor-diagnostics
-o ice.o -x c ice.c 
1.      <eof> parser at end of file
2.      Per-function optimization
3.      Running pass 'SROA' on function '@stomp_on_stack'
clang: error: unable to execute command: Aborted (core dumped)
clang: error: clang frontend command failed due to signal (use -v to see
invocation)
clang version 3.2 (http://llvm.org/git/clang.git
befd16738b89241b794e5ebfd02d0511f7e39f90) (http://llvm.org/git/llvm.git
f56817cfb593cb32d2fb84129fc31013bd9ac7f3)
Target: x86_64-unknown-linux-gnu
Thread model: posix
clang: note: diagnostic msg: PLEASE submit a bug report to
http://llvm.org/bugs/ and include the crash backtrace, preprocessed source, and
associated run script.
clang: note: diagnostic msg: 
********************

PLEASE ATTACH THE FOLLOWING FILES TO THE BUG REPORT:
Preprocessed source(s) and associated run script(s) are located at:
clang: note: diagnostic msg: /tmp/ice-Hg1JSe.c
clang: note: diagnostic msg: /tmp/ice-Hg1JSe.sh
clang: note: diagnostic msg: 

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 11:52:18 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 19:52:18 +0000
Subject: [LLVMbugs] [Bug 14466] New: pthread nptl lowlevellock.h fails to
 compile with macro expansion of inline assembly
Message-ID: <bug-14466-206@http.llvm.org/bugs/>

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

             Bug #: 14466
           Summary: pthread nptl lowlevellock.h fails to compile with
                    macro expansion of inline assembly
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sgs at redrocketcomputing.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Trying to compile uclibc 0.9.33 with nptl and see the following failure with
preprocessor expansion of inline assembly.

libc/misc/error/err.c:38:2: error: unknown directive
        __STDIO_AUTO_THREADLOCK(stderr);
        ^
./include/bits/uClibc_stdio.h:101:9: note: expanded from macro
'__STDIO_AUTO_THREADLOCK'
        __UCLIBC_IO_MUTEX_AUTO_LOCK((__stream)->__lock, __infunc_user_locking, 
\
        ^
./include/bits/uClibc_mutex.h:93:3: note: expanded from macro
'__UCLIBC_IO_MUTEX_AUTO_LOCK'
                __UCLIBC_IO_MUTEX_CONDITIONAL_LOCK(M,((A=(V))) == 0)
                ^
./include/bits/uClibc_mutex.h:84:3: note: expanded from macro
'__UCLIBC_IO_MUTEX_CONDITIONAL_LOCK'
                _IO_lock_lock(M);                                              
        \
                ^
./include/bits/stdio-lock.h:44:2: note: expanded from macro '_IO_lock_lock'
        lll_lock ((_name).lock, LLL_PRIVATE);                                 \
        ^
./libpthread/nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.h:296:25: note:
expanded from macro 'lll_lock'
         __asm__ __volatile__ (__lll_lock_asm_start                            
      \
                               ^
./libpthread/nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.h:289:19: note:
expanded from macro '__lll_lock_asm_start'
                              "jnz 1f\n\t"
                                       ^
<inline asm>:8:2: note: instantiated into assembly here
        .subsection 1
        ^
libc/misc/error/err.c:47:2: error: unknown directive
        __STDIO_AUTO_THREADUNLOCK(stderr);
        ^
./include/bits/uClibc_stdio.h:105:9: note: expanded from macro
'__STDIO_AUTO_THREADUNLOCK'
        __UCLIBC_IO_MUTEX_AUTO_UNLOCK((__stream)->__lock,
__infunc_user_locking)
        ^
./include/bits/uClibc_mutex.h:96:3: note: expanded from macro
'__UCLIBC_IO_MUTEX_AUTO_UNLOCK'
                __UCLIBC_IO_MUTEX_CONDITIONAL_UNLOCK(M,((A) == 0))
                ^
./include/bits/uClibc_mutex.h:89:3: note: expanded from macro
'__UCLIBC_IO_MUTEX_CONDITIONAL_UNLOCK'
                _IO_lock_unlock(M);                                            
        \
                ^
./include/bits/stdio-lock.h:74:2: note: expanded from macro '_IO_lock_unlock'
        lll_unlock ((_name).lock, LLL_PRIVATE);                               \
        ^
./libpthread/nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.h:466:25: note:
expanded from macro 'lll_unlock'
         __asm__ __volatile__ (__lll_unlock_asm_start                         \
                               ^
./libpthread/nptl/sysdeps/unix/sysv/linux/x86_64/lowlevellock.h:459:14: note:
expanded from macro '__lll_unlock_asm_start'
                                "jne 1f\n\t"
                                         ^
<inline asm>:8:2: note: instantiated into assembly here
        .subsection 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 Nov 30 12:06:22 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 20:06:22 +0000
Subject: [LLVMbugs] [Bug 14467] New: debug info types with no mentioned
	members
Message-ID: <bug-14467-206@http.llvm.org/bugs/>

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

             Bug #: 14467
           Summary: debug info types with no mentioned members
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: googler
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: dgregor at apple.com, llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


GCC produces debug info for member variables even when they're not directly
mentioned in the source:

struct foo {
  int i;
};

void func() {
  static foo* f = new foo();
}

GCC produces debug info for 'foo' (note: if you remove the nested type (& the
'n' static variable) GCC stops producing debug info for 'foo'), including the
unmentioned 'i' member.

Clang produces no debug info for 'foo' in the above example.
If you add code that mentions a member variable then all the member variables
are emitted.
If you add a nested type to 'foo' and then mention that type then debug info
for 'foo' (but not its member variable 'i') and 'foo::bar' are emitted.

This isn't strictly a bug, perhaps (hence filed as "enhancement") but fails the
GDB test suite. If this is resolved as "not a bug", please adjust the test
suite to be resilient to this (possibly by adding a reference to 'i' to cause
the debug info to be emitted).

GCC does emit the same kind of fieldless debug info (for the outer class) if
you instantiate the inner class but not the outer class. So that in and of
itself isn't necessarily wrong (or at least there is precedence for its
wrongness)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 12:47:49 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 20:47:49 +0000
Subject: [LLVMbugs] [Bug 14469] New: undefined reference to '__mulodi4'
Message-ID: <bug-14469-206@http.llvm.org/bugs/>

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

             Bug #: 14469
           Summary: undefined reference to '__mulodi4'
           Product: clang
           Version: 3.1
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: malex984 at gmail.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


Created attachment 9628
  --> http://llvm.org/bugs/attachment.cgi?id=9628
test

Multiplication of two "long long int" translates into the code that requires to
call missing function '__mulodi4' if compiled with -ftrapv -m32 (on 64 bit
linux)

Please compile the attached code with "clang -ftrapv -m32" (at least on a 64
bit machine).

Removing either "-ftrapv" or "-m32" will produce fine executable.

ps:
clang version 3.1 (branches/release_31)
Target: x86_64-unknown-linux-gnu

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 13:07:13 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 21:07:13 +0000
Subject: [LLVMbugs] [Bug 12281] Vector IR ICEs at
 lib/Target/ARM/ARMISelLowering.cpp:4816 with "unexpected types for extended
 operands to VMULL"
In-Reply-To: <bug-12281-206@http.llvm.org/bugs/>
References: <bug-12281-206@http.llvm.org/bugs/>
Message-ID: <bug-12281-206-jbnUil2vsE@http.llvm.org/bugs/>

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

David Peixotto <dpeixott at codeaurora.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |dpeixott at codeaurora.org
         Resolution|                            |FIXED

--- Comment #2 from David Peixotto <dpeixott at codeaurora.org> 2012-11-30 15:07:13 CST ---
Fixed in r169024.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 13:29:37 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 21:29:37 +0000
Subject: [LLVMbugs] [Bug 14471] New: debug info for static class members
Message-ID: <bug-14471-206@http.llvm.org/bugs/>

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

             Bug #: 14471
           Summary: debug info for static class members
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: googler
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: dgregor at apple.com, echristo at gmail.com,
                    llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


Clang does not produce debug info for static class members:

struct foo {
  int i;
  static int j;
};

unless they are defined in the TU. (ptype foo prints "struct foo { int i; };"
for the above code, even when both i and j are referenced, but j is not
defined)

"quality of implementation"

If this is resolved as "by design", the gdb 7.5 test suite should be updated to
account for that & pass rather than kfailing.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 13:51:39 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 21:51:39 +0000
Subject: [LLVMbugs] [Bug 14472] New: debug info for user specified copy ctor
 inside a template is missing 'const'
Message-ID: <bug-14472-206@http.llvm.org/bugs/>

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

             Bug #: 14472
           Summary: debug info for user specified copy ctor inside a
                    template is missing 'const'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: googler
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: dgregor at apple.com, echristo at gmail.com,
                    llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


If the copy ctor of a class template is written with the injected class name
(as in 'bar') the debug info for the copy ctor is correct (const bar<int>&). If
it is written with an explicit type (as in 'foo(const foo<int>&)') it is
incorrect (foo<int>&).

This shows up in the GDB 7.5 test suite, gdb.cp/templates.exp alongside
PR14471.


template<typename T>
struct foo {
    foo();
    foo(const foo<int>&);
};

foo<int> t;

template<typename T>
struct bar {
  bar();
  bar(const bar&);
};

bar<int> b;
(gdb) ptype foo<int>
type = struct foo<int> {
  public:
    void foo();
    void foo(foo<int> &);
}
(gdb) ptype bar<int>
type = struct bar<int> {
  public:
    void bar();
    void bar(const bar<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  Fri Nov 30 14:32:52 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 22:32:52 +0000
Subject: [LLVMbugs] [Bug 14473] New: Multiple breakpoints in class template
 member function definition
Message-ID: <bug-14473-206@http.llvm.org/bugs/>

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

             Bug #: 14473
           Summary: Multiple breakpoints in class template member function
                    definition
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: googler
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: dblaikie at gmail.com
                CC: dgregor at apple.com, echristo at gmail.com,
                    llvmbugs at cs.uiuc.edu
            Blocks: 14330
    Classification: Unclassified


Multiple breakpoints when breaking on foo<int>::foo in:

template<class T>
struct foo {
  foo(int);
  int val;
};

template<class T>
foo<T>::foo(int v) {
  val = v;
}

foo<int> x(3);

break foo<int>::foo
Breakpoint 1 at 0x53: foo<int>::foo. (2 locations)
(gdb) info breakpoints
Num     Type           Disp Enb Address            What
1       breakpoint     keep y   <MULTIPLE>         
1.1                         y     0x0000000000000053 in foo<int>::foo(int) at
type.cc:10
1.2                         y     0x0000000000000070 in foo<int>::foo(int) at
type.cc:8

(visible in gdb.cp/templates.exp in the GCC 7.5 test suite)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 14:43:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 22:43:17 +0000
Subject: [LLVMbugs] [Bug 14466] gas .subsection directive not implemented
In-Reply-To: <bug-14466-206@http.llvm.org/bugs/>
References: <bug-14466-206@http.llvm.org/bugs/>
Message-ID: <bug-14466-206-3dIi0B6e5A@http.llvm.org/bugs/>

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

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

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

--- Comment #5 from Benjamin Kramer <benny.kra at gmail.com> 2012-11-30 16:43:17 CST ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Nov 30 15:54:17 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 30 Nov 2012 23:54:17 +0000
Subject: [LLVMbugs] [Bug 14462] false positive: Dereference of null pointer
In-Reply-To: <bug-14462-206@http.llvm.org/bugs/>
References: <bug-14462-206@http.llvm.org/bugs/>
Message-ID: <bug-14462-206-UKmK3ZtrjO@http.llvm.org/bugs/>

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

Jordan Rose <jordan_rose at apple.com> changed:

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

--- Comment #9 from Jordan Rose <jordan_rose at apple.com> 2012-11-30 17:54:17 CST ---
Closing; we'll get better and better at inlining but won't be specifically
aiming to support 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 Nov 30 17:51:21 2012
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 01 Dec 2012 01:51:21 +0000
Subject: [LLVMbugs] [Bug 14474] New: Assertion failed:
 (CGM.getCodeGenOpts().getDebugInfo() >= CodeGenOptions::LimitedDebugInfo)
 with -gline-tables-only
Message-ID: <bug-14474-206@http.llvm.org/bugs/>

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

             Bug #: 14474
           Summary: Assertion failed: (CGM.getCodeGenOpts().getDebugInfo()
                    >= CodeGenOptions::LimitedDebugInfo) with
                    -gline-tables-only
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: glider at google.com
                CC: llvmbugs at cs.uiuc.edu
    Classification: Unclassified


$ cat mcam.ii
typedef signed char BOOL;
@class NSInvocation, NSMethodSignature, NSCoder, NSString, NSEnumerator;
@protocol NSObject - (BOOL)isEqual:(id)object;
@end
@protocol NSCoding - (void)encodeWithCoder:(NSCoder *)aCoder;
@end 
@interface NSObject <NSObject> {
}
@end    
@interface NSResponder : NSObject <NSCoding> { }
@end
@protocol NSValidatedUserInterfaceItem - (SEL)action;
@end
@protocol NSUserInterfaceValidations - (BOOL)validateUserInterfaceItem:(id
<NSValidatedUserInterfaceItem>)anItem;
@end
@interface NSRunningApplication : NSObject { }
@end
@interface NSApplication : NSResponder <NSUserInterfaceValidations> { }
@end
@implementation MockCrApp + (NSApplication*)sharedApplication { }
@end
=========================================================================
$ clang -cc1 -triple i386-apple-macosx10.6.0 -emit-obj -mdisable-fp-elim
-gline-tables-only -w -fblocks -fno-threadsafe-statics -x objective-c++ mcam.ii 
Assertion failed: (CGM.getCodeGenOpts().getDebugInfo() >=
CodeGenOptions::LimitedDebugInfo), function getOrCreateInterfaceType, file
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/lib/CodeGen/CGDebugInfo.cpp,
line 1218.
0  clang             0x00000001016d4b45 PrintStackTrace(void*) + 37
1  clang             0x00000001016d4f54 SignalHandler(int) + 564
2  libsystem_c.dylib 0x00007fff8c3d68ea _sigtramp + 26
3  clang             0x0000000100044013 llvm::StringMap<llvm::Value*,
llvm::MallocAllocator>::insert(llvm::StringMapEntry<llvm::Value*>*) + 83
4  clang             0x000000010004faf6 abort + 22
5  clang             0x000000010004fad1 __assert_rtn + 81
6  clang             0x0000000100219bb0
clang::CodeGen::CGDebugInfo::CreateType(clang::RecordType const*) + 0
7  clang             0x00000001002d58dc
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 668
8  clang             0x00000001002f263f (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 95
9  clang             0x00000001002c3a05
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 165
10 clang             0x0000000100300e73 clang::ParseAST(clang::Sema&, bool,
bool) + 419
11 clang             0x00000001002c29ea clang::CodeGenAction::ExecuteAction() +
458
12 clang             0x00000001000b2938 clang::FrontendAction::Execute() + 104
13 clang             0x000000010009446d
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 941
14 clang             0x000000010005a61a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3450
15 clang             0x0000000100052c48 cc1_main(char const**, char const**,
char const*, void*) + 840
16 clang             0x0000000100056e75 main + 3077
17 clang             0x00000001000528d4 start + 52
Stack dump:
0.      Program arguments:
/Users/glider/src/chrome-commit/src/third_party/llvm-build/Release+Asserts/bin/clang
-cc1 -triple i386-apple-macosx10.6.0 -emit-obj -mdisable-fp-elim
-gline-tables-only -w -fblocks -fno-threadsafe-statics -x objective-c++ mcam.ii 

Everything is fine if I replace -gline-tables-only with -g.

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