From bugzilla-daemon at llvm.org  Wed Jun  1 02:31:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 02:31:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10058] New: C standard incompatibility concerning
 untyped functions (and varargs)
Message-ID: <bug-10058-206@http.llvm.org/bugs/>

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

           Summary: C standard incompatibility concerning untyped
                    functions (and varargs)
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hranac.bz at email.cz
                CC: llvmbugs at cs.uiuc.edu


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

Pre-standard function definitions (with untyped parameters - e.g. "foo(a,b)
{...}") are processed in a wrong and inconsistent way.

Translate the attached C file with the following command:
clang example.c -emit-llvm -S
When you look at the resulting ll file (in the second attachment), you will see
that the definitions of the functions f1-f6 are all right and as expected
(everything defaults to integer). However, they are used (in the function main)
as if they were variadic. This behaviour is in contradiction with C standard
(functions are variadic only if explicitly declared and/or defined as such).

This (probably) happens during the LLVM IR generation (hence the component
"LLVM Codegen" was set instead of "Frontend").

Note: I understand that this is probably a "feature".
Also, it is easy for a backend to deal with this. However, let's say that you
are using clang for something else (let's say, semantics extraction) and you
need a correct result.

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

From bugzilla-daemon at llvm.org  Wed Jun  1 02:45:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 02:45:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10057] leftover temporaries in function
In-Reply-To: <bug-10057-206@http.llvm.org/bugs/>
References: <bug-10057-206@http.llvm.org/bugs/>
Message-ID: <20110601074556.CC43E2A6C12C@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

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

--- Comment #2 from Nick Lewycky <nicholas at mxc.ca> 2011-06-01 02:45:56 CDT ---
Fixed in r132390.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  1 08:02:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 08:02:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10059] New: UNREACHABLE executed at
	X86InstrInfo.cpp:2020
Message-ID: <bug-10059-206@http.llvm.org/bugs/>

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

           Summary: UNREACHABLE executed at X86InstrInfo.cpp:2020
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: hans at chromium.org
                CC: llvmbugs at cs.uiuc.edu


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

Trying to compile the attached program with "clang++ -c -O2 fail.ii" on Linux
causes the stack trace below.

It seems this started with LLVM r132358. This breaks the Chromium build.

Unknown regclass
UNREACHABLE executed at X86InstrInfo.cpp:2020!
0  clang           0x000000000190533f
1  clang           0x00000000019075b2
2  libpthread.so.0 0x00007f71281c38f0
3  libc.so.6       0x00007f71274b2a75 gsignal + 53
4  libc.so.6       0x00007f71274b65c0 abort + 384
5  clang           0x00000000018efc92 llvm::llvm_unreachable_internal(char
const*, char const*, unsigned int) + 354
6  clang           0x0000000001248227
7  clang           0x000000000124b047
llvm::X86InstrInfo::storeRegToStackSlot(llvm::MachineBasicBlock&,
llvm::ilist_iterator<llvm::MachineInstr>, unsigned int, bool, int,
llvm::TargetRegisterClass const*, llvm::TargetRegisterInfo const*) const + 151
8  clang           0x000000000154fec0
9  clang           0x0000000001550721
10 clang           0x0000000001554352
11 clang           0x00000000014a39de
12 clang           0x000000000159cf22 llvm::RegAllocBase::allocatePhysRegs() +
594
13 clang           0x000000000149b554
14 clang           0x000000000184ef0b
llvm::FPPassManager::runOnFunction(llvm::Function&) + 587
15 clang           0x000000000184f00b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
16 clang           0x00000000018505e7
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
17 clang           0x000000000185077b llvm::PassManagerImpl::run(llvm::Module&)
+ 187
18 clang           0x00000000007c1f3f
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 1807
19 clang           0x00000000007bf51b
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
20 clang           0x00000000008f17ed clang::ParseAST(clang::Sema&, bool) + 413
21 clang           0x00000000007be7e4 clang::CodeGenAction::ExecuteAction() +
68
22 clang           0x00000000006a7233
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
23 clang           0x00000000006816c4
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1268
24 clang           0x0000000000677d48 cc1_main(char const**, char const**, char
const*, void*) + 760
25 clang           0x0000000000680580 main + 7040
26 libc.so.6       0x00007f712749dc4d __libc_start_main + 253
27 clang           0x0000000000676179
Stack dump:
0.    Program arguments: /usr/local/google/work/llvm/Release+Asserts/bin/clang
-cc1 -triple x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name
fail.ii -mrelocation-model static -mdisable-fp-elim -masm-verbose
-mconstructor-aliases -munwind-tables -target-cpu x86-64 -target-linker-version
2.20.1 -momit-leaf-frame-pointer -coverage-file fail.o -resource-dir
/usr/local/google/work/llvm/Release+Asserts/bin/../lib/clang/3.0 -O2
-fdeprecated-macro -ferror-limit 19 -fmessage-length 102 -fcxx-exceptions
-fexceptions -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o
fail.o -x c++-cpp-output fail.ii 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'fail.ii'.
4.    Running pass 'Greedy Register Allocator' on function
'@_Z18softlight_modeprocjj'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (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 Jun  1 09:01:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 09:01:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10060] New: Overloaded operator new[] gets a wrong
 argument value
Message-ID: <bug-10060-206@http.llvm.org/bugs/>

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

           Summary: Overloaded operator new[] gets a wrong argument value
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: mikhail.kalugin at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


== Steps to reproduce (you can find the complete source code in the
attachment.):
1. Overload operator new[]:

inline void * operator new[] (std::size_t size) throw(std::bad_alloc) {
    printf("new[] was called with size = %lu\n", size);
    return NULL;
}

2. Allocate an array, where array size is a variable:

std::size_t cnt = 7;    
int * a = new int[cnt]; 

== Expected behavior:
"new[] was called with size = 28" is printed

== Actual behavior:
"new[] was called with size = 4294967295" is printed. With real new[]
implementation this causes a crash. What's interesting: if we use a constant as
the size of array, it works fine. 


== Environment:
Apple's build of clang from XCode 4.0.2 is used. Here's "clang++ --version"'s
output:

Apple clang version 2.0 (tags/Apple/clang-139) (based on LLVM 2.9svn) 
Target: x86_64-apple-darwin10
Thread model: posix

The bug appears only on armv6 target architecture ? I'm executing the app on
iPhone 2G with iOS 3.1.3. Everything is fine on armv7 devices.

Here's the command line used by XCode:

/Xcode4/Platforms/iPhoneOS.platform/Developer/usr/bin/clang -x c++ -arch armv6
-fmessage-length=0 -fdiagnostics-print-source-range-info
-fdiagnostics-show-category=id -fdiagnostics-parseable-fixits -Wno-trigraphs
-fpascal-strings -O0 -Wreturn-type -Wparentheses -Wswitch -Wno-unused-parameter
-Wunused-variable -Wunused-value -DDEBUG -isysroot
/Xcode4/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.3.sdk -gdwarf-2
-fvisibility-inlines-hidden -mthumb -miphoneos-version-min=3.0 -iquote
/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Intermediates/newop.build/Debug-iphoneos/newop.build/newop-generated-files.hmap
-I/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Intermediates/newop.build/Debug-iphoneos/newop.build/newop-own-target-headers.hmap
-I/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Intermediates/newop.build/Debug-iphoneos/newop.build/newop-all-target-headers.hmap
-iquote
/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Intermediates/newop.build/Debug-iphoneos/newop.build/newop-project-headers.hmap
-I/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Products/Debug-iphoneos/include
-I/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Intermediates/newop.build/Debug-iphoneos/newop.build/DerivedSources/armv6
-I/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Intermediates/newop.build/Debug-iphoneos/newop.build/DerivedSources
-F/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Products/Debug-iphoneos
-c /Users/fourdman/Documents/Projects/Yandex/newop/newop/main.cpp -o
/Users/fourdman/Library/Developer/Xcode/DerivedData/newop-ccwnmiceftmdgfeedfcpbcaktxjp/Build/Intermediates/newop.build/Debug-iphoneos/newop.build/Objects-normal/armv6/main.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 Jun  1 09:31:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 09:31:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10061] New: chain-empty-initial-namespace fails
	unit testing
Message-ID: <bug-10061-206@http.llvm.org/bugs/>

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

           Summary: chain-empty-initial-namespace fails unit testing
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: apacherulzz at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Yesterday morning I built everything from over the weekend and all tests passed
(except hello.c, filled a separate bug for that). This morning I checked out
trunk and built. When running unit testing chain-empty-initial-namespace fails.

llvm[0]: Running test suite
make[1]: Entering directory `/opt/llvm/build/test'
Making a new site.exp file...
Making LLVM unittest 'lit.site.cfg' file...
make -C /opt/llvm/build/test/../tools/clang/test lit.site.cfg Unit/lit.site.cfg
make[2]: Entering directory `/opt/llvm/build/tools/clang/test'
Making Clang 'lit.site.cfg' file...
Making Clang 'Unit/lit.site.cfg' file...
Making LLVM 'lit.site.cfg' file...
make[2]: Leaving directory `/opt/llvm/build/tools/clang/test'
( ulimit -t 600 ; ulimit -d 512000 ; ulimit -m 512000 ; ulimit -v 1024000 ; \
      /opt/llvm/llvm/utils/lit/lit.py -s -v .
/opt/llvm/build/test/../tools/clang/test )
lit.py: lit.cfg:143: note: using clang:
'/opt/llvm/build/Release+Asserts/bin/clang'
FAIL: Clang :: Driver/hello.c (1387 of 9215)
******************** TEST 'Clang :: Driver/hello.c' FAILED ********************
Script:
--
/opt/llvm/build/Release+Asserts/bin/clang  -ccc-echo -o
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.exe
/opt/llvm/llvm/tools/clang/test/Driver/hello.c 2>
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.log
grep 'clang\(-[0-9.]\+\)\?\(\.[Ee][Xx][Ee]\)\?" -cc1 .*hello.c'
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.log
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.exe >
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.out
grep "I'm a little driver, short and stout."
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.out
--
Exit Code: 1

********************
FAIL: Clang :: PCH/chain-empty-initial-namespace.cpp (1612 of 9215)
******************** TEST 'Clang :: PCH/chain-empty-initial-namespace.cpp'
FAILED ********************
Script:
--
/opt/llvm/build/Release+Asserts/bin/clang -cc1 -include
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp -include
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
-fsyntax-only
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
/opt/llvm/build/Release+Asserts/bin/clang -cc1 -chain-include
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
-chain-include
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
-fsyntax-only
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
--
Exit Code: 134
Command Output (stderr):
--
clang: /opt/llvm/llvm/lib/Support/raw_ostream.cpp:323: void
llvm::raw_ostream::copy_to_buffer(const char*, size_t): Assertion `Size <=
size_t(OutBufEnd - OutBufCur) && "Buffer overrun!"' failed.
0  clang 0x09651fb8
Stack dump:
0.    Program arguments: /opt/llvm/build/Release+Asserts/bin/clang -cc1
-chain-include
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
-chain-include
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
-fsyntax-only
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp 
1.    <eof> parser at end of file
/opt/llvm/build/tools/clang/test/PCH/Output/chain-empty-initial-namespace.cpp.script:
line 2:  9099 Aborted                 /opt/llvm/build/Release+Asserts/bin/clang
-cc1 -chain-include
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
-chain-include
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
-fsyntax-only
/opt/llvm/llvm/tools/clang/test/PCH/chain-empty-initial-namespace.cpp
--

********************
Testing Time: 189.84s
********************
Failing Tests (2):
    Clang :: Driver/hello.c
    Clang :: PCH/chain-empty-initial-namespace.cpp

  Expected Passes    : 8597
  Expected Failures  : 67
  Unsupported Tests  : 549
  Unexpected Failures: 2
make[1]: *** [check-local-all] Error 1
make[1]: Leaving directory `/opt/llvm/build/test'
make: *** [check-all] Error 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 Jun  1 10:15:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 10:15:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10052] Comparision of pointer to Objective-C object
 with C++0x nullptr fails to compile
In-Reply-To: <bug-10052-206@http.llvm.org/bugs/>
References: <bug-10052-206@http.llvm.org/bugs/>
Message-ID: <20110601151538.289CB2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-01 10:15:37 CDT ---
Fixed in Clang r132397.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  1 10:50:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 10:50:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10059] UNREACHABLE executed at X86InstrInfo.cpp:2020
In-Reply-To: <bug-10059-206@http.llvm.org/bugs/>
References: <bug-10059-206@http.llvm.org/bugs/>
Message-ID: <20110601155056.9231C2A6C12C@llvm.org>

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

Jakob Stoklund Olesen <stoklund at 2pi.dk> 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 Jun  1 11:05:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 11:05:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10043] Failure to warn about inaccessible copy
 constructor of member of class in -Wbind-to-temporary-copy
In-Reply-To: <bug-10043-206@http.llvm.org/bugs/>
References: <bug-10043-206@http.llvm.org/bugs/>
Message-ID: <20110601160522.5467C2A6C12C@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-01 11:05:21 CDT ---
g(Y()) doesn't warn in C++98 mode, and never did, because implicitly-declared
copy constructors are always public. We would only detect a problem if we went
ahead and caused the copy constructor to be implicitly defined, but at that
point it's going to be fairly tricky to avoid getting a hard error later on
down the line.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  1 11:15:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 11:15:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10060] Calling new[] with a variable size causes a
 crash (was: overloaded operator new[] gets a wrong argument value)
In-Reply-To: <bug-10060-206@http.llvm.org/bugs/>
References: <bug-10060-206@http.llvm.org/bugs/>
Message-ID: <20110601161550.E8A5F2A6C12D@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #3 from Eric Christopher <echristo at gmail.com> 2011-06-01 11:15:50 CDT ---
I fixed this a while ago in ToT and it should make its way into Xcode soon (if
it isn't there already):

/Volumes/Data/builds/build-llvm/Debug+Asserts/bin/clang++ -arch armv6 -O0
-mthumb main.cpp -isysroot
/Developer/Platforms/iPhoneOS.platform/Developer/SDKs/iPhoneOS4.2.sdk
-miphoneos-version-min=4.2

new[] was called with size = 28
a = 0x0
new[] was called with size = 28
b = 0x0

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  1 16:31:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 16:31:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10058] C standard incompatibility concerning
 untyped functions (and varargs)
In-Reply-To: <bug-10058-206@http.llvm.org/bugs/>
References: <bug-10058-206@http.llvm.org/bugs/>
Message-ID: <20110601213151.DC7A02A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-01 16:31:51 CDT ---
Yes, it's a "feature"; we do it for the sake of compatibility.  And it isn't
incompatible with the C standard in that the C standard doesn't directly say
anything about how LLVM IR represents function calls.

If you need help using the LLVM APIs to detect cases like this (it isn't too
hard), please email llvmdev.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  1 17:38:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 17:38:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10062] New: llvm doesn't merge masked loads
Message-ID: <bug-10062-206@http.llvm.org/bugs/>

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

           Summary: llvm doesn't merge masked loads
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu, scshunt at csclub.uwaterloo.ca


This is related to bug 5039 but is specifically concerned with cases where LLVM
should be able to merge the loads/tests across multiple fields. A patch in
development would put this sort of optimizable logic in clang's hot path, so we
took a look at what sort of code LLVM would generate for it. Testcase:

  struct Foo {
    unsigned char foo : 5;
    unsigned char bar : 3;
  };

  int test1(struct Foo foo) {
    // should be a single comparison
    return foo.foo == 3 && foo.bar == 3;
  }

  int test2(struct Foo foo) {
    // should be a single comparison
    return foo.foo != 0 || foo.bar != 0;
  }

  int test3(struct Foo foo) {
    // should be a single cast
    return foo.bar + (foo.foo << 3);
  }

test1 has an entire branch which looks like the same problem as bug 10054.
test2 and test3 are straight-line code with no optimization opportunities taken
advantage of.

For reference, GCC 4.6 produces:

test1:
        xorl    %eax, %eax
        cmpb    $99, %dil
        sete    %al
        ret

test2:
        xorl    %eax, %eax
        testb   %dil, %dil
        setne   %al
        ret

test3:
        movl    %edi, %eax
        andl    $31, %edi
        shrb    $5, %al
        movzbl  %al, %eax
        leal    (%rax,%rdi,8), %eax
        ret

with a missed optimization in test3.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  1 18:03:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  1 Jun 2011 18:03:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10063] New: Problems with 'switch' and destructors
 in control flow graph
Message-ID: <bug-10063-206@http.llvm.org/bugs/>

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

           Summary: Problems with 'switch' and destructors in control flow
                    graph
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthewbg at google.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

The attached file has a number of testcases which should not trigger
-Wreturn-type. In all cases, control enters a switch statement with no cases
but 'default', and the default case instantiates an object with a noreturn
destructor. We get it right in a few cases, but not all:

$ clang -fsyntax-only -Wreturn-type ~/testcases/noreturn_dtor_switch.cc 
/home/matthewbg/testcases/noreturn_dtor_switch.cc:24:1: warning: control
reaches end of non-void function [-Wreturn-type]
} // 2
^
/home/matthewbg/testcases/noreturn_dtor_switch.cc:46:1: warning: control
reaches end of non-void function [-Wreturn-type]
} // 5
^
/home/matthewbg/testcases/noreturn_dtor_switch.cc:54:1: warning: control
reaches end of non-void function [-Wreturn-type]
} // 6
^
/home/matthewbg/testcases/noreturn_dtor_switch.cc:62:1: warning: control
reaches end of non-void function [-Wreturn-type]
} // 7
^
/home/matthewbg/testcases/noreturn_dtor_switch.cc:70:1: warning: control
reaches end of non-void function [-Wreturn-type]
} // 8
^
5 warnings generated.

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

From bugzilla-daemon at llvm.org  Thu Jun  2 05:58:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 05:58:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10064] New: Clang doesn't know about Debian
	wheezy/sid
Message-ID: <bug-10064-206@http.llvm.org/bugs/>

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

           Summary: Clang doesn't know about Debian wheezy/sid
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: themiwi at users.sourceforge.net
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6674)
 --> (http://llvm.org/bugs/attachment.cgi?id=6674)
Patch adding Debian wheezy/sid handling

In lib/Driver/ToolChains.cpp the enum and detection for Debian wheezy/sid is
missing.

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

From bugzilla-daemon at llvm.org  Thu Jun  2 09:23:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 09:23:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10065] New: Bogus pedantic warning when using
 offsetof(type, field[n])
Message-ID: <bug-10065-206@http.llvm.org/bugs/>

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

           Summary: Bogus pedantic warning when using offsetof(type,
                    field[n])
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rb at ravenbrook.com
                CC: llvmbugs at cs.uiuc.edu


If you use an expression like

  offsetof(struct hello_s, stuff[99])

when compiling with -ansi -pedantic, you get a warning "using extended field
designator is an extension".  The C89 standard says:

"The member-designator shall be such that given

         static  type t;

then the expression &(t.  member-designator ) evaluates to an address
constant."

I can't find anything which says this is any kind of extension.  And,  for what
it's worth, gcc's pedantic mode doesn't complain.

Test code 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 Jun  2 09:32:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 09:32:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10061] chain-empty-initial-namespace fails unit
	testing
In-Reply-To: <bug-10061-206@http.llvm.org/bugs/>
References: <bug-10061-206@http.llvm.org/bugs/>
Message-ID: <20110602143239.9B4CA2A6C124@llvm.org>

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

apacherulzz at yahoo.com changed:

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

--- Comment #1 from apacherulzz at yahoo.com 2011-06-02 09:32:39 CDT ---
Just updated trunk this morning, recompiled and made check-all. The error
message has gone away so I believe the bug to be fixed. Closing this 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 Jun  2 10:33:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 10:33:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10066] New: Greedy allocator fails to fold a memory
 operand when spilling
Message-ID: <bug-10066-206@http.llvm.org/bugs/>

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

           Summary: Greedy allocator fails to fold a memory operand when
                    spilling
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sergey.galanov at intel.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6676)
 --> (http://llvm.org/bugs/attachment.cgi?id=6676)
LLVM IR source

Hi. 

The code produced for the test in attachment is worse with the greedy allocator
than it was with the linear scan allocator (note that the test is compiled with
-disable-fp-elim option).

The test is a pair of nested loops. The outer loop counter (in vreg17) is
spilled on x86 but despite being used only once (for decrementing) stack slot
is not folded into the instruction. This happens because vreg17 is first split
into two registers (vreg54 and vreg53). Physical register is allocated for the
first one and the second one is spilled, so at that point it is not possible to
fold the memory operand unless it is somehow known that the two registers
originated from a common one.

Seems that greedy allocator is too greedy at splitting the intervals :) This
might not be a problem for a RISC architecture but it is not very good for
CISC.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 11:14:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 11:14:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10041] add support for -fgnu89-inline
In-Reply-To: <bug-10041-206@http.llvm.org/bugs/>
References: <bug-10041-206@http.llvm.org/bugs/>
Message-ID: <20110602161408.C1AE52A6C12E@llvm.org>

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

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> 2011-06-02 11:14:08 CDT ---
Fixed in 132460

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 11:40:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 11:40:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10067] New: clang miscompiles MipsISelLowering.cpp
 on i386-linux.
Message-ID: <bug-10067-206@http.llvm.org/bugs/>

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

           Summary: clang miscompiles MipsISelLowering.cpp on i386-linux.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: benny.kra at gmail.com
                CC: llvmbugs at cs.uiuc.edu


See
http://google1.osuosl.org:8011/builders/clang-i686-linux-selfhost-rel/builds/18

Attached is a standalone c++ test case that shows the problem. It's not visible
on darwin or x86_64-linux though.

$  clang++ v.cc && ./a.out
DEADBEEF
$ clang++ -O1 v.cc && ./a.out
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 Jun  2 14:08:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 14:08:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10068] New: Assertion `Num < NumOperands &&
 "Invalid child # of SDNode!"
Message-ID: <bug-10068-206@http.llvm.org/bugs/>

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

           Summary: Assertion `Num < NumOperands && "Invalid child # of
                    SDNode!"
           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: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

/home/espindola/tmpfs/build/bin/llc test.ll
llc: /home/espindola/llvm/llvm/include/llvm/CodeGen/SelectionDAGNodes.h:514:
const llvm::SDValue &llvm::SDNode::getOperand(unsigned int) const: Assertion
`Num < NumOperands && "Invalid child # of SDNode!"' failed.
Stack dump:
0.    Program arguments: /home/espindola/tmpfs/build/bin/llc test.ll 
1.    Running pass 'Function Pass Manager' on module 'test.ll'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function '@foobar'

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 15:03:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 15:03:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10065] Bogus pedantic warning when using
 offsetof(type, field[n])
In-Reply-To: <bug-10065-206@http.llvm.org/bugs/>
References: <bug-10065-206@http.llvm.org/bugs/>
Message-ID: <20110602200333.673B62A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-02 15:03:32 CDT ---
"[...] expands to an integer constant expression that has type size_t, the
value of which is the offset in bytes, to the structure member (designated by
member-designator), from the beginning of its structure (designated by type)."

"stuff[99]" is not a "structure member"; it's part of an expression indexing
into a struct.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 15:03:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 15:03:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10068] Assertion `Num < NumOperands && "Invalid
 child # of SDNode!"
In-Reply-To: <bug-10068-206@http.llvm.org/bugs/>
References: <bug-10068-206@http.llvm.org/bugs/>
Message-ID: <20110602200337.24B152A6C132@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

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

--- Comment #3 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-06-02 15:03:36 CDT ---
Fixed by reverting 132424.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 15:14:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 15:14:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10069] New: Clang incorrectly reports substitution
 failure with default template arguments in function template
Message-ID: <bug-10069-206@http.llvm.org/bugs/>

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

           Summary: Clang incorrectly reports substitution failure with
                    default template arguments in function template
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Keywords: compile-fail
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jbytheway+llvm at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This is a case reduced from code in libstdc++ (as shipped with gcc 4.5.2).

The following code, which I believe is valid:

template<typename T, T a, T b=0, T c=1>
T f(T x)
{
  return x;
}

int main()
{
  f<unsigned int, 0>(0);
  return 0;
}

generates the following error when given to clang++ -std=gnu++0x:

template-int.cpp:9:3: error: no matching function for call to 'f'
  f<unsigned int, 0>(0);
  ^~~~~~~~~~~~~~~~~~
template-int.cpp:2:3: note: candidate template ignored: substitution failure
      [with T = unsigned int, a = 0, b = 0]
T f(T x)
  ^
1 error generated.

gcc 4.5.2 accepts this code.  Note that if you replace 'unsigned int' by just
'int' then it compiles fine.  Also, if the fourth template argument of f is
removed, then it compiles fine.

$ clang++ --version
clang version 3.0 (trunk 132479)
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  Thu Jun  2 16:25:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 16:25:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10067] clang miscompiles MipsISelLowering.cpp on
	i386-linux.
In-Reply-To: <bug-10067-206@http.llvm.org/bugs/>
References: <bug-10067-206@http.llvm.org/bugs/>
Message-ID: <20110602212534.0768B2A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #5 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-02 16:25:33 CDT ---
r132485.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 16:37:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 16:37:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10064] Clang doesn't know about Debian wheezy/sid
In-Reply-To: <bug-10064-206@http.llvm.org/bugs/>
References: <bug-10064-206@http.llvm.org/bugs/>
Message-ID: <20110602213723.7B8F52A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-02 16:37:23 CDT ---
r132489.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 19:50:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 19:50:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10056] PassManager segfault when trying to schedule
 custom Immutable Pass
In-Reply-To: <bug-10056-206@http.llvm.org/bugs/>
References: <bug-10056-206@http.llvm.org/bugs/>
Message-ID: <20110603005022.E83552A6C124@llvm.org>

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

Andrew Trick <atrick at apple.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|ASSIGNED                    |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|unassignedbugs at nondot.org   |atrick at apple.com

--- Comment #3 from Andrew Trick <atrick at apple.com> 2011-06-02 19:50:22 CDT ---
Basic assertions should do the trick. Fixed in r132520.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 22:00:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 22:00:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10069] Clang incorrectly reports substitution
 failure with default template arguments in function template
In-Reply-To: <bug-10069-206@http.llvm.org/bugs/>
References: <bug-10069-206@http.llvm.org/bugs/>
Message-ID: <20110603030015.BB11E2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-02 22:00:15 CDT ---
Fixed in Clang r132529.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 22:02:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 22:02:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8650] no implicit conversion in template values
In-Reply-To: <bug-8650-206@http.llvm.org/bugs/>
References: <bug-8650-206@http.llvm.org/bugs/>
Message-ID: <20110603030226.F01122A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-06-02 22:02:26 CDT ---
This is fixed in top-of-tree Clang.

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

From bugzilla-daemon at llvm.org  Thu Jun  2 22:35:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 22:35:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7985] clang ignores candidate template
In-Reply-To: <bug-7985-206@http.llvm.org/bugs/>
References: <bug-7985-206@http.llvm.org/bugs/>
Message-ID: <20110603033545.9C8142A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2011-06-02 22:35:44 CDT ---
Fixed in Clang r132530.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  2 23:19:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  2 Jun 2011 23:19:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10070] New: Needless sse spill/reload
Message-ID: <bug-10070-206@http.llvm.org/bugs/>

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

           Summary: Needless sse spill/reload
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jmuizelaar at mozilla.com
                CC: llvmbugs at cs.uiuc.edu


The following code:

#include <math.h>
class gfxRect {
        double x;
        double y;
        double width;
        double height;

        void RoundOut();
};
void gfxRect::RoundOut()        {
                double x0 = floor(x);
                double y0 = floor(y);
                double x1 = ceil(x+width);
                double y1 = ceil(y+height);

                x = x0;
                y = y0;

                width = x1 - x0;
                height = y1 - y0;
        }

compiles to the following with a needless spill/reload at the end:

        movq    %rdi, %rbx
        movsd   (%rbx), %xmm0
        callq   _floor
        movsd   %xmm0, -32(%rbp)        ## 8-byte Spill
        movsd   8(%rbx), %xmm0
        callq   _floor
        movsd   %xmm0, -24(%rbp)        ## 8-byte Spill
        movsd   (%rbx), %xmm0
        addsd   16(%rbx), %xmm0
        callq   _ceil
        movsd   %xmm0, -16(%rbp)        ## 8-byte Spill
        movsd   8(%rbx), %xmm0
        addsd   24(%rbx), %xmm0
        callq   _ceil
        movsd   -32(%rbp), %xmm3        ## 8-byte Reload
        movsd   %xmm3, (%rbx)
        movsd   -24(%rbp), %xmm2        ## 8-byte Reload
        movsd   %xmm2, 8(%rbx)
        movsd   -16(%rbp), %xmm1        ## 8-byte Reload
        subsd   %xmm3, %xmm1

        movsd   %xmm1, -16(%rbp)        ## 8-byte Spill
        movsd   -16(%rbp), %xmm1        ## 8-byte Reload
here ----^
        movsd   %xmm1, 16(%rbx)
        subsd   %xmm2, %xmm0
        movsd   %xmm0, 24(%rbx)
        addq    $24, %rsp
        popq    %rbx
        popq    %rbp
        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  Fri Jun  3 00:24:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 00:24:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10071] New: Assertion in codegen
Message-ID: <bug-10071-206@http.llvm.org/bugs/>

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

           Summary: Assertion in codegen
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: asl at math.spbu.ru
                CC: llvmbugs at cs.uiuc.edu


Consider the following testcase:

struct Foo {
  union {
    struct {
      unsigned char padding1[3];
      struct { } bar;
    };
  };
  Foo() { }
};

struct __attribute__((__aligned__((16)))) Bar {
  Foo m_subData;
};

Bar __attribute__((__aligned__((128)))) Baz[50];

We're having:

clang++ testcase.cpp 
Assertion failed: (Ty && "Invalid GetElementPtrInst indices for type!"),
function checkType, file
/Users/asl/Projects/llvm/src/include/llvm/Instructions.h, line 278.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 00:41:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 00:41:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10072] New: Necessary 'indirectbr' instruction is
 optimized away
Message-ID: <bug-10072-206@http.llvm.org/bugs/>

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

           Summary: Necessary 'indirectbr' instruction is optimized away
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Loop Optimizer
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: yuri at tsoft.com
                CC: llvmbugs at cs.uiuc.edu


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

Please run the attached testcase (shar shell archive) with the current trunk
version of llvm.

It will create the original module mod.ll. It will also optimize it into
mod-o.ll.
indirectbr instruction in question is missing from mod-o.ll.
This instruction is necessary because it depends on the return value of
undefined function xselectorx().

As a result mod-o.ll is wrong (not equivalent to mod.ll).

I observe the problem with the today's revision 132525 and with the older
revision 128446. I know this didn't happen with the code from few months 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  Fri Jun  3 01:27:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 01:27:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10031] crash when building with -O3
In-Reply-To: <bug-10031-206@http.llvm.org/bugs/>
References: <bug-10031-206@http.llvm.org/bugs/>
Message-ID: <20110603062733.E15522A6C130@llvm.org>

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

Nick Lewycky <nicholas at mxc.ca> changed:

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

--- Comment #4 from Nick Lewycky <nicholas at mxc.ca> 2011-06-03 01:27:32 CDT ---
Fixed in r132535. Thanks for the bug 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 Jun  3 04:23:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 04:23:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10073] New: "Cannot select" for bitcasts of AVX
	data types
Message-ID: <bug-10073-206@http.llvm.org/bugs/>

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

           Summary: "Cannot select" for bitcasts of AVX data types
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: karrenberg at cs.uni-saarland.de
                CC: llvmbugs at cs.uiuc.edu


The AVX backend gets confused about mask code as e.g. produced by VCMPPS
together with mask operations and corresponding bitcasts.

Masks that are represented as <8 x i32> should be able to be modified by
xor/and/or which should get lowered to VXORPS/VANDPS/VORPS.
It could also make sense to allow these to operate on <8 x float>, matching the
C intrinsics of immintrin.h (_mm256_cmpgt_ps etc. produce __m256 instead of
__m256i, _mm256_xor_ps takes __m256 operators as well) and LLVM's own
intrinsics (llvm.x86.avx.cmp.ps.256 produces <8 x float>,
llvm.x86.avx.blendv.ps.256 takes an <8 x float> operand as condition).

Currently, code generation for most of these operations fails with "Cannot
select" messages for a cast operation, which could mean that LLVM is only
confused about the required types, not about the bit operations.

Consider these examples:

define <8 x float> @test1(<8 x float> %a, <8 x float> %b, <8 x i32> %m) 
nounwind readnone {
entry:
   %cmp = tail call <8 x float> @llvm.x86.avx.cmp.ps.256(<8 x float> %a, 
<8 x float> %b, i8 1) nounwind readnone
   %res = tail call <8 x float> @llvm.x86.avx.blendv.ps.256(<8 x float> 
%a, <8 x float> %b, <8 x float> %cmp) nounwind readnone
   ret <8 x float> %res
}

This works fine and "llc -filetype=asm -mattr=avx" produces the expected
assembly (VCMPLTPS + VBLENDVPS).

On the other hand, this does not work:

define <8 x float> @test2(<8 x float> %a, <8 x float> %b, <8 x i32> %m) 
nounwind readnone {
entry:
   %cmp = tail call <8 x float> @llvm.x86.avx.cmp.ps.256(<8 x float> %a, 
<8 x float> %b, i8 1) nounwind readnone
   %cast = bitcast <8 x float> %cmp to <8 x i32>
   %mask = and <8 x i32> %cast, %m
   %blend_cond = bitcast <8 x i32> %mask to <8 x float>
   %res = tail call <8 x float> @llvm.x86.avx.blendv.ps.256(<8 x float> 
%a, <8 x float> %b, <8 x float> %blend_cond) nounwind readnone
   ret <8 x float> %res
}

This should produce VCMPLTPS, VANDPS, BLENDVPS, while llc (2.9 final as well as
latest trunk) bails out with:

LLVM ERROR: Cannot select: 0x2510540: v8f32 = bitcast 0x2532270 [ID=16]
   0x2532270: v4i64 = and 0x2532070, 0x2532170 [ID=15]
     0x2532070: v4i64 = bitcast 0x2510740 [ID=14]
       0x2510740: v8f32 = llvm.x86.avx.cmp.ps.256 0x2510640, 0x2511340, 
0x2510f40, 0x2511140 [ORD=3] [ID=12]
...

The same counts for or and xor.
However, one specific example works:

define <8 x float> @test3(<8 x float> %a, <8 x float> %b, <8 x i32> %m) 
nounwind readnone {
entry:
   %cond = xor <8 x i32> %m, %m
   %res = tail call <8 x float> @llvm.x86.avx.blendv.ps.256(<8 x float> 
%a, <8 x float> %b, <8 x float> %cond) nounwind readnone
   ret <8 x float> %res
}

This produces the expected (VXORPS + BLENDVPS), but the same fails for and/or.
In this case, no casting is required, which indicates that this is the actual
problem, not the instruction selection of the xor.

Apparently, LLVM is generally unable to handle bitcasts between <8 x i32> and
<8 x float> (and <4 x i64> vs. <4 x double>), which should always be allowed
for AVX as nops.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 07:27:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 07:27:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10074] New: clang++ does not use env. variable
 CPLUS_INCLUDE_PATH
Message-ID: <bug-10074-206@http.llvm.org/bugs/>

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

           Summary: clang++ does not use env. variable CPLUS_INCLUDE_PATH
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: simon at heisterkamp.dk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following little test project compiles with g++ but not with clang++:

File: test/setup.sh:
> export CPLUS_INCLUDE_PATH="$PWD/include"
File test/include/a.h:
> int a=1;
File test/main.cxx:
> #include <iostream>
> #include "sqr.h"
> int main (){ std::cout<<"a="<<a<<std::endl; return 0; }

before sourcing setup.sh, this doens't work.
After sourcing setup.sh this compiles with:
$ g++ main.cxx
$ ./a.out
a=1

This fails:
$ clang++ main.cxx 
main.cxx:2:10: fatal error: 'a.h' file not found
#include "a.h"
         ^
1 error generated.

The clang man page states that the environment variable CPLUS_INCLUDE_PATH will
be used when looking for includes, but from this test it certainly doesn't look
like that is the case. This is the bug I would like to report.

I noticed this error first with that clang that comes with Xcode 4.0
I have tried to install the latest clang 2.9, and got the same error, although
I'm not sure the installation was correct.

Regards
Simon

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 08:07:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 08:07:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10008] Clang does not work on upcoming ubuntu 11.11
In-Reply-To: <bug-10008-206@http.llvm.org/bugs/>
References: <bug-10008-206@http.llvm.org/bugs/>
Message-ID: <20110603130731.B4DD92A6C12C@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #5 from Eric Christopher <echristo at gmail.com> 2011-06-03 08:07:31 CDT ---
Applied thusly minus the ppc bits:


[issola:llvm/tools/clang] echristo% svn ci
Sending        lib/Frontend/InitHeaderSearch.cpp
Transmitting file data .
Committed revision 132541.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 10:48:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 10:48:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8487] Switch statement miscompiled on 64-bit PowerPC
In-Reply-To: <bug-8487-206@http.llvm.org/bugs/>
References: <bug-8487-206@http.llvm.org/bugs/>
Message-ID: <20110603154827.3E56E2A6C12F@llvm.org>

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

Roman Divacky <rdivacky at freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rdivacky at freebsd.org
         Resolution|                            |FIXED

--- Comment #5 from Roman Divacky <rdivacky at freebsd.org> 2011-06-03 10:48:26 CDT ---
Fixed in r132552.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 13:21:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 13:21:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10073] "Cannot select" for bitcasts of AVX data
	types
In-Reply-To: <bug-10073-206@http.llvm.org/bugs/>
References: <bug-10073-206@http.llvm.org/bugs/>
Message-ID: <20110603182120.909F22A6C12D@llvm.org>

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

Nadav Rotem <nadav.rotem at intel.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |nadav.rotem at intel.com
         Resolution|                            |DUPLICATE

--- Comment #1 from Nadav Rotem <nadav.rotem at intel.com> 2011-06-03 13:21:19 CDT ---
Ralf, thanks for the detailed report. I am trying to gather the vector-select
bugs into a single bug reports. I am marking this one as a duplicate of 2314. I
started committing the vector-select patch (which required a type-legalization
refactoring and other changes all over the codegen). I plan to submit more
patches next week. 
Cheers, Nadav

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 15:19:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 15:19:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10072] Necessary 'indirectbr' instruction is
 dropped by optimizer [regression]
In-Reply-To: <bug-10072-206@http.llvm.org/bugs/>
References: <bug-10072-206@http.llvm.org/bugs/>
Message-ID: <20110603201945.A2C912A6C12C@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #1 from Bill Wendling <wendling at apple.com> 2011-06-03 15:19:45 CDT ---
In the particular example you gave, we get this after the first few
optimization passes:


[Irk:llvm] opt < mod.ll -S -mem2reg -globalopt -ipsccp -deadargelim
-instcombine
; ModuleID = '<stdin>'

@xblkx.bbs = internal unnamed_addr constant [9 x i8*] [i8*
blockaddress(@xfuncx, %xblkx.begin), i8* blockaddress(@xfuncx, %xblkx.begin3),
i8* blockaddress(@xfuncx, %xblkx.begin4), i8* blockaddress(@xfuncx,
%xblkx.begin5), i8* blockaddress(@xfuncx, %xblkx.begin6), i8*
blockaddress(@xfuncx, %xblkx.begin7), i8* blockaddress(@xfuncx, %xblkx.begin8),
i8* blockaddress(@xfuncx, %xblkx.begin9), i8* blockaddress(@xfuncx,
%xblkx.end)]

define void @xfuncx() {
escape-string.top:
  %xval202x = call i32 @xfunc5x()
  br label %xlab5x

xlab8x:                                           ; preds = %xlab5x
  %xvaluex = call i32 @xselectorx()
  %xblkx.x = getelementptr [9 x i8*]* @xblkx.bbs, i32 0, i32 %xvaluex
  %xblkx.load = load i8** %xblkx.x
  indirectbr i8* %xblkx.load, [label %xblkx.begin, label %xblkx.begin3, label
%xblkx.begin4, label %xblkx.begin5, label %xblkx.begin6, label %xblkx.begin7,
label %xblkx.begin8, label %xblkx.begin9, label %xblkx.end]

xblkx.begin:                                      ; preds = %xlab8x
  br label %xblkx.end

xblkx.begin3:                                     ; preds = %xlab8x
  br label %xblkx.end

xblkx.begin4:                                     ; preds = %xlab8x
  br label %xblkx.end

xblkx.begin5:                                     ; preds = %xlab8x
  br label %xblkx.end

xblkx.begin6:                                     ; preds = %xlab8x
  br label %xblkx.end

xblkx.begin7:                                     ; preds = %xlab8x
  br label %xblkx.end

xblkx.begin8:                                     ; preds = %xlab8x
  br label %xblkx.end

xblkx.begin9:                                     ; preds = %xlab8x
  br label %xblkx.end

xblkx.end:                                        ; preds = %xblkx.begin9,
%xblkx.begin8, %xblkx.begin7, %xblkx.begin6, %xblkx.begin5, %xblkx.begin4,
%xblkx.begin3, %xblkx.begin, %xlab8x
  %yes.0 = phi i1 [ false, %xblkx.begin ], [ true, %xlab8x ], [ false,
%xblkx.begin9 ], [ false, %xblkx.begin8 ], [ false, %xblkx.begin7 ], [ false,
%xblkx.begin6 ], [ false, %xblkx.begin5 ], [ false, %xblkx.begin4 ], [ false,
%xblkx.begin3 ]
  br i1 %yes.0, label %v2j, label %xlab17x

v2j:                                              ; preds = %xblkx.end
  br label %xlab4x

xlab17x:                                          ; preds = %xblkx.end
  br label %xlab4x

xlab4x:                                           ; preds = %xlab17x, %v2j
  %incr19 = add i32 %xval704x.0, 1
  br label %xlab5x

xlab5x:                                           ; preds = %xlab4x,
%escape-string.top
  %xval704x.0 = phi i32 [ 0, %escape-string.top ], [ %incr19, %xlab4x ]
  %xval10x = icmp ult i32 %xval704x.0, %xval202x
  br i1 %xval10x, label %xlab8x, label %xlab9x

xlab9x:                                           ; preds = %xlab5x
  ret void
}

The "simplifycfg" pass comes along and realizes that the result of all
indirectbr branches wind up in the same place, and so eliminates it:


[Irk:llvm] opt < mod.ll -S -mem2reg -globalopt -ipsccp -deadargelim
-instcombine -simplifycfg
; ModuleID = '<stdin>'

@xblkx.bbs = internal unnamed_addr constant [9 x i8*] [i8*
blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8*
blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8*
blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8*
blockaddress(@xfuncx, %xlab4x), i8* blockaddress(@xfuncx, %xlab4x), i8*
blockaddress(@xfuncx, %xlab4x)]

define void @xfuncx() {
escape-string.top:
  %xval202x = call i32 @xfunc5x()
  br label %xlab5x

xlab8x:                                           ; preds = %xlab5x
  %xvaluex = call i32 @xselectorx()
  br label %xlab4x

xlab4x:                                           ; preds = %xlab8x
  %incr19 = add i32 %xval704x.0, 1
  br label %xlab5x

xlab5x:                                           ; preds = %xlab4x,
%escape-string.top
  %xval704x.0 = phi i32 [ 0, %escape-string.top ], [ %incr19, %xlab4x ]
  %xval10x = icmp ult i32 %xval704x.0, %xval202x
  br i1 %xval10x, label %xlab8x, label %xlab9x

xlab9x:                                           ; preds = %xlab5x
  ret void
}

Do you have another testcase which would show the failure? I.e., where all of
the branches of the indirectbr don't execute the same code? If so, please
reopen this bug.

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

From bugzilla-daemon at llvm.org  Fri Jun  3 16:55:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 16:55:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10075] New: Fast register allocator produces code
 that uses a lot of stack
Message-ID: <bug-10075-206@http.llvm.org/bugs/>

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

           Summary: Fast register allocator produces code that uses a lot
                    of stack
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

I know that the main objective of the fast register allocator is speed, but I
am getting test failures -O0 because the tests run out of stack space :-(

The results I got for the largest function by recompiling the .ii with gcc and
clang:

clang O0 0x00004690
gcc   O0 0x00001560

clang O1 0x00000868
gcc   O1 0x00000b98

clang O2 0x00000aa8
gcc   O2 0x00000bd8

clang O3 0x00000ab8
gcc   O3 0x00000bd8

clang Os 0x000010b8
gcc   Os 0x00000698

I then found that most of the -O0 to -O1 difference was because of the register
allocator:

$ llc jsinterp.bc  -o jsinterp.o -filetype=obj -regalloc=greedy -O0
$ otool -t -v jsinterp.o | grep -A 8
__ZN2js9InterpretEP9JSContextPNS_10StackFrameEjNS_10InterpModeE | grep sub.*rsp

000000000000001a    subq    $0x00001c78,%rsp

$ llc jsinterp.bc  -o jsinterp.o -filetype=obj -regalloc=fast -O0
$ otool -t -v jsinterp.o | grep -A 8
__ZN2js9InterpretEP9JSContextPNS_10StackFrameEjNS_10InterpModeE | grep sub.*rsp

0000000000000010    subq    $0x000045d8,%rsp

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 17:46:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 17:46:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10076] New: Simple mixup of "abs" and "fabs" leads
 to 65-line cascade of error messages
Message-ID: <bug-10076-206@http.llvm.org/bugs/>

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

           Summary: Simple mixup of "abs" and "fabs" leads to 65-line
                    cascade of error messages
           Product: new-bugs
           Version: 2.8
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: arthur.j.odwyer at gmail.com
                CC: llvmbugs at cs.uiuc.edu


This wouldn't be terribly shocking if it were a different compiler, or if C++
templates were involved, but it really surprised me that:
(A) anything could lead to such an icky-looking dump from the normally
user-friendly Clang front-end;
(B) the majority of the dump seems to have been triggered by Clang's attempt to
be *more* helpful by suggesting that I might have misspelled "fabs"; and
(C) that it apparently takes seven or eight levels of macro magic and compiler
builtins to implement "fabs" in the math headers. Couldn't this be simplified
somehow?

Simple test case:

cat >test.cc <<EOF
#include <math.h>  /* whoops! the user meant <stdlib.h> */
int main() { return abs(0); }
EOF
clang++ -c test.cc

I've pasted the output I got below (except multiply that by 6 since I used
"abs" six times in my original code, and every instance generated a new 60-line
cascade of errors). 

$ clang++ Narrate.cc
Narrate.cc:143:9: error: use of undeclared identifier 'abs'; did you mean
      'fabs'?
    if (abs(fa.x - fb.x) <= 3) relatedness += 2;
        ^~~
        fabs
In file included from Narrate.cc:3:
In file included from /usr/include/math.h:71:
/usr/include/bits/mathcalls.h:182:1: note: 'fabs' declared here
__MATHCALLX (fabs,, (_Mdouble_ __x), (__const__));
^
In file included from Narrate.cc:3:
/usr/include/math.h:60:3: note: instantiated from:
  __MATHDECLX (_Mdouble_,function,suffix, args, attrib)
  ^
/usr/include/math.h:62:3: note: instantiated from:
  __MATHDECL_1(type, function,suffix, args) __attribute__ (attrib); \
  ^
/usr/include/math.h:65:15: note: instantiated from:
  extern type __MATH_PRECNAME(function,suffix) args __THROW
              ^
/usr/include/math.h:68:33: note: instantiated from:
#define __MATH_PRECNAME(name,r) __CONCAT(name,r)
                                ^
In file included from Narrate.cc:3:
In file included from /usr/include/math.h:71:
/usr/include/bits/mathcalls.h:182:1: note: instantiated from:
__MATHCALLX (fabs,, (_Mdouble_ __x), (__const__));
^
In file included from Narrate.cc:3:
/usr/include/math.h:60:3: note: instantiated from:
  __MATHDECLX (_Mdouble_,function,suffix, args, attrib)
  ^
/usr/include/math.h:62:3: note: instantiated from:
  __MATHDECL_1(type, function,suffix, args) __attribute__ (attrib); \
  ^
/usr/include/math.h:65:15: note: instantiated from:
  extern type __MATH_PRECNAME(function,suffix) args __THROW
              ^
In file included from Narrate.cc:3:
In file included from /usr/include/math.h:71:
/usr/include/bits/mathcalls.h:182:1: note: instantiated from:
__MATHCALLX (fabs,, (_Mdouble_ __x), (__const__));
^
In file included from Narrate.cc:3:
/usr/include/math.h:60:3: note: instantiated from:
  __MATHDECLX (_Mdouble_,function,suffix, args, attrib)
  ^
/usr/include/math.h:62:3: note: instantiated from:
  __MATHDECL_1(type, function,suffix, args) __attribute__ (attrib); \
  ^
In file included from Narrate.cc:3:
In file included from /usr/include/math.h:71:
/usr/include/bits/mathcalls.h:182:1: note: instantiated from:
__MATHCALLX (fabs,, (_Mdouble_ __x), (__const__));
^
In file included from Narrate.cc:3:
/usr/include/math.h:60:3: note: instantiated from:
  __MATHDECLX (_Mdouble_,function,suffix, args, attrib)
  ^
In file included from Narrate.cc:3:
In file included from /usr/include/math.h:71:
/usr/include/bits/mathcalls.h:182:1: note: instantiated from:
__MATHCALLX (fabs,, (_Mdouble_ __x), (__const__));
^
/usr/include/bits/mathcalls.h:182:14: note: instantiated from:
__MATHCALLX (fabs,, (_Mdouble_ __x), (__const__));
             ^
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  Fri Jun  3 18:12:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 18:12:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10077] New: Crash with -O0 -regalloc=greedy
Message-ID: <bug-10077-206@http.llvm.org/bugs/>

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

           Summary: Crash with -O0 -regalloc=greedy
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


$ cat test.ll
%bar = type { i32 }

define i32 @foo()  {
  %tmp = extractvalue %bar undef, 0
  ret i32 %tmp
}


Starting program: /Users/espindola/llvm/build-dbg/Debug+Asserts/bin/llc test.ll
-O0 -regalloc=greedy
Reading symbols for shared libraries ++. done
Assertion failed: (MRI->getVRegDef(reg) && "Register use before def!"),
function HandleVirtRegUse, file
/Users/espindola/llvm/llvm/lib/CodeGen/LiveVariables.cpp, line 128.

Program received signal SIGABRT, Aborted.
0x9906051e in __pthread_kill ()
(gdb) bt
#0  0x9906051e in __pthread_kill ()
#1  0x9905fdcb in pthread_kill ()
#2  0x00e36ce0 in raise (sig=6) at Signals.inc:281
#3  0x00e36dd2 in abort () at Signals.inc:298
#4  0x00e36da2 in __assert_rtn (func=0xf40729 "HandleVirtRegUse", file=0xf40680
"/Users/espindola/llvm/llvm/lib/CodeGen/LiveVariables.cpp", line=128,
expr=0xf4073a "MRI->getVRegDef(reg) && \"Register use before def!\"") at
Signals.inc:294
#5  0x0085f197 in llvm::LiveVariables::HandleVirtRegUse (this=0x2905800,
reg=2147483649, MBB=0x3031a84, MI=0x3031b04) at
/Users/espindola/llvm/llvm/lib/CodeGen/LiveVariables.cpp:128
#6  0x00861284 in llvm::LiveVariables::runOnMachineFunction (this=0x2905800,
mf=@0x2909220) at /Users/espindola/llvm/llvm/lib/CodeGen/LiveVariables.cpp:557
#7  0x00890b93 in llvm::MachineFunctionPass::runOnFunction (this=0x2905800,
F=@0x29016b0) at
/Users/espindola/llvm/llvm/lib/CodeGen/MachineFunctionPass.cpp:33
#8  0x00d0f852 in llvm::FPPassManager::runOnFunction (this=0x29024b0,
F=@0x29016b0) at /Users/espindola/llvm/llvm/lib/VMCore/PassManager.cpp:1513
#9  0x00d0fc31 in llvm::FPPassManager::runOnModule (this=0x29024b0,
M=@0x29013f0) at /Users/espindola/llvm/llvm/lib/VMCore/PassManager.cpp:1535
#10 0x00d0feb7 in llvm::MPPassManager::runOnModule (this=0x2902180,
M=@0x29013f0) at /Users/espindola/llvm/llvm/lib/VMCore/PassManager.cpp:1589
#11 0x00d10657 in llvm::PassManagerImpl::run (this=0x2901fc0, M=@0x29013f0) at
/Users/espindola/llvm/llvm/lib/VMCore/PassManager.cpp:1671
#12 0x00d10b57 in llvm::PassManager::run (this=0xbffff768, M=@0x29013f0) at
/Users/espindola/llvm/llvm/lib/VMCore/PassManager.cpp:1715
#13 0x00002954 in main (argc=4, argv=0xbffff8b4) at
/Users/espindola/llvm/llvm/tools/llc/llc.cpp:338

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 18:17:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 18:17:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10078] New: LLVM test suite intolerant of '.' in
 directory names
Message-ID: <bug-10078-206@http.llvm.org/bugs/>

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

           Summary: LLVM test suite intolerant of '.' in directory names
           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: stuart at apple.com
                CC: llvmbugs at cs.uiuc.edu


If you check out LLVM into a directory with '.' characters in the path, the %p
variable seems to be mis-expanded when running the LLVM test suite.  This
causes bogus failures in the test suite.

Specifically, I had a copy of LLVM on my disk in
   /Volumes/sandbox/stuart/llvmCore.clang.test2

I believe (at least) these failures were caused by the directory name with
period characters:

    LLVM :: LLVMC/Alias.td
    LLVM :: LLVMC/AppendCmdHook.td
    LLVM :: LLVMC/EmptyCompilationGraph.td
    LLVM :: LLVMC/EnvParentheses.td
    LLVM :: LLVMC/ForwardAs.td
    LLVM :: LLVMC/ForwardTransformedValue.td
    LLVM :: LLVMC/ForwardValue.td
    LLVM :: LLVMC/HookWithArguments.td
    LLVM :: LLVMC/HookWithInFile.td
    LLVM :: LLVMC/Init.td
    LLVM :: LLVMC/LanguageMap.td
    LLVM :: LLVMC/MultiValuedOption.td
    LLVM :: LLVMC/MultipleCompilationGraphs.td
    LLVM :: LLVMC/MultipleOutputLanguages.td
    LLVM :: LLVMC/NoActions.td
    LLVM :: LLVMC/NoCompilationGraph.td
    LLVM :: LLVMC/OneOrMore.td
    LLVM :: LLVMC/OptionPreprocessor.td
    LLVM :: LLVMC/OutputSuffixHook.td

Obvious workaround: avoid period characters in directory names.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  3 20:58:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri,  3 Jun 2011 20:58:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10072] Necessary 'indirectbr' instruction is
 dropped by optimizer [regression]
In-Reply-To: <bug-10072-206@http.llvm.org/bugs/>
References: <bug-10072-206@http.llvm.org/bugs/>
Message-ID: <20110604015847.03FC02A6C12C@llvm.org>

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

Yuri <yuri at tsoft.com> changed:

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

--- Comment #2 from Yuri <yuri at tsoft.com> 2011-06-03 20:58:46 CDT ---
I don't think you are right.

My original testcase has the last label xblkx.end which doesn't do what all
other labels do.

Labels xblkx.begin to xblkx.begin9 (8 of them) all set 'yes' variable to 1
(from 0). But label xblkx.end is also in 'indirectbr' but doesn't do that.

Therefore 'indirectbr' or its equivalent should survive optimization. And it
doesn't. In fact, my really original testcase (that I simplified into this one)
produces wrong result with optimization and correct result without it, which
should never ever happen.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  4 04:35:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  4 Jun 2011 04:35:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10079] New: -mtune not supportd to the assembler
Message-ID: <bug-10079-206@http.llvm.org/bugs/>

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

           Summary: -mtune not supportd to the assembler
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nicholas at mxc.ca
                CC: llvmbugs at cs.uiuc.edu


$ clang -c -Wa,-mtune=i686 conftest.c
clang: error: unsupported argument '-mtune=i686' to option '-Wa,'

To my surprise, GNU as actually has this flag. I'm not sure if there's anything
to wire it up to in MC (what does it actually do in GNU as?), but it'd be
useful if we didn't error on 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  Sat Jun  4 04:42:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  4 Jun 2011 04:42:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10072] Necessary 'indirectbr' instruction is
 dropped by optimizer [regression]
In-Reply-To: <bug-10072-206@http.llvm.org/bugs/>
References: <bug-10072-206@http.llvm.org/bugs/>
Message-ID: <20110604094230.A8C612A6C12C@llvm.org>

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

Bill Wendling <wendling at apple.com> changed:

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

--- Comment #7 from Bill Wendling <wendling at apple.com> 2011-06-04 04:42:29 CDT ---
Ah! Okay. I see what the problem is. :-)

Fixed here r132638.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  4 06:24:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  4 Jun 2011 06:24:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10080] New: Crash on ill-formed alias-template code
 causing a dependent function declaration
Message-ID: <bug-10080-206@http.llvm.org/bugs/>

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

           Summary: Crash on ill-formed alias-template code causing a
                    dependent function declaration
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This code crashes clang (trunk 132184):

template<typename T> using Fn = void(T); 
template<typename T> Fn<T> f; // ill-formed!
int main() { f<int>(0); }

The line marked with "ill-formed" should be rejected, according to FDIS,
14.3.1p3.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  4 10:35:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  4 Jun 2011 10:35:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10081] New: c backend emits multiple definitions of
 global variables
Message-ID: <bug-10081-206@http.llvm.org/bugs/>

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

           Summary: c backend emits multiple definitions of global
                    variables
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


There is a one-character typo in CBackend.cpp that causes global variable
definitions to be emitted multiple times (and thence, compilation of the
generated C code to fail when globals are present in the input IR.)  The loop
that is supposed to only emit declarations has an extra '!'; fix is below.

diff --git a/lib/Target/CBackend/CBackend.cpp
b/lib/Target/CBackend/CBackend.cpp
index fde2e29..70ea9b9 100644
--- a/lib/Target/CBackend/CBackend.cpp
+++ b/lib/Target/CBackend/CBackend.cpp
@@ -1885,7 +1885,7 @@ bool CWriter::doInitialization(Module &M) {
     Out << "\n\n/* Global Variable Declarations */\n";
     for (Module::global_iterator I = M.global_begin(), E = M.global_end();
          I != E; ++I)
-      if (!I->isDeclaration()) {
+      if (I->isDeclaration()) {
         // Ignore special globals, such as debug info.
         if (getGlobalVariableClass(I))
           continue;

(This bug is present in both 2.9 and 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 Jun  4 10:51:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat,  4 Jun 2011 10:51:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10082] New: invalid cast assertion
Message-ID: <bug-10082-206@http.llvm.org/bugs/>

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

           Summary: invalid cast assertion
           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: marc.glisse at normalesup.org
                CC: llvmbugs at cs.uiuc.edu


clang++ -O2 a.cc -c
fails with an invalid cast assertion. This may or may not be related to bug
8769 (I discovered this one when I finally removed the workaround for 8769).

template<typename >     struct array     {
        float _M_instance[3] __attribute__((__aligned__));
        const float&       operator[](int __n) const       {
                return _M_instance[__n];
        }
};
struct PointC3 {
        array<float> base;
        const float & x() const   {
                return base[0];
        }
};
struct Point_3 : public PointC3 {
};
struct Equal_3   {
        bool     operator()(const PointC3 &p, const PointC3 &q) const     {
                return p.x() == q.x();
        }
};
Equal_3 equal_3_object();
inline bool operator==(const Point_3& p, const Point_3& q) {
        return equal_3_object()(p, q);
}
Point_3 f();
int main() {
        f() == f();
}





clang: /data/repos/llvm/lib/VMCore/Instructions.cpp:2079: static
llvm::CastInst* llvm::CastInst::Create(llvm::Instruction::CastOps,
llvm::Value*, const llvm::Type*, const llvm::Twine&, llvm::Instruction*):
Assertion `castIsValid(op, S, Ty) && "Invalid cast!"' failed.
0  clang           0x0000000001ab601f
1  clang           0x0000000001ab6b5a
2  libpthread.so.0 0x00007ff490785020
3  libc.so.6       0x00007ff48fa7f3d5 gsignal + 53
4  libc.so.6       0x00007ff48fa82650 abort + 384
5  libc.so.6       0x00007ff48fa78581 __assert_fail + 241
6  clang           0x00000000019bfcad
7  clang           0x00000000007fca66 llvm::IRBuilder<true,
llvm::ConstantFolder, llvm::IRBuilderDefaultInserter<true>
>::CreateCast(llvm::Instruction::CastOps, llvm::Value*, llvm::Type const*,
llvm::Twine const&) + 118
8  clang           0x0000000001779276
9  clang           0x0000000001779c84
10 clang           0x0000000001779b4c
11 clang           0x0000000001779a01
12 clang           0x000000000177e339
13 clang           0x0000000001780f49
14 clang           0x00000000019e296f
llvm::FPPassManager::runOnFunction(llvm::Function&) + 655
15 clang           0x0000000001862727
16 clang           0x0000000001864aee
17 clang           0x00000000019e2467
llvm::MPPassManager::runOnModule(llvm::Module&) + 551
18 clang           0x00000000019e25cb llvm::PassManagerImpl::run(llvm::Module&)
+ 187
19 clang           0x00000000007cf0f7
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 2967
20 clang           0x00000000007cce8b
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 251
21 clang           0x000000000092362f clang::ParseAST(clang::Sema&, bool) + 351
22 clang           0x00000000007cba94 clang::CodeGenAction::ExecuteAction() +
68
23 clang           0x00000000006ca233
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 371
24 clang           0x00000000006a306a
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1290
25 clang           0x000000000069783b cc1_main(char const**, char const**, char
const*, void*) + 779
26 clang           0x00000000006a1f43 main + 7667
27 libc.so.6       0x00007ff48fa6bead __libc_start_main + 253
28 clang           0x0000000000697349
Stack dump:
0.      Program arguments: /tmp/clang/inst/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -disable-free -main-file-name a.cc
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.21.51.20110523
-momit-leaf-frame-pointer -coverage-file a.o -resource-dir
/tmp/clang/inst/bin/../lib/clang/3.0 -O2 -fdeprecated-macro -ferror-limit 19
-fmessage-length 0 -fcxx-exceptions -fexceptions -fgnu-runtime
-fdiagnostics-show-option -o a.o -x c++ a.cc 
1.      <eof> parser at end of file
2.      Per-module optimization passes
3.      Running pass 'CallGraph Pass Manager' on module 'a.cc'.
4.      Running pass 'Scalar Replacement of Aggregates (SSAUp)' on function
'@main'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (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  Sun Jun  5 00:04:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  5 Jun 2011 00:04:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9982] Templated function returning an apple-block
 throwing assertion
In-Reply-To: <bug-9982-206@http.llvm.org/bugs/>
References: <bug-9982-206@http.llvm.org/bugs/>
Message-ID: <20110605050443.4EA892A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-06-05 00:04:41 CDT ---
Fixed in Clang r132657.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  5 00:39:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  5 Jun 2011 00:39:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9983] clang crashes when using std::bind with a
 non-static method
In-Reply-To: <bug-9983-206@http.llvm.org/bugs/>
References: <bug-9983-206@http.llvm.org/bugs/>
Message-ID: <20110605053951.5200E2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-06-05 00:39:50 CDT ---
Fixed in Clang r132659.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  5 01:16:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  5 Jun 2011 01:16:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9507] Lvalue transformation not ignored when
 parameter is a const-reference
In-Reply-To: <bug-9507-206@http.llvm.org/bugs/>
References: <bug-9507-206@http.llvm.org/bugs/>
Message-ID: <20110605061605.8057F2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-05 01:16:05 CDT ---
Fixed in Clang r132660.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  5 11:01:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  5 Jun 2011 11:01:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10084] New: Clang doesn't know about Ubuntu Oneiric
Message-ID: <bug-10084-206@http.llvm.org/bugs/>

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

           Summary: Clang doesn't know about Ubuntu Oneiric
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: themiwi at users.sourceforge.net
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6694)
 --> (http://llvm.org/bugs/attachment.cgi?id=6694)
Patch adding Ubuntu Oneiric handling

In lib/Driver/ToolChains.cpp the enum and detection for Ubuntu Oneiric is
missing.

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

From bugzilla-daemon at llvm.org  Sun Jun  5 11:09:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  5 Jun 2011 11:09:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10084] Clang doesn't know about Ubuntu Oneiric
In-Reply-To: <bug-10084-206@http.llvm.org/bugs/>
References: <bug-10084-206@http.llvm.org/bugs/>
Message-ID: <20110605160926.1500A2A6C124@llvm.org>

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

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

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

--- Comment #1 from Benjamin Kramer <benny.kra at gmail.com> 2011-06-05 11:09:25 CDT ---
    M    lib/Driver/ToolChains.cpp
Committed r132669

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  Sun Jun  5 16:31:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  5 Jun 2011 16:31:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10085] New: cannot select unknown target node #197
 (long double)
Message-ID: <bug-10085-206@http.llvm.org/bugs/>

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

           Summary: cannot select unknown target node #197 (long double)
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


This straight-line C code crashes clang:

  int signbitl (long double x) {
    __extension__ union { long double l; int i[3]; } u;
    u.l = x;
    return (u.i[2] & 0x8000) != 0;
  }

when targeting x86-64 and under -O2:

fatal error: error in backend: Cannot select: 0x58c8d20: i32 = <<Unknown Target
Node #197>> 0x58c30b0, 0x58c8c20 [ID=7]
  0x58c30b0: f80,ch = load 0x58893b8, 0x58c2eb0,
0x58c2fb0<LD10[FixedStack-1](align=16)> [ORD=1] [ID=6]
    0x58c2eb0: i64 = FrameIndex<-1> [ORD=1] [ID=1]
    0x58c2fb0: i64 = undef [ORD=1] [ID=2]
  0x58c8c20: i32 = Constant<1> [ID=5]

For reference the LLVM IR is:

target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

define i32 @signbitl(x86_fp80 %x) nounwind uwtable readnone {
entry:
  %tmp4 = bitcast x86_fp80 %x to i80
  %tmp4.lobit = lshr i80 %tmp4, 79
  %tmp = trunc i80 %tmp4.lobit to i32
  ret i32 %tmp
}

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

From bugzilla-daemon at llvm.org  Sun Jun  5 17:44:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun,  5 Jun 2011 17:44:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10053] [QoI] diagnostic in case of two-stage name
 lookup-related errors could be better
In-Reply-To: <bug-10053-206@http.llvm.org/bugs/>
References: <bug-10053-206@http.llvm.org/bugs/>
Message-ID: <20110605224434.AE4C62A6C12C@llvm.org>

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

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> 2011-06-05 17:44:33 CDT ---
Fixed in r132672. We now produce:


  my_file.cpp:2:10: error: call to function 'Multiply' that is neither visible
in the template definition nor found by argument dependent lookup
    return Multiply(x, x);
           ^
  my_file.cpp:10:3: note: in instantiation of function template specialization
'Squared<int>' requested here
    Squared(5);
    ^
  my_file.cpp:5:5: note: 'Multiply' should be declared prior to the call site
  int Multiply(int x, int y) {
      ^

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

From bugzilla-daemon at llvm.org  Mon Jun  6 00:48:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 00:48:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10077] Crash with -O0 -regalloc=greedy
In-Reply-To: <bug-10077-206@http.llvm.org/bugs/>
References: <bug-10077-206@http.llvm.org/bugs/>
Message-ID: <20110606054804.16AB12A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-06 00:48:03 CDT ---
r132676.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 05:00:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 05:00:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9595] [klee] llvm::APInt::operator|=(const
 llvm::APInt&): Assertion `BitWidth == RHS.BitWidth && "Bit widths must be
 the same"' failed.
In-Reply-To: <bug-9595-206@http.llvm.org/bugs/>
References: <bug-9595-206@http.llvm.org/bugs/>
Message-ID: <20110606100045.A3ABD2A6C12C@llvm.org>

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

arrowdodger <6yearold at gmail.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |6yearold 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  Mon Jun  6 09:51:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 09:51:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10086] New: Explicit Template Instantiation without
 Original Template Definition
Message-ID: <bug-10086-206@http.llvm.org/bugs/>

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

           Summary: Explicit Template Instantiation without Original
                    Template Definition
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ythrier at hsr.ch
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


CLANG seems to accept explicit template instantiation without a previous
template definition. The following example is accepted by clang++, but rejected
by g++:

[Example "A.cpp"

template void foobar(int i) {
  // ...
}

int main() {
  foobar(5);
}

end example]

~$clang++ A.cpp // Accept
~$g++ A.cpp // 'foobar' is not a template function

CLANG may threat the function as some kind of "overload", because in the
example, "foobar" is defined with a body statement. After removing the function
body, CLANG rejects the example code. However, the original situation should
not be possible. The example is accepted by g++ if a previous template
definition exists.

Regards

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

From bugzilla-daemon at llvm.org  Mon Jun  6 10:23:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 10:23:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10024] Assertion hit when specializing a member
 function of a template
In-Reply-To: <bug-10024-206@http.llvm.org/bugs/>
References: <bug-10024-206@http.llvm.org/bugs/>
Message-ID: <20110606152352.3B21F2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-06-06 10:23:51 CDT ---
Fixed in Clang r132677.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 10:47:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 10:47:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10087] New: Regression: Compile error with a map of
	strings
Message-ID: <bug-10087-206@http.llvm.org/bugs/>

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

           Summary: Regression: Compile error with a map of strings
           Product: libc++
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6697)
 --> (http://llvm.org/bugs/attachment.cgi?id=6697)
Complete log file

Hello,

the following program does not compile with current clang and current libc++:

#include <string>
#include <map>

int main(int, char**)
{
    std::map<std::string, std::string>    ss;
}


Instead, the following error message is produced (complete log attached):

$ clang -std=c++0x -stdlib=libc++ clang.cppIn file included from clang.cpp:1:
/usr/include/c++/v1/string:1031:35: error: no type named 'char_type' in
      'std::__1::basic_string<char>'
    typedef typename traits_type::char_type              value_type;
            ~~~~~~~~~~~~~~~~~~~~~~^~~~~~~~~


std::string alone works. It seems to be an interaction between it and std::map.

My clang version: $ clang --version
clang version 3.0 (trunk 132676)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

My libc++ version: $ svn info .
[...]
Revision: 132677

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 10:48:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 10:48:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10088] New: compilation regression "fatal error:
 error in backend" building vxl
Message-ID: <bug-10088-206@http.llvm.org/bugs/>

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

           Summary: compilation regression "fatal error: error in backend"
                    building vxl
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sean at rogue-research.com
                CC: llvmbugs at cs.uiuc.edu


The open source project vxl builds with clang r130865.

It no longer builds with r132417.  I don't know exactly when this regression
occurred.

clang spews:

fatal error: error in backend: Cannot select: 0x1036ddc10: f32 =
X86ISD::FSETCCss 0x10371ec10, 0x1036dd310, 0x10372c910 [ID=26] dbg:/usr/
include/c++/4.2.1/complex:450:7
  0x10371ec10: f80,ch = load 0x103698a10:1, 0x103698a10,
0x10373ab10<LD10[%12](align=16)> [ORD=696] [ID=18] dbg:/usr/include/c++/
4.2.1/complex:450:7
    0x103698a10: i64,ch,glue = CopyFromReg 0x1036ddb10, 0x1036dd810,
0x1036ddb10:1 [ORD=694] [ID=16] dbg:/usr/include/c++/4.2.1/complex:450:7
      0x1036dd810: i64 = Register %RAX [ORD=694] [ID=6]
      0x1036ddb10: ch,glue = callseq_end 0x103698e10, 0x103698910,
0x103698910, 0x103698e10:1 [ORD=694] [ID=15]
        0x103698910: i64 = TargetConstant<0> [ORD=694] [ID=3]
        0x103698910: i64 = TargetConstant<0> [ORD=694] [ID=3]
        0x103698e10: ch,glue = X86ISD::CALL 0x103699610, 0x10371ef10,
0x10372c210, 0x103699610:1 [ORD=694] [ID=14] dbg:/usr/include/c++/4.2.1/
complex:450:7
          0x10371ef10: i64 = TargetGlobalAddress<x86_fp80*
(%"struct.std::complex"*)* @_ZNKSt7complexIeE4imagEv> 0 [ORD=694] [ID=5]
dbg:/usr/include/c++/4.2.1/complex:450:7
          0x10372c210: i64 = Register %RDI [ORD=694] [ID=4]
          0x103699610: ch,glue = CopyToReg 0x10373ad10, 0x10372c210,
0x103699010 [ORD=694] [ID=13] dbg:/usr/include/c++/4.2.1/complex:450:7
            0x10372c210: i64 = Register %RDI [ORD=694] [ID=4]
            0x103699010: i64,ch = load 0x103b38608, 0x10372c410,
0x10373ab10<LD8[%1]> [ORD=693] [ID=11] dbg:/usr/include/c++/4.2.1/
complex:450:7
              0x10372c410: i64 = FrameIndex<0> [ORD=693] [ID=1]
              0x10373ab10: i64 = undef [ORD=693] [ID=2]
    0x10373ab10: i64 = undef [ORD=693] [ID=2]
  0x1036dd310: f80,ch = load 0x103699110:1, 0x103699110,
0x10373ab10<LD10[%15](align=16)> [ORD=700] [ID=25] dbg:/usr/include/c++/
4.2.1/complex:450:7
    0x103699110: i64,ch,glue = CopyFromReg 0x103699510, 0x1036dd810,
0x103699510:1 [ORD=698] [ID=24] dbg:/usr/include/c++/4.2.1/complex:450:7
      0x1036dd810: i64 = Register %RAX [ORD=694] [ID=6]
      0x103699510: ch,glue = callseq_end 0x10371e410, 0x103698910,
0x103698910, 0x10371e410:1 [ORD=698] [ID=23]
        0x103698910: i64 = TargetConstant<0> [ORD=694] [ID=3]
        0x103698910: i64 = TargetConstant<0> [ORD=694] [ID=3]
        0x10371e410: ch,glue = X86ISD::CALL 0x10372bf10, 0x10371ef10,
0x10372c210, 0x10372bf10:1 [ORD=698] [ID=22] dbg:/usr/include/c++/4.2.1/
complex:450:7
          0x10371ef10: i64 = TargetGlobalAddress<x86_fp80*
(%"struct.std::complex"*)* @_ZNKSt7complexIeE4imagEv> 0 [ORD=694] [ID=5]
dbg:/usr/include/c++/4.2.1/complex:450:7
          0x10372c210: i64 = Register %RDI [ORD=694] [ID=4]
          0x10372bf10: ch,glue = CopyToReg 0x10372c810, 0x10372c210,
0x10373ae10 [ORD=698] [ID=21] dbg:/usr/include/c++/4.2.1/complex:450:7
            0x10372c210: i64 = Register %RDI [ORD=694] [ID=4]
            0x10373ae10: i64,ch = load 0x103698a10:1, 0x10372c710,
0x10373ab10<LD8[%2]> [ORD=697] [ID=17] dbg:/usr/include/c++/4.2.1/
complex:450:7
              0x10372c710: i64 = FrameIndex<1> [ORD=697] [ID=7]
              0x10373ab10: i64 = undef [ORD=693] [ID=2]
    0x10373ab10: i64 = undef [ORD=693] [ID=2]
  0x10372c910: i8 = Constant<0> [ID=9]

Stuart Hastings believes this is his fault.  As requested, attached is the .bc
file resulting from -emit-llvm.

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

From bugzilla-daemon at llvm.org  Mon Jun  6 13:11:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 13:11:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10089] New: Lots of spills generated
Message-ID: <bug-10089-206@http.llvm.org/bugs/>

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

           Summary: Lots of spills generated
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6699)
 --> (http://llvm.org/bugs/attachment.cgi?id=6699)
jsinterp.ii

The included testcase compiles to 23572 bytes with clang and 4940 bytes with
gcc 4.2. The clang produced code has lots of:

        movq    %rax, %rcx
                                        ## implicit-def: EAX
        movl    %eax, -92(%rbp)         ## 4-byte Spill
                                        ## implicit-def: EAX
        movl    %eax, -68(%rbp)         ## 4-byte Spill
                                        ## implicit-def: EAX
        movq    %rax, -88(%rbp)         ## 8-byte Spill
                                        ## implicit-def: EAX
        movl    %eax, -496(%rbp)        ## 4-byte Spill
                                        ## implicit-def: EAX
        movl    %eax, -492(%rbp)        ## 4-byte Spill
        movq    %rcx, -488(%rbp)        ## 8-byte Spill
                                        ## implicit-def: EAX

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 14:04:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 14:04:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10088] compilation regression "fatal error: error
 in backend" building vxl
In-Reply-To: <bug-10088-206@http.llvm.org/bugs/>
References: <bug-10088-206@http.llvm.org/bugs/>
Message-ID: <20110606190410.B37422A6C12D@llvm.org>

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

Stuart Hastings <stuart at apple.com> changed:

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

--- Comment #2 from Stuart Hastings <stuart at apple.com> 2011-06-06 14:04:10 CDT ---
Fixed in 132606.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 14:07:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 14:07:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10085] cannot select FGETSIGN on x86_fp80
In-Reply-To: <bug-10085-206@http.llvm.org/bugs/>
References: <bug-10085-206@http.llvm.org/bugs/>
Message-ID: <20110606190716.013662A6C12C@llvm.org>

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

Stuart Hastings <stuart at apple.com> changed:

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

--- Comment #3 from Stuart Hastings <stuart at apple.com> 2011-06-06 14:07:15 CDT ---
Fixed in 132681.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 15:52:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 15:52:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10090] New: ScalarEvolution: requires 8MB stack
 size to compile a test case with long "value chain"
Message-ID: <bug-10090-206@http.llvm.org/bugs/>

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

           Summary: ScalarEvolution: requires 8MB stack size to compile a
                    test case with long "value chain"
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bixia.zheng at amd.com
                CC: llvmbugs at cs.uiuc.edu


The test case below stress the recursive algorithm used in ScalarEvulution.
On 64bit win7 with stack size set to 4MB, running "opt -O3" gives stack
overflow. Increasing the stack size to 8MB makes "opt -O3" pass.

We need a solution that does not rely on increasing the stack size:
(1) make the recursive algorithm aware of the depth of the recursive call
chains. This makes it possible to trade-off optimization aggressiveness for
small stack size
 or 
(2) to replace the recursive algorithm with a non-recursive algorithm without
such a problem.


//test case
#define REPEAT_1 i1 = i1 ^ i2; i2 += i1; n++;

#define REPEAT_5 \
    REPEAT_1 \
    REPEAT_1 \
    REPEAT_1 \
    REPEAT_1 \
    REPEAT_1

#define REPEAT_10 \
    REPEAT_5 \
    REPEAT_5 \

#define REPEAT_50 \
    REPEAT_10 \
    REPEAT_10 \
    REPEAT_10 \
    REPEAT_10 \
    REPEAT_10

#define REPEAT_100 \
    REPEAT_50 \
    REPEAT_50 \


#define REPEAT_500 \
    REPEAT_100 \
    REPEAT_100 \
    REPEAT_100 \
    REPEAT_100 \
    REPEAT_100

#define REPEAT_1000 \
    REPEAT_500 \
    REPEAT_500 \


extern int getid(int);
void foo(unsigned int *output)
{
  unsigned int i1 = -1, i2 = 0, n = getid(0), sum = 0;

  for (unsigned loop = 0; loop < 1; loop++) {
    // repeat the "i1 = .." line 2000 times
    REPEAT_1000
    REPEAT_1000
    sum += i1 + n;
  }

  *output = sum;
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 16:14:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 16:14:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10091] New: Please, add support of -MT option
Message-ID: <bug-10091-206@http.llvm.org/bugs/>

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

           Summary: Please, add support of -MT option
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: anton.kochkov at gmail.com
                CC: llvmbugs at cs.uiuc.edu


>From GCC help:

-MT target Change the target of the rule emitted by dependency generation. By
default CPP takes the name of the main input file, deletes any directory
components and any file suffix such as `.c', and appends the platform's usual
object suffix. The result is the target.

An -MT option will set the target to be exactly the string you specify. If you
want multiple targets, you can specify them as a single argument to -MT, or use
multiple -MT options.

For example, -MT '$(objpfx)foo.o' might give
         $(objpfx)foo.o: foo.c

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

From bugzilla-daemon at llvm.org  Mon Jun  6 17:04:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 17:04:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10092] New: -O0 -regalloc=greedy -disable-fp-elim
	crash
Message-ID: <bug-10092-206@http.llvm.org/bugs/>

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

           Summary: -O0 -regalloc=greedy -disable-fp-elim crash
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

$ ./bin/llc test.ll -O0 -regalloc=greedy -disable-fp-elim 
Don't know how to fold this instruction!
UNREACHABLE executed at
/home/espindola/llvm/llvm/lib/Target/X86/X86InstrInfo.cpp:2423!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 17:16:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 17:16:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10093] New: clang disallows to instantiate template
 for typedefed class
Message-ID: <bug-10093-206@http.llvm.org/bugs/>

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

           Summary: clang disallows to instantiate template for typedefed
                    class
           Product: clang
           Version: trunk
          Platform: Other
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: yuri at tsoft.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

I get such warning with typedef.
st1.C:14:21: warning: qualifier in explicit instantiation of 'Cls<int>::less'
requires a template-id (a typedef is not permitted)
template bool TCls::less(const TCls*, const TCls*);

And no warning without the typedef.

There is no danger in allowing such instantiation. This should be allowed for
better flexibility of templateed code.

gcc (as of 4.6.0) allows such instantiation.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  6 17:24:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 17:24:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10094] New: --analyze does not produce warning when
 ignoring return values
Message-ID: <bug-10094-206@http.llvm.org/bugs/>

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

           Summary: --analyze does not produce warning when ignoring
                    return 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: noloader at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6702)
 --> (http://llvm.org/bugs/attachment.cgi?id=6702)
Test program from OpenSSL website

The attached program (taken from
http://www.openssl.org/docs/crypto/EVP_DigestInit.html) does not generate a
warning when ignoring return values. EVP_DigestInit_ex, EVP_DigestUpdate,
EVP_DigestUpdate, EVP_DigestFinal_ex, adn EVP_MD_CTX_cleanup each return 1 for
success (see http://www.openssl.org/docs/crypto/EVP_DigestInit.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 Jun  6 18:21:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 18:21:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10095] New: [MC] Object writer drops W even if
 relocations are present
Message-ID: <bug-10095-206@http.llvm.org/bugs/>

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

           Summary: [MC] Object writer drops W even if relocations are
                    present
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


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

After r131951, linker sets on NetBSD are no longer writeable. They do have
outstanding relocations and that breaks with --warn-text-rel during linkage. A
preprocessed example is attached. Compile with -O2 -fPIC and compare the flags
of section "link_set_all_categories" before and after this change.

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

From bugzilla-daemon at llvm.org  Mon Jun  6 18:55:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 18:55:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10070] Needless sse spill/reload
In-Reply-To: <bug-10070-206@http.llvm.org/bugs/>
References: <bug-10070-206@http.llvm.org/bugs/>
Message-ID: <20110606235546.305F52A6C124@llvm.org>

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

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> 2011-06-06 18:55:45 CDT ---
Fixed in r132697, 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  Mon Jun  6 20:11:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 20:11:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10094] --analyze does not produce warning when
 ignoring return values
In-Reply-To: <bug-10094-206@http.llvm.org/bugs/>
References: <bug-10094-206@http.llvm.org/bugs/>
Message-ID: <20110607011143.F17332A6C12C@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

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

From bugzilla-daemon at llvm.org  Mon Jun  6 21:21:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon,  6 Jun 2011 21:21:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10093] clang disallows to instantiate template for
 typedefed class
In-Reply-To: <bug-10093-206@http.llvm.org/bugs/>
References: <bug-10093-206@http.llvm.org/bugs/>
Message-ID: <20110607022159.82E0F2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-06-06 21:21:58 CDT ---
C++ [temp.explicit]p3 is very clear that this code is ill-formed. However,
since no other vendors seem to implement this rule, I've downgraded it to an
"Extension" so it won't warn by default.

Fixed in Clang r132704.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  7 00:17:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  7 Jun 2011 00:17:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10096] New: Early tail dup can cause problems to
 register allocator don't
Message-ID: <bug-10096-206@http.llvm.org/bugs/>

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

           Summary: Early tail dup can cause problems to register
                    allocator don't
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

I am reporting a bug to keep track of the recent discussions on llvm-commits.

With the attached bitcode file:

$ time ./bin/llc -disable-early-taildup ~/llvm/master2.bc  -o master.o
-tail-dup-size=8 -filetype=obj

real    0m1.667s
user    0m1.640s
sys    0m0.024s

$ ls -l master.o
-rw-rw-r--. 1 espindola espindola 126256 Jun  7 01:19 master.o

$ time ./bin/llc  ~/llvm/master2.bc  -o master.o  -filetype=obj

real    0m24.317s
user    0m24.204s
sys    0m0.063s
$ ls -l master.o
-rw-rw-r--. 1 espindola espindola 675912 Jun  7 01:20 master.o

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

From bugzilla-daemon at llvm.org  Tue Jun  7 09:17:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  7 Jun 2011 09:17:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9716] -ffast-math -O2
 -fplugin-arg-dragonegg-enable-gcc-optzns fails to compile aermod.f90
In-Reply-To: <bug-9716-206@http.llvm.org/bugs/>
References: <bug-9716-206@http.llvm.org/bugs/>
Message-ID: <20110607141750.C743A2A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #12 from Duncan Sands <baldrick at free.fr> 2011-06-07 09:17:50 CDT ---
Support for rsqrtf was added here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110606/121968.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 Jun  7 09:54:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  7 Jun 2011 09:54:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9716] -ffast-math -O2
 -fplugin-arg-dragonegg-enable-gcc-optzns fails to compile aermod.f90
In-Reply-To: <bug-9716-206@http.llvm.org/bugs/>
References: <bug-9716-206@http.llvm.org/bugs/>
Message-ID: <20110607145451.B782F2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
         Resolution|FIXED                       |DUPLICATE

--- Comment #16 from Duncan Sands <baldrick at free.fr> 2011-06-07 09:54:51 CDT ---
My mistake, I forgot to add -fplugin-arg-dragonegg-enable-gcc-optzns (!).
Yes, this is PR2314.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  7 15:20:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  7 Jun 2011 15:20:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10097] New: MCDisassembler is unable to decode XOR
	r32, r/m32
Message-ID: <bug-10097-206@http.llvm.org/bugs/>

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

           Summary: MCDisassembler is unable to decode XOR r32,r/m32
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: karl.vogel at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The MCDisassembler is unable to decode the XOR r32,r/m32 variant. It only knows
the XOR r/m32,r32 variant.

$ echo "0x31 0xc0"|./bin/llvm-mc --disassemble
    xorl    %eax, %eax
$ echo "0x33 0xc0"|./bin/llvm-mc --disassemble
<stdin>:1:1: warning: invalid instruction encoding
0x33 0xc0
^

both are valid opcode sequences. (cfr. Intel(R) 64 and IA-32 Architectures
Software Developer's Manual, Volume 2 (2A & 2B) - Vol 2B p4-515).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  7 18:30:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue,  7 Jun 2011 18:30:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10095] [MC] Object writer drops W even if
 relocations are present
In-Reply-To: <bug-10095-206@http.llvm.org/bugs/>
References: <bug-10095-206@http.llvm.org/bugs/>
Message-ID: <20110607233032.33AE62A6C124@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

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

--- Comment #2 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-06-07 18:30:31 CDT ---
Fixed in 132735.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 03:08:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 03:08:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10014] vect_var_.957_3273 =
 [vec_unpack_float_lo_expr] vect_var_.955_3272
In-Reply-To: <bug-10014-206@http.llvm.org/bugs/>
References: <bug-10014-206@http.llvm.org/bugs/>
Message-ID: <20110608080802.BAB762A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-06-08 03:08:01 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110606/122000.html
The resulting code is not pretty, but that needs to be fixed in the LLVM code
generators.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 04:03:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 04:03:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10098] New: Should codegen to CVTDQ2PD etc but is
	scalarized
Message-ID: <bug-10098-206@http.llvm.org/bugs/>

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

           Summary: Should codegen to CVTDQ2PD etc but is scalarized
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


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

In the attached testcases, the vector operations are all scalarized by codegen,
but GCC manages to produce vector code for all of them (they correspond to
vec_unpack_lo_expr, vec_unpack_hi_expr, vec_unpack_float_lo_expr,
vec_unpack_float_hi_expr).  The simplest case looks to be @float_lo which could
be codegened as a CVTDQ2PD instruction.

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

From bugzilla-daemon at llvm.org  Wed Jun  8 04:48:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 04:48:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10099] New: rsqrt_ss has wrong type
Message-ID: <bug-10099-206@http.llvm.org/bugs/>

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

           Summary: rsqrt_ss has wrong type
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


The rsqrtss instruction takes the reciprocal square root of a float, but LLVM
declares it as taking <4 x float>:

  def int_x86_sse_rsqrt_ss : GCCBuiltin<"__builtin_ia32_rsqrtss">,
              Intrinsic<[llvm_v4f32_ty], [llvm_v4f32_ty],
                        [IntrNoMem]>;

Note that it is rsqrt_ps (declared just afterwards) that operates on <4 x
float>.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 06:11:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 06:11:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10100] New: Debian sid installs crt{1, i,
 n}.o in multi-arch lib directory
Message-ID: <bug-10100-206@http.llvm.org/bugs/>

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

           Summary: Debian sid installs crt{1,i,n}.o in multi-arch lib
                    directory
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: themiwi at users.sourceforge.net
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6711)
 --> (http://llvm.org/bugs/attachment.cgi?id=6711)
Search crt{1,i,n}.o in mutli-arch library directory on Debian

A recent updated of the eglibc package in Debian sid now installs the
crt{1,i,n}.o files in a multi-arch directory under /usr/lib
(/usr/lib/i386-linux-gnu and /usr/lib/x86_64-linux-gnu for i386 and amd64,
respectively). Attached patch teaches tools/Driver/ToolChains.cpp to look there
if compiling natively.

I'm not quite happy with the patch, because on a i386 install, the GccTriple is
i486-linux-gnu, but the multi-arch triple in the installation path is
i386-linux-gnu, so this needs a bit of hackery...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 12:31:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 12:31:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10101] New: [QoI] error recovery and fixit for
 stray ; in function definition
Message-ID: <bug-10101-206@http.llvm.org/bugs/>

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

           Summary: [QoI] error recovery and fixit for stray ; in function
                    definition
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I occasionally forget to remove the semicolon after the function declaration
when copying it to write a function definition:


struct C
{
  int foo();
};

int C::foo();
{
}

C c;
int n = c.foo();


clang complains:

my_file.cpp:6:8: error: out-of-line declaration of a member must be a
definition
int C::foo();
    ~~~^
my_file.cpp:7:1: error: expected unqualified-id
{
^
my_file.cpp:11:9: error: use of undeclared identifier 'c'
int n = c.foo();
        ^


These errors are not awesome! A function declaration (which is the sole
declarator in the declaration) at namespace scope, followed by '{' or 'try' or
':', is most likely a function definition with a stray ';'. This would be
fantastic:

my_file.cpp:5:13: error: stray ';' in function definition
int C::foo();
            ^

(with a fixit to remove the ';').


The same error recovery should probably also apply to tag declarations at
namespace scope followed by '{' or ':', though those cases probably don't occur
in practice as frequently.


We're also skipping too far forwards when we encounter the stray '{': it seems
we skip to the next (top-level) semicolon and thus usually skip the rest of the
translation unit (as can be seen above: 'C c;' is skipped). This skipping is
also visible with typos like this:

extenr "C" {
  void f();
}

void g() {
  la la la la la;  
}

my_file.cpp:1:1: error: unknown type name 'extenr'; did you mean 'extern'?
extenr "C" {
^
my_file.cpp:1:8: error: expected unqualified-id
extenr "C" {
       ^

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

From bugzilla-daemon at llvm.org  Wed Jun  8 15:57:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 15:57:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8030] Add code coverage support / create gcov
	replacement
In-Reply-To: <bug-8030-206@http.llvm.org/bugs/>
References: <bug-8030-206@http.llvm.org/bugs/>
Message-ID: <20110608205724.DF3032A6C124@llvm.org>

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

Nick Lewycky <nlewycky at google.com> changed:

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

--- Comment #1 from Nick Lewycky <nlewycky at google.com> 2011-06-08 15:57:24 CDT ---
Fixed, we now support GCOV data 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  Wed Jun  8 16:33:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 16:33:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10102] New: Warn on attribute mismatch between
 prototype and body
Message-ID: <bug-10102-206@http.llvm.org/bugs/>

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

           Summary: Warn on attribute mismatch between prototype and body
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


clang doesn't warn for the following when compiling for i386:

__attribute__((__regparm__(3))) int test(int);

int test(int a)
{
    return a;
}

GCC warns on i386 and silently accepts it on amd64. The GCC behavior is more
useful here IMO.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 17:10:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 17:10:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10082] invalid cast assertion
In-Reply-To: <bug-10082-206@http.llvm.org/bugs/>
References: <bug-10082-206@http.llvm.org/bugs/>
Message-ID: <20110608221006.7FCE32A6C12D@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #4 from Cameron Zwarich <zwarich at apple.com> 2011-06-08 17:10:05 CDT ---
Fixed in r132759.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 17:46:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 17:46:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10103] New: enum type translation functions
 generate a lot of code
Message-ID: <bug-10103-206@http.llvm.org/bugs/>

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

           Summary: enum type translation functions generate a lot of code
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jmuizelaar at mozilla.com
                CC: llvmbugs at cs.uiuc.edu


The following code compiles to a jump table instead of a simpler version that
uses the fact that the enum values are the same:

enum bar {
        MROUND, MSQUARE, MBUTT, MTRI, MERROR
};

enum foo { FROUND, FSQUARE, FBUTT, FTRI, FERROR} ;

enum foo t(enum bar m) {
        switch (m) {
                case MROUND:
                        return FROUND;
                case MSQUARE:
                        return FSQUARE;
                case MBUTT:
                        return FBUTT;
                case MTRI:
                        return FTRI;
                default:
                case MERROR:
                        return FERROR;
        }
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 17:48:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 17:48:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8962] Static analyzer fail with GObject macro
In-Reply-To: <bug-8962-206@http.llvm.org/bugs/>
References: <bug-8962-206@http.llvm.org/bugs/>
Message-ID: <20110608224825.5B9682A6C124@llvm.org>

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

Jordy Rose <jediknil at belkadan.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 Jun  8 18:09:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 18:09:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10104] New: Test case from PR10082 miscompiled
Message-ID: <bug-10104-206@http.llvm.org/bugs/>

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

           Summary: Test case from PR10082 miscompiled
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: zwarich at apple.com
                CC: llvmbugs at cs.uiuc.edu


One of the test cases checked in from PR10082 is still misoptimized by
scalarrepl.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 18:47:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 18:47:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8962] Static analyzer fail with GObject macro
In-Reply-To: <bug-8962-206@http.llvm.org/bugs/>
References: <bug-8962-206@http.llvm.org/bugs/>
Message-ID: <20110608234745.25A212A6C124@llvm.org>

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

Jordy Rose <jediknil at belkadan.com> changed:

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

--- Comment #5 from Jordy Rose <jediknil at belkadan.com> 2011-06-08 18:47:44 CDT ---
Okay, I take it back, that's not the only problem. Something about
__extension__ together with the statement expression is acting funny...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  8 18:51:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 18:51:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10105] New: DWARF compile_unit is missing AT_low_pc
	attribute
Message-ID: <bug-10105-206@http.llvm.org/bugs/>

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

           Summary: DWARF compile_unit is missing AT_low_pc attribute
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: wiml at omnigroup.com
                CC: llvmbugs at cs.uiuc.edu


The compilation unit DIE emitted by llvm is missing the low_pc attribute, which
is necessary in order to interpret location lists (AT_location) and range lists
(AT_ranges) referred to by that DIE's debug information.

OTOH, llvm does emit an entry_pc attribute whose value is what I'd expect the
low_pc to be. This may be a misreading of a remark in 2.18, which says that if
the entry_pc is missing, then a consumer can assume that it's the same as
low_pc; perhaps llvm simply gets this backwards? At any rate, DWARF doesn't
define a meaning for entry_pc when found in a compilation unit, so it seems
like an error.

For reference see the following bits of the DWARF4 spec (iiirc, there's no
substantial difference here wrt DWARF3):
  Section 3.1.1, last paragraph.
  Section 3.1.1, top of p.44
For the use of the compilation unit's base address in location lists and range
lists: 2.6.2; 2.17.3

Here's a snippet of dwarfdump output:

0x0000000b: TAG_compile_unit [1] *
             AT_producer( "clang version 3.0 (trunk 132731)" )
             AT_language( DW_LANG_C99 )
             AT_name( "split.c" )
             AT_entry_pc( 0x0000000000000000 )
             AT_stmt_list( 0x00000000 )
             AT_comp_dir( "/Volumes/Local/wiml/netsrc/llvm.org/build" )
             AT_APPLE_optimized( 0x01 )

[....]
0x0000008f:         TAG_formal_parameter [3]  
[....]
                     AT_location( 0x00000000
                        0x0000000000000000 - 0x000000000000000c: rdi
                        0x000000000000000c - 0x000000000000001f: rbx )


Note that there's no explicit base address entry in the location list
(hex-dumping the debug_loc section confirms this), and therefore it relies on
the base address given by the containing compilation unit.

I just tested against clang trunk r132731, and the versions shipped with
Apple's Xcode 3.x behave the same 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  Wed Jun  8 19:15:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 19:15:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 6965] Alignment for ByVal arguments does not work
	on x86_64
In-Reply-To: <bug-6965-206@http.llvm.org/bugs/>
References: <bug-6965-206@http.llvm.org/bugs/>
Message-ID: <20110609001548.347722A6C12E@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #17 from Eric Christopher <echristo at gmail.com> 2011-06-08 19:15:47 CDT ---
Fixed thusly:


[event-10-1-113-217:~/sources/llvm] echristo% svn ci
Sending        lib/CodeGen/CallingConvLower.cpp
Adding         test/CodeGen/X86/byval-align.ll
Transmitting file data ..
Committed revision 132764.


Can you verify?

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

From bugzilla-daemon at llvm.org  Wed Jun  8 20:48:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed,  8 Jun 2011 20:48:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10104] Test case from PR10082 miscompiled
In-Reply-To: <bug-10104-206@http.llvm.org/bugs/>
References: <bug-10104-206@http.llvm.org/bugs/>
Message-ID: <20110609014837.03D252A6C12C@llvm.org>

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

Cameron Zwarich <zwarich at apple.com> changed:

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

--- Comment #6 from Cameron Zwarich <zwarich at apple.com> 2011-06-08 20:48:36 CDT ---
I fixed it a bit differently in r132766., by adding a bounds check on the
implied vector access. I think there are still some crazy theoretical edge
cases here with vector types whose allocated size differs from their bitwise
size, but I'll try to make some test cases. I might have to make up some fake
TargetData to trigger 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  Thu Jun  9 00:02:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 00:02:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10106] New: LTO crash possibly related to
	zero-length arrays
Message-ID: <bug-10106-206@http.llvm.org/bugs/>

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

           Summary: LTO crash possibly related to zero-length arrays
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

In my code, I've got something like

value = buffer[(writeIndex - 1) & (buflen - 1)];

which if I change to the incorrect

value = buffer[(writeIndex - 1) & buflen];

no longer crashes the code generator. buflen is a constant 32 which gets fed
in, so there's something clever it must be trying to do. In any case, I've
attached the simplified .bc file from running Bugpoint on it. Hopefully that is
of some use.

The structs involved here look like

#define CDC_BUFLEN (32)

struct PSB_Ring_Type
{
    uintptr_t ReadIndex, WriteIndex;
    uint8_t   Buffer[0];
} PACKED_ALIGN(4);

struct PSB_CDC_Side_Type
{
    struct PSB_Ring_Type Ring;
    uint8_t              Buffer[CDC_BUFLEN];
    uint32_t             BaudRate;
} PACKED_ALIGN(4);

struct PSB_CDC_Type
{
    struct PSB_CDC_Side_Type FromMe, ToMe;
} PACKED_ALIGN(4);

I'm thinking it might have something to do with calculating the address of
PSB_Ring_Type's Buffer, or parts of the structure after it. In any case, this
crashes the assembler when LTO 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  Thu Jun  9 02:42:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 02:42:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10107] New: Address of compound literal fails in
 gnu++0x but not C99
Message-ID: <bug-10107-206@http.llvm.org/bugs/>

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

           Summary: Address of compound literal fails in gnu++0x but not
                    C99
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: 691D2C6C-B023-46A5-B1D7-ACCBA4713A87 at uuid-mail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The code below is C99 and supported by GCC in C++ mode since they allow 
C99 features.

Clang accepts the code in C99 mode, it (correctly) says that compound 
literals are a C99-specific feature in C++ mode, but with -std=gnu++0x 
(which should support GCC extensions, i.e. C99) I get the following 
error:

    error: taking the address of a temporary object of type 'struct 
point' [-Waddress-of-temporary]

----------8<----------

struct point { int x; int y; };
void draw_point (struct point const* aPoint) { }

int main (int argc, char const* argv[])
{
    draw_point(&(struct point){ 1, 2 });
    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  Thu Jun  9 02:55:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 02:55:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10108] New: Property of reference type not
 supported for Objective-C++
Message-ID: <bug-10108-206@http.llvm.org/bugs/>

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

           Summary: Property of reference type not supported for
                    Objective-C++
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: 691D2C6C-B023-46A5-B1D7-ACCBA4713A87 at uuid-mail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


GCC supports reference types for properties in Objective-C++ mode. This is not
supported by clang even when using -std=gnu++0x.

Example:

% cat main.mm
#import <Foundation/Foundation.h>

@interface Test : NSObject { int i; }
@property (readonly) int const& i;
@end

@implementation Test
@synthesize i;
@end

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

----------8<----------

% clang++ -std=gnu++0x -lobjc -framework Foundation main.mm
main.mm:4:1: error: property of reference type is not supported
@property (readonly) int const& i;
^
main.mm:8:13: error: property implementation must have its declaration in
interface 'Test'
@synthesize i;
            ^
2 errors generated.

----------8<----------

Using references is required when wrapping non-POD types in an Objective-C
class.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  9 04:11:01 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 04:11:01 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10109] New: Segfault compiling template with
 invalid nested type
Message-ID: <bug-10109-206@http.llvm.org/bugs/>

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

           Summary: Segfault compiling template with invalid nested type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: max at duempel.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6715)
 --> (http://llvm.org/bugs/attachment.cgi?id=6715)
test source code

The attached source code cannot be compiled with clang trunk/2.9. It is
important that both the "template" and the "protected" keywords are present;
with "public" or "private", it does not crash. I get the following crash
message:

bug.cpp:5:13: error: template specialization or definition requires a template
parameter list corresponding to the nested type 'A<T>'
  struct B::C;
            ^
bug.cpp:5:13: error: no struct named 'C' in 'A::B'
  struct B::C;
         ~~~^
0  clang           0x00000000017e537f
1  clang           0x00000000017e57e9
2  libpthread.so.0 0x00007f81adad9020
3  clang           0x00000000008dfe1a
4  clang           0x00000000008e1359
5  clang           0x00000000008e2511
6  clang           0x00000000008e2779
7  clang           0x00000000008ebdc2
clang::Sema::HandleDelayedAccessCheck(clang::sema::DelayedDiagnostic&,
clang::Decl*) + 1602
8  clang           0x000000000096c7fc
clang::Sema::DelayedDiagnostics::popParsingDecl(clang::Sema&,
clang::Sema::ParsingDeclState, clang::Decl*) + 124
9  clang           0x00000000008b4307
clang::Parser::ParseCXXClassMemberDeclaration(clang::AccessSpecifier,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject*) + 5799
10 clang           0x00000000008b522f
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 1455
11 clang           0x00000000008b6360
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 3376
12 clang           0x00000000008a3d51
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 1345
13 clang           0x0000000000886ddd
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier) + 749
14 clang           0x000000000088a106
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 614
15 clang           0x00000000008a841a
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 458
16 clang           0x0000000000896931
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 769
17 clang           0x00000000008974bc
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 140
18 clang           0x0000000000870c9d clang::ParseAST(clang::Sema&, bool) + 253
19 clang           0x0000000000750e13 clang::CodeGenAction::ExecuteAction() +
51
20 clang           0x000000000066a9a3
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 307
21 clang           0x000000000064a74b
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 955
22 clang           0x000000000063ff62 cc1_main(char const**, char const**, char
const*, void*) + 706
23 clang           0x0000000000649106 main + 678
24 libc.so.6       0x00007f81acdbfead __libc_start_main + 253
25 clang           0x000000000063fb39
Stack dump:
0.      Program arguments: /usr/local/stow/llvm/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name bug.cpp -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21.52.20110606
-momit-leaf-frame-pointer -resource-dir
/usr/local/stow/llvm/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 266 -fcxx-exceptions -fexceptions -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-MO7CtE.o -x c++
bug.cpp 
1.      bug.cpp:6:1: current parser token '}'
2.      bug.cpp:2:1: parsing struct/union/class body 'A'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 2 (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  Thu Jun  9 10:01:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 10:01:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9931] Assertion `L->isLCSSAForm(*DT)' failed.
In-Reply-To: <bug-9931-206@http.llvm.org/bugs/>
References: <bug-9931-206@http.llvm.org/bugs/>
Message-ID: <20110609150156.C839B2A6C12C@llvm.org>

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

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

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

--- Comment #7 from John Regehr <regehr at cs.utah.edu> 2011-06-09 10:01:55 CDT ---
Works!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  9 10:21:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 10:21:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10110] New: Add support for
 __attribute__((bitwise)) and -Wbitwise
Message-ID: <bug-10110-206@http.llvm.org/bugs/>

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

           Summary: Add support for __attribute__((bitwise)) and -Wbitwise
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tim.nieradzik at gmx.de
                CC: llvmbugs at cs.uiuc.edu


__attribute__((bitwise)) allows annotating integer types to detect type
mismatches. This feature is implemented in Sparse but it would be certainly
useful if Clang could do these checks out-of-the-box.

>From the man page:

---
Warn about unsupported operations or type mismatches with restricted integer
types.
Sparse supports an extended attribute, __attribute__((bitwise)), which creates
a new restricted integer type from a base integer type, distinct from the base
integer type and from any other restricted integer type not declared in the
same declaration or typedef. For example, this allows programs to create
typedefs for integer types with specific endianness. With -Wbitwise, Sparse
will warn on any use of a restricted type in arithmetic operations other than
bitwise operations, and on any conversion of one restricted type into another,
except via a cast that includes __attribute__((force)).
---

The Linux kernel already makes extensive use of __attribute__((bitwise)) to
distinguish between big-endian and little-endian integers, cf.
http://www.gelato.unsw.edu.au/IA64wiki/SparseAnnotations

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  9 10:24:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 10:24:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10111] New: nonnull attribute generates a warning
 for transparent unions
Message-ID: <bug-10111-206@http.llvm.org/bugs/>

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

           Summary: nonnull attribute generates a warning for transparent
                    unions
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tim.nieradzik at gmx.de
                CC: llvmbugs at cs.uiuc.edu


typedef struct {
    char *str;
} Class;

typedef union {
    Class *object;
} Instance __attribute__((transparent_union));

__attribute__((nonnull(1))) void Class_init(Instance this, char *str) {
    this.object->str = str;
}

int main(void) {
    Class obj;
    Class_init(0, "Hello World");
}

Clang reports: "nonnull attribute only applies to pointer arguments". However,
as transparent unions are guaranteed to contain only pointers, using nonnull is
safe.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  9 10:56:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 10:56:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10107] Address of compound literal fails in gnu++0x
	but not C99
In-Reply-To: <bug-10107-206@http.llvm.org/bugs/>
References: <bug-10107-206@http.llvm.org/bugs/>
Message-ID: <20110609155602.233622A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-06-09 10:56:01 CDT ---
Clang errors in all C++ modes, since this is an extension that is extremely
unsafe. You can downgrade the error to a warning with the

  -Wno-error=address-of-temporary

command-line option or turn it off entirely with

  -Wno-address-of-temporary

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  9 11:38:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 11:38:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10112] New: extra error message for problems in
 statement expressions
Message-ID: <bug-10112-206@http.llvm.org/bugs/>

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

           Summary: extra error message for problems in statement
                    expressions
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bob.wilson at apple.com
                CC: llvmbugs at cs.uiuc.edu


Clang is not propagating expression errors for statement expressions so that it
thinks that the expression type is void, which in turn causes an extra error
message to be printed.

Testcase:

$ cat experr.c 
float test(int v) {
  return ({ int __a = (v); (float)__a/; });
}


$ clang -S experr.c 
experr.c:2:39: error: expected expression
  return ({ int __a = (v); (float)__a/; });
                                      ^
experr.c:2:10: error: returning 'void' from a function with incompatible result
      type 'float'
  return ({ int __a = (v); (float)__a/; });
         ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2 errors generated.

That second message ("returning 'void'....") should be suppressed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  9 13:17:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 13:17:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10113] New: Explicit template instantiation with
 default visibility fails to generate global symbols for certain types
Message-ID: <bug-10113-206@http.llvm.org/bugs/>

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

           Summary: Explicit template instantiation with default
                    visibility fails to generate global symbols for
                    certain types
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: 691D2C6C-B023-46A5-B1D7-ACCBA4713A87 at uuid-mail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Explicit template instantiation does not (always) result in an exported symbol
when compiling with ?-fvisibility=hidden? despite setting the visibility
attribute to ?default? for the template prototype.

Example source (lib.cc):

    #include <string>

    template <typename T> __attribute__((__visibility__("default")))
    void foo (T value) { /* dummmy */ }

    template void foo (std::string value);
    template void foo (int value);

Building with clang++ and dumping global symbols:

    % clang++ -dynamiclib -fvisibility=hidden lib.cc -o lib.dylib && nm -g
lib.dylib|c++filt 
    0000000000000f30 T void foo<int>(int)
                     U dyld_stub_binder

Building with g++ and dumping global symbols:

    % g++ -dynamiclib -fvisibility=hidden lib.cc -o lib.dylib && nm -g
lib.dylib|c++filt 
    0000000000000f0c T void foo<std::basic_string<char, std::char_traits<char>,
std::allocator<char> > >(std::basic_string<char, std::char_traits<char>,
std::allocator<char> >)
    0000000000000f16 T void foo<int>(int)
                     U ___gxx_personality_v0
                     U dyld_stub_binder

Notice that the std::string specialization is missing when using clang++.

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

From bugzilla-daemon at llvm.org  Thu Jun  9 13:55:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 13:55:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10092] -O0 -regalloc=greedy -disable-fp-elim crash
In-Reply-To: <bug-10092-206@http.llvm.org/bugs/>
References: <bug-10092-206@http.llvm.org/bugs/>
Message-ID: <20110609185512.A23052A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-09 13:55:12 CDT ---
r132789

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  9 13:58:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 13:58:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10114] New: EltsFromConsecutiveLoads does not
 preserve chain successor dependencies from the original loads.
Message-ID: <bug-10114-206@http.llvm.org/bugs/>

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

           Summary: EltsFromConsecutiveLoads does not preserve chain
                    successor dependencies from the original loads.
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jan_sjodin at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


The EltsFromConsecutiveLoads in X86ISelLowering.cpp replaces several load
instructions with a single instruction. But if the replaced loads are before a
a call the new load may be inserted after the call, because the dependencies
are not preserved.

For example:

          chain
        /       \
       /         \
      V           V
 load addr       load addr+4
   |  \           /   |
   |   \         /    |
   |    V       V     |
   |   token_factor   |
   |         |        |
   \         |        /
    \        V       /
     \     call     / 
      \            / 
       \          / 
        \        /
       op1      op2

Will be replaced with:



       token_factor
            |
            |
            V
          call

          chain
            |
            |
            V  
          vload (not guaranteed to be executed before the call)
           /  \
          /    \
         /      \
       op1      op2

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun  9 14:16:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 14:16:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10115] New: clang crashes on invalid code
Message-ID: <bug-10115-206@http.llvm.org/bugs/>

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

           Summary: clang crashes on invalid code
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zaffanella at cs.unipr.it
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


When parsing the following invalid code

struct S {
  int m[];
  not_known foo();
  S() {}
};

clang crashes on an assertion producing the following:

$ Debug+Asserts/bin/clang++  -c bug.cc
bug.cc:3:3: error: unknown type name
      'not_known'
  not_known foo();
  ^
clang: SemaDeclCXX.cpp:2260: bool
clang::Sema::SetCtorInitializers(clang::CXXConstructorDecl*,
clang::CXXCtorInitializer**, unsigned int, bool): Assertion
`ClassDecl->hasFlexibleArrayMember() && "Incomplete array type is not valid"'
failed.

[...]

1.    bug.cc:4:7: current parser token '{'
2.    bug.cc:1:1: parsing struct/union/class body 'S'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)

Note that the assertion is not triggered if the method foo() is commented 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 Jun  9 17:56:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 17:56:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10116] New: [mc] No support for .common
Message-ID: <bug-10116-206@http.llvm.org/bugs/>

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

           Summary: [mc] No support for .common
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$ cat test.cc 
void f() {
  asm volatile(".common _f,8,8");
}

thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$ gcc -c test.cc
thakis at yearofthelinuxdesktop:/usr/local/google/chrome/src$
third_party/llvm-build/Release+Asserts/bin/clang -c test.cc
test.cc:2:16: error: warning: ignoring directive for now
  asm volatile(".common _f,8,8");
               ^
<inline asm>:1:2: note: instantiated into assembly here
        .common _f,8,8
        ^
1 error generated.

This is a bogus example. Real code that uses this is e.g. here:
http://google.com/codesearch#OAMlx_jo-ck/src/seccompsandbox/linux_syscall_support.h&q=linux_syscall_support.h&l=1435
(used by chrome/linux).

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

From bugzilla-daemon at llvm.org  Thu Jun  9 18:41:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu,  9 Jun 2011 18:41:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10117] New: Strange multiplication result possibly
 related to trapping
Message-ID: <bug-10117-206@http.llvm.org/bugs/>

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

           Summary: Strange multiplication result possibly related to
                    trapping
           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: wendling at apple.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6719)
 --> (http://llvm.org/bugs/attachment.cgi?id=6719)
Shows the failing program.

The attached program when run claims that 29 * 29 == 1711. This isn't exactly
correct. 

$ clang++ -o bar -O1 -fPIC foo.cpp
$ ./bar
...

diffX: 29 diffY: 0
diffX squared: 1711
diffY squared: 0
diffX * diffX + diffY * diffY :: 1711
a 41.3642
41.3642

If you use -ftrapv, the value is okay. But there doesn't seem to be any
undefined behavior 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 Jun 10 02:40:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 02:40:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10118] New: (in_file_option "-i") does not work
Message-ID: <bug-10118-206@http.llvm.org/bugs/>

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

           Summary: (in_file_option "-i") does not work
           Product: tools
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llvmc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: idolihal at fit.vutbr.cz
                CC: llvmbugs at cs.uiuc.edu


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

Hi, 
  I would like to create compiler driver llvmc. But as soon as I use in file
option, error is reported. I use the examples/Skeleton/Autogenerated.td file
and the error is reported in Autogenerated.inc. 

Error looks like that:
AutoGenerated.inc: In member function ?virtual
int<unnamed>::assembler2::GenerateAction(llvmc::Action&, const
llvmc::PathVector&, bool, const llvm::sys::Path&, const
llvmc::InputLanguagesSet&, const llvmc::LanguageMap&) const?:
AutoGenerated.inc:92: error: expected ?)? before ?;? token
AutoGenerated.inc: In member function ?virtual
int<unnamed>::assembler2::GenerateAction(llvmc::Action&, const
llvm::sys::Path&, bool, const llvm::sys::Path&, const
llvmc::InputLanguagesSet&, const llvmc::LanguageMap&) const?:
AutoGenerated.inc:128: error: expected ?)? before ?;? token

I attach Autogenerated.td as well as Autogenerated.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  Fri Jun 10 02:49:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 02:49:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9969] Warn about missing parentheses for ?: operator
In-Reply-To: <bug-9969-206@http.llvm.org/bugs/>
References: <bug-9969-206@http.llvm.org/bugs/>
Message-ID: <20110610074956.327F52A6C12E@llvm.org>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #3 from Hans Wennborg <hans at chromium.org> 2011-06-10 02:49:55 CDT ---
(In reply to comment #2)
> That doesn't cover overloaded operators such as in Chandler's example, though.
> I'll try to address that too.

Fixed in r132784.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 10 10:17:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 10:17:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10119] New: Placement new bug with -O2 or -O3 and
	-DNDEBUG
Message-ID: <bug-10119-206@http.llvm.org/bugs/>

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

           Summary: Placement new bug with -O2 or -O3 and -DNDEBUG
           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: m95lah at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6725)
 --> (http://llvm.org/bugs/attachment.cgi?id=6725)
Program that demonstrates bug.

I am experiencing a problem when building some c++ code with -O2 or -O3 and
-DNDEBUG.
It seems to be related to a use of placement new, but it could be something
else as well.

The problem occurs when using Boost.Interprocess 1.46 shared memory strings. It
appears that the internal string does not get correctly null terminated. E.g.
calling c_str() returns a string that is not null terminated. 

Attached is a snippet of code that, if compiled with -O2 -DNDEBUG -lrt
-lpthread shows the problem. 
It will allocate a bunch of short strings and compare it with .c_str(). If a
string fails to compare correctly it will print the strings.

I'm using ubuntu natty 64bit with clang/llvm svn r131788/r131725.

I've tried to rearrange some of the code in
boost/interprocess/containers/container/boost.hpp to see if I could see any
specific construction that causes this problem, but when I move stuff around
(e.g. priv_construct_null(...) the problem disappears.
So I am guessing this is either to do with the placement new that is performed
further into the code from priv_construct_null, or some optimization that
removes the function altogether...

I'd be happy to help by providing more info or testing things.

/Lars

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 10 12:09:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 12:09:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9684] llvm-gcc and clang both miscompile
 nedit-5.5/source/regularExp.c at -O2
In-Reply-To: <bug-9684-206@http.llvm.org/bugs/>
References: <bug-9684-206@http.llvm.org/bugs/>
Message-ID: <20110610170932.9CB842A6C12D@llvm.org>

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

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

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

--- Comment #5 from Benjamin Kramer <benny.kra at gmail.com> 2011-06-10 12:09:31 CDT ---
This is a bug in nedit. It boils down to:

===
#include <string.h>
#include <limits.h>

static unsigned char Default_Delimiters[UCHAR_MAX] = {0};

int main() {
  memset(Default_Delimiters, 0, 256);
}
===

The memset will overrun Default_Delimiters by one byte. OS X enables checking
of memset bounds, in this case it only sees the size of Default_Delimiters
through inlining at -O2 though.

You can either patch nedit or compile with -D_FORTIFY_SOURCE=0, which disables
memset checking.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 10 14:51:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 14:51:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10119] Placement new bug with -O2 or -O3 and
	-DNDEBUG
In-Reply-To: <bug-10119-206@http.llvm.org/bugs/>
References: <bug-10119-206@http.llvm.org/bugs/>
Message-ID: <20110610195153.B98102A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-10 14:51:53 CDT ---
The issue comes down to the following code in boost::interprocess::offset_ptr:
   void* get_pointer() const
   {  return (internal.m_offset == 1) ? 0 :
(const_cast<char*>(reinterpret_cast<const char*>(this)) + internal.m_offset); }

Given the values of m_offset which are used, this code has undefined behavior
per the C++ standard.  As such, marking invalid; please file a bug against
boost.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 10 15:08:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 15:08:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8962] Static analyzer fail with GObject macro
In-Reply-To: <bug-8962-206@http.llvm.org/bugs/>
References: <bug-8962-206@http.llvm.org/bugs/>
Message-ID: <20110610200849.42D612A6C124@llvm.org>

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

Jordy Rose <jediknil at belkadan.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|REOPENED                    |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 Jun 10 15:28:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 15:28:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10120] New: Wrong vtable for template class
 instantiated with anonymous type
Message-ID: <bug-10120-206@http.llvm.org/bugs/>

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

           Summary: Wrong vtable for template class instantiated with
                    anonymous type
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: 691D2C6C-B023-46A5-B1D7-ACCBA4713A87 at uuid-mail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6726)
 --> (http://llvm.org/bugs/attachment.cgi?id=6726)
Sample project to show problem

If in a header I declare a template class like this:

   // header.h
   #include <assert.h>
   #include <typeinfo>

   template <typename T>
   class klass
   {
       char const* tn1 () const         { return typeid(T()).name(); }
       virtual char const* tn2 () const { return typeid(T()).name(); }
   public:
       void test () const               { assert(tn1() == tn2());    }
   };

Then in two different translation units instantiate the template class with
identically named types, but from anonymous namespaces, example:

   // foo.cc
   #include "header.h"
   namespace { struct my_type_t { }; }
   void foo () { klass<my_type_t> foo_instance; foo_instance.test(); }

   // bar.cc
   #include "header.h"
   namespace { struct my_type_t { }; }
   void bar () { klass<my_type_t> bar_instance; bar_instance.test(); }

Then the two instances will share the same vtable, meaning calling tn2() on
either will return the same value, whereas calling tn1() will return different
values.

The assertion in test() will fail for one of the two instances.

To test this, save the 3 files above and add main.cc as:

   // main.cc
   void foo ();
   void bar ();

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

Then in Terminal run:

   % clang++ {foo,bar,main}.cc && ./a.out

The result I get is:

   Assertion failed: (tn1() == tn2()), function test, file ./header.h, line 10.

I also attached an archive with the four files + build.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  Fri Jun 10 16:58:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 16:58:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10120] Wrong vtable for template class instantiated
 with anonymous type
In-Reply-To: <bug-10120-206@http.llvm.org/bugs/>
References: <bug-10120-206@http.llvm.org/bugs/>
Message-ID: <20110610215803.3DE1C2A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-10 16:58:02 CDT ---
r132861.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 10 18:10:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 18:10:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10121] New: mem2reg/scalarrepl is blocked by
 llvm.lifetime.start/end
Message-ID: <bug-10121-206@http.llvm.org/bugs/>

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

           Summary: mem2reg/scalarrepl is blocked by
                    llvm.lifetime.start/end
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: nicholas at mxc.ca, llvmbugs at cs.uiuc.edu


At the moment, lifetime.begin/end blocks mem2reg and scalarepl; that's bad. I
ran into this while reducing bug 10119.  This will get a lot worse if we start
emitting lifetime intrinsics outside of the inliner.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 10 20:07:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 20:07:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10106] LTO crash possibly related to zero-length
	arrays
In-Reply-To: <bug-10106-206@http.llvm.org/bugs/>
References: <bug-10106-206@http.llvm.org/bugs/>
Message-ID: <20110611010745.657EF2A6C12C@llvm.org>

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

James Bellinger <xocotl at gmail.com> changed:

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

--- Comment #4 from James Bellinger <xocotl at gmail.com> 2011-06-10 20:07:44 CDT ---
Basically compiling it with full LTO does.
I have upgraded to the newest SVN (was using about a three week old one before)
and I do not get the crash anymore. I'll let you know if the resulting code
generation is wrong or anything.

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

From bugzilla-daemon at llvm.org  Fri Jun 10 21:14:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 10 Jun 2011 21:14:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10122] New: Need warning group for "local
 declaration of 'foo' hides instance variable" warning
Message-ID: <bug-10122-206@http.llvm.org/bugs/>

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

           Summary: Need warning group for "local declaration of 'foo'
                    hides instance variable" warning
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


See
http://stackoverflow.com/questions/6311126/how-to-disable-the-local-declaration-of-foo-hides-instance-variable-warning
; it isn't possible to disable this warning at the moment.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 11 03:10:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 11 Jun 2011 03:10:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10123] New: Linker error when mixing visibility
Message-ID: <bug-10123-206@http.llvm.org/bugs/>

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

           Summary: Linker error when mixing visibility
           Product: clang
           Version: 2.9
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: 691D2C6C-B023-46A5-B1D7-ACCBA4713A87 at uuid-mail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6727)
 --> (http://llvm.org/bugs/attachment.cgi?id=6727)
Example project

If I define a new non-POD type in a header and then include this header from
two sources, respectively compiled with -fvisibility=hidden and
-fvisibility=default *and* -m32 then I get a linker error if both sources
instantiate the non-POD type, example of error:

   ld: bad codegen, pointer diff in _main to global weak symbol
__ZNSt6vectorIiSaIiEED1Ev for architecture i386

This is even though the shared header is enclosed in #pragma GCC visibility
push(default) ? pop.

Note though that it *does* link without problems when building with -m64.

I have attached an example project with a build.sh which shows the problem.

If you wonder why I mix visibility for my sources then it is due to issue
10113, which prevents me from compiling all my sources with visibility set to
hidden.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 11 04:44:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 11 Jun 2011 04:44:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10124] New: libclang: clang_CXCursorSet_contains()
 returns opposite of correct value
Message-ID: <bug-10124-206@http.llvm.org/bugs/>

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

           Summary: libclang: clang_CXCursorSet_contains() returns
                    opposite of correct value
           Product: clang
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jjk at acm.org
                CC: llvmbugs at cs.uiuc.edu


clang_CXCursorSet_contains() is documented to return a non-zero value when the
cursor is found
in the set. The implementation however returns 0 in this case (and 1 if the
cursor isn't found).

I think this is just a typo (== for !=).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 12 02:33:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 12 Jun 2011 02:33:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10125] New: debug variables incorrectly deleted by
 LLVM in the Live Debug Variables pass
Message-ID: <bug-10125-206@http.llvm.org/bugs/>

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

           Summary: debug variables incorrectly deleted by LLVM in the
                    Live Debug Variables pass
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Common Code Generator Code
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: yousef.shajrawi at amd.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6728)
 --> (http://llvm.org/bugs/attachment.cgi?id=6728)
simple OpenCL kernel exibiting this bug

There is a problem with handling DEBUG_VALUE in the method
LDVImpl::collectDebugValues in the Live Debug Variables pass.

The 7th basic block in the kernel vecMul had the DEBUG_VALUE as the first line
in the basic block. Attached to vreg9 which is first defined in this basic
block (1st instruction).

handleDebugValue() returned true and the debug value was erased from the basic
block. In later passes vreg9 is replaced with vreg31 (simple register
coalescing) and later on vreg31 is removed all together (register allocation)
thus removing line #7 from the basic block.

A change is needed for the method LDVImpl::collectDebugValues to handle
DBG_VALUE that has no slot index / use the previous instruction instead &
Handle consecutive DBG_VALUE instructions with the same slot index as follows:

  ? In case the target/register operand of the DBG_VALUE is a live in of the
basic block (as it is the regular usual case, for example in the prolog BB and
the variables passed to the kernel)
    o work as usual / previous behavior..
  ? Else (the bug described above)
    o Do not erase the DEBUG_VALUE instruction from the basic block

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

From bugzilla-daemon at llvm.org  Sun Jun 12 11:51:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 12 Jun 2011 11:51:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10126] New: Class accessed before it is constructed
 not warned about
Message-ID: <bug-10126-206@http.llvm.org/bugs/>

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

           Summary: Class accessed before it is constructed not warned
                    about
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: overminddl1 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


There is an article on GOTW listed on: http://www.gotw.ca/gotw/080.htm
It details a program bug that is not caught be almost every compiler.  Here is
the example program:
"""
#include <string>
using namespace std;

class A
{
public:
  A( const string& s ) { /* ... */ }
  string f() { return "hello, world"; }
};

class B : public A
{
public:
  B() : A( s = f() ) {} // The bug is on this line
private:
  string s;
};

int main()
{
  B b;
}
"""
The bug is in the A( s = f() ) call, it calls f() (which is in A and 'this' is
not constructed yet), and it sets s to it (which is in B and not constructed
yet since A is not yet constructed), then passes the result on to A.

clang++ currently issues no warning about the code even with -Wall on the trunk
as of r132876.  As an enhancement, this kind of access should be warned about
on some level.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 12 13:56:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 12 Jun 2011 13:56:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10127] New: Clang does not implement N3031:
 decltype(type)::subtype does not compile
Message-ID: <bug-10127-206@http.llvm.org/bugs/>

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

           Summary: Clang does not implement N3031:
                    decltype(type)::subtype does not compile
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The following program does not compile with clang r132676:

struct Vec3 {
    typedef float value_type;
};


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

    decltype(v)::value_type    x;    // Should work according to N3031
}

This results in:

$ clang -std=c++0x -stdlib=libc++ clang.cpp
clang.cpp:10:15: error: definition or redeclaration of 'value_type' cannot name
the global scope
        decltype(v)::value_type x;      // Should work according to N3031
                   ~~^
clang.cpp:10:15: error: no member named 'value_type' in the global namespace
        decltype(v)::value_type x;      // Should work according to N3031
                   ~~^
clang.cpp:10:25: error: expected ';' at end of declaration
        decltype(v)::value_type x;      // Should work according to N3031
                               ^
                               ;
3 errors generated.



This is because clang does not implement N3031 yet, the resolution for core
issue 743 which has been included in FDIS.

Core Issue 743:
http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2011/n3237.html#743

N3031: http://www.open-std.org/jtc1/sc22/wg21/docs/papers/2010/n3031.pdf

Related StackOverflow question:
http://stackoverflow.com/questions/6101728/behavior-of-decltype

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 12 23:49:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 12 Jun 2011 23:49:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10128] New: ARM Thumb 2: Alignment getting lost
 between .ll and .s
Message-ID: <bug-10128-206@http.llvm.org/bugs/>

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

           Summary: ARM Thumb 2: Alignment getting lost between .ll and .s
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6731)
 --> (http://llvm.org/bugs/attachment.cgi?id=6731)
llvm code you can compile to see the problem

On this .ll file, the syntax I am using is:
llc -mcpu=cortex-m3 -filetype=asm Bad.ll
Alternatively -filetype=obj.

In any case, __node_3__locals is not being aligned.
When emitted as an ELF, it places at 0x1d in .bss.
It's a 4-byte value, so this causes a crash at runtime.
The .s file doesn't have any align directives that I
can see for the value, while the .ll file does. ELF
output has this same problem, so the bug must be before
it gets that far.

This does not occur if these variables are not internalized.
Only when declared static or when internalized for global
optimization does this occur. If the symbols are exported,
the problem isn't there. Perhaps it's some optimization that
only occurs when they are local?

This bug is causing me serious problems, so please take a
look at it.

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

From bugzilla-daemon at llvm.org  Mon Jun 13 01:24:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 01:24:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10129] New: clang crashes with -Wlarge-by-value-copy
Message-ID: <bug-10129-206@http.llvm.org/bugs/>

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

           Summary: clang crashes with -Wlarge-by-value-copy
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


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

1. unzip tmp.ii.zip
2. thakis$ ~/src/llvm-rw/Release+Asserts/bin/clang -Wlarge-by-value-copy tmp.ii

Crashes:
Assertion failed: (0 && "Unknown builtin type!"), function getTypeInfo, file
ASTContext.cpp, line 798.0  clang             0x0000000101759c02
PrintStackTrace(void*) + 341  clang             0x000000010175aa53
SignalHandler(int) + 7072  libSystem.B.dylib 0x00007fff812f266a _sigtramp + 263
 libSystem.B.dylib 0x00007fff5fbfb12e _sigtramp + 37340146864  clang           
 0x000000010001a832 __assert_rtn + 665  clang             0x0000000100898aed
clang::ASTContext::getTypeInfo(clang::Type const*) const + 13896  clang        
    0x0000000100899385 clang::ASTContext::getTypeInfo(clang::Type const*) const
+ 3589
7  clang             0x000000010089b092
clang::ASTContext::getTypeSizeInChars(clang::QualType) const + 50
8  clang             0x000000010041a116
clang::Sema::DiagnoseSizeOfParametersAndReturnValue(clang::ParmVarDecl* const*,
clang::ParmVarDecl* const*, clang::QualType, clang::NamedDecl*) + 166
9  clang             0x000000010041fded
clang::Sema::ActOnFinishFunctionBody(clang::Decl*, clang::Stmt*, bool) + 237
10 clang             0x0000000100364d78
clang::Parser::ParseFunctionStatementBody(clang::Decl*,
clang::Parser::ParseScope&) + 248
11 clang             0x0000000100313136
clang::Parser::ParseLexedMethodDef(clang::Parser::LexedMethod&) + 262
12 clang             0x0000000100312c68
clang::Parser::ParseLexedMethodDefs(clang::Parser::ParsingClass&) + 104
13 clang             0x000000010033632c
clang::Parser::ParseCXXMemberSpecification(clang::SourceLocation, unsigned int,
clang::Decl*) + 988
14 clang             0x0000000100337f83
clang::Parser::ParseClassSpecifier(clang::tok::TokenKind,
clang::SourceLocation, clang::DeclSpec&, clang::Parser::ParsedTemplateInfo
const&, clang::AccessSpecifier, bool) + 4755
15 clang             0x0000000100323309
clang::Parser::ParseDeclarationSpecifiers(clang::DeclSpec&,
clang::Parser::ParsedTemplateInfo const&, clang::AccessSpecifier,
clang::Parser::DeclSpecContext) + 3689
16 clang             0x000000010036e486
clang::Parser::ParseSingleDeclarationAfterTemplate(unsigned int,
clang::Parser::ParsedTemplateInfo const&,
clang::Parser::ParsingDeclRAIIObject&, clang::SourceLocation&,
clang::AccessSpecifier) + 710
17 clang             0x000000010036f419
clang::Parser::ParseTemplateDeclarationOrSpecialization(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 761
18 clang             0x000000010036f841
clang::Parser::ParseDeclarationStartingWithTemplate(unsigned int,
clang::SourceLocation&, clang::AccessSpecifier) + 417
19 clang             0x000000010032bbe8
clang::Parser::ParseDeclaration(clang::ASTOwningVector<clang::Stmt*, 32u>&,
unsigned int, clang::SourceLocation&,
clang::Parser::ParsedAttributesWithRange&) + 760
20 clang             0x000000010037d93f
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 1327
21 clang             0x000000010037e39d
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 173
22 clang             0x000000010031248b clang::ParseAST(clang::Sema&, bool) +
299
23 clang             0x00000001002de23c clang::CodeGenAction::ExecuteAction() +
60
24 clang             0x00000001000593f1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 433
25 clang             0x0000000100024f95
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1493
26 clang             0x000000010001bb51 cc1_main(char const**, char const**,
char const*, void*) + 577
27 clang             0x0000000100023dee main + 4526
28 clang             0x000000010001af84 start + 52
29 clang             0x0000000000000028 start + 4294856920
Stack dump:
0.    Program arguments: /Users/thakis/src/llvm-rw/Release+Asserts/bin/clang
-cc1 -triple x86_64-apple-macosx10.6.7 -emit-obj -mrelax-all -disable-free
-main-file-name tmp.ii -pic-level 1 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 97.17 -resource-dir
/Users/thakis/src/llvm-rw/Release+Asserts/bin/../lib/clang/3.0
-fdeprecated-macro -Wlarge-by-value-copy 64 -ferror-limit 19 -fmessage-length
188 -fobjc-infer-related-result-type -stack-protector 1 -fblocks
-fcxx-exceptions -fexceptions -fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/cc-fGB3vb.o -x c++-cpp-output
tmp.ii 
1.    ../base/observer_list.h:187:2: current parser token ';'
2.    ../base/observer_list.h:65:1: parsing struct/union/class body
'ObserverListBase'
3.    ../base/observer_list.h:116:39: parsing function body
'ObserverListBase<ObserverType>'
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Mon Jun 13 02:43:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 02:43:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10130] New: 2 scan-build crashes
Message-ID: <bug-10130-206@http.llvm.org/bugs/>

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

           Summary: 2 scan-build crashes
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: nizze86 at hotmail.com
                CC: llvmbugs at cs.uiuc.edu


I tried running a build or rockbox[1] through scan-build. Twice clang started
eating all my memory (4G real 8G swap) and finally crashed or was killed by the
OOM. Attatched is an archive with the files it placed in the 'failures' dir.

[1]: www.rockbox.org

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 13 12:25:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 12:25:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10131] New: Clang crashes after printing diagnostic
Message-ID: <bug-10131-206@http.llvm.org/bugs/>

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

           Summary: Clang crashes after printing diagnostic
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: matthieu.monrocq at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

This simple (but erroneous) program crashes clang:

  #include <string>

  class StringRef
  {
  public:
    typedef std::size_t Length;

    StringRef(std::string const& s): buffer(s.buffer()), length(s.size() {}

    template <Length N>
    StringRef(char const (&s)[N]): buffer(s), length(N-1) {}

  private:
    char const* buffer;
    Length length;
  }; // class StringRef

(See output at the end of the bug report)

I have not succeeded in reducing the file further, and it contains 2 errors:
- 's.buffer()' as there is no such string method
- 'length(s.size()' as a parenthesis is missing

Interestingly enough removing the 'typedef std::size_t Length' or the template
constructor solve the crash.

Output by Clang:

$ clang++ -fsyntax-only crasher.cpp -v
clang version 3.0 (trunk 132889)
Target: i686-pc-mingw32
Thread model: posix
 "d:/clang/build-cmake/bin/clang++.exe" -cc1 -triple i686-pc-mingw32
-fsyntax-only -disable-free -main-file-name crasher.cpp -mrelocation-model
static -mdisable-fp-elim -mconstructor-aliases -target-cpu pentium4
-momit-leaf-frame-pointer -v -resource-dir
d:/clang/build-cmake/bin\..\lib\clang\3.0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 200 -fobjc-infer-related-result-type -fcxx-exceptions
-fexceptions -fno-use-cxa-atexit -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -x c++ ../test/crasher.cpp
clang -cc1 version 3.0 based upon llvm 3.0 hosted on i686-pc-mingw32
ignoring nonexistent directory "c:/MinGW/lib/gcc/mingw32/4.5.0/include/c++"
ignoring nonexistent directory
"c:/MinGW/lib/gcc/mingw32/4.5.0/include/c++/mingw32"
ignoring nonexistent directory
"c:/MinGW/lib/gcc/mingw32/4.5.0/include/c++/backward"
ignoring nonexistent directory "c:/MinGW/lib/gcc/mingw32/4.4.0/include/c++"
ignoring nonexistent directory
"c:/MinGW/lib/gcc/mingw32/4.4.0/include/c++/mingw32"
ignoring nonexistent directory
"c:/MinGW/lib/gcc/mingw32/4.4.0/include/c++/backward"
ignoring nonexistent directory "c:/MinGW/lib/gcc/mingw32/4.3.0/include/c++"
ignoring nonexistent directory
"c:/MinGW/lib/gcc/mingw32/4.3.0/include/c++/mingw32"
ignoring nonexistent directory
"c:/MinGW/lib/gcc/mingw32/4.3.0/include/c++/backward"
ignoring nonexistent directory "/usr/local/include"
ignoring nonexistent directory "c:/mingw/include"
ignoring nonexistent directory "/usr/include"
#include "..." search starts here:
#include <...> search starts here:
 /mingw/lib/gcc/mingw32/4.5.2/include/c++
 /mingw/lib/gcc/mingw32/4.5.2/include/c++/mingw32
 /mingw/lib/gcc/mingw32/4.5.2/include/c++/backward
 d:/clang/build-cmake/bin/../lib/clang/3.0/include
 /mingw/include
End of search list.
../test/crasher.cpp:16:22: error: expected '}'
}; // class StringRef
                     ^
../test/crasher.cpp:4:1: note: to match this '{'
{
^
../test/crasher.cpp:8:45: error: no member named 'buffer' in
'std::basic_string<char>'
  StringRef(std::string const& s): buffer(s.buffer()), length(s.size() {}
                                          ~ ^
../test/crasher.cpp:8:72: error: expected ')'
  StringRef(std::string const& s): buffer(s.buffer()), length(s.size() {}
                                                                       ^
../test/crasher.cpp:8:62: note: to match this '('
  StringRef(std::string const& s): buffer(s.buffer()), length(s.size() {}
                                                             ^
../test/crasher.cpp:8:56: error: member initializer 'length' does not name a
non-static data member or base class
  StringRef(std::string const& s): buffer(s.buffer()), length(s.size() {}
                                                       ^~~~~~~~~~~~~~~~~
../test/crasher.cpp:14:21: error: expected '{' or ','
  char const* buffer;
                    ^
../test/crasher.cpp:15:3: error: unknown type name 'Length'
  Length length;
  ^
Stack dump:
0.      Program arguments: d:/clang/build-cmake/bin/clang++.exe -cc1 -triple
i686-pc-mingw32 -fsyntax-only -disable-free -main-file-name crasher.cpp
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases -target-cpu
pentium4 -momit-leaf-frame-pointer -v -resource-dir
d:/clang/build-cmake/bin\..\lib\clang\3.0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 200 -fobjc-infer-related-result-type -fcxx-exceptions
-fexceptions -fno-use-cxa-atexit -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -x c++ ../test/crasher.cpp
1.      ../test/crasher.cpp:15:10: current parser token 'length'
01438F96 (0xB381E376 0x0000003C 0x0000000E 0x01355CB1)
0048A83E (0x024A9900 0x022F9370 0x0022E268 0x0022E28C)
01355EF3 (0x0225A4C0 0x022F9370 0x7C920041 0x003E0C28)
0048B440 (0x0225A4C0 0x00000001 0x0022E2C8 0x014505D5)
01355FF4 (0x0225A4C0 0x00000000 0x00000007 0x0022E2E8)
013928DC (0x02284FC8 0x00000006 0x0000011A 0x00000268)
004D25EE (0x02284FC8 0x0022E6C4 0x00000000 0x00000001)
004B3F81 (0x02284FC8 0x0022E898 0x004B4714 0x00000000)
004B3E8A (0x02284FC8 0x0022E898 0x0022ED14 0x00000000)
004AD6BB (0x02284FC8 0x0022ED14 0x00000000 0x00000001)
0049F57C (0x02284FC8 0x0022ED14 0x00000003 0x00000000)
0049F5D2 (0x02284FC8 0x0022F118 0x00000003 0x0022F038)
0049EF2B (0x02284FC8 0x0022F118 0x00000000 0x0022F11C)
0049E5DB (0x02284FC8 0x0022F160 0x022841C8 0x00456349)
0049C313 (0x022841C8 0x00000000 0x00000000 0x0143DE78)
00460D24 (0x0225AC30 0x0225A1DC 0x00000013 0xFFFFFFFF)
004609AE (0x0225AC30 0x003EFEA8 0x0225AB84 0x00000013)
004572F5 (0x003EFEA8 0x0225AC30 0x00000003 0x00000000)
0047904B (0x003EFEA8 0x0225A8F0 0x0022F6F0 0x00000000)
004038F5 (0x0022F6F0 0x0022F76C 0x003EFEF4 0x004013C0)
00402739 (0x7FFDF000 0x000001E7 0x0022FFA0 0x004010DB)
004010DB (0x00000001 0xB5B04D08 0x7C91DCBA 0x7C817074)
00401178 (0x000001A6 0x000001E7 0x7FFDF000 0xC0000005)
7C817077 (0x00401160 0x00000000 0x78746341 0x00000020),
RegisterWaitForInputIdle()+0073 bytes(s)
clang++: error: clang frontend command failed due to signal 1073741819 (use -v
to see invocation)

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

From bugzilla-daemon at llvm.org  Mon Jun 13 13:16:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 13:16:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10132] New: clang c++ missing error on union with
 multiple members initialized
Message-ID: <bug-10132-206@http.llvm.org/bugs/>

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

           Summary: clang c++ missing error on union with multiple members
                    initialized
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Testcase:
union U { int a, b; U() : a(10),b(20) {} };

clang accepts this.  gcc gives:
<stdin>: In constructor ?U::U()?:
<stdin>:1: error: initializations for multiple members of ?U?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 13 13:23:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 13:23:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10132] clang c++ missing error on union with
 multiple members initialized
In-Reply-To: <bug-10132-206@http.llvm.org/bugs/>
References: <bug-10132-206@http.llvm.org/bugs/>
Message-ID: <20110613182302.1C8B12A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-13 13:23:01 CDT ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 13 16:33:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 16:33:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10133] New: Objective-C should adopt `auto` keyword
	from C++0x
Message-ID: <bug-10133-206@http.llvm.org/bugs/>

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

           Summary: Objective-C should adopt `auto` keyword from C++0x
           Product: clang
           Version: unspecified
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: kyle at omnigroup.com
                CC: llvmbugs at cs.uiuc.edu


C++0x overloads the auto keyword to support type inference in declarations.
This makes declarations much shorter and more readable without sacrificing
static type safety. Objective-C should adopt this feature, with the additional
enhancement of using `auto` in the return type of a declaration to refer to the
type of the receiver (or an instance of the receiver in class methods). For
example:

@interface MyObject : NSObject

+ (auto)sharedInstance; // every subclass has its own shared instance
+ (NSString *)defaultName;

- (auto)initWithName:(NSString *)name;

@property(readonly, nonatomic) NSString *name;

@end

@implementation MyObject

+ (auto)sharedInstance;
{
    static NSDictionary classToInstanceMap;
    if (!classToInstanceMap)
      classToInstanceMap = [[NSDictionary alloc] init];

    NSString *className = NSStringFromClass(self);
    MyObject *instance = [classToInstanceMap valueForKey:className];
    if (!instance) {
      instance = [[[self alloc] initWithName:[self defaultName]] autorelease];
      [classToInstanceMap setValue:instance forKey:className];
    }

    return instance;
}

+ (NSString *)defaultName;
{
    return @"defaultInstance";
}

- (auto)initWithName:(NSString *)name;
{
    return [[self class] initWithName:name];
}

@end

// ---

@interface SpecialObject : MyObject

@property(readonly, nonatomic) NSUInteger numberOfFoos;

@end

// ---

void DoSomething()
{
    auto anObject = [SpecialObject sharedInstance];
    NSLog(@"%lu", anObject.numberOfFoos); // okay; type inference says that
+[SpecialController sharedController] returns an instance of SharedController

    auto nFoos = anObject.numberOfFoos;
    NSLog(@"%@", nFoos.intValue); // error: invalid type `unsigned long` of
receiver

    anObject = [[MyObject alloc] init]; // error: anObject was already
determined to be of type MyObject at declaration

    auto anotherObject; // error: can't infer type without initializer
}

// ----****----

It's worth noting the compiler still needs the hardcoded knowledge that
-[NSObject class] returns an instance of the _metaclass_ of the receiver.
Alternatively, a new keyword like `auto Class` could be used here that is only
valid in the return type of a method declaration.

These keywords should all be implemented in terms of implied properties. That
is to say, these two declarations should be equivalent:

- (auto)initWithFoo:(id)foo;
- (id)initWithFoo:(id)foo __attribute__((__auto_return__));

As should these:

- (auto Class)class;
- (Class)class __attribute__((__auto_class_return__));

The programmer should be instructed to keep using explicit type declarations
where it makes sense--that is, where the intended API guarantee is only that
instances of a certain type are returned, even if a subclass overrides the
method. For example, +[NSDocumentController sharedDocumentController] should
*not* be declared with `auto`, because calling +sharedDocumentController on any
subclass should always return the same value, even if that instance is not of
the type of an instance of the receiver.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 13 17:14:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 17:14:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10133] Objective-C should adopt `auto` keyword from
	C++0x
In-Reply-To: <bug-10133-206@http.llvm.org/bugs/>
References: <bug-10133-206@http.llvm.org/bugs/>
Message-ID: <20110613221439.65B2F2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #1 from Chris Lattner <clattner at apple.com> 2011-06-13 17:14:38 CDT ---
Hi Kyle,

Please file this in bugreporter.apple.com, thanks!

-Chris

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

From bugzilla-daemon at llvm.org  Mon Jun 13 18:41:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 18:41:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7838] unable to generate code for
 llvm.smul.with.overflow.i64 on x86-32
In-Reply-To: <bug-7838-206@http.llvm.org/bugs/>
References: <bug-7838-206@http.llvm.org/bugs/>
Message-ID: <20110613234126.586CF2A6C135@llvm.org>

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

Bartosz Brachaczek <b.brachaczek at gmail.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  Mon Jun 13 20:32:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 13 Jun 2011 20:32:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10134] New: MC has movq and movd wrong
Message-ID: <bug-10134-206@http.llvm.org/bugs/>

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

           Summary: MC has movq and movd wrong
           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: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


Binutils doesn't care about the difference between movd and movq, in that
these:

  movq %rdi,%xmm0
  movd %rdi,%xmm0

both assemble to "66 48 0f 6e c7". However, MC rejects the former and accepts
the latter. It's great that it's distinguishing between the two ...

... but it's got it backwards. According to
http://support.amd.com/us/Processor_TechDocs/26568.pdf (book #26568?Rev.
3.12?May 2011) movd is for moving between XMM and 32-bit while movq is for
moving between XMM and 64-bit:

"Mnemonic Opcode Description
MOVD xmm, reg32/mem32 66 (W0) 0F 6E /r Move a 32-bit value from reg32/mem32 to
xmm.
MOVQ xmm, reg64/mem64 66 (W1) 0F 6E /r Move a 64-bit value from reg64/mem64 to
xmm.
MOVD reg32/mem32, xmm 66 (W0) 0F 7E /r Move a 32-bit value from xmm to
reg32/mem32
MOVQ reg64/mem64, xmm 66 (W1) 0F 7E /r Move a 64-bit value from xmm to
reg64/mem64."

%rdi is 64-bit and thusly should really be a movq, not a movd. This is breaking
current versions of OpenSSL.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 14 07:49:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 07:49:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10135] New: recent trunk build fails LLVM ::
 CodeGen/X86/mem-promote-integers.ll
Message-ID: <bug-10135-206@http.llvm.org/bugs/>

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

           Summary: recent trunk build fails LLVM ::
                    CodeGen/X86/mem-promote-integers.ll
           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: apacherulzz at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


FAIL: Clang :: Driver/hello.c (1399 of 9276)
******************** TEST 'Clang :: Driver/hello.c' FAILED ********************
Script:
--
/opt/llvm/build/Release+Asserts/bin/clang  -ccc-echo -o
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.exe
/opt/llvm/llvm/tools/clang/test/Driver/hello.c 2>
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.log
grep 'clang\(-[0-9.]\+\)\?\(\.[Ee][Xx][Ee]\)\?" -cc1 .*hello.c'
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.log
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.exe >
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.out
grep "I'm a little driver, short and stout."
/opt/llvm/build/tools/clang/test/Driver/Output/hello.c.tmp.out
--
Exit Code: 1

********************
FAIL: LLVM :: CodeGen/X86/mem-promote-integers.ll (5814 of 9276)
******************** TEST 'LLVM :: CodeGen/X86/mem-promote-integers.ll' FAILED
********************
Script:
--
/opt/llvm/build/Release+Asserts/bin/llc -march=x86 -promote-elements <
/opt/llvm/llvm/test/CodeGen/X86/mem-promote-integers.ll
/opt/llvm/build/Release+Asserts/bin/llc -march=x86                   <
/opt/llvm/llvm/test/CodeGen/X86/mem-promote-integers.ll
/opt/llvm/build/Release+Asserts/bin/llc -march=x86-64 -promote-elements <
/opt/llvm/llvm/test/CodeGen/X86/mem-promote-integers.ll
/opt/llvm/build/Release+Asserts/bin/llc -march=x86-64                   <
/opt/llvm/llvm/test/CodeGen/X86/mem-promote-integers.ll
--
Exit Code: 134
Command Output (stdout):
--
    .file    "<stdin>"
    .text
    .globl    test_1xi8
    .align    16, 0x90
    .type    test_1xi8, at function
test_1xi8:                              # @test_1xi8
.Ltmp0:
    .cfi_startproc
# BB#0:
    movl    8(%esp), %ecx
    movb    4(%esp), %al
    xorb    (%ecx), %al
    movb    %al, (%ecx)
    ret
.Ltmp1:
    .size    test_1xi8, .Ltmp1-test_1xi8
.Ltmp2:
    .cfi_endproc
.Leh_func_end0:

    .globl    test_1xi16
    .align    16, 0x90
    .type    test_1xi16, at function
test_1xi16:                             # @test_1xi16
.Ltmp3:
    .cfi_startproc
# BB#0:
    movl    8(%esp), %ecx
    movw    4(%esp), %ax
    xorw    (%ecx), %ax
    movw    %ax, (%ecx)
    ret
.Ltmp4:
    .size    test_1xi16, .Ltmp4-test_1xi16
.Ltmp5:
    .cfi_endproc
.Leh_func_end1:

    .globl    test_1xi32
    .align    16, 0x90
    .type    test_1xi32, at function
test_1xi32:                             # @test_1xi32
.Ltmp6:
    .cfi_startproc
# BB#0:
    movl    8(%esp), %ecx
    movl    4(%esp), %eax
    xorl    (%ecx), %eax
    movl    %eax, (%ecx)
    ret
.Ltmp7:
    .size    test_1xi32, .Ltmp7-test_1xi32
.Ltmp8:
    .cfi_endproc
.Leh_func_end2:

    .globl    test_1xi64
    .align    16, 0x90
    .type    test_1xi64, at function
test_1xi64:                             # @test_1xi64
.Ltmp10:
    .cfi_startproc
# BB#0:
    subl    $12, %esp
.Ltmp11:
    .cfi_def_cfa_offset 16
    movl    24(%esp), %ecx
    movl    16(%esp), %eax
    movl    20(%esp), %edx
    xorl    (%ecx), %eax
    xorl    4(%ecx), %edx
    movl    %edx, 4(%ecx)
    movl    %eax, (%ecx)
    movl    %edx, 4(%esp)
    movl    %eax, (%esp)
    pinsrd    $1, 4(%esp), %xmm0
    pinsrd    $3, 8(%esp), %xmm0
    pextrd    $2, %xmm0, %edx
    movd    %xmm0, %eax
    addl    $12, %esp
    ret
.Ltmp12:
    .size    test_1xi64, .Ltmp12-test_1xi64
.Ltmp13:
    .cfi_endproc
.Leh_func_end3:

    .globl    test_1xi128
    .align    16, 0x90
    .type    test_1xi128, at function
test_1xi128:                            # @test_1xi128
.Ltmp18:
    .cfi_startproc
# BB#0:
    pushl    %ebx
.Ltmp19:
    .cfi_def_cfa_offset 8
    pushl    %edi
.Ltmp20:
    .cfi_def_cfa_offset 12
    pushl    %esi
.Ltmp21:
    .cfi_def_cfa_offset 16
.Ltmp22:
    .cfi_offset %esi, -16
.Ltmp23:
    .cfi_offset %edi, -12
.Ltmp24:
    .cfi_offset %ebx, -8
    movl    16(%esp), %eax
    movl    36(%esp), %esi
    movl    20(%esp), %edx
    movl    24(%esp), %ecx
    xorl    (%esi), %edx
    xorl    4(%esi), %ecx
    movl    28(%esp), %ebx
    movl    32(%esp), %edi
    xorl    8(%esi), %ebx
    xorl    12(%esi), %edi
    movl    %edi, 12(%esi)
    movl    %ebx, 8(%esi)
    movl    %ecx, 4(%esi)
    movl    %edx, (%esi)
    movl    %edx, (%eax)
    movl    %ecx, 4(%eax)
    movl    %ebx, 8(%eax)
    movl    %edi, 12(%eax)
    popl    %esi
    popl    %edi
    popl    %ebx
    ret    $4
.Ltmp25:
    .size    test_1xi128, .Ltmp25-test_1xi128
.Ltmp26:
    .cfi_endproc
.Leh_func_end4:

    .globl    test_1xi256
    .align    16, 0x90
    .type    test_1xi256, at function
test_1xi256:                            # @test_1xi256
.Ltmp32:
    .cfi_startproc
# BB#0:
    pushl    %ebp
.Ltmp33:
    .cfi_def_cfa_offset 8
    pushl    %ebx
.Ltmp34:
    .cfi_def_cfa_offset 12
    pushl    %edi
.Ltmp35:
    .cfi_def_cfa_offset 16
    pushl    %esi
.Ltmp36:
    .cfi_def_cfa_offset 20
    subl    $20, %esp
.Ltmp37:
    .cfi_def_cfa_offset 40
.Ltmp38:
    .cfi_offset %esi, -20
.Ltmp39:
    .cfi_offset %edi, -16
.Ltmp40:
    .cfi_offset %ebx, -12
.Ltmp41:
    .cfi_offset %ebp, -8
    movl    76(%esp), %ebx
    movl    44(%esp), %eax
    movl    48(%esp), %ecx
    xorl    (%ebx), %eax
    movl    %eax, 4(%esp)           # 4-byte Spill
    xorl    4(%ebx), %ecx
    movl    %ecx, 16(%esp)          # 4-byte Spill
    movl    52(%esp), %edi
    movl    56(%esp), %eax
    xorl    8(%ebx), %edi
    xorl    12(%ebx), %eax
    movl    %eax, %esi
    movl    60(%esp), %eax
    movl    64(%esp), %ebp
    xorl    16(%ebx), %eax
    xorl    20(%ebx), %ebp
    movl    68(%esp), %edx
    movl    72(%esp), %ecx
    xorl    24(%ebx), %edx
    xorl    28(%ebx), %ecx
    movl    %ecx, 28(%ebx)
    movl    %edx, 24(%ebx)
    movl    %ebp, 20(%ebx)
    movl    %eax, 16(%ebx)
    movl    %esi, 12(%ebx)
    movl    %esi, 8(%esp)           # 4-byte Spill
    movl    %edi, 8(%ebx)
    movl    16(%esp), %esi          # 4-byte Reload
    movl    %esi, 4(%ebx)
    movl    4(%esp), %esi           # 4-byte Reload
    movl    %esi, (%ebx)
    movd    %eax, %xmm0
    pinsrd    $1, %ebp, %xmm0
    pinsrd    $2, %edx, %xmm0
    pinsrd    $3, %ecx, %xmm0
    pextrd    $3, %xmm0, %eax
    movl    %eax, 12(%esp)          # 4-byte Spill
    pextrd    $2, %xmm0, %eax
    movl    %eax, (%esp)            # 4-byte Spill
    pextrd    $1, %xmm0, %eax
    movd    %xmm0, %ecx
    movd    %esi, %xmm0
    movl    16(%esp), %edx          # 4-byte Reload
    pinsrd    $1, %edx, %xmm0
    pinsrd    $2, %edi, %xmm0
    movl    8(%esp), %edx           # 4-byte Reload
    pinsrd    $3, %edx, %xmm0
    pextrd    $3, %xmm0, %edx
    pextrd    $2, %xmm0, %esi
    pextrd    $1, %xmm0, %edi
    movd    %xmm0, %ebx
    movl    40(%esp), %ebp
    movl    %ebx, (%ebp)
    movl    %edi, 4(%ebp)
    movl    %esi, 8(%ebp)
    movl    %edx, 12(%ebp)
    movl    %ecx, 16(%ebp)
    movl    %eax, 20(%ebp)
    movl    (%esp), %eax            # 4-byte Reload
    movl    %eax, 24(%ebp)
    movl    12(%esp), %eax          # 4-byte Reload
    movl    %eax, 28(%ebp)
    addl    $20, %esp
    popl    %esi
    popl    %edi
    popl    %ebx
    popl    %ebp
    ret    $4
.Ltmp42:
    .size    test_1xi256, .Ltmp42-test_1xi256
.Ltmp43:
    .cfi_endproc
.Leh_func_end5:

    .globl    test_2xi8
    .align    16, 0x90
    .type    test_2xi8, at function
test_2xi8:                              # @test_2xi8
.Ltmp44:
    .cfi_startproc
# BB#0:
    movdqa    %xmm0, %xmm1
    movl    4(%esp), %eax
    movzbl    1(%eax), %ecx
    shll    $8, %ecx
    pinsrw    $3, %ecx, %xmm0
    movzbl    2(%eax), %ecx
    shll    $8, %ecx
    pinsrw    $7, %ecx, %xmm0
    pxor    %xmm1, %xmm0
    pextrb    $15, %xmm0, %ecx
    movb    %cl, 16(%eax)
    pextrb    $7, %xmm0, %ecx
    movb    %cl, 8(%eax)
    ret
.Ltmp45:
    .size    test_2xi8, .Ltmp45-test_2xi8
.Ltmp46:
    .cfi_endproc
.Leh_func_end6:

    .globl    test_2xi16
    .align    16, 0x90
    .type    test_2xi16, at function
test_2xi16:                             # @test_2xi16
.Ltmp47:
    .cfi_startproc
# BB#0:
    movdqa    %xmm0, %xmm1
    movl    4(%esp), %eax
    pinsrw    $3, 2(%eax), %xmm0
    pinsrw    $7, 4(%eax), %xmm0
    pxor    %xmm1, %xmm0
    pextrw    $7, %xmm0, %ecx
    movw    %cx, 16(%eax)
    pextrw    $3, %xmm0, %ecx
    movw    %cx, 8(%eax)
    ret
.Ltmp48:
    .size    test_2xi16, .Ltmp48-test_2xi16
.Ltmp49:
    .cfi_endproc
.Leh_func_end7:

    .globl    test_2xi32
    .align    16, 0x90
    .type    test_2xi32, at function
test_2xi32:                             # @test_2xi32
.Ltmp50:
    .cfi_startproc
# BB#0:
    movdqa    %xmm0, %xmm1
    movl    4(%esp), %eax
    pinsrd    $1, 4(%eax), %xmm0
    pinsrd    $3, 8(%eax), %xmm0
    pxor    %xmm1, %xmm0
    pextrd    $3, %xmm0, 16(%eax)
    pextrd    $1, %xmm0, 8(%eax)
    ret
.Ltmp51:
    .size    test_2xi32, .Ltmp51-test_2xi32
.Ltmp52:
    .cfi_endproc
.Leh_func_end8:

    .globl    test_2xi64
    .align    16, 0x90
    .type    test_2xi64, at function
test_2xi64:                             # @test_2xi64
.Ltmp53:
    .cfi_startproc
# BB#0:
    movl    4(%esp), %eax
    pxor    (%eax), %xmm0
    movaps    %xmm0, (%eax)
    ret
.Ltmp54:
    .size    test_2xi64, .Ltmp54-test_2xi64
.Ltmp55:
    .cfi_endproc
.Leh_func_end9:

    .globl    test_2xi128
    .align    16, 0x90
    .type    test_2xi128, at function
test_2xi128:                            # @test_2xi128
.Ltmp61:
    .cfi_startproc
# BB#0:
    pushl    %ebp
.Ltmp62:
    .cfi_def_cfa_offset 8
    pushl    %ebx
.Ltmp63:
    .cfi_def_cfa_offset 12
    pushl    %edi
.Ltmp64:
    .cfi_def_cfa_offset 16
    pushl    %esi
.Ltmp65:
    .cfi_def_cfa_offset 20
    subl    $20, %esp
.Ltmp66:
    .cfi_def_cfa_offset 40
.Ltmp67:
    .cfi_offset %esi, -20
.Ltmp68:
    .cfi_offset %edi, -16
.Ltmp69:
    .cfi_offset %ebx, -12
.Ltmp70:
    .cfi_offset %ebp, -8
    movl    76(%esp), %ebx
    movl    44(%esp), %eax
    movl    48(%esp), %ecx
    xorl    (%ebx), %eax
    movl    %eax, 4(%esp)           # 4-byte Spill
    xorl    4(%ebx), %ecx
    movl    %ecx, 16(%esp)          # 4-byte Spill
    movl    52(%esp), %edi
    movl    56(%esp), %eax
    xorl    8(%ebx), %edi
    xorl    12(%ebx), %eax
    movl    %eax, %esi
    movl    60(%esp), %eax
    movl    64(%esp), %ebp
    xorl    16(%ebx), %eax
    xorl    20(%ebx), %ebp
    movl    68(%esp), %edx
    movl    72(%esp), %ecx
    xorl    24(%ebx), %edx
    xorl    28(%ebx), %ecx
    movl    %ecx, 28(%ebx)
    movl    %edx, 24(%ebx)
    movl    %ebp, 20(%ebx)
    movl    %eax, 16(%ebx)
    movl    %esi, 12(%ebx)
    movl    %esi, 8(%esp)           # 4-byte Spill
    movl    %edi, 8(%ebx)
    movl    16(%esp), %esi          # 4-byte Reload
    movl    %esi, 4(%ebx)
    movl    4(%esp), %esi           # 4-byte Reload
    movl    %esi, (%ebx)
    movd    %eax, %xmm0
    pinsrd    $1, %ebp, %xmm0
    pinsrd    $2, %edx, %xmm0
    pinsrd    $3, %ecx, %xmm0
    pextrd    $3, %xmm0, %eax
    movl    %eax, 12(%esp)          # 4-byte Spill
    pextrd    $2, %xmm0, %eax
    movl    %eax, (%esp)            # 4-byte Spill
    pextrd    $1, %xmm0, %eax
    movd    %xmm0, %ecx
    movd    %esi, %xmm0
    movl    16(%esp), %edx          # 4-byte Reload
    pinsrd    $1, %edx, %xmm0
    pinsrd    $2, %edi, %xmm0
    movl    8(%esp), %edx           # 4-byte Reload
    pinsrd    $3, %edx, %xmm0
    pextrd    $3, %xmm0, %edx
    pextrd    $2, %xmm0, %esi
    pextrd    $1, %xmm0, %edi
    movd    %xmm0, %ebx
    movl    40(%esp), %ebp
    movl    %ebx, (%ebp--
Command Output (stderr):
--
llc: /opt/llvm/llvm/lib/VMCore/Type.cpp:807: static const llvm::IntegerType*
llvm::IntegerType::get(llvm::LLVMContext&, unsigned int): Assertion `NumBits <=
MAX_INT_BITS && "bitwidth too large"' failed.
0  llc 0x08b54388
Stack dump:
0.    Program arguments: /opt/llvm/build/Release+Asserts/bin/llc -march=x86
-promote-elements 
1.    Running pass 'Function Pass Manager' on module '<stdin>'.
2.    Running pass 'X86 DAG->DAG Instruction Selection' on function
'@test_2xi256'
/opt/llvm/build/test/CodeGen/X86/Output/mem-promote-integers.ll.script: line 8:
21123 Aborted                 '/opt/llvm/build/Release+Asserts/bin/llc'
'-march=x86' '-promote-elements' <
'/opt/llvm/llvm/test/CodeGen/X86/mem-promote-integers.ll'
--

********************
Testing Time: 156.79s
********************
Failing Tests (2):
    Clang :: Driver/hello.c
    LLVM :: CodeGen/X86/mem-promote-integers.ll

  Expected Passes    : 8654
  Expected Failures  : 69
  Unsupported Tests  : 551
  Unexpected Failures: 2
make[1]: *** [check-local-all] Error 1
make[1]: Leaving directory `/opt/llvm/build/test'
make: *** [check-all] Error 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  Tue Jun 14 11:44:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 11:44:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10087] Regression: Compile error with a map of
	strings
In-Reply-To: <bug-10087-206@http.llvm.org/bugs/>
References: <bug-10087-206@http.llvm.org/bugs/>
Message-ID: <20110614164404.5D9FE2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #5 from Douglas Gregor <dgregor at apple.com> 2011-06-14 11:44:03 CDT ---
Fixed in Clang r132998.

FWIW, bugs in new C++0x features shouldn't be tagged as release blockers.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 14 13:19:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 13:19:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9981] crash with ## token
In-Reply-To: <bug-9981-206@http.llvm.org/bugs/>
References: <bug-9981-206@http.llvm.org/bugs/>
Message-ID: <20110614181947.E677A2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #5 from Chris Lattner <clattner at apple.com> 2011-06-14 13:19:47 CDT ---
Fixed properly in r133005, 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 Jun 14 15:47:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 15:47:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10136] New: CR6 not being set before a vararg call
Message-ID: <bug-10136-206@http.llvm.org/bugs/>

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

           Summary: CR6 not being set before a vararg call
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: PowerPC
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


[rdivacky at anacreon ~/llvm]$ cat printf.c 
int printf(const char *, ...);
int main() {
  float f = 3.13;
  printf("%f", f);
}
[rdivacky at anacreon ~/llvm]$ ./Release+Asserts/bin/clang  -m32 -O2 -S -o -
printf.c  | grep creq
        creqv 0, 0, 0
[rdivacky at anacreon ~/llvm]$ gcc  -m32 -O2 -S -o - printf.c  | grep creq
        creqv 6,6,6

the CR6 is not being, it looks like it's being overwritten as the code there
suggests it should be there:


  // Set CR6 to true if this is a vararg call.
  if (isVarArg) {
    SDValue SetCR(DAG.getMachineNode(PPC::CRSET, dl, MVT::i32), 0);
    Chain = DAG.getCopyToReg(Chain, dl, PPC::CR1EQ, SetCR, InFlag);
    InFlag = Chain.getValue(1);
  }

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

From bugzilla-daemon at llvm.org  Tue Jun 14 17:16:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 17:16:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10136] CR6 not being set before a vararg call
In-Reply-To: <bug-10136-206@http.llvm.org/bugs/>
References: <bug-10136-206@http.llvm.org/bugs/>
Message-ID: <20110614221649.CDDD42A6C12D@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-14 17:16:49 CDT ---
r133018; I would appreciate if you would write/commit an appropriate test.

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

From bugzilla-daemon at llvm.org  Tue Jun 14 18:39:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 18:39:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10137] New: Invalid "goto into protected scope"
	error
Message-ID: <bug-10137-206@http.llvm.org/bugs/>

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

           Summary: Invalid "goto into protected scope" error
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


A small variation from the test is bug 10034 still fails:
-----------------------------------
void puts(const char*);

struct Y {};
struct X : Y {};

void exx(X) {}

int main(int argc, char **argv)
{
 if (argc > 3)
   goto end;

 X x;
 exx(x);

 end:

   for (int i = 0; i < argc; ++i)
   {
     puts(argv[i]);
   }

   return 0;
}
--------------------------------
Are we OK with extending clang to accept 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 Jun 14 19:19:41 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 19:19:41 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10138] New: Assertion with aggregate minimization
Message-ID: <bug-10138-206@http.llvm.org/bugs/>

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

           Summary: Assertion with aggregate minimization
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: Pidgeot18 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The following file causes an error when compiling with clang++:
#include <string>
class outer {
public:
    typedef struct {
        bool a;
        std::string b;
    } Aggregate;

    Aggregate getAgg() {
        return (Aggregate){false, ""};
    }
};

int main() {
    outer tower;
    outer::Aggregate res = tower.getAgg();
}


clang: /src/llvm/tools/clang/lib/CodeGen/CGExprAgg.cpp:910: void
clang::CodeGen::CodeGenFunction::EmitAggregateCopy(llvm::Value*, llvm::Value*,
clang::QualType, bool): Assertion `(Record->hasTrivialCopyConstructor() ||
Record->hasTrivialCopyAssignment()) && "Trying to aggregate-copy a type without
a trivial copy " "constructor or assignment operator"' failed.

I'm not entirely sure which svn revision I'm on, but this is the output from
svn info:
jcranmer at xochiquetzal /src/llvm/tools/clang $ svn info
Path: .
URL: http://llvm.org/svn/llvm-project/cfe/trunk
Repository Root: http://llvm.org/svn/llvm-project
Repository UUID: 91177308-0d34-0410-b5e6-96231b3b80d8
Revision: 132484
Node Kind: directory
Schedule: normal
Last Changed Author: akirtzidis
Last Changed Rev: 132481
Last Changed Date: 2011-06-02 13:01:46 -0700 (Thu, 02 Jun 2011)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 14 19:55:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 19:55:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9651] -Wshift-overflow should show the shift result
	in hex
In-Reply-To: <bug-9651-206@http.llvm.org/bugs/>
References: <bug-9651-206@http.llvm.org/bugs/>
Message-ID: <20110615005553.853622A6C12D@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #20 from Ted Kremenek <kremenek at apple.com> 2011-06-14 19:55:52 CDT ---
(In reply to comment #14)
> Created an attachment (id=6568)
 --> (http://llvm.org/bugs/attachment.cgi?id=6568) [details]
> [clang] Sema: show shift result in hexadecimal

Applied in r133033

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 14 21:56:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 14 Jun 2011 21:56:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10137] Invalid "goto into protected scope" error
In-Reply-To: <bug-10137-206@http.llvm.org/bugs/>
References: <bug-10137-206@http.llvm.org/bugs/>
Message-ID: <20110615025610.4D2E12A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #6 from Douglas Gregor <dgregor at apple.com> 2011-06-14 21:56:09 CDT ---
With bug 10034, the type was a POD type, so the code was well-formed according
to the C++ standard and we have to accept it.

With this bug, the type is non-POD, so the code is ill-formed in C++98/03.
Since GCC also rejects it, I see no reason to accept this ill-formed code.

In C++0x, the rules changed and this code because well-formed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 15 01:15:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 01:15:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10139] New: unordered_set declared inside class
Message-ID: <bug-10139-206@http.llvm.org/bugs/>

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

           Summary: unordered_set declared inside class
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: oroppas at gmail.com
                CC: llvmbugs at cs.uiuc.edu


The following piece of code cannot be compiled by clang with libc++:

#include <unordered_set>

class FlowGraph
{
  public:
    typedef unsigned int RegisterId;

    class Register
    {
      public:
        RegisterId _id;

        Register( RegisterId id = 0 ) : _id(id) { }

        bool operator==( const Register& r ) const
        {
          return _id == r._id;
        }
    };

    typedef std::unordered_set< Register > RegisterSet;

    private:
      RegisterSet _In;
};

int main()
{
  return 0;
}

$ clang++ -g -O0 -std=c++0x -stdlib=libc++ ./unordered_set_class.cpp 
In file included from ./unordered_set_class.cpp:2:
In file included from /usr/include/c++/v1/unordered_set:305:
In file included from /usr/include/c++/v1/__hash_table:16:
In file included from /usr/include/c++/v1/memory:589:
/usr/include/c++/v1/type_traits:787:14: error: implicit instantiation of
      undefined template 'std::__1::hash<FlowGraph::Register>'
    : public _Tp
             ^
/usr/include/c++/v1/type_traits:798:56: note: in instantiation of template
      class 'std::__1::__is_empty1<std::__1::hash<FlowGraph::Register> >'
      requested here
struct __libcpp_empty : public integral_constant<bool, sizeof(...
                                                       ^
/usr/include/c++/v1/type_traits:802:63: note: in instantiation of template
      class 'std::__1::__libcpp_empty<std::__1::hash<FlowGraph::Register>,
      true>' requested here
  ..._Tp> struct _LIBCPP_VISIBLE is_empty : public __libcpp_empty<_Tp> {};
                                                   ^
/usr/include/c++/v1/memory:1806:40: note: in instantiation of template class
      'std::__1::is_empty<std::__1::hash<FlowGraph::Register> >' requested here
                                bool = is_empty<_T2>::value>
                                       ^
/usr/include/c++/v1/memory:1824:44: note: in instantiation of default argument
      for '__libcpp_compressed_pair_switch<unsigned long,
      std::__1::hash<FlowGraph::Register>, false, false>' required here
  ...class _T2, unsigned = __libcpp_compressed_pair_switch<_T1, _T2>::value>
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/memory:2011:15: note: in instantiation of default argument
      for '__libcpp_compressed_pair_imp<unsigned long,
      std::__1::hash<FlowGraph::Register> >' required here
    : private __libcpp_compressed_pair_imp<_T1, _T2>
              ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/__hash_table:501:55: note: in instantiation of template
      class 'std::__1::__compressed_pair<unsigned long,
      std::__1::hash<FlowGraph::Register> >' requested here
    __compressed_pair<size_type, hasher>              __p2_;
                                                      ^
/usr/include/c++/v1/unordered_set:328:13: note: in instantiation of template
      class 'std::__1::__hash_table<FlowGraph::Register,
      std::__1::hash<FlowGraph::Register>,
      std::__1::equal_to<FlowGraph::Register>,
      std::__1::allocator<FlowGraph::Register> >' requested here
    __table __table_;
            ^
./unordered_set_class.cpp:25:19: note: in instantiation of template class
      'std::__1::unordered_set<FlowGraph::Register,
      std::__1::hash<FlowGraph::Register>,
      std::__1::equal_to<FlowGraph::Register>,
      std::__1::allocator<FlowGraph::Register> >' requested here
      RegisterSet _In;
                  ^
/usr/include/c++/v1/memory:2509:29: note: template is declared here
template <class _Tp> struct hash;
                            ^
/usr/include/c++/v1/memory:1806:55: error: no member named 'value' in
      'std::__1::is_empty<std::__1::hash<FlowGraph::Register> >'
                                bool = is_empty<_T2>::value>
                                       ~~~~~~~~~~~~~~~^
/usr/include/c++/v1/memory:1824:44: note: in instantiation of default argument
      for '__libcpp_compressed_pair_switch<unsigned long,
      std::__1::hash<FlowGraph::Register>, false, false>' required here
  ...class _T2, unsigned = __libcpp_compressed_pair_switch<_T1, _T2>::value>
                           ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/memory:2013:13: note: in instantiation of default argument
      for '__libcpp_compressed_pair_imp<unsigned long,
      std::__1::hash<FlowGraph::Register> >' required here
    typedef __libcpp_compressed_pair_imp<_T1, _T2> base;
            ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
/usr/include/c++/v1/__hash_table:501:55: note: in instantiation of template
      class 'std::__1::__compressed_pair<unsigned long,
      std::__1::hash<FlowGraph::Register> >' requested here
    __compressed_pair<size_type, hasher>              __p2_;
                                                      ^
/usr/include/c++/v1/unordered_set:328:13: note: in instantiation of template
      class 'std::__1::__hash_table<FlowGraph::Register,
      std::__1::hash<FlowGraph::Register>,
      std::__1::equal_to<FlowGraph::Register>,
      std::__1::allocator<FlowGraph::Register> >' requested here
    __table __table_;
            ^
./unordered_set_class.cpp:25:19: note: in instantiation of template class
      'std::__1::unordered_set<FlowGraph::Register,
      std::__1::hash<FlowGraph::Register>,
      std::__1::equal_to<FlowGraph::Register>,
      std::__1::allocator<FlowGraph::Register> >' requested here
      RegisterSet _In;
                  ^
In file included from ./unordered_set_class.cpp:2:
In file included from /usr/include/c++/v1/unordered_set:305:
In file included from /usr/include/c++/v1/__hash_table:16:
/usr/include/c++/v1/memory:2029:31: error: constructor cannot be redeclared
    _LIBCPP_INLINE_VISIBILITY __compressed_pair(_T1_param __t1, _T2_param __t2)
                              ^
/usr/include/c++/v1/__hash_table:501:55: note: in instantiation of template
      class 'std::__1::__compressed_pair<unsigned long,
      std::__1::hash<FlowGraph::Register> >' requested here
    __compressed_pair<size_type, hasher>              __p2_;
                                                      ^
/usr/include/c++/v1/unordered_set:328:13: note: in instantiation of template
      class 'std::__1::__hash_table<FlowGraph::Register,
      std::__1::hash<FlowGraph::Register>,
      std::__1::equal_to<FlowGraph::Register>,
      std::__1::allocator<FlowGraph::Register> >' requested here
    __table __table_;
            ^
./unordered_set_class.cpp:25:19: note: in instantiation of template class
      'std::__1::unordered_set<FlowGraph::Register,
      std::__1::hash<FlowGraph::Register>,
      std::__1::equal_to<FlowGraph::Register>,
      std::__1::allocator<FlowGraph::Register> >' requested here
      RegisterSet _In;
                  ^
/usr/include/c++/v1/memory:2025:40: note: previous declaration is here
    _LIBCPP_INLINE_VISIBILITY explicit __compressed_pair(_T1_param ...
                                       ^
clang-3.0:
/home/ryuta/devel/llvm/src/llvm/tools/clang/include/clang/AST/DeclCXX.h:523:
const clang::CXXRecordDecl::DefinitionData& clang::CXXRecordDecl::data() const:
Assertion `DefinitionData && "queried property of class with no definition"'
failed.
Stack dump:
0.    Program arguments: /usr/bin/clang-3.0 -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free -main-file-name
unordered_set_class.cpp -mrelocation-model static -mdisable-fp-elim
-masm-verbose -mconstructor-aliases -munwind-tables -target-cpu x86-64
-momit-leaf-frame-pointer -g -resource-dir /usr/bin/../lib/clang/3.0
-nostdinc++ -cxx-isystem /usr/include/c++/v1 -O0 -std=c++0x -fdeprecated-macro
-ferror-limit 19 -fmessage-length 79 -fcxx-exceptions -fexceptions
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-Dt9rrS.o
-x c++ ./unordered_set_class.cpp 
1.    ./unordered_set_class.cpp:25:22: current parser token ';'
2.    ./unordered_set_class.cpp:4:1: parsing struct/union/class body
'FlowGraph'
clang-3: error: unable to execute command: Aborted
clang-3: error: clang frontend command failed due to signal 2 (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 Jun 15 03:21:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 03:21:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10140] New: StringPool's PooledStringPtr has
 non-const operator== causing bad OR-result
Message-ID: <bug-10140-206@http.llvm.org/bugs/>

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

           Summary: StringPool's PooledStringPtr has non-const operator==
                    causing bad OR-result
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Support Libraries
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu


This just caused me some hours of debugging fun:

class LexedIdentifier {
...
   bool equals(LexedIdentifier const& other) const {
      return other.m_ident == m_ident;
   }

   llvm::PooledStringPtr m_ident;
...
};

Rather than comparing both PooledStringPtr, it converted both to "bool" and
compared those booleans, because the respective operator== of PooledStringPtr
is non-const, hence is not preferred by the compiler!

// Support/StringPool.h
00131     inline operator bool() const { return S != 0; }
00132 
00133     inline bool operator==(const PooledStringPtr &That) { return S ==
That.S; }

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

From bugzilla-daemon at llvm.org  Wed Jun 15 04:11:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 04:11:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10141] New: pthread_mutex_lock is assumed to always
	return 0
Message-ID: <bug-10141-206@http.llvm.org/bugs/>

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

           Summary: pthread_mutex_lock is assumed to always return 0
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: scott at scottnz.com
                CC: llvmbugs at cs.uiuc.edu


With this code

    {
        int lock_res = pthread_mutex_lock(&o->lock);
        if(lock_res != 0) return false;
        if(o->destroyed)
        {
            pthread_mutex_unlock(&o->lock);
            return false;
        }
    }

Clang says:

us_datacoding_datacoding.c:163:21: warning: This statement is never executed
                if(lock_res != 0) return false;

pointing at the return false;

In my case, the mutex o->lock is created as PTHREAD_MUTEX_ERRORCHECK which is
allowed to 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 Jun 15 08:39:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 08:39:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10139] unordered_set declared inside class
In-Reply-To: <bug-10139-206@http.llvm.org/bugs/>
References: <bug-10139-206@http.llvm.org/bugs/>
Message-ID: <20110615133954.4AAE32A6C124@llvm.org>

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

Howard Hinnant <hhinnant at apple.com> changed:

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

--- Comment #1 from Howard Hinnant <hhinnant at apple.com> 2011-06-15 08:39:53 CDT ---
std::hash<FlowGraph::Register> is not a complete type.  Either you need to
define std::hash<FlowGraph::Register> before you use it.  Or you need to define
and use another hash function.  For example:


class FlowGraph
{
  public:
    typedef unsigned int RegisterId;

    class Register
    {
      public:
        RegisterId _id;

        Register( RegisterId id = 0 ) : _id(id) { }

        bool operator==( const Register& r ) const
        {
          return _id == r._id;
        }

        std::size_t hash() const {return _id;}
    };

    struct hash
    {
        std::size_t operator()(const Register& r) const
            {return r.hash();}
    };

    typedef std::unordered_set< Register, hash > RegisterSet;

    private:
      RegisterSet _In;
};

Closing as "not a bug".

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

From bugzilla-daemon at llvm.org  Wed Jun 15 09:18:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 09:18:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10142] New: Exception mistakenly moved from
Message-ID: <bug-10142-206@http.llvm.org/bugs/>

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

           Summary: Exception mistakenly moved from
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I stumbled across the following code:


#include <iostream>
using std::cout;
using std::cin;
using std::endl;

struct Blob {
  Blob() { cout << "C" << endl; }
  Blob(const Blob&) { cout << "c" << endl; }
  Blob(Blob&&) { cout << "m" << endl; }
  Blob& operator =(const Blob&) { cout << "=" << endl; return *this; }
  Blob& operator =(Blob&&) { cout << "=m" << endl; return *this; }
  ~Blob() { cout << "~" << endl; }

  int i;
};

int main() {
  try {
     cout << "Throw directly: " << endl;
     throw Blob();
  } catch(const Blob& e) { cout << "caught: " << &e << endl; }
  try {
     cout << "Throw with object about to die anyhow" << endl;
     Blob b;
     throw b;
  } catch(const Blob& e) { cout << "caught: " << &e << endl;  }
  {
    cout << "Throw with object not about to die anyhow (enter non-zero
integer)" << endl;
    Blob b;
    int tmp = 1;
    try {
      if(tmp) throw b;
      cout << "Test is worthless if you enter '0' silly" << endl;
    } catch(const Blob& e) { cout << "caught: " << &e << endl;  }
    b.i = tmp;
    cout << b.i << endl;
  }
}

This code detects whether the compiler moves from the local exception object in
the throw expression.  clang does so for the 2nd and 3rd throw expressions. 
This is correct for the 2nd, but not for the 3rd.  Reference
[class.copy]/p31/b2:

* in a throw-expression, when the operand is the name of a non-volatile
automatic object (other than a function or catch-clause parameter) whose scope
does not extend beyond the end of the innermost enclosing try-block (if there
is one), the copy/move operation from the operand to the exception object
(15.1) can be omitted by constructing the automatic object directly into the
exception object

In the 3rd case of the example the scope **does** extend beyond the end of the
innermost enclosing try-block, and thus 'b' is not eligible for copy/move
elision, and thus according to p32, should not be implicitly moved from.  That
is, the output should be:

...
Throw with object not about to die anyhow (enter non-zero integer)
C
c
...

instead of:

...
Throw with object not about to die anyhow (enter non-zero integer)
C
m
...

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

From bugzilla-daemon at llvm.org  Wed Jun 15 09:21:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 09:21:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9643] clang crash on template template argument
In-Reply-To: <bug-9643-206@http.llvm.org/bugs/>
References: <bug-9643-206@http.llvm.org/bugs/>
Message-ID: <20110615142104.346522A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-06-15 09:21:03 CDT ---
Fixed in Clang r133055.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 15 09:57:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 09:57:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10143] New: Return value of std::uncaught_exception
Message-ID: <bug-10143-206@http.llvm.org/bugs/>

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

           Summary: Return value of std::uncaught_exception
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: maxime at altribe.org
                CC: llvmbugs at cs.uiuc.edu


Return value of std::uncaught_exception inside the terminate handler seems
inconsistent. When using an empty throw or throwing an std::runtime_error,
std::uncaught_exception returns true, but when throwing an int it returns
false.

I'm using :
$ clang++ --version
clang version 2.9 (tags/RELEASE_29/final)
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 Jun 15 10:04:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 10:04:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10144] New: Debug info slows down compilation a lot
Message-ID: <bug-10144-206@http.llvm.org/bugs/>

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

           Summary: Debug info slows down compilation a lot
           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: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Found while accidentally trying to build gcc with clang :-)

$ time gcc -c -O2 -g fold-const.i 
real    0m12.294s
user    0m11.938s
sys    0m0.323s

$ time clang -O2 -c -g fold-const.i -w -o test.bc -emit-llvm
real    0m5.892s
user    0m5.773s
sys    0m0.105s

$ time clang -O2 -c  fold-const.i -w -o test-nodebug.bc -emit-llvm

real    0m4.131s
user    0m4.029s
sys    0m0.091s

$ time llc test-nodebug.bc 
real    0m4.926s
user    0m4.855s
sys    0m0.059s

$ time ./build-master/bin/llc test.bc 
real    1m2.980s
user    1m2.383s
sys    0m0.446s

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 15 15:42:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 15:42:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10135] recent trunk build fails LLVM ::
 CodeGen/X86/mem-promote-integers.ll
In-Reply-To: <bug-10135-206@http.llvm.org/bugs/>
References: <bug-10135-206@http.llvm.org/bugs/>
Message-ID: <20110615204211.4F2C32A6C12C@llvm.org>

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

apacherulzz at yahoo.com changed:

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

--- Comment #1 from apacherulzz at yahoo.com 2011-06-15 15:42:10 CDT ---
updated this afternoon and rebuilt. the test is no longer failing. marking
resolved.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 15 16:37:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 16:37:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10145] New: clang objc++0x rejects-invalid with
 apple block pointer and nullptr
Message-ID: <bug-10145-206@http.llvm.org/bugs/>

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

           Summary: clang objc++0x rejects-invalid with apple block
                    pointer and nullptr
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Testcase:
int test = (void(^)())0 == nullptr;

I assume this is supposed to 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 Jun 15 19:01:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 15 Jun 2011 19:01:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10129] clang crashes with -Wlarge-by-value-copy
In-Reply-To: <bug-10129-206@http.llvm.org/bugs/>
References: <bug-10129-206@http.llvm.org/bugs/>
Message-ID: <20110616000111.BC6582A6C12E@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #3 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-06-15 19:01:10 CDT ---
Do not see the crash in r133110.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 16 08:52:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 16 Jun 2011 08:52:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10146] New: clang++ segfaults on (incorrect)
	template code
Message-ID: <bug-10146-206@http.llvm.org/bugs/>

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

           Summary: clang++ segfaults on (incorrect) template code
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: llvmbugz at ghalkes.nl
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6742)
 --> (http://llvm.org/bugs/attachment.cgi?id=6742)
Template classes causing clang++ segfault

When compiling the attached code, by invoking:

clang++ test.cc

causes a segmentation fault in both version 2.8 as included with Ubuntu x86_64,
as well as with the LLVM supplied 2.9 x86_64 and i686 versions.

Stack dump:
0.      Program arguments:
/home/gertjan/tmp/clang/clang+llvm-2.9-x86_64-linux.tar/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name test.cc -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21.0.20110327
-momit-leaf-frame-pointer -resource-dir
/home/gertjan/tmp/clang/clang+llvm-2.9-x86_64-linux.tar/bin/../lib/clang/2.9
-ferror-limit 19 -fmessage-length 80 -fcxx-exceptions -fexceptions
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-hc4Fnt.o
-x c++ test.cc 
1.      test.cc:11:10: current parser token '{'
2.      test.cc:10:1: parsing struct/union/class body 'B'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 1 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Thu Jun 16 11:23:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 16 Jun 2011 11:23:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10147] New: too few template arguments for class
	template 'set'
Message-ID: <bug-10147-206@http.llvm.org/bugs/>

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

           Summary: too few template arguments for class template 'set'
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: hhinnant at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I have a report that the following code example compiles with gcc 4.6.0.  It
does not compile with:

Apple clang version 3.0 (trunk 133051) (based on LLVM 3.0svn)
Target: x86_64-apple-darwin10.7.0
Thread model: posix

I do not know if clang is correct or incorrect in rejecting this program.

#include <set>
#include <cstdint>
#include <tuple>

template<typename PackR, typename PackL>
struct Cat;

template<typename ...R, typename ...L>
struct Cat<std::tuple<R...>, std::tuple<L...>>
{
        typedef std::tuple<R..., L...> type;
};

template<typename Pack, template<typename ...T> class Receiver>
struct Unpack;

template<typename ...Args, template<typename ...T> class Receiver>
struct Unpack<std::tuple<Args...>, Receiver>
{
        typedef Receiver<Args...> type;
};

template<typename ...Args>
struct Forward
{    
        //typedef Args... args; // Problem here!!
        typedef std::tuple<Args...> args; // Workaround

        static const std::size_t size = sizeof...(Args);
};

template<typename S, typename T, 
        template<typename ...SArgs> class SCont, 
        template<typename ...TArgs> class TCont, 
        typename SForward = Forward<> ,
        typename TForward = Forward<>>
class Bimap
{
        //typedef SCont<S, typename SForward::args> left_type;
        //typedef TCont<T, typename TForward::args> right_type;
        typedef typename Unpack<typename Cat<std::tuple<S>, typename
SForward::args>::type, SCont>::type left_type; //Workaround
        typedef typename Unpack<typename Cat<std::tuple<T>, typename
TForward::args>::type, TCont>::type right_type; //Workaround

        template<typename LeftIt, typename RightIt> struct Relation; // to be
implemented

        typedef Relation<typename left_type::const_iterator, typename
right_type::const_iterator> relation_type;

};

int main()
{
    Bimap<int, int, std::set, std::set, Forward<std::less<int>> ,
Forward<std::greater<int>>> x;
}


test.cpp:20:17: error: too few template arguments for class template 'set'
        typedef Receiver<Args...> type;
                ^
test.cpp:41:26: note: in instantiation of template class
'Unpack<std::__1::tuple<int, std::__1::less<int> >, set>' requested here
        typedef typename Unpack<typename Cat<std::tuple<S>, typename
SForward::args>::type, SCont>::type left_type; //Workaround
                         ^
test.cpp:52:95: note: in instantiation of template class 'Bimap<int, int,
std::set, std::set, Forward<std::__1::less<int> >,
Forward<std::__1::greater<int> > >' requested here
    Bimap<int, int, std::set, std::set, Forward<std::less<int>> ,
Forward<std::greater<int>>> x;
                                                                               
              ^
/usr/include/c++/v1/__tree:33:27: note: template is declared here
    class _LIBCPP_VISIBLE set;
                          ^

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 16 11:51:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 16 Jun 2011 11:51:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9233] Template deduction succeeds despite qualifier
	mismatch
In-Reply-To: <bug-9233-206@http.llvm.org/bugs/>
References: <bug-9233-206@http.llvm.org/bugs/>
Message-ID: <20110616165155.414FE2A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-06-16 11:51:54 CDT ---
Fixed in Clang r133163.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 16 12:08:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 16 Jun 2011 12:08:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10108] Property of reference type not supported for
 Objective-C++
In-Reply-To: <bug-10108-206@http.llvm.org/bugs/>
References: <bug-10108-206@http.llvm.org/bugs/>
Message-ID: <20110616170823.788F02A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-16 12:08:23 CDT ---
This is supported on Clang top-of-tree

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

From bugzilla-daemon at llvm.org  Thu Jun 16 13:52:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 16 Jun 2011 13:52:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10145] clang objc++0x rejects-invalid with apple
 block pointer and nullptr
In-Reply-To: <bug-10145-206@http.llvm.org/bugs/>
References: <bug-10145-206@http.llvm.org/bugs/>
Message-ID: <20110616185218.9A8922A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-16 13:52:18 CDT ---
Fixed in Clang r133179.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 16 22:29:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 16 Jun 2011 22:29:02 -0500 (CDT)
Subject: [LLVMbugs] =?utf-8?q?=5BBug_9977=5D_clang_should_warn_on_memset?=
 =?utf-8?b?KHMsIDAsIHNpemVvZihzKSkgIOKAkyBuZWVkcyB0byBiZSBzaXplb2YgKCpz?=
 =?utf-8?q?=29?=
In-Reply-To: <bug-9977-206@http.llvm.org/bugs/>
References: <bug-9977-206@http.llvm.org/bugs/>
Message-ID: <20110617032902.4201C2A6C124@llvm.org>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #3 from Nico Weber <nicolasweber at gmx.de> 2011-06-16 22:29:01 CDT ---
dgregor fixed the "doesn't work in .c files" issue, and chandlerc rewrote how
this warning works ? all done 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  Thu Jun 16 23:44:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 16 Jun 2011 23:44:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9075] ns_consumed should work with void* pointers.
In-Reply-To: <bug-9075-206@http.llvm.org/bugs/>
References: <bug-9075-206@http.llvm.org/bugs/>
Message-ID: <20110617044457.6E4D32A6C12C@llvm.org>

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

Ted Kremenek <kremenek at apple.com> changed:

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

--- Comment #4 from Ted Kremenek <kremenek at apple.com> 2011-06-16 23:44:56 CDT ---
We went back and forth on this.  We decided we only want to support ns_consumed
for values the compiler can tell are Objective-C object references.

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

From bugzilla-daemon at llvm.org  Thu Jun 16 23:59:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 16 Jun 2011 23:59:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10138] Assertion with aggregate minimization
In-Reply-To: <bug-10138-206@http.llvm.org/bugs/>
References: <bug-10138-206@http.llvm.org/bugs/>
Message-ID: <20110617045943.BB2602A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-06-16 23:59:43 CDT ---
Fixed in Clang r133235.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 17 02:17:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 17 Jun 2011 02:17:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10148] New: llvm-ld aborts with "Aliasee not
 linked" on virtual destructors
Message-ID: <bug-10148-206@http.llvm.org/bugs/>

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

           Summary: llvm-ld aborts with "Aliasee not linked" on virtual
                    destructors
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: ka5427-536 at online.de
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6743)
 --> (http://llvm.org/bugs/attachment.cgi?id=6743)
failing virtual destructor

I am working on a very large projects where llvm-ld aborts several 60 times
with the message  "Aliasee not linked".

It seems that the issue has somehow todo with virtual destructors.
(see attachment example.cpp/Makefile)

    class  Base {
        public:
            virtual ~Base() = 0;
    };

    class Derived : public Base {
        public:
            virtual ~Derived();
    };

    Base::~Base() { }

    Derived::~Derived() { }

    int main() {
        Derived d;
    }

build output:

  clang++ -pedantic -Wall -emit-llvm -c example.cpp
  llvm-ld   example.o -o example
  llvm-ld: /home/eval/gnu/llvm/llvm/lib/Linker/LinkModules.cpp:675: bool
LinkAlias(llvm::Module*, const llvm::Module*, llvm::ValueToValueMapTy&,
std::string*): Assertion `VMI != Va
  0  llvm-ld         0x0000000000c79d56
  1  llvm-ld         0x0000000000c7a31c
  2  libpthread.so.0 0x00002b2e484f5a80
  3  libc.so.6       0x00002b2e490dfed5 gsignal + 53
  4  libc.so.6       0x00002b2e490e13f3 abort + 387
  5  libc.so.6       0x00002b2e490d8dc9 __assert_fail + 233
  6  llvm-ld         0x0000000000830a37
  7  llvm-ld         0x0000000000832ec2
llvm::Linker::LinkModules(llvm::Module*, llvm::Module*, std::string*) + 2014
  8  llvm-ld         0x000000000082da03
llvm::Linker::LinkInModule(llvm::Module*, std::string*) + 41
  9  llvm-ld         0x000000000082ce32
llvm::Linker::LinkInFile(llvm::sys::Path const&, bool&) + 1486
  10 llvm-ld         0x000000000082d509
llvm::Linker::LinkInItems(std::vector<std::pair<std::string, bool>,
std::allocator<std::pair<std::string, bool> > > const&, std::vector<std:
  11 llvm-ld         0x0000000000806988 main + 1364
  12 libc.so.6       0x00002b2e490cc1a6 __libc_start_main + 230
  13 llvm-ld         0x00000000007ff609
  Stack dump:
  0.      Program arguments: llvm-ld example.o -o example
  gmake: *** [libexample.so] Aborted


more details:

  os is debian lenny 64bit
  llvm/clang++ is version 3.0 (trunk 133240)
  happens with virtual destructors only. Other virtual methods seems to work
OK.

  this is OK:  g++     -Wall -pedantic -o example example.cpp
  this is OK:  clang++ -Wall -pedantic -o example example.cpp

  the llvm-nm command reports a symbol of unknown type, e.g.:

     llvm-nm example.o | grep ' ? '

        ' ? _ZN7DerivedD1Ev'

    echo _ZN7DerivedD1Ev | c++filt

        'Derived::~Derived()'

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 17 09:12:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 17 Jun 2011 09:12:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10149] New: __asm__ segfaults
Message-ID: <bug-10149-206@http.llvm.org/bugs/>

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

           Summary: __asm__ segfaults
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: tim.nieradzik at gmx.de
                CC: llvmbugs at cs.uiuc.edu


int main(void) {
        int value;
        __asm__("test" : "=l" (value));
}

$ clang crash.c
0  clang           0x0000000001916b7f
1  clang           0x0000000001916f4a
2  libpthread.so.0 0x00007f7904564000
3  clang           0x00000000012945b9 llvm::SelectionDAG::getNode(unsigned int,
llvm::DebugLoc, llvm::SDVTList, llvm::SDValue const*, unsigned int) + 1449
4  clang           0x00000000012bb5ba
llvm::SelectionDAGBuilder::visitInlineAsm(llvm::ImmutableCallSite) + 8314
5  clang           0x00000000012cd822
llvm::SelectionDAGBuilder::visitCall(llvm::CallInst const&) + 1218
6  clang           0x00000000012b42ad llvm::SelectionDAGBuilder::visit(unsigned
int, llvm::User const&) + 317
7  clang           0x00000000012dc332
llvm::SelectionDAGBuilder::visit(llvm::Instruction const&) + 50
8  clang           0x00000000012ea395
llvm::SelectionDAGISel::SelectBasicBlock(llvm::ilist_iterator<llvm::Instruction
const>, llvm::ilist_iterator<llvm::Instruction const>, bool&) + 53
9  clang           0x00000000012ec463
llvm::SelectionDAGISel::SelectAllBasicBlocks(llvm::Function const&) + 8227
10 clang           0x00000000012ede7a
llvm::SelectionDAGISel::runOnMachineFunction(llvm::MachineFunction&) + 650
11 clang           0x000000000184fa07
llvm::FPPassManager::runOnFunction(llvm::Function&) + 615
12 clang           0x000000000184fa8b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
13 clang           0x000000000184f5b7
llvm::MPPassManager::runOnModule(llvm::Module&) + 519
14 clang           0x000000000184f6c1 llvm::PassManagerImpl::run(llvm::Module&)
+ 145
15 clang           0x000000000075cdfe
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 3006
16 clang           0x000000000075ad55
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 245
17 clang           0x00000000008a26af clang::ParseAST(clang::Sema&, bool) + 351
18 clang           0x0000000000759ba3 clang::CodeGenAction::ExecuteAction() +
51
19 clang           0x0000000000666a3b
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 315
20 clang           0x00000000006427ba
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1178
21 clang           0x0000000000637481 cc1_main(char const**, char const**, char
const*, void*) + 737
22 clang           0x00000000006414bc main + 6844
23 libc.so.6       0x00007f790386dc7d __libc_start_main + 253
24 clang           0x0000000000636fe9
Stack dump:
0.      Program arguments: /home/tim/dev/build/Release/bin/clang -cc1 -triple
x86_64-unknown-linux-gnu -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name crash.c -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.20.1 -momit-leaf-frame-pointer
-resource-dir /home/tim/dev/build/Release/bin/../lib/clang/3.0 -ferror-limit 19
-fmessage-length 80 -fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics
-o /tmp/cc-QHYMkf.o -x c crash.c
1.      <eof> parser at end of file
2.      Code generation
3.      Running pass 'Function Pass Manager' on module 'crash.c'.
4.      Running pass 'X86 DAG->DAG Instruction Selection' on function '@main'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)

$ clang -v
clang version 3.0 (trunk 132756)
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  Fri Jun 17 14:51:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 17 Jun 2011 14:51:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10150] New: [C] Segfault during compilation
Message-ID: <bug-10150-206@http.llvm.org/bugs/>

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

           Summary: [C] Segfault during compilation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu


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

With a build from today (git 12189f573f5dafb7fa33e8dc32ff06cd6fd35963), I get
the following segfaults:

% clang -c noalias.c 
0  libLLVM-3.0svn.so 0x00007f550098b05f
1  libLLVM-3.0svn.so 0x00007f550098b7c0
2  libpthread.so.0   0x00007f55001f4ff0
3  clang             0x000000000089b91c
clang::Sema::MergeCompatibleFunctionDecls(clang::FunctionDecl*,
clang::FunctionDecl*) + 216
4  clang             0x00000000008a43b0
clang::Sema::MergeFunctionDecl(clang::FunctionDecl*, clang::Decl*) + 4692
5  clang             0x00000000008b0337
clang::Sema::CheckFunctionDeclaration(clang::Scope*, clang::FunctionDecl*,
clang::LookupResult&, bool, bool&) + 1117
6  clang             0x00000000008b4047
clang::Sema::ActOnFunctionDeclarator(clang::Scope*, clang::Declarator&,
clang::DeclContext*, clang::QualType, clang::TypeSourceInfo*,
clang::LookupResult&, clang::ASTMultiPtr<clang::TemplateParameterList*>, bool,
bool&) + 9413
7  clang             0x00000000008bc205
clang::Sema::HandleDeclarator(clang::Scope*, clang::Declarator&,
clang::ASTMultiPtr<clang::TemplateParameterList*>, bool) + 3841
8  clang             0x00000000008bc4cf
clang::Sema::ActOnStartOfFunctionDef(clang::Scope*, clang::Declarator&) + 297
9  clang             0x00000000007e16df
clang::Parser::ParseFunctionDefinition(clang::Parser::ParsingDeclarator&,
clang::Parser::ParsedTemplateInfo const&) + 2505
10 clang             0x00000000007ef599
clang::Parser::ParseDeclGroup(clang::Parser::ParsingDeclSpec&, unsigned int,
bool, clang::SourceLocation*, clang::Parser::ForRangeInit*) + 891
11 clang             0x00000000007dd34a
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::Parser::ParsingDeclSpec&,
clang::AccessSpecifier) + 1026
12 clang             0x00000000007dd553
clang::Parser::ParseDeclarationOrFunctionDefinition(clang::ParsedAttributes&,
clang::AccessSpecifier) + 519
13 clang             0x00000000007dee61
clang::Parser::ParseExternalDeclaration(clang::Parser::ParsedAttributesWithRange&,
clang::Parser::ParsingDeclSpec*) + 4397
14 clang             0x00000000007def9d
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 225
15 clang             0x00000000007b2906 clang::ParseAST(clang::Sema&, bool) +
290
16 clang             0x000000000057ee80
clang::ASTFrontendAction::ExecuteAction() + 196
17 clang             0x0000000000664185 clang::CodeGenAction::ExecuteAction() +
2493
18 clang             0x000000000057f3bd clang::FrontendAction::Execute() + 389
19 clang             0x000000000056ce25
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 859
20 clang             0x0000000000546f70
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3680
21 clang             0x000000000053e06c cc1_main(char const**, char const**,
char const*, void*) + 6876
22 clang             0x0000000000544028 main + 751
23 libc.so.6         0x00007f54ff4fec7d __libc_start_main + 253
24 clang             0x000000000053c3b9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name noalias.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -target-linker-version 2.21
-momit-leaf-frame-pointer -coverage-file noalias.o -resource-dir
/usr/bin/../lib/clang/3.0 -ferror-limit 19 -fmessage-length 118 -fgnu-runtime
-fdiagnostics-show-option -fcolor-diagnostics -o noalias.o -x c noalias.c 
1.      noalias.c:3:19: current parser token '{'
clang: error: unable to execute command: Segmentation fault
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
% 

and

% clang -c alias.c 
Aliasing chain should end with function or global variable
void (...)* @foo1
Aliasing chain should end with function or global variable
void (...)* @foo
Broken module found, compilation aborted!
0  libLLVM-3.0svn.so 0x00007fc40336d05f
1  libLLVM-3.0svn.so 0x00007fc40336d7c0
2  libpthread.so.0   0x00007fc402bd6ff0
3  libc.so.6         0x00007fc401ef4605 gsignal + 53
4  libc.so.6         0x00007fc401ef5905 abort + 389
5  libLLVM-3.0svn.so 0x00007fc40396fdea
6  libLLVM-3.0svn.so 0x00007fc40394b34c
llvm::FPPassManager::doFinalization(llvm::Module&) + 142
7  libLLVM-3.0svn.so 0x00007fc40394b427
llvm::FunctionPassManagerImpl::doFinalization(llvm::Module&) + 173
8  libLLVM-3.0svn.so 0x00007fc40394b46f
llvm::FunctionPassManager::doFinalization() + 17
9  clang             0x0000000000667601
clang::EmitBackendOutput(clang::Diagnostic&, clang::CodeGenOptions const&,
clang::TargetOptions const&, llvm::Module*, clang::BackendAction,
llvm::raw_ostream*) + 5905
10 clang             0x0000000000664bfd
clang::BackendConsumer::HandleTranslationUnit(clang::ASTContext&) + 309
11 clang             0x00000000007b2960 clang::ParseAST(clang::Sema&, bool) +
380
12 clang             0x000000000057ee80
clang::ASTFrontendAction::ExecuteAction() + 196
13 clang             0x0000000000664185 clang::CodeGenAction::ExecuteAction() +
2493
14 clang             0x000000000057f3bd clang::FrontendAction::Execute() + 389
15 clang             0x000000000056ce25
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 859
16 clang             0x0000000000546f70
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 3680
17 clang             0x000000000053e06c cc1_main(char const**, char const**,
char const*, void*) + 6876
18 clang             0x0000000000544028 main + 751
19 libc.so.6         0x00007fc401ee0c7d __libc_start_main + 253
20 clang             0x000000000053c3b9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name alias.c -mrelocation-model
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21 -momit-leaf-frame-pointer
-coverage-file alias.o -resource-dir /usr/bin/../lib/clang/3.0 -ferror-limit 19
-fmessage-length 118 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o alias.o -x c alias.c 
1.      <eof> parser at end of file
2.      Per-function optimization
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
%

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

From bugzilla-daemon at llvm.org  Sat Jun 18 05:39:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 18 Jun 2011 05:39:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10103] enum type translation functions generate a
	lot of code
In-Reply-To: <bug-10103-206@http.llvm.org/bugs/>
References: <bug-10103-206@http.llvm.org/bugs/>
Message-ID: <20110618103900.5B1712A6C12D@llvm.org>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #2 from Hans Wennborg <hans at chromium.org> 2011-06-18 05:38:59 CDT ---
Fixed in r133344.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 18 08:18:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 18 Jun 2011 08:18:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10151] New: Clang should support -fno-trapv
Message-ID: <bug-10151-206@http.llvm.org/bugs/>

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

           Summary: Clang should support -fno-trapv
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: b.brachaczek at gmail.com
                CC: llvmbugs at cs.uiuc.edu


GCC doesn't have problems with it. I wanted to compile specific files with
-fno-trapv, since I use -ftrapv and hit bug 7838, and as it's not supported I
had to disable -ftrapv at all.

BTW, I noticed that more useful -fno-foo flags supported by GCC aren't
supported by Clang.

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

From bugzilla-daemon at llvm.org  Sat Jun 18 09:14:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 18 Jun 2011 09:14:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10116] [mc] No support for .common
In-Reply-To: <bug-10116-206@http.llvm.org/bugs/>
References: <bug-10116-206@http.llvm.org/bugs/>
Message-ID: <20110618141434.0D6632A6C12D@llvm.org>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #2 from Hans Wennborg <hans at chromium.org> 2011-06-18 09:14:33 CDT ---
Fixed in r133349.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 18 16:52:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 18 Jun 2011 16:52:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10152] New: Clang produced qmake.exe crashes on exit
Message-ID: <bug-10152-206@http.llvm.org/bugs/>

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

           Summary: Clang produced qmake.exe crashes on exit
           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: vanboxem.ruben at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I built clang with GCC 4.6 for x86_64-w64-mingw32 (64-bit Windows) in Cmake's
"Release" mode, modified InitHeaderSearch.cpp to point at all the headers,
(applied some patches that were required to Clang and mingw-w64's float.h, see
my email on cfe-dev) and modified Qt's qmake/makefile.win32-g++ to use clang++
instead of g++, changed the optimization to "-O0 -ggdb3" and removed the "-s"
from the link line.  I used the plain win32-g++ mkspec.

The resulting qmake binary runs OK seemingly (it starts processing Qt's pro
files, and only crashes on exit), but segfaults for sure when invoked with
"qmake --version" with this short backtrace:

#0  0x00000000005fd015 in QBasicAtomicInt::deref (this=0x0)
#1  0x0000000000000000 in ?? ()

This, of course, does not happen with plain GCC compiled qmake.

The crash on exit does not seem to affect qmake's runtime operation. The
generated makefiles are fine and can be used to attempt building Qt (however,
that's another story, euh bug 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  Sat Jun 18 23:25:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 18 Jun 2011 23:25:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10153] New: clang preprocessor crashes when using
 -E -CC option on MFC code.
Message-ID: <bug-10153-206@http.llvm.org/bugs/>

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

           Summary: clang preprocessor crashes when using -E -CC option on
                    MFC code.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pichet2000 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


If you are trying to get the preprocessed output file of a MFC file using the
-E -CC options, clang will crash.

Here is a reduction:
test.cpp:
#define A text//\


clang -E -CC test.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  Sun Jun 19 01:28:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 19 Jun 2011 01:28:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10154] New: clang rejects a constructor if the
 first parameter uses decltype()
Message-ID: <bug-10154-206@http.llvm.org/bugs/>

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

           Summary: clang rejects a constructor if the first parameter
                    uses decltype()
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pichet2000 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com,
                    pichet2000 at gmail.com


clang rejects the following C++0x, I believe it is valid:


class A{
    A(decltype(nullptr) param);
};

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 19 03:03:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 19 Jun 2011 03:03:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10154] clang rejects a constructor if the first
 parameter uses decltype()
In-Reply-To: <bug-10154-206@http.llvm.org/bugs/>
References: <bug-10154-206@http.llvm.org/bugs/>
Message-ID: <20110619080320.25A692A6C12C@llvm.org>

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

Francois Pichet <pichet2000 at gmail.com> changed:

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

--- Comment #1 from Francois Pichet <pichet2000 at gmail.com> 2011-06-19 03:03:19 CDT ---
Fixed in r133380

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 19 04:25:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 19 Jun 2011 04:25:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10155] New: C library functions in object files
 (building Qt's zlib)
Message-ID: <bug-10155-206@http.llvm.org/bugs/>

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

           Summary: C library functions in object files (building Qt's
                    zlib)
           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: vanboxem.ruben at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6748)
 --> (http://llvm.org/bugs/attachment.cgi?id=6748)
commandline and "nm" output for Clang and GCC objects

With Clang 3.0, on Windows x64 (built with GCC 4.6 for x86_64-w64-mingw32), a
lot of C library functions are placed in the .text section of object files
using them.

I have attached a text file detailing the commandlines (with a lot of Qt
specific stuff that shouldn't be very important) used to build the
"libbootstrap" library, with the "nm" output for both GCC and Clang produced
output. Note all the C library functions introduced in the .text section in the
case of Clang. This only seems to be a problem in the zlib source files, but
not all of them.

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

From bugzilla-daemon at llvm.org  Sun Jun 19 10:30:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 19 Jun 2011 10:30:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10156] New: llvm-as incorrectly flags multiple
 declarations as multiple definitions
Message-ID: <bug-10156-206@http.llvm.org/bugs/>

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

           Summary: llvm-as incorrectly flags multiple declarations as
                    multiple definitions
           Product: new-bugs
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: matt at pharr.org
                CC: llvmbugs at cs.uiuc.edu


If a function is declared multiple times in bitcode, TOT now issues an error
about it being multiply defined:

% echo "declare i1 @foo()\ndeclare i1 @foo()\n" | llvm-as
llvm-as: <stdin>:2:12: error: invalid redefinition of function 'foo'
declare i1 @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  Sun Jun 19 15:22:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 19 Jun 2011 15:22:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10158] New: clang fails to compile binutils gold
Message-ID: <bug-10158-206@http.llvm.org/bugs/>

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

           Summary: clang fails to compile binutils gold
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


While trying to compile binutils gold with clang, I encountered the following
problematic C++ code:

[~]> cat script.ii 
namespace gold
{
extern "C" {
extern void
yyerror(void* closure, const char*);
};
}
using namespace gold;
extern "C" void
yyerror(void* closurev, const char* message)
{
}
extern "C" struct Version_expression_list*
version_script_push_lang(void* closurev, const char* lang, int langlen)
{
    {
      char* buf = new char[langlen + 100];
      yyerror(closurev, buf);
    }
}

[~]> clang++ -c script.ii 
script.ii:18:7: error: call to 'yyerror' is ambiguous
      yyerror(closurev, buf);
      ^~~~~~~
script.ii:5:1: note: candidate function
yyerror(void* closure, const char*);
^
script.ii:10:1: note: candidate function
yyerror(void* closurev, const char* message)
^
1 error generated.

Where as gcc does not complain:

[~]> g++ -c script.ii 
[~]>

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

From bugzilla-daemon at llvm.org  Sun Jun 19 21:39:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 19 Jun 2011 21:39:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10159] New: clang could do a better job at warning
 for implicit conversion to bool
Message-ID: <bug-10159-206@http.llvm.org/bugs/>

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

           Summary: clang could do a better job at warning for implicit
                    conversion to bool
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pichet2000 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


MSVC will emit warnings for the following code, clang not:

enum E {
   e = 3,
};

int main() {
  bool var1 = e; // truncation from 'E' to 'bool'
  bool var2 = 3; // truncation from 'int' to 'bool'
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 20 04:28:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 20 Jun 2011 04:28:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10160] New: Problem with autoconf's mmap check
Message-ID: <bug-10160-206@http.llvm.org/bugs/>

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

           Summary: Problem with autoconf's mmap check
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ismail at namtrac.org
                CC: llvmbugs at cs.uiuc.edu


mmap.c contains the default MMAP check from autoconf

[/kutu/stuff]> clang -O1 -D_FORTIFY_SOURCE=2 mmap.c    
[/kutu/stuff]> ./a.out 
[... hangs ... ]

[/kutu/stuff]> gcc -O1 -D_FORTIFY_SOURCE=2 mmap.c 
[/kutu/stuff]> ./a.out 
[/kutu/stuff]> 

This only happens when -D_FORTIFY_SOURCE=2 is specified, according to gdb
program hangs in line 223:

    if (read (fd, data3, pagesize) != pagesize)

Due to this problem lots of configure scripts just hang when compiling programs
with clang.

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

From bugzilla-daemon at llvm.org  Mon Jun 20 07:16:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 20 Jun 2011 07:16:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10048] llc 2.9 doesn't care of packed attribute to
 generate code for x86 target
In-Reply-To: <bug-10048-206@http.llvm.org/bugs/>
References: <bug-10048-206@http.llvm.org/bugs/>
Message-ID: <20110620121640.090672A6C12C@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #13 from Duncan Sands <baldrick at free.fr> 2011-06-20 07:16:39 CDT ---
On x86-32 I can reproduce that you still get movaps even with my modified
declaration of foo1.  However the pointers being accessed are all multiples
of 16 bytes from the stack pointer, i.e. properly aligned for movaps, so there
doesn't seem to be anything wrong here.  To show that something is wrong you
need a testcase where the movaps is being used with a pointer that is not 16
bytes aligned.  If you think you might have such a testcase I suggest you have
the bitcode print the pointer value to confirm that it really isn't 16 byte
aligned.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 20 07:48:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 20 Jun 2011 07:48:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10161] New: dragonegg svn on FSF gcc 4.6.1 fails to
 compile himenoBMTxpa.c
Message-ID: <bug-10161-206@http.llvm.org/bugs/>

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

           Summary: dragonegg svn on FSF gcc 4.6.1 fails to compile
                    himenoBMTxpa.c
           Product: dragonegg
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


The himenoBMTxpa.c benchmark, 

http://accc.riken.jp/HPC_e/himenobmt_e/download1_e.html
http://accc.riken.jp/assets/files/himenob_loadmodule/himenoBMTxpa.lzh

fails to compile using the dragonegg svn plugin against FSF gcc 4.6.1svn. The
compilation fails as...


[MacPro:~] howarth% /sw/lib/gcc4.6/bin/gcc-4
-fplugin=/sw/lib/gcc4.6/lib/dragonegg.so himenoBMTxpa.c
himenoBMTxpa.c: In function ?main?:
himenoBMTxpa.c:79:5: warning: incompatible implicit declaration of built-in
function ?strcpy? [enabled by default]
himenoBMTxpa.c: In function ?set_param?:
himenoBMTxpa.c:226:5: warning: incompatible implicit declaration of built-in
function ?exit? [enabled by default]
himenoBMTxpa.c: In function ?newMat?:
himenoBMTxpa.c:239:5: warning: incompatible implicit declaration of built-in
function ?malloc? [enabled by default]
himenoBMTxpa.c: In function ?clearMat?:
himenoBMTxpa.c:248:5: warning: incompatible implicit declaration of built-in
function ?free? [enabled by default]
 <mem_ref 0x100d9f850
    type <pointer_type 0x142828930
        type <integer_type 0x1428152a0 char sizes-gimplified public string-flag
QI
            size <integer_cst 0x1428014b0 constant 8>
            unit size <integer_cst 0x1428014d8 constant 1>
            align 8 symtab 0 alias set 0 canonical type 0x1428152a0 precision 8
min <integer_cst 0x142801460 -128> max <integer_cst 0x142801578 127>
            pointer_to_this <pointer_type 0x142828930>>
        unsigned DI
        size <integer_cst 0x1428017a8 constant 64>
        unit size <integer_cst 0x1428017d0 constant 8>
        align 64 symtab 0 alias set -1 canonical type 0x142828930
        pointer_to_this <pointer_type 0x1433a1930> reference_to_this
<reference_type 0x14333c540>>

    arg 0 <ssa_name 0x100dcea50
        type <pointer_type 0x1433a1930 type <pointer_type 0x142828930>
            public unsigned DI size <integer_cst 0x1428017a8 64> unit size
<integer_cst 0x1428017d0 8>
            align 64 symtab 0 alias set -1 canonical type 0x1433a1930>
        visited var <var_decl 0x100da38c0 D.4167>def_stmt D.4167_3 = argv_2(D)
+ 8;

        version 3>
    arg 1 <integer_cst 0x100da90f0 type <pointer_type 0x1433a1930> constant 0>
    himenoBMTxpa.c:79:11>
*** WARNING *** there are active plugins, do not report this as a bug unless
you can reproduce it without enabling any plugins.
Event                            | Plugins
PLUGIN_FINISH_UNIT               | dragonegg
PLUGIN_FINISH                    | dragonegg
PLUGIN_START_UNIT                | dragonegg
himenoBMTxpa.c: In function ?main?:
himenoBMTxpa.c:70:1: internal compiler error: Segmentation fault: 11
Please submit a full bug report,
with preprocessed source if appropriate.
See <http://gcc.gnu.org/bugs.html> for instructions.

This problem doesn't exist with dragonegg svn using FSF gcc 4.5.4svn.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 20 08:02:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 20 Jun 2011 08:02:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10158] clang fails to compile binutils gold
In-Reply-To: <bug-10158-206@http.llvm.org/bugs/>
References: <bug-10158-206@http.llvm.org/bugs/>
Message-ID: <20110620130249.ED0772A6C12D@llvm.org>

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

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

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

--- Comment #5 from ?smail "cartman" D?nmez <ismail at namtrac.org> 2011-06-20 08:02:49 CDT ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 20 12:49:20 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 20 Jun 2011 12:49:20 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7868] [LAPACK, basicaa] major missed optimizations
In-Reply-To: <bug-7868-206@http.llvm.org/bugs/>
References: <bug-7868-206@http.llvm.org/bugs/>
Message-ID: <20110620174920.EB5D32A6C12F@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #8 from Chris Lattner <clattner at apple.com> 2011-06-20 12:49:20 CDT ---
Nice! 25% faster sounds great.

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

From bugzilla-daemon at llvm.org  Mon Jun 20 15:46:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 20 Jun 2011 15:46:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10162] New: Operands of blockaddress incorrect when
 function is inlined.
Message-ID: <bug-10162-206@http.llvm.org/bugs/>

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

           Summary: Operands of blockaddress incorrect when function is
                    inlined.
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ahatanak at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Compiling the code shown below (990208-1.c, adapted from torture test) with
clang and llc fails with the following error message:

$ clang 990208-1.c -o 990208-1.x86.ll -O3 -emit-llvm -S
$ llc 990208-1.x86.ll -o -
llc: 990208-1.x86.ll:27:33: error: referenced value is not a basic block
  store i8* blockaddress(@doit, %here.i), i8** @ptr1, align 8, !tbaa !0

There are no errors if __attribute__ ((noinline)) is added to function doit.

/// 990208-1.c
void *ptr1;
int i = 1;

//__attribute__ ((noinline))
void doit(void **pptr, int cond)
{
  if (cond) {
  //++i;
  here:
    *pptr = &&here;
  }
}

void f(int cond)
{
  doit (&ptr1, cond);
}

/// 990208-1.x86.ll
; ModuleID = '990208-1.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

@i = global i32 1, align 4
@ptr1 = common global i8* null, align 8

define void @doit(i8** nocapture %pptr, i32 %cond) nounwind uwtable {
entry:
  %tobool = icmp eq i32 %cond, 0
  br i1 %tobool, label %if.end, label %here

here:                                             ; preds = %entry
  store i8* blockaddress(@doit, %here), i8** %pptr, align 8, !tbaa !0
  br label %if.end

if.end:                                           ; preds = %entry, %here
  ret void
}

define void @f(i32 %cond) nounwind uwtable {
entry:
  %tobool.i = icmp eq i32 %cond, 0
  br i1 %tobool.i, label %doit.exit, label %here.i

here.i:                                           ; preds = %entry
  store i8* blockaddress(@doit, %here.i), i8** @ptr1, align 8, !tbaa !0
  br label %doit.exit

doit.exit:                                        ; preds = %entry, %here.i
  ret void
}

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 20 19:01:00 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 20 Jun 2011 19:01:00 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9921] UNREACHABLE at LegalizeIntegerTypes.cpp:982
 when using clang's -ftrapv
In-Reply-To: <bug-9921-206@http.llvm.org/bugs/>
References: <bug-9921-206@http.llvm.org/bugs/>
Message-ID: <20110621000100.DC6B82A6C124@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #4 from Eric Christopher <echristo at gmail.com> 2011-06-20 19:00:59 CDT ---
Should be fixed now:

r133288 | echristo | 2011-06-17 13:41:29 -0700 (Fri, 17 Jun 2011) | 6 lines

Lower multiply with overflow checking to __mulo<mode>
calls if we haven't been able to lower them any
other way.

Fixes rdar://9090077 and rdar://9210061


r133318 | echristo | 2011-06-17 17:09:57 -0700 (Fri, 17 Jun 2011) | 6 lines

Fix UMULO support for 2x register width to allow the full
range without a libcall to a new mulo<mode> libcall
that we'd have to create.

Finishes the rest of rdar://9090077 and rdar://9210061

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 20 19:40:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 20 Jun 2011 19:40:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10074] clang++ does not use env. variable
	CPLUS_INCLUDE_PATH
In-Reply-To: <bug-10074-206@http.llvm.org/bugs/>
References: <bug-10074-206@http.llvm.org/bugs/>
Message-ID: <20110621004043.ABA092A6C124@llvm.org>

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

Jordy Rose <jediknil at belkadan.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jediknil at belkadan.com
         Resolution|                            |DUPLICATE

--- Comment #2 from Jordy Rose <jediknil at belkadan.com> 2011-06-20 19:40:42 CDT ---
None of the *PATH variables are hooked up right now, unfortunately.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 21 02:48:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 02:48:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10163] New: false positive on partially initialized
 array of floating point values.
Message-ID: <bug-10163-206@http.llvm.org/bugs/>

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

           Summary: false positive on partially initialized array of
                    floating point values.
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


When using implicit array initialization on array of non integral values
(either float or double), clang properly generate a memset(0) to initialize the
array, but the static analyzer does not consider the array as initialized.

----- foo.c
extern void CGAffineTransformMake(double a, double b, double c, double d,
double tx, double ty);

void test2() {
  float matrix[6] = { 0 };
  return CGAffineTransformMake(matrix[0], matrix[1], matrix[2], matrix[3],
matrix[4], matrix[5]);
}
------

$ clang --analyze foo.c
foo.c:7:10: warning: Function call argument is an uninitialized value
  return CGAffineTransformMake(matrix[0], matrix[1], matrix[2], matrix[3],
matrix[4], matrix[5]);
         ^                                ~~~~~~~~~
1 warning generated.

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

From bugzilla-daemon at llvm.org  Tue Jun 21 02:52:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 02:52:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10164] New: Issue with objc_method_family(init) in
 class extension.
Message-ID: <bug-10164-206@http.llvm.org/bugs/>

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

           Summary: Issue with objc_method_family(init) in class
                    extension.
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: devlists at shadowlab.org
                CC: llvmbugs at cs.uiuc.edu


When using the objc_method_family(init) attribute in class extension, clang
does not properly infer the return type and emit a diagnostic to tell it
mismatch (whatever you set as return type).

---------- method_family_init.m
@interface Foo {}
@end

@interface Foo() 
- (id)myinit __attribute__((objc_method_family(init)));
@end

@implementation Foo
- (id)myinit { return self; }
@end

------------
% clang -c method_family_init.m
method_family_init.m:9:1: warning: method is expected to return an instance of
its class type 'Foo', but is declared to return 'id'
- (id)myinit { return self; }
^  ~~
method_family_init.m:5:1: note: overridden method is part of the 'init' method
family
- (id)myinit __attribute__((objc_method_family(init)));
^
1 warning generated.


Note that setting the return type to (Foo *) will not solve the issue as clang
expect 'Foo' and not 'Foo *', which is meaningless in Obj-C.

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

From bugzilla-daemon at llvm.org  Tue Jun 21 09:32:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 09:32:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8808] clang -m32 does not pass -L/usr/lib32 to the
	linker
In-Reply-To: <bug-8808-206@http.llvm.org/bugs/>
References: <bug-8808-206@http.llvm.org/bugs/>
Message-ID: <20110621143206.196D42A6C12D@llvm.org>

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

Roman Divacky <rdivacky at freebsd.org> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |rdivacky at freebsd.org
         Resolution|                            |FIXED

--- Comment #4 from Roman Divacky <rdivacky at freebsd.org> 2011-06-21 09:32:04 CDT ---
this has been already fixed:


pes $ clang -m32 -v hello.c
clang version 3.0 (trunk 133513)
Target: i386-unknown-freebsd8.2
Thread model: posix
 "/usr/local/bin/clang" -cc1 -triple i386-unknown-freebsd8.2 -emit-obj
-mrelax-all -disable-free -main-file-name hello.c -mrelocation-model static
-mdisable-fp-elim -masm-verbose -mconstructor-aliases -target-cpu i486
-target-linker-version 2.15 -momit-leaf-frame-pointer -v -resource-dir
/usr/local/bin/../lib/clang/3.0 -ferror-limit 19 -fmessage-length 116
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-C7PT95.o
-x c hello.c
clang -cc1 version 3.0 based upon llvm 3.0svn hosted on
x86_64-unknown-freebsd8.2
ignoring nonexistent directory "/usr/include/clang/3.0"
ignoring duplicate directory "/usr/local/bin/../lib/clang/3.0/include"
#include "..." search starts here:
#include <...> search starts here:
 /usr/local/bin/../lib/clang/3.0/include
 /usr/include
End of search list.
 "/usr/local/bin/ld" --eh-frame-hdr -dynamic-linker /libexec/ld-elf.so.1 -m
elf_i386_fbsd -o a.out crt1.o crti.o crtbegin.o -L/usr/lib32 /tmp/cc-C7PT95.o
-lgcc --as-needed -lgcc_s --no-as-needed -lc -lgcc --as-needed -lgcc_s
--no-as-needed crtend.o crtn.o

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

From bugzilla-daemon at llvm.org  Tue Jun 21 10:55:35 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 10:55:35 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10165] New: llvm-mc: floating point load shown as
 invalid with i386 target
Message-ID: <bug-10165-206@http.llvm.org/bugs/>

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

           Summary: llvm-mc: floating point load shown as invalid with
                    i386 target
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: kkhoo at perfwizard.com
                CC: llvmbugs at cs.uiuc.edu


$ echo '0xdd 0x45 0xf0'|./llvm-mc -disassemble -triple=x86_64
    fldl    -16(%rbp)
$ echo '0xdd 0x45 0xf0'|./llvm-mc -disassemble -triple=i386
<stdin>:1:1: warning: invalid instruction encoding
0xdd 0x45 0xf0
^

>From the Intel software reference manual: "FLD?Load Floating Point Value...This
instruction?s operation is the same in non-64-bit modes and 64-bit mode."



$ ./llvm-mc -version
Low Level Virtual Machine (http://llvm.org/):
  llvm version 2.9
  Optimized build.
  Built Jun 20 2011 (12:11:38).
  Host: i386-apple-darwin10
  Host CPU: corei7

  Registered Targets:
    alpha   - Alpha [experimental]
    arm     - ARM
    bfin    - Analog Devices Blackfin [experimental]
    c       - C backend
    cellspu - STI CBEA Cell SPU [experimental]
    cpp     - C++ backend
    mblaze  - MBlaze
    mips    - Mips
    mipsel  - Mipsel
    msp430  - MSP430 [experimental]
    ppc32   - PowerPC 32
    ppc64   - PowerPC 64
    ptx     - PTX
    sparc   - Sparc
    sparcv9 - Sparc V9
    systemz - SystemZ
    thumb   - Thumb
    x86     - 32-bit X86: Pentium-Pro and above
    x86-64  - 64-bit X86: EM64T and AMD64
    xcore   - XCore

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 21 11:08:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 11:08:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10097] MCDisassembler is unable to decode XOR r32,
	r/m32
In-Reply-To: <bug-10097-206@http.llvm.org/bugs/>
References: <bug-10097-206@http.llvm.org/bugs/>
Message-ID: <20110621160843.82A082A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-21 11:08:43 CDT ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 21 12:07:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 12:07:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10166] New: Over-conservative handling of asm
	volatile
Message-ID: <bug-10166-206@http.llvm.org/bugs/>

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

           Summary: Over-conservative handling of asm volatile
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


GCC hoists the load of *n out of this loop, LLVM doesn't:

void foo(double *p, long *n) {
  long i;
  for (i=0;i<*n;++i) {
    asm volatile("#hello");
  }
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 21 12:40:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 12:40:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10155] C library functions in object files
	(building Qt's zlib)
In-Reply-To: <bug-10155-206@http.llvm.org/bugs/>
References: <bug-10155-206@http.llvm.org/bugs/>
Message-ID: <20110621174016.66F182A6C124@llvm.org>

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

vanboxem.ruben at gmail.com changed:

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

--- Comment #5 from vanboxem.ruben at gmail.com 2011-06-21 12:40:15 CDT ---
This bug pointed me in the right direction:
http://llvm.org/bugs/show_bug.cgi?id=5960

I am contacting the mingw-w64 devs now to change their inline usage. This
wouldn't have been a problem at all I think if Clang identified itself as GCC
4.3.

The relevant line I changed in _mingw.h (starting at line 74):

#ifdef __cplusplus
# define __CRT_INLINE inline
#elif defined(_MSC_VER)
# define __CRT_INLINE __inline
#else
# if ( __MINGW_GNUC_PREREQ(4, 3)  &&  __STDC_VERSION__ >= 199901L) ||
(defined(__clang__))
#  define __CRT_INLINE extern inline __attribute__((__gnu_inline__))
# else

Mind you: the proposed change will soon be integrated in mingw-w64, but that
does not mean mingw.org will pick up 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  Tue Jun 21 13:23:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 13:23:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9565] clang c++ bad codegen with const reference?
In-Reply-To: <bug-9565-206@http.llvm.org/bugs/>
References: <bug-9565-206@http.llvm.org/bugs/>
Message-ID: <20110621182350.E47FA2A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-21 13:23:50 CDT ---
Fixed in Clang r133521 and r133528.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 21 17:50:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 17:50:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10167] New: Failure to Compile Boost Lambda Function
Message-ID: <bug-10167-206@http.llvm.org/bugs/>

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

           Summary: Failure to Compile Boost Lambda Function
           Product: clang
           Version: 2.7
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ViperX883 at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This program fails to compile:

------------------
#include <vector>
#include <iostream>
#include <algorithm>

#include <boost/lambda/lambda.hpp>

int main( ) {

  std::vector< int > v( 5, 5 );

  std::for_each( v.begin( ), v.end( ), std::cout << boost::lambda::_1 );
}
------------------

The output when using the -v command line option is:

------------------
clang version 1.1 (branches/release_27)
Target: x86_64-pc-linux-gnu
Thread model: posix
 "/usr/bin/clang" -cc1 -triple x86_64-pc-linux-gnu -S -disable-free
-disable-llvm-verifier -main-file-name blah.cpp -mrelocation-model static
-mdisable-fp-elim -mconstructor-aliases -munwind-tables -target-cpu x86-64 -v
-resource-dir /usr/lib/clang/1.1 -fmessage-length 150 -fexceptions
-fgnu-runtime -fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-msASiK.s
-x c++ blah.cpp
clang -cc1 version 1.1 based upon llvm 2.7 hosted on x86_64-pc-linux-gnu
ignoring nonexistent directory "/usr/include/c++/4.4.3/x86_64-pc-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.4.3/i686-pc-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.4/i486-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.1.3"
ignoring nonexistent directory "/usr/include/c++/4.1.3/i486-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.1.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.3.3"
ignoring nonexistent directory "/usr/include/c++/4.3.3/x86_64-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.3.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.1"
ignoring nonexistent directory "/usr/include/c++/4.4.1/x86_64-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.4.1/backward"
ignoring nonexistent directory "/usr/include/c++/4.1.2"
ignoring nonexistent directory "/usr/include/c++/4.1.2/i386-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.1.2/backward"
ignoring nonexistent directory "/usr/include/c++/4.3.0"
ignoring nonexistent directory "/usr/include/c++/4.3.0/i386-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.3.0/backward"
ignoring nonexistent directory "/usr/include/c++/4.3.2"
ignoring nonexistent directory "/usr/include/c++/4.3.2/i386-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.3.2/backward"
ignoring nonexistent directory "/usr/include/c++/4.3.2"
ignoring nonexistent directory "/usr/include/c++/4.3.2/x86_64-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.3.2/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.1"
ignoring nonexistent directory "/usr/include/c++/4.4.1/i586-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.1/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.2"
ignoring nonexistent directory "/usr/include/c++/4.4.2/i686-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4.2/backward"
ignoring nonexistent directory "/usr/include/c++/4.4.3/i686-redhat-linux/"
ignoring nonexistent directory "/usr/include/c++/4.3"
ignoring nonexistent directory "/usr/include/c++/4.3/i586-suse-linux/"
ignoring nonexistent directory "/usr/include/c++/4.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.3"
ignoring nonexistent directory "/usr/include/c++/4.3/x86_64-suse-linux/"
ignoring nonexistent directory "/usr/include/c++/4.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.4/i586-suse-linux/"
ignoring nonexistent directory "/usr/include/c++/4.4/x86_64-suse-linux/"
ignoring nonexistent directory "/usr/include/c++/4.3.1"
ignoring nonexistent directory "/usr/include/c++/4.3.1/i686-pc-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.3.1/backward"
ignoring nonexistent directory "/usr/include/c++/4.3.1"
ignoring nonexistent directory
"/usr/include/c++/4.3.1/x86_64-unknown-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.3.1/backward"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/i686-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.4/include/g++-v4/backward"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/i686-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.3.2/include/g++-v4/backward"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/i686-pc-linux-gnu/4.1.2/include/g++-v4/backward"
ignoring nonexistent directory "/usr/include/c++/4.3"
ignoring nonexistent directory "/usr/include/c++/4.3/i486-pc-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.3/backward"
ignoring nonexistent directory "/usr/include/c++/4.3"
ignoring nonexistent directory "/usr/include/c++/4.3/i486-linux-gnu/"
ignoring nonexistent directory "/usr/include/c++/4.3/backward"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/i686-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.1.2/include/g++-v4/backward"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/x86_64-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.3.2/include/g++-v4/backward"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/x86_64-pc-linux-gnu/"
ignoring nonexistent directory
"/usr/lib/gcc/x86_64-pc-linux-gnu/4.4.3/include/g++-v4/backward"
ignoring duplicate directory "/usr/include/c++/4.4.3"
ignoring duplicate directory "/usr/include/c++/4.4.3/backward"
ignoring duplicate directory "/usr/include/c++/4.4.3"
ignoring duplicate directory "/usr/include/c++/4.4.3/backward"
ignoring duplicate directory "/usr/include/c++/4.4.3"
ignoring duplicate directory "/usr/include/c++/4.4.3/backward"
ignoring duplicate directory "/usr/include/c++/4.4.3"
ignoring duplicate directory "/usr/include/c++/4.4.3/backward"
ignoring duplicate directory "/usr/include/c++/4.4.3"
ignoring duplicate directory "/usr/include/c++/4.4.3/backward"
ignoring duplicate directory "/usr/include/c++/4.4.3"
ignoring duplicate directory "/usr/include/c++/4.4.3/backward"
#include "..." search starts here:
#include <...> search starts here:
 /usr/lib/clang/1.1/include
 /usr/include/c++/4.4.3
 /usr/include/c++/4.4.3/backward
 /usr/include/c++/4.4/x86_64-linux-gnu
 /usr/local/include
 /usr/include
End of search list.
0  libLLVM-2.7.so.1 0x00007f4783d91d2f
1  libLLVM-2.7.so.1 0x00007f4783d9238d
2  libpthread.so.0  0x00007f47831838f0
3  clang            0x0000000000517ac7
4  clang            0x0000000000518039
5  clang            0x0000000000518d95
6  clang            0x0000000000519079
7  clang            0x000000000051bc5c
8  clang            0x000000000050868d
9  clang            0x000000000051046a
10 clang            0x000000000051069b
11 clang            0x00000000005072e1
12 clang            0x000000000041c3d4
13 clang            0x0000000000759cf1
14 clang            0x0000000000759675
15 clang            0x000000000075a15b
16 clang            0x0000000000759675
17 clang            0x000000000075a15b
18 clang            0x0000000000759675
19 clang            0x000000000075a15b
20 clang            0x0000000000759675
21 clang            0x00000000005f7a9a
22 clang            0x00000000008f783d
23 clang            0x00000000005f523b
24 clang            0x0000000000421479
25 clang            0x0000000000415186
26 clang            0x0000000000417b9b main + 1771
27 libc.so.6        0x00007f4782255c4d __libc_start_main + 253
28 clang            0x0000000000412cd9
Stack dump:
0.    Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu -S
-disable-free -disable-llvm-verifier -main-file-name blah.cpp
-mrelocation-model static -mdisable-fp-elim -mconstructor-aliases
-munwind-tables -target-cpu x86-64 -v -resource-dir /usr/lib/clang/1.1
-fmessage-length 150 -fexceptions -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o /tmp/cc-msASiK.s -x c++ blah.cpp 
1.    <eof> parser at end of file
2.    /usr/include/c++/4.4.3/bits/stl_algo.h:4194:5: instantiating function
definition 'std::for_each'
3.    /usr/include/boost/lambda/detail/lambda_functors.hpp:172:3: instantiating
function definition 'boost::lambda::lambda_functor<class
boost::lambda::lambda_functor_base<class boost::lambda::bitwise_action<class
boost::lambda::leftshift_action>, class boost::tuples::tuple<class
std::basic_ostream<char, struct std::char_traits<char> > &, class
boost::lambda::lambda_functor<struct boost::lambda::placeholder<1> >, struct
boost::tuples::null_type, struct boost::tuples::null_type, struct
boost::tuples::null_type, struct boost::tuples::null_type, struct
boost::tuples::null_type, struct boost::tuples::null_type, struct
boost::tuples::null_type, struct boost::tuples::null_type> > >::operator()'
4.    /usr/include/boost/lambda/detail/operator_lambda_func_base.hpp:212:1
<Spelling=/usr/include/boost/lambda/detail/operator_lambda_func_base.hpp:157:7>:
instantiating function definition 'boost::lambda::lambda_functor_base<class
boost::lambda::bitwise_action<class boost::lambda::leftshift_action>, class
boost::tuples::tuple<class std::basic_ostream<char, struct
std::char_traits<char> > &, class boost::lambda::lambda_functor<struct
boost::lambda::placeholder<1> >, struct boost::tuples::null_type, struct
boost::tuples::null_type, struct boost::tuples::null_type, struct
boost::tuples::null_type, struct boost::tuples::null_type, struct
boost::tuples::null_type, struct boost::tuples::null_type, struct
boost::tuples::null_type> >::call'
5.    /usr/include/boost/lambda/detail/select_functions.hpp:27:1: instantiating
function definition 'boost::lambda::detail::select'
6.    /usr/include/boost/lambda/detail/select_functions.hpp:27:1: LLVM IR
generation of declaration 'boost::lambda::detail::select'
7.    /usr/include/boost/lambda/detail/select_functions.hpp:27:1: Mangling
declaration 'boost::lambda::detail::select'
clang: error: compiler command failed due to signal 11 (use -v to see
invocation)
--------------------

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

From bugzilla-daemon at llvm.org  Tue Jun 21 17:53:02 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 17:53:02 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10167] Failure to Compile Boost Lambda Function
In-Reply-To: <bug-10167-206@http.llvm.org/bugs/>
References: <bug-10167-206@http.llvm.org/bugs/>
Message-ID: <20110621225302.2A5602A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-21 17:53:01 CDT ---
Please use a recent version of Clang (2.9 or top-of-tree); 2.7 provided almost
no C++ support.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 21 18:01:55 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 18:01:55 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10168] New: -Wunused gives multiple errors for
 unused variable in template
Message-ID: <bug-10168-206@http.llvm.org/bugs/>

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

           Summary: -Wunused gives multiple errors for unused variable in
                    template
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


template<typename T>
struct S {
  void f() {
    int a;
  }
};

int main() {
  S<int>().f();
  S<double>().f();
}


tmp.cpp:4:9: warning: unused variable 'a' [-Wunused-variable]
    int a;
        ^
tmp.cpp:4:9: warning: unused variable 'a' [-Wunused-variable]                   
tmp.cpp:9:12: note: in instantiation of member function 'S<int>::f' requested
here
  S<int>().f();
           ^
tmp.cpp:4:9: warning: unused variable 'a' [-Wunused-variable]                   
    int a;
        ^
tmp.cpp:10:15: note: in instantiation of member function 'S<double>::f'
requested here     
  S<double>().f();
              ^

One warning is produced for the template definition, and one more is produced
for each instantiation. Strangely, we don't get the first warning for a
dependently-typed unused variable.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 21 18:42:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 18:42:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10168] -Wunused gives multiple errors for unused
 variable in template
In-Reply-To: <bug-10168-206@http.llvm.org/bugs/>
References: <bug-10168-206@http.llvm.org/bugs/>
Message-ID: <20110621234231.E18712A6C12D@llvm.org>

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

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> 2011-06-21 18:42:31 CDT ---
Fixed in r133580.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 21 21:13:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 21 Jun 2011 21:13:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8319] clang -O can't build ruby trunk
In-Reply-To: <bug-8319-206@http.llvm.org/bugs/>
References: <bug-8319-206@http.llvm.org/bugs/>
Message-ID: <20110622021308.4A5D52A6C12E@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-21 21:13:06 CDT ---
I recently fixed a bug affecting ruby, and I can't reproduce the given issue,
so I'm going to call this fixed; please reopen if you still run into issues.

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

From bugzilla-daemon at llvm.org  Wed Jun 22 07:05:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 22 Jun 2011 07:05:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10169] New: Using address of global non-weak is
	tautologic
Message-ID: <bug-10169-206@http.llvm.org/bugs/>

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

           Summary: Using address of global non-weak is tautologic
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: joerg at NetBSD.org
                CC: llvmbugs at cs.uiuc.edu


int foo;

int main(void)
{
  return &foo ? 1 : 0;
}

gives a warning with GCC 4.5.

Possible exceptions are: section, weak or weakref attribute set. This warning
triggered at least one real bug in the NetBSD code base, so it is useful 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  Wed Jun 22 07:33:07 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 22 Jun 2011 07:33:07 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10170] New: opt std-compile-opts wronly optimizes
 trap instruction
Message-ID: <bug-10170-206@http.llvm.org/bugs/>

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

           Summary: opt std-compile-opts wronly optimizes trap instruction
           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: martijn at martijnrutten.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6759)
 --> (http://llvm.org/bugs/attachment.cgi?id=6759)
Source code that triggers the error (returns 2 iso. trap)

opt -std-compile-opts creates wrong code in case of a llvm.trap() instruction
in the following example code 'trap.c' (extracted from a coding bug in the
OpenCV library)

  #include <stdio.h>

  int foo(int **p) {
    if (!p && !*p) return 1; /* trap on *p if p is 0 */
    return 2;
  }

  int main() {
    return foo(NULL);
  }

To reproduce:
Environment: 32 bits Ubuntu 10.4
clang and llvm from svn trunk revision r133615 (2011-06-22)

clang -O1 trap.c -c -emit-llvm -o trap.bc
opt -std-compile-opts trap.bc -o trap.opt.bc
llvm-dis trap.opt.bc

This gives trap.opt.ll (snippet):

  define i32 @foo(i32** %p) nounwind readonly {
  entry:
    %tobool = icmp eq i32** %p, null
    br i1 %tobool, label %land.lhs.true, label %return

  land.lhs.true:                                    ; preds = %entry
    tail call void @llvm.trap()
    unreachable

  return:                                           ; preds = %entry
    ret i32 2
  }

  define i32 @main() nounwind readnone {
  entry:
    ret i32 2
  }

This shows that in main(), the call to foo() is inlined and the result=2 is
returned, whereas it should trigger the trap() instruction. Note that the clang
-O1 command still gives correct code where the call to foo is not inlined.

Interestingly, compilation with clang -O2 trap.c does give the correct result,
where inlining of foo() leads to main() direcly calling the trap() instruction.

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

From bugzilla-daemon at llvm.org  Wed Jun 22 11:26:52 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 22 Jun 2011 11:26:52 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10170] opt std-compile-opts wronly optimizes trap
	instruction
In-Reply-To: <bug-10170-206@http.llvm.org/bugs/>
References: <bug-10170-206@http.llvm.org/bugs/>
Message-ID: <20110622162652.958712A6C12C@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2011-06-22 11:26:52 CDT ---
Yes, GCC is pretty careful about preserving traps.  Clang has a different
policy.
You could open a new bug report requesting that clang preserve more traps as an
enhancement if you feel strongly about 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 Jun 22 13:10:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 22 Jun 2011 13:10:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10171] New: Substitute unpckhpd,
 unpcklpd and movddup for shufpd
Message-ID: <bug-10171-206@http.llvm.org/bugs/>

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

           Summary: Substitute unpckhpd, unpcklpd and movddup for shufpd
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jmuizelaar at mozilla.com
                CC: llvmbugs at cs.uiuc.edu


shufpd    $0, %xmm0, %xmm0 ## xmm0 = xmm0[0,0]
can be replaced with unpcklpd when restricted to sse2 and movddup when using
sse3.

shufpd    $3, %xmm0, %xmm0 ## xmm0 = xmm0[1,1]
can be replaced with unpckhpd

These variants are faster on some processors and take a byte less to encode.
moddup also allows the source to be different than the destination which can
allow a copy to be avoided.

GCC also makes these substitutions.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 22 13:17:14 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 22 Jun 2011 13:17:14 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9654] Crash on call to function template declared
 without function declarator
In-Reply-To: <bug-9654-206@http.llvm.org/bugs/>
References: <bug-9654-206@http.llvm.org/bugs/>
Message-ID: <20110622181714.40BD82A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #4 from Douglas Gregor <dgregor at apple.com> 2011-06-22 13:17:13 CDT ---
This wasn't as horrible as I thought; everywhere else, Sema maintains the AST
invariant by synthesizing parameter declarations. Template instantiation needs
to do this as well.

Fixed in Clang r133628.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 22 16:23:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 22 Jun 2011 16:23:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10005] DebugLoc information is lost in code
	generation
In-Reply-To: <bug-10005-206@http.llvm.org/bugs/>
References: <bug-10005-206@http.llvm.org/bugs/>
Message-ID: <20110622212337.5B0412A6C12C@llvm.org>

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

Devang Patel <dpatel at apple.com> changed:

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

--- Comment #1 from Devang Patel <dpatel at apple.com> 2011-06-22 16:23:37 CDT ---
In this test case, there is not any code at line no. 3  and the code at line
no. 8 is dead.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 22 18:16:15 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 22 Jun 2011 18:16:15 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10172] New: Different Output with and without Fast
 Instruction Selector (coreutils bytecode)
Message-ID: <bug-10172-206@http.llvm.org/bugs/>

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

           Summary: Different Output with and without Fast Instruction
                    Selector (coreutils bytecode)
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bprosnitz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I generated a bitcode file that runs a coreutils function with klee-generated
arguments. The output of this bitcode file differs with and without -fast-isel
enabled.

$ ~/llvm-2.9/Release/bin/lli -fast-isel bug.bc
0
$ ~/llvm-2.9/Release/bin/lli bug.bc
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  Wed Jun 22 20:20:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 22 Jun 2011 20:20:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10173] New: Clang asserts/crashes when compiling
 static member function with late-specified return type
Message-ID: <bug-10173-206@http.llvm.org/bugs/>

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

           Summary: Clang asserts/crashes when compiling static member
                    function with late-specified return type
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: james at jamesmcnellis.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


(Using clang version 3.0 (trunk 133044) / i686-pc-mingw32)

Clang crashes when compiling the following trivial program:

    struct S
    {
        template <typename T>
        static auto f() -> void { }
    };

c:\dev>clang++ -std=c++0x stubby.cpp
Assertion failed: isa<X>(Val) && "cast<Ty>() argument of incompatible type!",
file C:\dev\tools\clang_trunk\llvm\include/llvm/Support/Casting.h, line 194

This application has requested the Runtime to terminate it in an unusual way.
Please contact the application's support team for more information.
clang++: error: clang frontend command failed with exit code 3 (use -v to see
invocation)

-------------------------------------------------------
If we make 'f' a nontemplate static member function, Clang just gets confused:

    struct S 
    { 
        static auto f() -> void { } 
    };

c:\dev>clang++ -std=c++0x stubby.cpp
stubby.cpp:3:17: error: declaration of variable 'f' with type 'void ()'
requires an initializer
    static auto f() -> void { }
                ^
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 Jun 23 01:54:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 01:54:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10174] New: Incorrect decoration of symbols in
 export declaration (dllexport)
Message-ID: <bug-10174-206@http.llvm.org/bugs/>

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

           Summary: Incorrect decoration of symbols in export declaration
                    (dllexport)
           Product: tools
           Version: 2.9
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: l0calh05t at gmx.net
                CC: llvmbugs at cs.uiuc.edu


When a function is declared with the dllexport option such as

define dllexport %struct.AEffect* @VSTPluginMain(i32 (%struct.AEffect*, i32,
i32, i32, i8*, float)* %audioMaster)

results in the symbol _VstPluginMain (with _ prefix) in the generated assembly,
as required per dll export rules, but the export declaration

.ascii     " -export:_VSTPluginMain"

should *NOT* contain this decoration, which results in the following linker
error:

Cannot export _VSTPluginMain: symbol not found

Manually correcting the export declaration to

.ascii     " -export:VSTPluginMain"

corrects this error.

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

From bugzilla-daemon at llvm.org  Thu Jun 23 05:03:19 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 05:03:19 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10175] New: Wrong symbol names with cross compiling
Message-ID: <bug-10175-206@http.llvm.org/bugs/>

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

           Summary: Wrong symbol names with cross compiling
           Product: libraries
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Backend: X86
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: glenn at egastones.ch
                CC: llvmbugs at cs.uiuc.edu


The cross compiler produces wrong export symbols if you cross compile a windows
target.

/Developer/usr/bin/clang -shared -ccc-host-triple i386-pc-mingw32 -ccc-gcc-name
/Developer/Cocotron/1.0/Windows/i386/gcc-4.3.1/bin/i386-pc-mingw32msvc-gcc
-I/Developer/Cocotron/1.0/Windows/i386/llvm-clang-trunk/i386-pc-mingw32msvc/include
exportTest.c

produces
Cannot export _Function1: symbol not found
collect2: ld returned 1 exit status
clang: error: linker command failed with exit code 1 (use -v to see invocation)



Cotent of exportTest.c:

__declspec(dllexport) void __cdecl Function1(void)
{

}


see mailing list :
http://lists.cs.uiuc.edu/pipermail/cfe-dev/2011-June/015757.html


I have a workaround for this in lib/Target/X86/X86AsmPrinter.cpp to delete the
first character of the symbol wiht .substr(1) at line 624 and 637.


Line 624: 
    name += DLLExportedGlobals[i]->getName() 
To 
   name += DLLExportedGlobals[i]->getName().substr(1); 

AND 

Line 637:
        name += DLLExportedFns[i]->getName(); 
To 
        name += DLLExportedFns[i]->getName().substr(1); 


This is for sure the wrong place and this is only a hack.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 23 05:51:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 05:51:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10175] Wrong symbol names with cross compiling
In-Reply-To: <bug-10175-206@http.llvm.org/bugs/>
References: <bug-10175-206@http.llvm.org/bugs/>
Message-ID: <20110623105104.53EE12A6C12C@llvm.org>

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

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

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

--- Comment #1 from Anton Korobeynikov <asl at math.spbu.ru> 2011-06-23 05:51:04 CDT ---
This is not correct since we'll have a problems with fastcall stuff. Anyway,
dup of 10174

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 23 10:15:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 10:15:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10176] New: reassociate corrupts debug info
Message-ID: <bug-10176-206@http.llvm.org/bugs/>

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

           Summary: reassociate corrupts debug info
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: gohman at apple.com
                CC: llvmbugs at cs.uiuc.edu


On this C testcase:

long foo(long a, long b, long c) {
  long d = c + b;
  return d + a;
}

clang -O2 -g produces this output (edited for clarity):

  tail call void @llvm.dbg.value(metadata !{i64 %add}, i64 0, metadata !9)
  %add = add i64 %b, %a
  %add4 = add i64 %add, %c
  ret i64 %add4
[...]
!9 = metadata !{i32 590080, metadata !10, metadata !"d", metadata !2, i32 2,
metadata !5, i32 0} ; [ DW_TAG_auto_variable ]

This says that the variable "d" has the value of %add. This is actively wrong,
because %add is b+a, not c+b.

To be conservatively correct within the current system, any pass which modifies
instructions in place (reassociate, in this case) should also search for
@llvm.dbg.value calls that reference instructions to be modified, and delete
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  Thu Jun 23 10:22:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 10:22:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10177] New: non-type template arguments to alias
 templates which don't appear in the expansion are not marked as used in
 dependent contexts
Message-ID: <bug-10177-206@http.llvm.org/bugs/>

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

           Summary: non-type template arguments to alias templates which
                    don't appear in the expansion are not marked as used
                    in dependent contexts
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Consider the following:


#include <iostream>

template<typename T, typename U, U> using alias_ref = T;

template<typename T>
struct U {
  static int a;
};

template<typename T>
int U<T>::a = (std::cout << "called" << std::endl, 0);

template<typename T>
void f() {
  alias_ref<int, int&, U<int>::a> a;
};

int main() {
  f<int>();
}


Here, the definition of U<int>::a should be instantiated, since it is odr-used.
However, clang does not instantiate it. Presumably we're canonicalizing the
type of f<T>'s 'a' variable to 'int' at some point and thus not noticing that
U<int>::a 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  Thu Jun 23 12:39:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 12:39:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10178] New: multiple typeinfo name
Message-ID: <bug-10178-206@http.llvm.org/bugs/>

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

           Summary: multiple typeinfo name
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: FreeBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rdivacky at freebsd.org
                CC: llvmbugs at cs.uiuc.edu


pes delta-2006.08.03$ clang++ -D_REENTRANT -I./source/common -I./source/i18n
-I./source/tools/toolutil -I./source/tools/ctestfw -D'U_TOPSRCDIR="../../"'
-D'U_TOPBUILDDIR="/usr/ports/devel/icu/work/icu/source/"' -O2 -pipe
-fno-strict-aliasing -W -Wall -ansi -pedantic -Wpointer-arith -Wwrite-strings
-Wno-long-long -c -o uobjtest.o uobjtest.cpp && nm uobjtest.o | grep
N6icu_4613DecimalFormatE
                 U _ZTIN6icu_4613DecimalFormatE
                 U _ZTSN6icu_4613DecimalFormatE

pes delta-2006.08.03$ g++ -D_REENTRANT -I./source/common -I./source/i18n
-I./source/tools/toolutil -I./source/tools/ctestfw -D'U_TOPSRCDIR="../../"'
-D'U_TOPBUILDDIR="/usr/ports/devel/icu/work/icu/source/"' -O2 -pipe
-fno-strict-aliasing -W -Wall -ansi -pedantic -Wpointer-arith -Wwrite-strings
-Wno-long-long -c -o uobjtest.o uobjtest.cpp && nm uobjtest.o | grep
N6icu_4613DecimalFormatE
                 U _ZTIN6icu_4613DecimalFormatE

Note that with clang++ the typeinfo name is there twice. This causes problems
for typeid as in this example (derived from icu testcase):

typeid(*nf) != typeid(DecimalFormat)

where each is one instance of the _ZTSN6icu_4613DecimalFormatE.

This cannot be reproduced with a flat C++ file. The attached directory
structure must be preserved. To reproduce untar the source.tgz and invoke the
command line as in above.

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

From bugzilla-daemon at llvm.org  Thu Jun 23 13:18:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 13:18:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10179] New: call to wctob generates infinite loop
Message-ID: <bug-10179-206@http.llvm.org/bugs/>

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

           Summary: call to wctob generates infinite loop
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ahatanak at gmail.com
                CC: llvmbugs at cs.uiuc.edu


An infinite loop is created when the code shown below is compiled with clang. 

$ clang infloop2.c  -O3 -S -o infloop2.O3.ll -emit-llvm
$ clang infloop2.c  -O1 -S -o infloop2.O1.ll -emit-llvm

// infloop2.c
#include <wchar.h>

int f (int i)
{
  return  wctob (i);
}

// infloop2.O3.ll
; ModuleID = 'infloop2.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

define i32 @f(i32 %i) nounwind uwtable readnone {
entry:
  br label %tailrecurse.i

tailrecurse.i:                                    ; preds = %tailrecurse.i,
%entry
  br label %tailrecurse.i
}

// infloop2.O1.ll
; ModuleID = 'infloop2.c'
target datalayout =
"e-p:64:64:64-i1:8:8-i8:8:8-i16:16:16-i32:32:32-i64:64:64-f32:32:32-f64:64:64-v64:64:64-v128:128:128-a0:0:64-s0:64:64-f80:128:128-n8:16:32:64"
target triple = "x86_64-unknown-linux-gnu"

define i32 @f(i32 %i) nounwind uwtable readnone {
entry:
  %call = tail call i32 @wctob(i32 %i) nounwind
  ret i32 %call
}

define available_externally i32 @wctob(i32 %__wc) nounwind uwtable readnone
inlinehint {
entry:
  br label %tailrecurse

tailrecurse:                                      ; preds = %tailrecurse,
%entry
  br label %tailrecurse
}

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 23 13:52:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 13:52:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10180] New: InstCombineSelect incorrectly handles
	vector floats
Message-ID: <bug-10180-206@http.llvm.org/bugs/>

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

           Summary: InstCombineSelect incorrectly handles vector floats
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: micah.villmow at amd.com
                CC: llvmbugs at cs.uiuc.edu


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

Value *NegVal;  // Compute -Z
if (SI.getType()->isFloatingPointTy()) {
    NegVal = Builder->CreateFNeg(SubOp->getOperand(1));
} else {
    NegVal = Builder->CreateNeg(SubOp->getOperand(1));
}

If SI.getType() returns a VectorType and the vector type is a float, the
initial condition fails, creating integer subtract with floating point
arguments in release 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  Thu Jun 23 13:53:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 13:53:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10179] call to wctob generates infinite loop
In-Reply-To: <bug-10179-206@http.llvm.org/bugs/>
References: <bug-10179-206@http.llvm.org/bugs/>
Message-ID: <20110623185338.9A6EC2A6C124@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #1 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-23 13:53:38 CDT ---


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

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

From bugzilla-daemon at llvm.org  Thu Jun 23 15:43:10 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 15:43:10 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10180] InstCombineSelect incorrectly handles vector
	floats
In-Reply-To: <bug-10180-206@http.llvm.org/bugs/>
References: <bug-10180-206@http.llvm.org/bugs/>
Message-ID: <20110623204310.C7B1C2A6C12C@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-23 15:43:10 CDT ---
r133756.

It doesn't really matter whether you attach text or binary; the issue was that
I couldn't actually reproduce the bug with the IR you 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 Jun 23 16:02:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 16:02:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10181] New: jit miscompiles, llc doesn't
Message-ID: <bug-10181-206@http.llvm.org/bugs/>

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

           Summary: jit miscompiles, llc doesn't
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows XP
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: AAkN7YjW at mailinator.com
                CC: llvmbugs at cs.uiuc.edu


This works:
 llvm-as < testing.ll | opt -std-compile-opts -disable-simplify-libcalls | llc
> testing.s; gcc testing.s; ./a.exe

This also works:
 llvm-as < testing.ll | opt -std-compile-opts -disable-simplify-libcalls | lli
-force-interpreter=true

This doesn't work (I get a stack dump and no "hello world" output):
 llvm-as < testing.ll | opt -std-compile-opts -disable-simplify-libcalls | lli


---- Program code below ----


@A = internal constant [13 x i8] c"hello world\0A\00"

declare i32 @printf(i8* noalias nocapture,...)

define i32 @main() {

  br label %a

a:
  br label %g

b:
  br label %c

c:
  br label %g

d:
  br label %e

e:
  br label %g

f:
  ret i32 0

g:
  %z = phi i8*
[blockaddress(@main,%b),%a],[blockaddress(@main,%d),%c],[blockaddress(@main,%f),%e]
  %x = getelementptr [13 x i8]* @A, i64 0, i64 0
  call i32 (i8* noalias nocapture,...)* @printf(i8* %x)
  indirectbr i8* %z, [label %b,label %d,label %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  Thu Jun 23 16:10:58 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 16:10:58 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10182] New: bugpoint -safe-int is not acceptable
Message-ID: <bug-10182-206@http.llvm.org/bugs/>

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

           Summary: bugpoint -safe-int is not acceptable
           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: AAkN7YjW at mailinator.com
                CC: llvmbugs at cs.uiuc.edu


bugpoint -safe-int is not acceptable why?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 23 16:40:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 16:40:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10183] New: Large bottleneck observed for certain
 PostgreSQL TUs
Message-ID: <bug-10183-206@http.llvm.org/bugs/>

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

           Summary: Large bottleneck observed for certain PostgreSQL TUs
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: peter.geoghegan86 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


When building PostgreSQL using my own build of today's clang trunk, I observed
performance that is dramatically inferior for some TUs, to the extent that I am
confident that something is wrong.

Observe the differences in compile times of the file
/src/backend/parser/gram.c . The warning message that you see is a
known bug with Gnu Bison that they refuse to fix:

[peter at peter postgresql]$ time /home/peter/build/Release/bin/clang -O2
-Wall -Wmissing-prototypes -Wpointer-arith
-Wdeclaration-after-statement -Wendif-labels -Wformat-security
-fno-strict-aliasing -fwrapv -Wno-error -I. -I. -I
/home/peter/postgresql/src/include -D_GNU_SOURCE   -c -o gram.o
/home/peter/postgresql/src/backend/parser/gram.c
In file included from gram.y:12939:
scan.c:16246:23: warning: unused variable 'yyg' [-Wunused-variable]
   struct yyguts_t * yyg = (struct yyguts_t*)yyscanner; /* This var may be ...
                     ^
1 warning generated.

real    1m5.660s
user    1m5.344s
sys     0m0.083s
[peter at peter postgresql]$ time gcc -O2 -Wall -Wmissing-prototypes
-Wpointer-arith -Wdeclaration-after-statement -Wendif-labels
-Wformat-security -fno-strict-aliasing -fwrapv -Wno-error -I. -I. -I
/home/peter/postgresql/src/include -D_GNU_SOURCE   -c -o gram.o
/home/peter/postgresql/src/backend/parser/gram.c
In file included from gram.y:12939:0:
scan.c: In function ?yy_try_NUL_trans?:
scan.c:16246:23: warning: unused variable ?yyg? [-Wunused-variable]

real    0m2.800s
user    0m2.688s
sys     0m0.094s

That's a difference way out of proportion to the total
difference in compile times, which are:

2 minutes 1 second for gcc 4.6. 
3 minutes 23 seconds for Clang, built today from SVN tip.

Clearly, this source file and perhaps one or two others like it are massive
bottlenecks.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 23 17:30:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 17:30:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10184] New: type traits workaround for libstdc++
 4.2 breaks boost
Message-ID: <bug-10184-206@http.llvm.org/bugs/>

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

           Summary: type traits workaround for libstdc++ 4.2 breaks boost
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: richard-llvm at metafoo.co.uk
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


We revert the following keywords to normal identifiers when libstdc++ 4.2's
type traits header is included:

__is_arithmetic
__is_convertible
__is_empty
__is_floating_point
__is_function
__is_fundamental
__is_integral
__is_member_function_pointer
__is_member_pointer
__is_pod
__is_pointer
__is_same
__is_scalar
__is_signed
__is_unsigned
__is_void

Consequently, these type traits are unavailable to code which wants to use both
libstdc++ 4.2 and these traits (such as boost). Perhaps we should add another
set of builtins of the form __builtin_is_foo which don't evaporate in the
presence of 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  Thu Jun 23 17:55:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 17:55:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9202] False unused function warning for extern "C"
 function in unnamed namespace
In-Reply-To: <bug-9202-206@http.llvm.org/bugs/>
References: <bug-9202-206@http.llvm.org/bugs/>
Message-ID: <20110623225538.825402A6C124@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #3 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-06-23 17:55:38 CDT ---
Works fine in r133769.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 23 20:44:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 20:44:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10185] New: Allow metadata for -profile-estimator
Message-ID: <bug-10185-206@http.llvm.org/bugs/>

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

           Summary: Allow metadata for -profile-estimator
           Product: new-bugs
           Version: unspecified
          Platform: All
        OS/Version: All
            Status: NEW
          Keywords: new-feature
          Severity: enhancement
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: AAkN7YjW at mailinator.com
                CC: llvmbugs at cs.uiuc.edu


I propose a new feature allowing you to attach metadata to instructions that
affects the profile estimation.

!loopweight to set the loop weight parameter for individual loops.

!adjustexecutioncount to adjust the execution count manually.

!adjustedgeweight to adjust edge weights.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 23 23:19:34 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 23 Jun 2011 23:19:34 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10185] Allow metadata for -profile-estimator
In-Reply-To: <bug-10185-206@http.llvm.org/bugs/>
References: <bug-10185-206@http.llvm.org/bugs/>
Message-ID: <20110624041934.C9F7F2A6C12C@llvm.org>

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

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

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

--- Comment #1 from Bob Wilson <bob.wilson at apple.com> 2011-06-23 23:19:34 CDT ---
We don't generally use bug reports to track proposals for new features.  Please
make suggestions like this on the llvm-dev mailing list.

With regard to this particular proposal, we've already had some related
discussions and are currently in the process of implementing an alternative
form of metadata that will provide essentially the same information.  In my
opinion, it wouldn't make sense to pursue this as well, but perhaps others on
the mailing list will have different opinions.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 24 14:04:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 24 Jun 2011 14:04:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10186] New: Infinite loop in llc on ARMv7 (LLVM
 HEAD from June 17)
Message-ID: <bug-10186-206@http.llvm.org/bugs/>

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

           Summary: Infinite loop in llc on ARMv7 (LLVM HEAD from June 17)
           Product: tools
           Version: trunk
          Platform: Other
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: llc
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: karel.gardas at centrum.cz
                CC: llvmbugs at cs.uiuc.edu


Hello,

it looks like I do have infinite loop in llc on linux/armv7 platform somewhere
in llvm::SmallVectorImpl. Two backtraces obtained with 10 seconds delay are:

0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd
(this=0x7ee90b38, P=0x5c06988)
    at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103
103      void setEnd(T *P) { this->EndX = P; }
(gdb) where
#0  0x0099be14 in llvm::SmallVectorTemplateCommon<llvm::SDNode*>::setEnd
(this=0x7ee90b38,
    P=0x5c06988) at
/export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:103
#1  0x00a4849c in llvm::SmallVectorImpl<llvm::SDNode*>::pop_back
(this=0x7ee90b38)
    at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:334
#2  0x00a483b8 in llvm::SmallVectorImpl<llvm::SDNode*>::pop_back_val
(this=0x7ee90b38)
    at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:340
#3  0x00a6f074 in llvm::SDNode::isPredecessorOf (this=0x641bb08, N=0x6212a40)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5703
#4  0x00a057c8 in CombineToPreIndexedLoadStore (this=0x7ee90f84, N=0x6238040)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:5707
#5  0x00a07544 in visitLOAD (this=0x7ee90f84, N=0x6238040)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6011
#6  0x009e307c in visit (this=0x7ee90f84, N=0x6238040)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1099
#7  0x009e3148 in combine (this=0x7ee90f84, N=0x6238040)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1112
#8  0x009e24cc in Run (this=0x7ee90f84, AtLevel=llvm::NoIllegalOperations)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:978
#9  0x00a111ac in llvm::SelectionDAG::Combine (this=0x1bea328,
Level=llvm::NoIllegalOperations,
    AA=..., OptLevel=llvm::CodeGenOpt::Less)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:7732
#10 0x00acd9c0 in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x1be9f40)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:559
#11 0x00acc9a0 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x1be9f40,
Begin=..., End=...,
    HadTailCall=@0x7ee91158)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:414
#12 0x00acf420 in llvm::SelectionDAGISel::SelectAllBasicBlocks (this=0x1be9f40,
Fn=...)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:972
#13 0x00acbee4 in llvm::SelectionDAGISel::runOnMachineFunction (this=0x1be9f40,
mf=...)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:282
#14 0x00c40d7c in llvm::MachineFunctionPass::runOnFunction (this=0x1be9f40,
F=...)
    at /export/home/karel/vcs/llvm-head/lib/CodeGen/MachineFunctionPass.cpp:33
#15 0x010b6a48 in llvm::FPPassManager::runOnFunction (this=0x1be53d8, F=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1513
#16 0x010b6c80 in llvm::FPPassManager::runOnModule (this=0x1be53d8, M=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1535
#17 0x010b7030 in llvm::MPPassManager::runOnModule (this=0x16d07e8, M=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1589
#18 0x010b75f8 in llvm::PassManagerImpl::run (this=0x16d0638, M=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1671
#19 0x010b7c64 in llvm::PassManager::run (this=0x7ee91470, M=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1715
#20 0x005517a4 in main (argc=6, argv=0x7ee91644)
    at /export/home/karel/vcs/llvm-head/tools/llc/llc.cpp:338


and

llvm::SmallVectorImpl<llvm::SDNode*>::pop_back (this=0x7ee90b38)
    at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:334
334        this->setEnd(this->end()-1);
(gdb) where
#0  llvm::SmallVectorImpl<llvm::SDNode*>::pop_back (this=0x7ee90b38)
    at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:334
#1  0x00a483b8 in llvm::SmallVectorImpl<llvm::SDNode*>::pop_back_val
(this=0x7ee90b38)
    at /export/home/karel/vcs/llvm-head/include/llvm/ADT/SmallVector.h:340
#2  0x00a6f074 in llvm::SDNode::isPredecessorOf (this=0x643a8a8, N=0x6348d68)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAG.cpp:5703
#3  0x00a057c8 in CombineToPreIndexedLoadStore (this=0x7ee90f84, N=0x6237d98)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:5707
#4  0x00a07544 in visitLOAD (this=0x7ee90f84, N=0x6237d98)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:6011
#5  0x009e307c in visit (this=0x7ee90f84, N=0x6237d98)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1099
#6  0x009e3148 in combine (this=0x7ee90f84, N=0x6237d98)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:1112
#7  0x009e24cc in Run (this=0x7ee90f84, AtLevel=llvm::NoIllegalOperations)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:978
#8  0x00a111ac in llvm::SelectionDAG::Combine (this=0x1bea328,
Level=llvm::NoIllegalOperations,
    AA=..., OptLevel=llvm::CodeGenOpt::Less)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/DAGCombiner.cpp:7732
#9  0x00acd9c0 in llvm::SelectionDAGISel::CodeGenAndEmitDAG (this=0x1be9f40)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:559
#10 0x00acc9a0 in llvm::SelectionDAGISel::SelectBasicBlock (this=0x1be9f40,
Begin=..., End=...,
    HadTailCall=@0x7ee91158)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:414
#11 0x00acf420 in llvm::SelectionDAGISel::SelectAllBasicBlocks (this=0x1be9f40,
Fn=...)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:972
#12 0x00acbee4 in llvm::SelectionDAGISel::runOnMachineFunction (this=0x1be9f40,
mf=...)
    at
/export/home/karel/vcs/llvm-head/lib/CodeGen/SelectionDAG/SelectionDAGISel.cpp:282
#13 0x00c40d7c in llvm::MachineFunctionPass::runOnFunction (this=0x1be9f40,
F=...)
    at /export/home/karel/vcs/llvm-head/lib/CodeGen/MachineFunctionPass.cpp:33
#14 0x010b6a48 in llvm::FPPassManager::runOnFunction (this=0x1be53d8, F=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1513
#15 0x010b6c80 in llvm::FPPassManager::runOnModule (this=0x1be53d8, M=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1535
#16 0x010b7030 in llvm::MPPassManager::runOnModule (this=0x16d07e8, M=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1589
#17 0x010b75f8 in llvm::PassManagerImpl::run (this=0x16d0638, M=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1671
#18 0x010b7c64 in llvm::PassManager::run (this=0x7ee91470, M=...)
    at /export/home/karel/vcs/llvm-head/lib/VMCore/PassManager.cpp:1715
#19 0x005517a4 in main (argc=6, argv=0x7ee91644)
    at /export/home/karel/vcs/llvm-head/tools/llc/llc.cpp:338


LLC is invoked with flags:

llc -O1 -relocation-model=static ghc1436_0.bc -o ghc1436_0.lm_s

The LLC is from LLVM head as of June 17, the HEAD is:

commit ed6fa188c4cf2d382991dd054f7c5157420908c3
Author: Galina Kistanova <gkistanova at gmail.com>
Date:   Fri Jun 17 18:26:23 2011 +0000

    est 2008-06-04-indirectmem.ll is X86-specific. Move to X86 folder.

    git-svn-id: https://llvm.org/svn/llvm-project/llvm/trunk at 133275
91177308-0d34-0410-b5e6-96231b3b80


Whole LLVM was build as debug build with assertions enabled, original .ll file
was produced by GHC HEAD LLVM backend while compiling Haskell file from GHC
source tree. The ghc1436_0.bc is attached. If you like original ghc1436_0.ll
just ask, I also do have it for you, but it's long: 26MB uncompressed.
Also LLVM was build with gcc:
$ gcc --version
gcc (Ubuntu 4.4.1-4ubuntu9) 4.4.1

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 Jun 24 15:00:18 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 24 Jun 2011 15:00:18 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10109] Segfault compiling template with invalid
	nested type
In-Reply-To: <bug-10109-206@http.llvm.org/bugs/>
References: <bug-10109-206@http.llvm.org/bugs/>
Message-ID: <20110624200018.11DC82A6C124@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #2 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-06-24 15:00:17 CDT ---
Fixed in r133816.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 24 15:17:26 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 24 Jun 2011 15:17:26 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10187] New: Assertion when using '__range' in a
 ranged for loop in a template
Message-ID: <bug-10187-206@http.llvm.org/bugs/>

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

           Summary: Assertion when using '__range' in a ranged for loop in
                    a template
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: akyrtzi at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


On r133816, the following test case asserts.

template<typename T>
struct S {
  void f() {
    for (auto &a : e)
      __range(a);
  }
  T e[10];
};

void g() { S<int>().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  Fri Jun 24 15:18:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 24 Jun 2011 15:18:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9968] False positive "unused variable '__range'"
 with ranged for loop in template
In-Reply-To: <bug-9968-206@http.llvm.org/bugs/>
References: <bug-9968-206@http.llvm.org/bugs/>
Message-ID: <20110624201859.217872A6C12C@llvm.org>

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

Argyrios Kyrtzidis <akyrtzi at gmail.com> changed:

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

--- Comment #5 from Argyrios Kyrtzidis <akyrtzi at gmail.com> 2011-06-24 15:18:58 CDT ---
(In reply to comment #4)
> The first part is fixed in r133572.

Thanks Richard! Submitted http://llvm.org/PR10187 for the second issue.

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

From bugzilla-daemon at llvm.org  Fri Jun 24 17:33:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 24 Jun 2011 17:33:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10182] bugpoint -safe-int is not acceptable
In-Reply-To: <bug-10182-206@http.llvm.org/bugs/>
References: <bug-10182-206@http.llvm.org/bugs/>
Message-ID: <20110624223312.31DAA2A6C12D@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #2 from Chris Lattner <clattner at apple.com> 2011-06-24 17:33:11 CDT ---
In fact, the interpreter is widely known to be broken.

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

From bugzilla-daemon at llvm.org  Fri Jun 24 18:26:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Fri, 24 Jun 2011 18:26:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10188] New: FPPassManager::runOnModule may return
 incorrect values
Message-ID: <bug-10188-206@http.llvm.org/bugs/>

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

           Summary: FPPassManager::runOnModule may return incorrect values
           Product: libraries
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Core LLVM classes
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: wujingyue at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Hi, 

In lib/VMCore/PassManager, around Line 1530: 

1531 bool FPPassManager::runOnModule(Module &M) {
1532   bool Changed = doInitialization(M);
1533 
1534   for (Module::iterator I = M.begin(), E = M.end(); I != E; ++I)
1535     runOnFunction(*I);
1536 
1537   return doFinalization(M) || Changed;
1538 }

I think
"runOnFunction(*I)"
should be changed to
"Changed |= runOnFunction(*I)"
because FPPassManager::runOnModule is supposed to return true if any function
gets changed. 

Let me know if I'm understanding it correctly. Thanks much. 

Best,
Jingyue

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 25 00:21:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 00:21:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10189] New: Assertion `!Duplicates.count(Factor) &&
 "Shouldn't have two constant factors, missed a canonicalize"' failed.
Message-ID: <bug-10189-206@http.llvm.org/bugs/>

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

           Summary: Assertion `!Duplicates.count(Factor) && "Shouldn't
                    have two constant factors, missed a canonicalize"'
                    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: regehr at cs.utah.edu
                CC: llvmbugs at cs.uiuc.edu, chenyang at cs.utah.edu


regehr at home:~/volatile/bugs/tmp038$ clang -v
clang version 3.0 (trunk 133864)
Target: i386-pc-linux-gnu
Thread model: posix
regehr at home:~/volatile/bugs/tmp038$ clang -c -w -O2 small.c
clang: Reassociate.cpp:818:
llvm::Value*<unnamed>::Reassociate::OptimizeAdd(llvm::Instruction*,
llvm::SmallVectorImpl<<unnamed>::ValueEntry>&): Assertion
`!Duplicates.count(Factor) && "Shouldn't have two constant factors, missed a
canonicalize"' failed.
0  clang 0x0980aa58
Stack dump:
0.    Program arguments:
/mnt/z/z/compiler-install/llvm-gcc-r133864-install/bin/clang -cc1 -triple
i386-pc-linux-gnu -emit-obj -disable-free -main-file-name small.c
-mrelocation-model static -mdisable-fp-elim -masm-verbose -mconstructor-aliases
-target-cpu pentium4 -target-linker-version 2.20.51 -momit-leaf-frame-pointer
-coverage-file small.o -resource-dir
/mnt/z/z/compiler-install/llvm-gcc-r133864-install/bin/../lib/clang/3.0 -O2 -w
-ferror-limit 19 -fmessage-length 78 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o small.o -x c small.c 
1.    <eof> parser at end of file
2.    Per-module optimization passes
3.    Running pass 'CallGraph Pass Manager' on module 'small.c'.
4.    Running pass 'Reassociate expressions' on function '@mn'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
regehr at home:~/volatile/bugs/tmp038$ cat small.c
unsigned short
safe_53 (int short ui1, int short ui2)
{
  return ui1 - ui2;
}

int short
safe_60 (int short left, int right)
{
  return right ? 0 : left >> right;
}

struct S0
{
  int f;
};

struct S1
{
  int f3;
};

struct S2
{
  volatile struct S0 f2;
};

struct S3
{
  int f;
};

int short g_8;
int g_20[][1][0];
int g_37;

struct S2 g_6;

struct S3 g_169;

struct S1 g_177;
struct S2 g_1639[];

char func_13 (unsigned, unsigned short, short);

char func_21 (unsigned char, unsigned, int *);

struct S2 func_1 (vo)
{
  int l_2 = 1;
  l_2 && func_13 (0, 0, 0), 0;
  return g_1639[0];
}

char func_13 (unsigned p_, unsigned short p_15, short p_1)
{
  int l_346;
  int *l_701 = &g_37;
  for (l_346 = 2; l_346 >= 0; l_346 -= 1)
    {
      for (; g_177.f3; g_177.f3 += 1);
      for (p_15 = 0; p_15 <= 2; p_15 += 1)
    *l_701 = safe_60 (g_6.f2.f, func_21 (g_169.f, 0, 0)) > 0;
    }
  return 0;
}

char
func_21 (unsigned char p_, unsigned p_2, int *p_24)
{
  int *l_30 = &g_20[0][0][1];
  int **l_29 = &l_30;
  **l_29 = safe_53 (*l_30, g_8);
  return **l_29;
}

int mn (void)
{
  func_1 ();
  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  Sat Jun 25 00:33:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 00:33:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9898] debug assertion (and possibly more errors) in
 ~ScopedNullTerminator()
In-Reply-To: <bug-9898-206@http.llvm.org/bugs/>
References: <bug-9898-206@http.llvm.org/bugs/>
Message-ID: <20110625053303.C265E2A6C12C@llvm.org>

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

NAKAMURA Takumi <geek4civic at gmail.com> changed:

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

--- Comment #3 from NAKAMURA Takumi <geek4civic at gmail.com> 2011-06-25 00:33:03 CDT ---
It was dupe of bug 8460.

I thought, I have to apply the fix.

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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 25 02:26:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 02:26:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10190] New: The behaviour of Module::setDataLayout
 is not as expected.
Message-ID: <bug-10190-206@http.llvm.org/bugs/>

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

           Summary: The behaviour of Module::setDataLayout is not as
                    expected.
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: wuye9036 at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6768)
 --> (http://llvm.org/bugs/attachment.cgi?id=6768)
generated code. "Mvs_main@@QSVSIn@@" is the main function

Hi, guys,

Thans for your attention.

I found that the Module::setDataLayout did not works well.

If I set layout ( such as struct alignment ), it could not affect the data
layout of target machine.

An easiler sample as following:

void foo( struct{ <4 x float>, <4 x float> }* ptr ){
.entry:
  second_member = load ptr[1] ; You know what i mean.
  second_copy = alloca struct{ <4 x float>, <4 x float> ; no alignment
  ; // blah blah blah
  add( another_vec4, second_copy ); // You know what i mean;
  ; // blah blah blah
}

And the mentioned code will generate asm (SSE on x86) as following:

; //blah blah blah
movups xmmword ptr[second_copy], xmm0 ; // unaligned memory access, it's right.
; //blah blah blah
addps xmm1, xmmword ptr[second_copy] ; // Here we need second_copy are 16 bytes
aligned.

But even if I set data layout as "s0:128:128", these code would crash since
unaligned access. if I create the alloca instruction with align 16, all is ok.

And I traced code and found that the data layout doesn't affect the TargetData
of JIT.

Could you help me, thanks.

And, another question I will ask is the difference between ABI alignment and
Preferred 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  Sat Jun 25 03:33:33 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 03:33:33 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10191] New: compiling libcxx with clang
Message-ID: <bug-10191-206@http.llvm.org/bugs/>

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

           Summary: compiling libcxx with clang
           Product: libc++
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: hiraditya at msn.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6770)
 --> (http://llvm.org/bugs/attachment.cgi?id=6770)
modified $LIBCXX_DIR/lib/buildit.sh

My OS is Ubuntu-11.04
i compiled llvm with clang as per the user manual successfully.
then i tried to compile libcxx with clang++,
i made modifications to the $LIBCXX_DIR/lib/buildit by reading the following

lists.cs.uiuc.edu/pipermail/cfe-dev/2011-February/013228.html
The buildit.sh is attached along with this report.

with the modified buildit.sh i get following errors. It seems clang++ is unable
to compile 'string' successfully.
Here is the complete compilation report:

vmplanet at kubuntu-vm:~/usr/libcxx/lib$ ./buildit 
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include
../src/algorithm.cpp
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include ../src/bind.cpp
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include ../src/chrono.cpp
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include
../src/condition_variable.cpp
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include
../src/exception.cpp
../src/exception.cpp:85:6: warning: #warning uncaught_exception not yet
implemented [-W#warnings]
    #warning uncaught_exception not yet implemented
     ^
../src/exception.cpp:119:6: warning: #warning exception_ptr not yet implemented
[-W#warnings]                                                                   
    #warning exception_ptr not yet implemented
     ^
../src/exception.cpp:130:6: warning: #warning exception_ptr not yet implemented
[-W#warnings]                                                                   
    #warning exception_ptr not yet implemented
     ^
../src/exception.cpp:146:6: warning: #warning exception_ptr not yet implemented
[-W#warnings]                                                                   
    #warning exception_ptr not yet implemented
     ^
../src/exception.cpp:181:6: warning: #warning exception_ptr not yet implemented
[-W#warnings]                                                                   
    #warning exception_ptr not yet implemented
     ^
../src/exception.cpp:193:6: warning: #warning exception_ptr not yet implemented
[-W#warnings]                                                                   
    #warning exception_ptr not yet implemented
     ^
6 warnings generated.                                                           
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include ../src/future.cpp
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include ../src/hash.cpp
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include ../src/ios.cpp
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include ../src/iostream.cpp
clang++ -c -g -Os -fPIC -std=c++0x -nostdinc++ -I../include ../src/locale.cpp
In file included from ../src/locale.cpp:10:
../include/string:2122:10: error: overload resolution selected deleted operator
'='
    __r_ = _STD::move(__str.__r_);
    ~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~
../include/string:2133:5: note: in instantiation of member function
'std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::__move_assign'      
      requested here
    __move_assign(__str, integral_constant<bool,
    ^
../src/locale.cpp:4772:10: note: in instantiation of member function
'std::__1::basic_string<char, std::__1::char_traits<char>,
std::__1::allocator<char> >::operator='         
      requested here
    __c_ = __analyze('c', ct);
         ^
../include/memory:2050:7: note: candidate function (the implicit copy
assignment operator) has been explicitly deleted                                
class __compressed_pair
      ^
In file included from ../src/locale.cpp:10:                                     
../include/string:2122:10: error: overload resolution selected deleted operator
'='
    __r_ = _STD::move(__str.__r_);
    ~~~~ ^ ~~~~~~~~~~~~~~~~~~~~~~
../include/string:2133:5: note: in instantiation of member function
'std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>,
std::__1::allocator<wchar_t>               
      >::__move_assign' requested here
    __move_assign(__str, integral_constant<bool,
    ^
../include/locale:2796:15: note: in instantiation of member function
'std::__1::basic_string<wchar_t, std::__1::char_traits<wchar_t>,
std::__1::allocator<wchar_t> >::operator='
      requested here
        __nsn = __mp.negative_sign();
              ^
../include/memory:2050:7: note: candidate function (the implicit copy
assignment operator) has been explicitly deleted                                
class __compressed_pair
      ^
2 errors generated.

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

From bugzilla-daemon at llvm.org  Sat Jun 25 07:34:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 07:34:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10192] New: Defining 0 for clz does not optimize
Message-ID: <bug-10192-206@http.llvm.org/bugs/>

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

           Summary: Defining 0 for clz does not optimize
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: Windows NT
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: Backend: ARM
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: xocotl at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Howdy... GCC leaves __builtin_clz undefined for zero, so writing code in Clang
like

return 31 - (value == 0 ? 32 : __builtin_clz(value));

You would think the 'value == 0 ? 32 : ' would get optimized out, since CLZ on
ARM is defined as 32 for value 0. However that does not appear to be the case.
On Thumb 2 I get the following output for the above snippet:

00000000 <uint32_log2_floor>:
   0:    2120          movs    r1, #32
   2:    2800          cmp    r0, #0
   4:    bf18          it    ne
   6:    fab0 f180     clzne    r1, r0
   a:    f1c1 001f     rsb    r0, r1, #31    ; 0x1f
   e:    4770          bx    lr

It would be nice if LLVM could recognize this situation, where the branch is
identical to the defined behavior for the CPU instruction.

Thanks

James

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

From bugzilla-daemon at llvm.org  Sat Jun 25 11:16:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 11:16:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10193] New: std::stringbuf performance vs libstdc++
Message-ID: <bug-10193-206@http.llvm.org/bugs/>

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

           Summary: std::stringbuf performance vs libstdc++
           Product: libc++
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: puurtuur at me.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6771)
 --> (http://llvm.org/bugs/attachment.cgi?id=6771)
Time profile of 10M iters of libstdc++ and libc++ with 6 char str.

I've been running some tests on libc++ with various classes and I saw that
libc++ was quite a bit slower (relatively at least) than libstdc++ with
std::stringbuf. Full source of sample app follows:

#include <string>
#include <iostream>
#include <sstream>
#include <time.h>

static const int NUM_ITERATIONS = 10000000;

void bench_buf() {
    std::stringbuf sb;

    for(int i = 0; i < NUM_ITERATIONS; ++i)
        sb.sputn("foobar", 6);

    // force string to be generated and sanity check length output
    std::string s = sb.str();
    std::cout << s.length() << std::endl;
}

int main(int argc, char *argv[]) {
    clock_t clk = clock();
    bench_buf();
    std::cout << ((clock() - clk) / static_cast<double>(CLOCKS_PER_SEC)) <<
std::endl;

    return 0;
}

--

If I compile this with libc++, the runtime is around 0.30s, with libstdc++ it's
around 0.20s (iMac Core i7 2.93GHz). Given how libc++ is mostly faster I though
it was worth mentioning. I attached two runs made in Profiler that show
libstdc++ (run 1) is more busy moving around memory where libc++ (run 2) spends
 a lot of time in xsputn itself.

Increasing the string length to 46 chars changes times to:
libstdc++: 0.83s
libc++: 2.04s
So the gap widens as more data is involved.

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

From bugzilla-daemon at llvm.org  Sat Jun 25 11:37:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 11:37:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10194] New: Bug in opt -std-compile-opts: invalid
 conversion of ugt to sgt
Message-ID: <bug-10194-206@http.llvm.org/bugs/>

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

           Summary: Bug in opt -std-compile-opts: invalid conversion of
                    ugt to sgt
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: bprosnitz at gmail.com
                CC: llvmbugs at cs.uiuc.edu


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

If opt (with -std-compile-opts) is run on the following program which exits
with a code 1

define zeroext i32 @test(i8* noalias %in, i64 %inlen) nounwind noinline {
entry:
  %0 = getelementptr inbounds i8* %in, i64 %inlen ; <i8*> [#uses=1]
  %1 = icmp ult i8* %in, %0                       ; <i1> [#uses=1]
  br i1 %1, label %return, label %retfalse

retfalse:                                         ; preds = %entry
  ret i32 0

return:                                           ; preds = %entry
  ret i32 1
}

define i32 @main() nounwind {
entry:
  %0 = alloca i8, i32 8                           ; <i8*> [#uses=9]
  %1 = call i32 @test(i8* %0, i64 -9223372036854775808) ; <i8> [#uses=1]
  ret i32 %1
}

it generates a different program, that exits with a code 0:

define zeroext i32 @test(i8* noalias %in, i64 %inlen) nounwind noinline {
entry:
  %0 = icmp sgt i64 %inlen, 0
  br i1 %0, label %return, label %retfalse

retfalse:                                         ; preds = %entry
  ret i32 0

return:                                           ; preds = %entry
  ret i32 1
}

define i32 @main() nounwind {
entry:
  %0 = alloca [8 x i8], align 1
  %.sub = getelementptr inbounds [8 x i8]* %0, i64 0, i64 0
  %1 = call i32 @test(i8* %.sub, i64 -9223372036854775808)
  ret i32 %1
}

I reduced the operations in -std-compile-opts which cause this issue to a
minimal set of flags that still cause it:
opt  -instcombine -inline -scalarrepl -instcombine -indvars

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 25 11:44:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 11:44:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10190] The behaviour of Module::setDataLayout is
 not as expected.
In-Reply-To: <bug-10190-206@http.llvm.org/bugs/>
References: <bug-10190-206@http.llvm.org/bugs/>
Message-ID: <20110625164423.40FBB2A6C12C@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #4 from Chris Lattner <clattner at apple.com> 2011-06-25 11:44:22 CDT ---
This is a misunderstanding of what Datalayout is for.  This is part of the
contract with the code generator: the frontend is required to specify the exact
target data that the code generator expects, or specify no target data if you
don't care.  You cannot specify a different target data and expect to get
different behavior.

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

From bugzilla-daemon at llvm.org  Sat Jun 25 15:48:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 15:48:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10195] New: code with no apparent errors generates
 a lone "note: X declared here" warning
Message-ID: <bug-10195-206@http.llvm.org/bugs/>

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

           Summary: code with no apparent errors generates a lone "note: X
                    declared here" warning
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ori at avtalion.name
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Using r133872

Compiling this:

struct A {
    virtual ~A();
    virtual void Foo() = 0;
};

struct B  {
    ~B();
    A *_a;
};

B::~B() {
    _a->Foo();
}



Yields:

$ clang++ -fsyntax-only a.cpp
a.cpp:3:2: note: 'Foo' declared here
        virtual void Foo() = 0;


Why is this 'note' printed?

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 25 17:35:48 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sat, 25 Jun 2011 17:35:48 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10196] New: Clang C++98 too eagerly consumes "&&"
 logical-AND as a rvalue reference
Message-ID: <bug-10196-206@http.llvm.org/bugs/>

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

           Summary: Clang C++98 too eagerly consumes "&&" logical-AND as a
                    rvalue reference
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: schaub.johannes at googlemail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


This is valid C++03:

struct A {
  operator int();
} a;

void operator+(int(A::*)(), A);

void f() { &A::operator int&& +a; }

Clang complains

main1.cpp:7:28: warning: rvalue references are a C++0x extension
[-Wc++0x-extensions]
void f() { &A::operator int&& +a; }
                           ^
main1.cpp:7:16: error: no member named 'operator int &&' in 'A'
void f() { &A::operator int&& +a; }

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

From bugzilla-daemon at llvm.org  Sun Jun 26 14:40:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 26 Jun 2011 14:40:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10197] New: Instantiation of a class (from a
 template parameter) with "new" gives incorrect object initialization
Message-ID: <bug-10197-206@http.llvm.org/bugs/>

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

           Summary: Instantiation of a class (from a template parameter)
                    with "new" gives incorrect object initialization
           Product: clang
           Version: 2.8
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: adrianosf at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The code below produces strang result (and different than GCC). It seems clang
lost yourself when using the new operator with a template parameter.

The C++ standard says:
---------------------
? If the new-initializer is omitted:
? If T is a (possibly cv-qualified) non-POD class type (or array
thereof), the object is default-
initialized (8.5). If T is a const-qualified type, the underlying class
type shall have a user-declared
default constructor.

and

To default-initialize an object of type T means:
? if T is a non-POD class type (9), the default constructor for T is
called (and the initialization is ill-
formed if T has no accessible default constructor);
---------------------

But I see in the disassembled code that clang explicitely assigns a 0 to the
member variable.

GCC result: 102, 103
clang result: 0, 103


//----------------------------------------
#include <stdio.h>


class C1
{
public:
    C1()
    {
    }

    void* operator new(size_t size, int n)
    {
        C1* p = (C1*) ::new char[size];
        p->n = n;
        return p;
    }

    int n;
};

template <typename T>
class Factory
{
public:
    T* newItem(int n)
    {
        return new(n) T;
    }
};


class C2 : public C1
{
public:
};

Factory<C2> factory;


int main()
{
    C2* a = factory.newItem(102);
    C2* b = new(103) C2;

    printf("--> %d, %d\n", a->n, b->n);

    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  Sun Jun 26 14:43:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 26 Jun 2011 14:43:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10161] dragonegg svn on FSF gcc 4.6.1 fails to
 compile himenoBMTxpa.c
In-Reply-To: <bug-10161-206@http.llvm.org/bugs/>
References: <bug-10161-206@http.llvm.org/bugs/>
Message-ID: <20110626194304.716BF2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #2 from Duncan Sands <baldrick at free.fr> 2011-06-26 14:43:02 CDT ---
Fixed here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110620/123017.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 Jun 26 17:06:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 26 Jun 2011 17:06:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10198] New: clang ignores -fno-operator-names when
 invoked with -c
Message-ID: <bug-10198-206@http.llvm.org/bugs/>

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

           Summary: clang ignores -fno-operator-names when invoked with -c
           Product: clang
           Version: trunk
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Driver
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: bpfoley at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6781)
 --> (http://llvm.org/bugs/attachment.cgi?id=6781)
Trivial reproducer; compile with clang -c -fno-operator-names

If a C++ program uses names such as 'and', 'xor', etc that collide with C++
reserved operator names, it won't compile unless you use the
-fno-operator-names command line option.

clang implements this option, but unfortunately when you invoke clang with -c,
the -fno-operator-names parameter isn't passed through to the compiler, and
instead prints the following warning, and fails to compile correctly.

clang: warning: argument unused during compilation: '-fno-operator-names'


The attached diff fixes this on trunk. Hopefully this is the right way to do it
and it can be applied directly.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 26 17:26:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 26 Jun 2011 17:26:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10187] Assertion when two-phase lookup diagnostic
 finds a declaration of unexpected type
In-Reply-To: <bug-10187-206@http.llvm.org/bugs/>
References: <bug-10187-206@http.llvm.org/bugs/>
Message-ID: <20110626222646.985122A6C12D@llvm.org>

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

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

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
         Resolution|                            |FIXED
         AssignedTo|unassignedclangbugs at nondot. |richard-llvm at metafoo.co.uk
                   |org                         |

--- Comment #2 from Richard Smith <richard-llvm at metafoo.co.uk> 2011-06-26 17:26:46 CDT ---
Fixed in r133898.

The issue with __range being visible inside function template instantiations is
still present, but should not be detectable to user code at least.

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

From bugzilla-daemon at llvm.org  Sun Jun 26 18:30:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Sun, 26 Jun 2011 18:30:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10199] New: Static analyzer fails to track path
 invariants involving bitmasks.
Message-ID: <bug-10199-206@http.llvm.org/bugs/>

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

           Summary: Static analyzer fails to track path invariants
                    involving bitmasks.
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Static Analyzer
        AssignedTo: kremenek at apple.com
        ReportedBy: juli at clockworksquid.com
                CC: llvmbugs at cs.uiuc.edu


%%%
void f(unsigned);
void g(unsigned, unsigned);

void
f(unsigned flags)
{
    unsigned inbytes, outbytes;

    if ((flags & 1) != 0)
        inbytes = outbytes = 0;

    if ((flags & 1) != 0)
        g(inbytes, outbytes);
}
%%%

Yields:

%%%
x.cc:13:3: warning: Function call argument is an uninitialized value
                g(inbytes, outbytes);
%%%

Eliminating the bitmask (i.e. "if (flags != 0)") the analyzer detects that
inbytes and outbytes are always initialized.

Version:

%%%
clang version 3.0 (trunk 133679)
Target: x86_64-apple-darwin10.7.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  Mon Jun 27 03:32:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 03:32:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10195] code with an abstract virtual method
 generates a lone "note: X declared here" warning
In-Reply-To: <bug-10195-206@http.llvm.org/bugs/>
References: <bug-10195-206@http.llvm.org/bugs/>
Message-ID: <20110627083225.9E9172A6C124@llvm.org>

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

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> 2011-06-27 03:32:25 CDT ---
The note is printed because the check which suppresses a warning in this code
didn't correctly suppress the note.

It has silently snuck through all our testing due to the very peculiar behavior
of notes which mis-associate with some other diagnostic.

Fixed in r133907.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 07:58:36 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 07:58:36 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10200] New: dragonegg svn on FSF gcc 4.6.1 produces
 unresolved symbols
Message-ID: <bug-10200-206@http.llvm.org/bugs/>

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

           Summary: dragonegg svn on FSF gcc 4.6.1 produces unresolved
                    symbols
           Product: dragonegg
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6787)
 --> (http://llvm.org/bugs/attachment.cgi?id=6787)
preprocessed source file for dint-atom.cc generated with dragonegg svn and FSF
gcc 4.6.1

While dragonegg svn builds xplor-nih 2.27 without issues using FSF gcc
4.5.4svn, the same build with dragonegg svn using FSF gcc 4.6.1 results in
unresolved symbols in intVar.dylib. These symbols are all...

[MacPro:~/xplor-nih-2.27/intVar/bin.Darwin_11_x86_64] howarth% nm *atom.o |
grep __ZN3CDS11IOExceptionD0Ev                 U __ZN3CDS11IOExceptionD0Ev

and exist in all of the object files in the intVar build directory. The
preprocessed source for the smallest source file in intVar, dint-atom.cc, is
attached from both dragonegg svn with FSF gcc 4.5.4svn and 4.6.1.
The *ExceptionD* symbols don't exist in the object files created with dragonegg
svn under FSF gcc 4.5.4svn.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 10:28:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 10:28:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10194] Bug in opt -std-compile-opts: invalid
 conversion of ugt to sgt
In-Reply-To: <bug-10194-206@http.llvm.org/bugs/>
References: <bug-10194-206@http.llvm.org/bugs/>
Message-ID: <20110627152823.9740D2A6C12E@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #3 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-27 10:28:23 CDT ---
The given code has undefined behavior because it expects an inbounds GEP to
have wrapping behavior.

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

From bugzilla-daemon at llvm.org  Mon Jun 27 11:41:28 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 11:41:28 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10201] New: clang does not warn on va_arg(args,
	float)
Message-ID: <bug-10201-206@http.llvm.org/bugs/>

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

           Summary: clang does not warn on va_arg(args, float)
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Please consider the following program:

/* From stdarg.h: */
typedef __builtin_va_list va_list;
#define va_arg(ap, type)    __builtin_va_arg(ap, type)


static void foo(va_list args)
{
    /* Should be <double> */
    va_arg(args, float);
}


When this is compiled using Apple's GCC 4.2, GCC outputs this:

$ gcc -S clang.c
clang.c: In function ?void foo(__va_list_tag*)?:
clang.c:9: warning: ?float? is promoted to ?double? when passed through ?...?
clang.c:9: warning: (so you should pass ?double? not ?float? to ?va_arg?)
clang.c:9: note: if this code is reached, the program will abort


When compiled with clang r133415, on the other hand, no warning is printed,
even though the code still does not work:

$ clang -S clang.c


Background for this are ISO C99 6.5.2.2p6 and p7:

If the expression that denotes the called function has a type that does not
include a prototype, [...] arguments that have type float are promoted to
double. These are called the default argument promotions. 

[...] The ellipsis notation in a function prototype declarator causes argument
type conversion to stop after the last declared parameter. The default argument
promotions are performed on trailing 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  Mon Jun 27 11:56:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 11:56:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10197] Instantiation of a class (from a template
 parameter) with "new" gives incorrect object initialization
In-Reply-To: <bug-10197-206@http.llvm.org/bugs/>
References: <bug-10197-206@http.llvm.org/bugs/>
Message-ID: <20110627165653.C15E02A6C124@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #2 from Douglas Gregor <dgregor at apple.com> 2011-06-27 11:56:53 CDT ---
Thanks for the great diagnosis. Fixed in Clang r133913.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 12:44:21 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 12:44:21 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10202] New: Warn for missing braces if a bracesless
 if/for/while is followed by a line with increased indentation
Message-ID: <bug-10202-206@http.llvm.org/bugs/>

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

           Summary: Warn for missing braces if a bracesless if/for/while
                    is followed by a line with increased indentation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: akyrtzi at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Have the parser warn for cases like:

if (x)
    foo1(); // #1
    foo2(); // #2

#2 line has the same indentation as #1 but braces as missing.

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

From bugzilla-daemon at llvm.org  Mon Jun 27 13:05:23 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 13:05:23 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10203] New: [regression] tail duplication changes
 negatively impacted Clang runtime performance
Message-ID: <bug-10203-206@http.llvm.org/bugs/>

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

           Summary: [regression] tail duplication changes negatively
                    impacted Clang runtime performance
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Scalar Optimizations
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: daniel at zuster.org
                CC: llvmbugs at cs.uiuc.edu


I happened to notice that the code generation changes in:
  http://llvm.org/viewvc/llvm-project?view=rev&revision=133682
had a negative impact on the runtime performance of a self-hosted Clang
executable, by a fairly significant margin (1-2%).

I don't have more detailed information on the exact piece of code where the
regression is yet, but here is the data I have on the regression:

My test scenario uses flops-8.c from nightly test, although I suspect the exact
input isn't very important, it is just one where we noticed the regression:
 
http://llvm.org/viewvc/llvm-project/test-suite/trunk/SingleSource/Benchmarks/Misc/flops-8.c?revision=47963&content-type=text%2Fplain

My test script uses a simple timing tool 'runN' and runs the frontend on the
same input many times to decrease sampling error. You can replace 'runN 10'
with 'time':
--
ddunbar at smoosh-17:9670555$ cat test.sh
#!/bin/sh

runN 10 $1 \
    "-cc1" "-triple" "x86_64-apple-macosx10.6.7" "-emit-obj" "-mrelax-all"
"-disable-free" "-main-file-name" "flops-8.c" "-pic-level" "1" \
    "-mdisable-fp-elim" "-masm-verbose" "-munwind-tables" "-target-cpu" "core2"
"-target-linker-version" "123.4" "-g" \
    "-coverage-file" "flops-8.o" "-resource-dir" "/tmp" \
    "-O0" "-ferror-limit" "19" "-fmessage-length" "90" "-stack-protector" "1"
"-fblocks" "-fdiagnostics-show-option" "-o" "flops-8.o" "-x" "c" \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c \
    flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c flops-8.c
flops-8.c flops-8.c flops-8.c
--


The following test samples show the regression. Here I am using a fixed
LLVM/Clang revision (r133682) built and installed in the normal
configure/make/make install fashion using the following configure arguments:
--
~/llvm.ref/src/configure \
    --prefix=$idir \
    --disable-bindings --with-built-clang --with-llvmcc=clang \
    --without-llvmgcc --without-llvmgxx \
    --enable-optimized \
    CC=$HOSTDIR/usr/bin/clang \
    CXX=$HOSTDIR/usr/bin/clang++ &> $dir/configure.log
--
and using "Apple Clang" compilers as the host compilers, from revisions r133679
and r133682. The Apple Clang compilers just differ in the exact way they are
built, they should be functionally identical to configure/make style compilers
at the same revisions.

Here is the timing data on a MacPro 5,1:
--
ddunbar at smoosh-17:9670555$ ./test.sh
custom_builds/clang-r133682__apple-clang-x86_64-darwin10-R__clang-r133679-t20110622_190133-b5349.install/bin/clang
name      avg     min     med     max      SD    total
user     0.8674  0.8667  0.8675  0.8680  0.0004  8.6739
 sys     0.0555  0.0544  0.0551  0.0546  0.0011  0.5550
wall     0.9298  0.9331  0.9290  0.9295  0.0016  9.2978

ddunbar at smoosh-17:9670555$ ./test.sh
custom_builds/clang-r133682__apple-clang-x86_64-darwin10-R__clang-r133682-t20110622_204833-b5350.install/bin/clang
name      avg     min     med     max      SD    total
user     0.8874  0.8865  0.8875  0.8888  0.0007  8.8741
 sys     0.0555  0.0562  0.0552  0.0541  0.0008  0.5550
wall     0.9706  0.9483  0.9491  0.9506  0.0542  9.7059

# Compare min user times...
ddunbar at smoosh-17:9670555$ python -c 'print .8865 / .8667'
1.02284527518
--

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 14:04:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 14:04:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10204] New: Regression(r133860): Clang crashes when
 compiling code
Message-ID: <bug-10204-206@http.llvm.org/bugs/>

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

           Summary: Regression(r133860): Clang crashes when compiling code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu


$
/Users/thakis/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang++
 -std=c99 -x c repro.ii 
Assertion failed: (!LV.getType()->isFunctionType()), function EmitLoadOfLValue,
file
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm/tools/clang/lib/CodeGen/CGExpr.cpp,
line 794.
0  clang             0x0000000101914622 PrintStackTrace(void*) + 34
1  clang             0x0000000101915473 SignalHandler(int) + 707
2  libSystem.B.dylib 0x00007fff8064767a _sigtramp + 26
3  clang             0x00000001001cefba
getFunctionInfo(clang::CodeGen::CodeGenTypes&,
llvm::SmallVectorImpl<clang::CanQual<clang::Type> >&,
clang::CanQual<clang::FunctionProtoType>, bool) + 378
4  clang             0x000000010001ae62 __assert_rtn + 66
5  clang             0x000000010021e5ac
clang::CodeGen::CodeGenFunction::EmitLoadOfLValue(clang::CodeGen::LValue) +
1340
6  clang             0x000000010024da3c (anonymous
namespace)::ScalarExprEmitter::VisitDeclRefExpr(clang::DeclRefExpr*) + 284
7  clang             0x0000000100258191 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
6433
8  clang             0x000000010025886d
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 141
9  clang             0x0000000100218a00
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 80
10 clang             0x0000000100226ff5
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 53
11 clang             0x000000010025bf55 (anonymous
namespace)::ScalarExprEmitter::VisitCastExpr(clang::CastExpr*) + 2613
12 clang             0x0000000100257845 clang::StmtVisitorBase<clang::make_ptr,
(anonymous namespace)::ScalarExprEmitter, llvm::Value*>::Visit(clang::Stmt*) +
4053
13 clang             0x000000010025886d
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 141
14 clang             0x0000000100218a00
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 80
15 clang             0x0000000100226ff5
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 53
16 clang             0x00000001002cc11c
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 1356
17 clang             0x00000001002cf89b
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 283
18 clang             0x00000001002cfc69
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 505
19 clang             0x00000001002cbc00
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 48
20 clang             0x00000001002f7d4d
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 909
21 clang             0x00000001002ff8eb
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 1035
22 clang             0x000000010030452b
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 379
23 clang             0x00000001003046aa
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 154
24 clang             0x00000001003056dc
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 1148
25 clang             0x0000000100319b1f (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl(clang::DeclGroupRef) + 63
26 clang             0x00000001002f333b
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 155
27 clang             0x0000000100327292 clang::ParseAST(clang::Sema&, bool) +
322
28 clang             0x00000001002f16bc clang::CodeGenAction::ExecuteAction() +
60
29 clang             0x000000010005a1b1
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 433
30 clang             0x00000001000255f7
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 1527
31 clang             0x000000010001c181 cc1_main(char const**, char const**,
char const*, void*) + 577
32 clang             0x000000010002442e main + 4526
33 clang             0x000000010001b5b4 start + 52
34 clang             0x0000000000000023 start + 4294855331
Stack dump:
0.    Program arguments:
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/clang
-cc1 -triple x86_64-apple-macosx10.6.6 -emit-obj -mrelax-all -disable-free
-main-file-name repro.ii -pic-level 1 -mdisable-fp-elim -masm-verbose
-munwind-tables -target-cpu core2 -target-linker-version 97.14 -resource-dir
/Volumes/MacintoshHD2/src/chrome-git/src/third_party/llvm-build/Release+Asserts/bin/../lib/clang/3.0
-std=c99 -ferror-limit 19 -fmessage-length 337 -stack-protector 1 -fblocks
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/++/++1Gyk++6+0++4RjPqRgNE++ojg/-Tmp-/cc-6LmOcK.o -x c repro.ii 
1.    <eof> parser at end of file
2.   
/Users/thakis/src/chrome-git/src/third_party/mesa/MesaLib/src/mesa/main/api_loopback.c:1581:1:
LLVM IR generation of declaration '_mesa_loopback_init_api_table'
3.   
/Users/thakis/src/chrome-git/src/third_party/mesa/MesaLib/src/mesa/main/api_loopback.c:1581:1:
Generating code for declaration '_mesa_loopback_init_api_table'
4.   
/Users/thakis/src/chrome-git/src/third_party/mesa/MesaLib/src/mesa/main/api_loopback.c:1582:1:
LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)

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

From bugzilla-daemon at llvm.org  Mon Jun 27 14:44:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 14:44:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10202] Warn for missing braces if a bracesless
 if/for/while is followed by a line with increased indentation
In-Reply-To: <bug-10202-206@http.llvm.org/bugs/>
References: <bug-10202-206@http.llvm.org/bugs/>
Message-ID: <20110627194451.45A5C2A6C12D@llvm.org>

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

Jordy Rose <jediknil at belkadan.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jediknil at belkadan.com
         Resolution|                            |DUPLICATE

--- Comment #2 from Jordy Rose <jediknil at belkadan.com> 2011-06-27 14:44:51 CDT ---


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

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 14:47:08 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 14:47:08 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10204] Regression(r133860): Clang crashes when
	compiling code
In-Reply-To: <bug-10204-206@http.llvm.org/bugs/>
References: <bug-10204-206@http.llvm.org/bugs/>
Message-ID: <20110627194708.9A97B2A6C12D@llvm.org>

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

Nico Weber <nicolasweber at gmx.de> changed:

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

--- Comment #4 from Nico Weber <nicolasweber at gmx.de> 2011-06-27 14:47:07 CDT ---
r133931

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 15:05:53 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 15:05:53 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10205] New: clang++ aborts while compiling
Message-ID: <bug-10205-206@http.llvm.org/bugs/>

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

           Summary: clang++ aborts while compiling
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


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

I've tried to compile the file eigen/test/geometry.cpp from eigen[1] 2.0.15

It fails in the following way (with -O0 -emit-llvm):

<<<FAIL
unexpected type in nested name specifier!
UNREACHABLE executed at ItaniumMangle.cpp:836!
0  libLLVM-3.0svn.so 0x00007fd3f0cefeff
1  libLLVM-3.0svn.so 0x00007fd3f0cf02f1
2  libpthread.so.0   0x00007fd3efcefff0
3  libc.so.6         0x00007fd3ef00d605 gsignal + 53
4  libc.so.6         0x00007fd3ef00e905 abort + 389
5  libLLVM-3.0svn.so 0x00007fd3f0cdf35b
6  clang             0x00000000010f7a0c
7  clang             0x00000000010f74cd
8  clang             0x00000000010f67c7
9  clang             0x00000000010f57e4
10 clang             0x00000000010f5698
11 clang             0x00000000010f562d
12 clang             0x00000000010f8676
13 clang             0x00000000010f8497
14 clang             0x00000000010f525b
15 clang             0x00000000010f42d4
16 clang             0x00000000010f4081
17 clang             0x00000000010f714f
18 clang             0x00000000010f70e9
19 clang             0x00000000010f6ff6
20 clang             0x00000000010f2765
21 clang             0x0000000000b6d9d5
clang::CodeGen::CodeGenModule::getMangledName(clang::GlobalDecl) + 469
22 clang             0x0000000000b6f07e
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 606
23 clang             0x0000000000b71ce9
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 233
24 clang             0x0000000000b6a0d3
25 clang             0x0000000000b699c9
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 121
26 clang             0x0000000000e6c9dd
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 1725
27 clang             0x0000000000e6d4a4
clang::Sema::PerformPendingInstantiations(bool) + 388
28 clang             0x0000000000e6ca0f
clang::Sema::InstantiateFunctionDefinition(clang::SourceLocation,
clang::FunctionDecl*, bool, bool) + 1775
29 clang             0x0000000000e6d4a4
clang::Sema::PerformPendingInstantiations(bool) + 388
30 clang             0x0000000000cb193f
clang::Sema::ActOnEndOfTranslationUnit() + 239
31 clang             0x0000000000c81376
clang::Parser::ParseTopLevelDecl(clang::OpaquePtr<clang::DeclGroupRef>&) + 150
32 clang             0x0000000000c6aa6f clang::ParseAST(clang::Sema&, bool) +
303
33 clang             0x0000000000b6907f clang::CodeGenAction::ExecuteAction() +
623
34 clang             0x0000000000a8d2f7 clang::FrontendAction::Execute() + 231
35 clang             0x0000000000a7ad2a
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 506
36 clang             0x0000000000a46910
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 640
37 clang             0x0000000000a3cb47 cc1_main(char const**, char const**,
char const*, void*) + 647
38 clang             0x0000000000a43070 main + 368
39 libc.so.6         0x00007fd3eeff9c7d __libc_start_main + 253
40 clang             0x0000000000a3c7f9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-llvm-bc -disable-free -main-file-name geometry.ii -mrelocation-model
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21 -momit-leaf-frame-pointer
-resource-dir /usr/bin/../lib/clang/3.0 -O0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 118 -fgnu-runtime -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o /tmp/cc-ByiyOR.o -x
c++-cpp-output geometry.ii 
1.      <eof> parser at end of file
2.     
/var/tmp/paludis/build/sci-libs-eigen-2.0.15/work/eigen/test/geometry.cpp:30:32:
instantiating function definition 'geometry'
3.     
/var/tmp/paludis/build/sci-libs-eigen-2.0.15/work/eigen/Eigen/src/Geometry/Transform.h:184:3:
instantiating function definition 'operator*'
4.     
/var/tmp/paludis/build/sci-libs-eigen-2.0.15/work/eigen/Eigen/src/Geometry/Transform.h:184:3:
LLVM IR generation of declaration 'Eigen::Transform<float, 3>::operator*'
5.     
/var/tmp/paludis/build/sci-libs-eigen-2.0.15/work/eigen/Eigen/src/Geometry/Transform.h:184:3:
Mangling declaration 'Eigen::Transform<float, 3>::operator*'
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)
<<<FAIL

I'm attaching the output of -save-temps. Since it is 1.3M in size every
invocation of clang takes very long and I've not yet delta-reduced it. I've
also only attached an xz-compressed version.

I'm on clang 3.0 git-6594942e98e25640f226aba622eb76bcaf0a521c


[1] http://eigen.tuxfamily.org/

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 15:31:13 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 15:31:13 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10206] New: Crash on undefined template
	specialization
Message-ID: <bug-10206-206@http.llvm.org/bugs/>

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

           Summary: Crash on undefined template specialization
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: scshunt at csclub.uwaterloo.ca
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


While reducing a testcase for an unrelated bug, I encountered the attached
crash-on-invalid. It has not been reduced.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 15:38:16 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 15:38:16 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10163] false positive on partially initialized
 array of floating point values.
In-Reply-To: <bug-10163-206@http.llvm.org/bugs/>
References: <bug-10163-206@http.llvm.org/bugs/>
Message-ID: <20110627203816.069002A6C12E@llvm.org>

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

Jordy Rose <jediknil at belkadan.com> changed:

           What    |Removed                     |Added
----------------------------------------------------------------------------
             Status|NEW                         |RESOLVED
                 CC|                            |jediknil at belkadan.com
         Resolution|                            |FIXED

--- Comment #1 from Jordy Rose <jediknil at belkadan.com> 2011-06-27 15:38:15 CDT ---
Since we don't model floats (yet), we were just skipping the
default-initialization step in RegionStore. Instead, we can use a default value
of UnknownVal to mark that the array has at least been initialized. Fixed in
r133937.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 16:13:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 16:13:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10207] New: [C] btowc() autoconf check hangs
Message-ID: <bug-10207-206@http.llvm.org/bugs/>

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

           Summary: [C] btowc() autoconf check hangs
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6793)
 --> (http://llvm.org/bugs/attachment.cgi?id=6793)
configure check

the btowc.m4 check generated from gnulib's gl_FUNC_BTOWC looks like this:

<<<SNIP
#include <string.h>
/* Tru64 with Desktop Toolkit C has a bug: <stdio.h> must be included before
   <wchar.h>.
   BSD/OS 4.0.1 has a bug: <stddef.h>, <stdio.h> and <time.h> must be
   included before <wchar.h>.  */
#include <stddef.h>
#include <stdio.h>
#include <time.h>
#include <wchar.h>
int main ()
{
  if (btowc ('\0') != 0)
    return 1;
  return 0;
}
<<<SNIP

If I compile this with gcc and run it, it returns as expected (even with -O3).

It compiles and returns when run as well for clang with -O0 and -O1.

It hangs for clang -O2 and -O3.

This on linux 2.6.39.2 with clang 3.0
git-6594942e98e25640f226aba622eb76bcaf0a521c.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 16:14:47 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 16:14:47 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10111] nonnull attribute generates a warning for
 transparent unions
In-Reply-To: <bug-10111-206@http.llvm.org/bugs/>
References: <bug-10111-206@http.llvm.org/bugs/>
Message-ID: <20110627211447.AF03B2A6C12E@llvm.org>

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

Fariborz Jahanian <fjahanian at apple.com> changed:

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

--- Comment #2 from Fariborz Jahanian <fjahanian at apple.com> 2011-06-27 16:14:47 CDT ---
Fixed in TOT: http://llvm.org/viewvc/llvm-project?view=rev&revision=133941

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 18:13:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 18:13:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10208] New: [C] Abort during compilation
Message-ID: <bug-10208-206@http.llvm.org/bugs/>

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

           Summary: [C] Abort during compilation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: pipping at exherbo.org
                CC: llvmbugs at cs.uiuc.edu


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

pipping at bogus /home/pipping % clang -c foo.c
clang: CGExpr.cpp:794: clang::CodeGen::RValue
clang::CodeGen::CodeGenFunction::EmitLoadOfLValue(clang::CodeGen::LValue):
Assertion `!LV.getType()->isFunctionType()' failed.
0  libLLVM-3.0svn.so 0x00007f86740ffeff
1  libLLVM-3.0svn.so 0x00007f86741002f1
2  libpthread.so.0   0x00007f86730ffff0
3  libc.so.6         0x00007f867241d605 gsignal + 53
4  libc.so.6         0x00007f867241e905 abort + 389
5  libc.so.6         0x00007f8672416235 __assert_fail + 245
6  clang             0x0000000000bd0744
clang::CodeGen::CodeGenFunction::EmitLoadOfLValue(clang::CodeGen::LValue) +
1044
7  clang             0x0000000000beee34
8  clang             0x0000000000beeeb8
9  clang             0x0000000000bf4403
10 clang             0x0000000000bf1d45
11 clang             0x0000000000bed892
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 98
12 clang             0x0000000000bca3be
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 62
13 clang             0x0000000000bca35b
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 59
14 clang             0x0000000000bf6f99
15 clang             0x0000000000bf75a3
16 clang             0x0000000000bf1c95
17 clang             0x0000000000bed892
clang::CodeGen::CodeGenFunction::EmitScalarExpr(clang::Expr const*, bool) + 98
18 clang             0x0000000000bca3be
clang::CodeGen::CodeGenFunction::EmitAnyExpr(clang::Expr const*,
clang::CodeGen::AggValueSlot, bool) + 62
19 clang             0x0000000000bca35b
clang::CodeGen::CodeGenFunction::EmitIgnoredExpr(clang::Expr const*) + 59

20 clang             0x0000000000c3283a
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 266
21 clang             0x0000000000c35ddb
clang::CodeGen::CodeGenFunction::EmitCompoundStmt(clang::CompoundStmt const&,
bool, clang::CodeGen::AggValueSlot) + 203
22 clang             0x0000000000c32cf8
clang::CodeGen::CodeGenFunction::EmitSimpleStmt(clang::Stmt const*) + 168
23 clang             0x0000000000c32750
clang::CodeGen::CodeGenFunction::EmitStmt(clang::Stmt const*) + 32
24 clang             0x0000000000c55635
clang::CodeGen::CodeGenFunction::EmitFunctionBody(clang::CodeGen::FunctionArgList&)
+ 69
25 clang             0x0000000000c55862
clang::CodeGen::CodeGenFunction::GenerateCode(clang::GlobalDecl,
llvm::Function*, clang::CodeGen::CGFunctionInfo const&) + 514
26 clang             0x0000000000b6f625
clang::CodeGen::CodeGenModule::EmitGlobalFunctionDefinition(clang::GlobalDecl)
+ 645
27 clang             0x0000000000b6e471
clang::CodeGen::CodeGenModule::EmitGlobalDefinition(clang::GlobalDecl) + 385
28 clang             0x0000000000b6eff6
clang::CodeGen::CodeGenModule::EmitGlobal(clang::GlobalDecl) + 470
29 clang             0x0000000000b71ce9
clang::CodeGen::CodeGenModule::EmitTopLevelDecl(clang::Decl*) + 233
30 clang             0x0000000000b6a0d3
31 clang             0x0000000000b699c9
clang::BackendConsumer::HandleTopLevelDecl(clang::DeclGroupRef) + 121
32 clang             0x0000000000c6aa64 clang::ParseAST(clang::Sema&, bool) +
292
33 clang             0x0000000000b6907f clang::CodeGenAction::ExecuteAction() +
623
34 clang             0x0000000000a8d2f7 clang::FrontendAction::Execute() + 231

35 clang             0x0000000000a7ad2a
clang::CompilerInstance::ExecuteAction(clang::FrontendAction&) + 506
36 clang             0x0000000000a46910
clang::ExecuteCompilerInvocation(clang::CompilerInstance*) + 640
37 clang             0x0000000000a3cb47 cc1_main(char const**, char const**,
char const*, void*) + 647
38 clang             0x0000000000a43070 main + 368
39 libc.so.6         0x00007f8672409c7d __libc_start_main + 253
40 clang             0x0000000000a3c7f9
Stack dump:
0.      Program arguments: /usr/bin/clang -cc1 -triple x86_64-pc-linux-gnu
-emit-obj -mrelax-all -disable-free -main-file-name foo.c -mrelocation-model
static -mdisable-fp-elim -masm-verbose -mconstructor-aliases -munwind-tables
-target-cpu x86-64 -target-linker-version 2.21 -momit-leaf-frame-pointer
-coverage-file foo.o -resource-dir /usr/bin/../lib/clang/3.0 -ferror-limit 19
-fmessage-length 118 -fgnu-runtime -fdiagnostics-show-option
-fcolor-diagnostics -o foo.o -x c foo.c 
1.      <eof> parser at end of file
2.      foo.c:4:1: LLVM IR generation of declaration 'main'
3.      foo.c:4:1: Generating code for declaration 'main'
4.      foo.c:5:1: LLVM IR generation of compound statement ('{}')
clang: error: unable to execute command: Aborted
clang: error: clang frontend command failed due to signal 2 (use -v to see
invocation)


clang 3.0 git-6594942e98e25640f226aba622eb76bcaf0a521c

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 18:20:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 18:20:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10207] [C] btowc() autoconf check hangs
In-Reply-To: <bug-10207-206@http.llvm.org/bugs/>
References: <bug-10207-206@http.llvm.org/bugs/>
Message-ID: <20110627232031.CF0112A6C12E@llvm.org>

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

Eli Friedman <sharparrow1 at yahoo.com> changed:

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

--- Comment #2 from Eli Friedman <sharparrow1 at yahoo.com> 2011-06-27 18:20:31 CDT ---


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

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

From bugzilla-daemon at llvm.org  Mon Jun 27 18:52:42 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 18:52:42 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10209] New: Num arg handling seems incorrect in
 ownership attribute
Message-ID: <bug-10209-206@http.llvm.org/bugs/>

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

           Summary: Num arg handling seems incorrect in ownership
                    attribute
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: supertri at google.com
                CC: llvmbugs at cs.uiuc.edu


prompt$ clang -x c -
void bar() __attribute__((ownership_returns(foo, 1, 2)));

Returns:

<stdin>:1:27: error: attribute requires exactly 3 arguments
void bar() __attribute__((ownership_returns(foo, 1, 2)));
                          ^
1 error generated.

I gave it 3 arguments...

In the ownership returns case in SemaDeclAttr.cpp, checking for the number of
arguments is very different from the other cases:

    if (AL.getNumArgs() > 1) {
      S.Diag(AL.getLoc(), diag::err_attribute_wrong_number_arguments)
          << AL.getNumArgs() + 1;
      return;

Should the number of args for AL be exactly 1? Or 1 or 0? Or 2? Or any number
greater than or equal to 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  Mon Jun 27 19:45:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 19:45:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10210] New: Odd behavior with
 llvm::StringMap::GetOrCreateValue when passed const char * vs. std::string.
Message-ID: <bug-10210-206@http.llvm.org/bugs/>

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

           Summary: Odd behavior with llvm::StringMap::GetOrCreateValue
                    when passed const char * vs. std::string.
           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: chad.rosier at gmail.com
                CC: llvmbugs at cs.uiuc.edu


LLVM commit r133516 caused link-time errors when LTO was enabled for a number
of the ObjC and ObjC++ benchmarks in the llvm test-suite.  The change in
r133516 are all of the nature:

-        _undefines.GetOrCreateValue(superclassName.c_str());
+        _undefines.GetOrCreateValue(superclassName);

In the first instance a C style string (i.e., const char *) is passed, while in
the second version a std::string is passed.  It is unclear as to why passing a
std::string would cause an issue and should be further investigated.

** To Reproduce:
1. Checkout revision 133516.
2. Checkout the llvm test-suite.
3. Build with --enable-optimized
4. Run the test-suite in the ObjC and/or Obj-C++ subdirectories with the
following flags:
make ARCH=x86 CC_UNDER_TEST_IS_CLANG=1 CC_UNDER_TEST_TARGET_IS_I386=1
DISABLE_CBE=1
DISABLE_JIT=1 ENABLE_HASHED_PROGRAM_OUTPUT=1 ENABLE_OPTIMIZED=1
LD_ENV_OVERRIDES="env DYLD_LIBRARY_PATH=$YOUR_INSTALL_DIR/lib" LLC_OPTFLAGS=-O2
LLI_OPTFLAGS=-O2 OPTFLAGS=-Os SMALL_PROBLEM_SIZE=1 TARGET_CC="" TARGET_CXX=""
TARGET_FLAGS="-flto -arch i386" TARGET_LLVMGCC=$YOUR_INSTALL_DIR/bin/clang
TARGET_LLVMGXX=$YOUR_INSTALL_DIR/bin/clang++ TEST=simple USE_REFERENCE_OUTPUT=1
report

Obviously, $YOUR_TEST_DIR should be the directory where clang has been
installed.  You should see many of the ObjC and ObjC++ tests fails due to a
linking issue of the form "ld: duplicate symbol ...".  If you repeat the above
process with r133955 (which reverts 133516) the errors are removed.

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

From bugzilla-daemon at llvm.org  Mon Jun 27 21:27:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 21:27:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10211] New: False positives with
 -Wconstant-logical-operand in template code
Message-ID: <bug-10211-206@http.llvm.org/bugs/>

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

           Summary: False positives with -Wconstant-logical-operand in
                    template code
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rjmccall at apple.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


-Wconstant-logical-operand warns about code where the constant argument was
instantiated from a template.  This is idiomatically acceptable code.  It comes
up a lot in e.g. Eigen:
  http://eigen.tuxfamily.org/index.php?title=Main_Page
Anyone verifying this should probably do a test compile with some Eigen files,
e.g. 2.0.15's test/geometry.cpp [note: clang -I.. -D test_geometry], but here's
a short reduction of a few cases we should get:

  template <class T> class A {
    unsigned count() { return 0; }

    bool test1() { return (count() && int(T::SomeBit)); }

    enum {
      SomeBit = T::SomeBit
    };
    bool test2() { return (count() && int(SomeBit)); }
  };
  struct B { enum { SomeBit = true }; };
  template class A<B>;

The warning doesn't trigger here without the function-style casts.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 27 23:14:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Mon, 27 Jun 2011 23:14:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10212] New: Please add support for ms_hook_prologue
 function attritube
Message-ID: <bug-10212-206@http.llvm.org/bugs/>

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

           Summary: Please add support for ms_hook_prologue function
                    attritube
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: enhancement
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: austinenglish at gmail.com
                CC: llvmbugs at cs.uiuc.edu




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

From bugzilla-daemon at llvm.org  Tue Jun 28 00:06:29 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 00:06:29 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10213] New: "lit not-existing.c" prints "contained
 no tests" warning
Message-ID: <bug-10213-206@http.llvm.org/bugs/>

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

           Summary: "lit not-existing.c" prints "contained no tests"
                    warning
           Product: Test Suite
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: lit
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: clattner at apple.com
                CC: llvmbugs at cs.uiuc.edu, daniel at zuster.org


I would expect:

$ rm frotz.c
$ lit frotz.c

to produce an error about the file not existing.  Instead it prints a very limp
warning:


lit.py: lit.cfg:143: note: using clang:
'/Volumes/Data/Users/sabre/cvs/llvm-2/Debug+Asserts/bin/clang'
lit.py: main.py:517: warning: input 'frotz.c' contained no tests
-- Testing: 0 tests, 16 threads --
Testing Time: 0.00s

1 warning(s) in tests.


which is easy to miss, and I commonly get when I forget to include the full
path to a testcase I'm working with.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 00:11:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 00:11:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 9279] Macro expansion stack trace seriously broken
 with function-style macros
In-Reply-To: <bug-9279-206@http.llvm.org/bugs/>
References: <bug-9279-206@http.llvm.org/bugs/>
Message-ID: <20110628051146.EE7E02A6C12E@llvm.org>

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

Chris Lattner <clattner at apple.com> changed:

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

--- Comment #22 from Chris Lattner <clattner at apple.com> 2011-06-28 00:11:44 CDT ---
Fixed in r133993.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 01:59:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 01:59:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10214] New: Macro expansion stack fails to list
 bottom most macro for errors in arguments
Message-ID: <bug-10214-206@http.llvm.org/bugs/>

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

           Summary: Macro expansion stack fails to list bottom most macro
                    for errors in arguments
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6795)
 --> (http://llvm.org/bugs/attachment.cgi?id=6795)
Patch originally proposed for PR9279

This is reduced from one of several test cases I provided as part of my patch
to PR9279. It is also one of the problems listed on the original PR.

Given:
% cat x1.c
#define A 1
#define B A
#define C B
void bar() {
  C;
}

#define M1(x) x
#define M2(x) M1(x)
#define M3(x) M2(x)

void test() {
  M3(1);
}

Clang currently prints (after Chris's patch for PR9279):
% ./bin/clang -fsyntax-only x1.c
x1.c:5:3: warning: expression result unused [-Wunused-value]
  C;
  ^
x1.c:3:11: note: instantiated from:
#define C B
          ^
x1.c:2:11: note: instantiated from:
#define B A
          ^
x1.c:1:11: note: instantiated from:
#define A 1
          ^
x1.c:13:3: warning: expression result unused [-Wunused-value]
  M3(1);
  ^~~~~
x1.c:10:15: note: instantiated from:
#define M3(x) M2(x)
              ^
x1.c:9:15: note: instantiated from:
#define M2(x) M1(x)
              ^
x1.c:13:3: note: instantiated from:
  M3(1);
     ^
2 warnings generated.

Note that M1's definition isn't shown, but A's definition is.

With my patch for PR9279 we get what I would expect here:
% ./bin/clang -fsyntax-only x1.c 
x1.c:5:3: warning: expression result unused [-Wunused-value]
  C;
  ^
x1.c:3:11: note: instantiated from:
#define C B
          ^
x1.c:2:11: note: instantiated from:
#define B A
          ^
x1.c:1:11: note: instantiated from:
#define A 1
          ^
x1.c:13:6: warning: expression result unused [-Wunused-value]
  M3(1);
  ~~~^~
x1.c:10:18: note: instantiated from:
#define M3(x) M2(x)
                 ^
x1.c:9:18: note: instantiated from:
#define M2(x) M1(x)
                 ^
x1.c:8:15: note: instantiated from:
#define M1(x) x
              ^
2 warnings generated.


I've attached (an updated version of) my patch for PR9279 so that people can
replicate these. This patch may be overkill for this particular bug, but it
fixes several interrelated issues at the same time. See the original PR for a
discussion of the performance and memory impact.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 02:14:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 02:14:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10215] New: Location of argument to function style
 macro not correctly tracked
Message-ID: <bug-10215-206@http.llvm.org/bugs/>

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

           Summary: Location of argument to function style macro not
                    correctly tracked
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: chandlerc at gmail.com
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6796)
 --> (http://llvm.org/bugs/attachment.cgi?id=6796)
Patch originally proposed for PR9279

This is reduced from two of several test cases I provided as part of my patch
to PR9279. It also contributes to the final problem listed on the original PR.

Given:
% cat x2.c
#define macro_args1(x) x
#define macro_args2(x) macro_args1(x)
#define macro_args3(x) macro_args2(x)

#define macro_many_args1(x, y, z) y
#define macro_many_args2(x, y, z) macro_many_args1(x, y, z)
#define macro_many_args3(x, y, z) macro_many_args2(x, y, z)

void test() {
  macro_many_args3(
    1,
    2,
    3);

  macro_many_args3(
    1,
    macro_args2(2),
    3);
}

Clang currently prints (after Chris's patch for PR9279):
% ./bin/clang -fsyntax-only x2.c
x2.c:14:3: warning: expression result unused [-Wunused-value]
  macro_many_args3(
  ^~~~~~~~~~~~~~~~~
x2.c:9:35: note: instantiated from:
#define macro_many_args3(x, y, z) macro_many_args2(x, \
                                  ^
x2.c:6:35: note: instantiated from:
#define macro_many_args2(x, y, z) macro_many_args1(x, \
                                  ^
x2.c:14:3: note: instantiated from:
    2,
    ^
x2.c:19:3: warning: expression result unused [-Wunused-value]
  macro_many_args3(
  ^~~~~~~~~~~~~~~~~
x2.c:9:35: note: instantiated from:
#define macro_many_args3(x, y, z) macro_many_args2(x, \
                                  ^
x2.c:6:35: note: instantiated from:
#define macro_many_args2(x, y, z) macro_many_args1(x, \
                                  ^
x2.c:19:3: note: instantiated from:
    macro_args2(2),
    ~~~~~~~~~~~~^~
2 warnings generated.

The incorrect source locations of the arguments to the function style macro
manifest as a number of problems with these two diagnostics.

The first one shows that the warning location is at the start of the macro
rather than the argument to the macro which was actually used to produce the
error. Also, the intermediate notes don't point to where the function style
macro argument occurred within the definition; in this case, it isn't even the
correct line of the file.

The second has the same problems as the first, but compounded by the fact that
there is an entire macro involved in the error which isn't expanded at all; we
don't know what macro_args2 actually leads to.

With my patch for PR9279 we get about the best I would expect from Clang here:
% ./bin/clang -fsyntax-only x2.c
x2.c:16:5: warning: expression result unused [-Wunused-value]
    2,
    ^~
x2.c:10:52: note: instantiated from:
                                                   y, \
                                                   ^
x2.c:7:52: note: instantiated from:
                                                   y, \
                                                   ^
x2.c:5:35: note: instantiated from:
#define macro_many_args1(x, y, z) y
                                  ^
x2.c:21:17: warning: expression result unused [-Wunused-value]
    macro_args2(2),
    ~~~~~~~~~~~~^~~
x2.c:2:36: note: instantiated from:
#define macro_args2(x) macro_args1(x)
                                   ^
x2.c:1:24: note: instantiated from:
#define macro_args1(x) x
                       ^
x2.c:10:52: note: instantiated from:
                                                   y, \
                                                   ^
x2.c:7:52: note: instantiated from:
                                                   y, \
                                                   ^
x2.c:5:35: note: instantiated from:
#define macro_many_args1(x, y, z) y
                                  ^
2 warnings generated.

The test case is a stress test, but it highlights real problems we hit with
Clang diagnostics in real code. 

I've attached (an updated version of) my patch for PR9279 so that people can
replicate these. Note that fixing this bug also (almost necessarily) fixes
PR10214. I'm breaking them up as requested by Chris. More details on the patch,
the reasoning that led to it, performance analysis and memory consumption can
be read on PR9279 where it was originally proposed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 02:21:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 02:21:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10216] New: assertion "Unknown stmt kind" in make
 check in trunk
Message-ID: <bug-10216-206@http.llvm.org/bugs/>

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

           Summary: assertion "Unknown stmt kind" in make check in trunk
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: release blocker
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: ps at kr.tuwien.ac.at
                CC: llvmbugs at cs.uiuc.edu


I run ubuntu 64bit and for me make check and using the built clang for building
my software project fails.

It started failing between [133476] and [133566].

The assertion "Unknown stmt kind" appears quite often in the make check output.

But plain segfaults also happen and the compiler is currently unusable for me.

Do you need more information?

-- Testing: 3270 tests, 4 threads --
Testing: 
FAIL: Clang :: ARCMT/atautorelease-3.m (4 of 3270)
******************** TEST 'Clang :: ARCMT/atautorelease-3.m' FAILED
********************
Script:
--
/var/lib/buildbot/clang-slave/trunk/build/Release+Asserts/bin/clang -cc1
-triple x86_64-apple-darwin10 -fobjc-nonfragile-abi -fsyntax-only -fobjc-arc -x
objective-c
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/test/ARCMT/atautorelease-3.m.result
arcmt-test --args -triple x86_64-apple-darwin10 -fobjc-nonfragile-abi
-fsyntax-only -x objective-c
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/test/ARCMT/atautorelease-3.m
>
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/test/ARCMT/Output/atautorelease-3.m.tmp
diff
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/test/ARCMT/Output/atautorelease-3.m.tmp
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/test/ARCMT/atautorelease-3.m.result
--
Exit Code: 134
Command Output (stderr):
--
arcmt-test:
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/lib/ARCMigrate/../../include/clang/AST/StmtVisitor.h:102:
RetTy clang::StmtVisitorBase<Ptr, ImplClass, RetTy>::Visit(typename
Ptr<clang::Stmt>::type) [with Ptr = clang::make_ptr, ImplClass =
<unnamed>::EmptyChecker, RetTy = bool, typename Ptr<clang::Stmt>::type =
clang::Stmt*]: Assertion `0 && "Unknown stmt kind!"' failed.
0  arcmt-test      0x0000000000b1101f
1  arcmt-test      0x0000000000b11b6a
2  libpthread.so.0 0x00002b90902c4b40
3  libc.so.6       0x00002b9090eaaba5 gsignal + 53
4  libc.so.6       0x00002b9090eae6b0 abort + 384
5  libc.so.6       0x00002b9090ea3a71 __assert_fail + 241
6  arcmt-test      0x000000000049f897
7  arcmt-test      0x00000000004a1f62
8  arcmt-test      0x00000000004a1070
9  arcmt-test      0x00000000004adbd8
10 arcmt-test      0x00000000004a6c02
11 arcmt-test      0x00000000004a8aa1
12 arcmt-test      0x00000000004a62d1
13 arcmt-test      0x00000000004a8406
14 arcmt-test      0x000000000040e2ee
15 arcmt-test      0x0000000000407c58
16 arcmt-test      0x0000000000408106
17 libc.so.6       0x00002b9090e95d8e __libc_start_main + 254
18 arcmt-test      0x0000000000405729
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/test/ARCMT/Output/atautorelease-3.m.script:
line 3: 20258 Aborted                 arcmt-test --args -triple
x86_64-apple-darwin10 -fobjc-nonfragile-abi -fsyntax-only -x objective-c
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/test/ARCMT/atautorelease-3.m
>
/var/lib/buildbot/clang-slave/trunk/build/tools/clang/test/ARCMT/Output/atautorelease-3.m.tmp
--

********************
Testing: 
FAIL: Clang :: ARCMT/atautorelease.m (6 of 3270)
******************** TEST 'Clang :: ARCMT/atautorelease.m' 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 Jun 28 02:48:25 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 02:48:25 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10208] [C] Abort during compilation
In-Reply-To: <bug-10208-206@http.llvm.org/bugs/>
References: <bug-10208-206@http.llvm.org/bugs/>
Message-ID: <20110628074825.3D6E52A6C12D@llvm.org>

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

Elias Pipping <pipping at exherbo.org> changed:

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

--- Comment #2 from Elias Pipping <pipping at exherbo.org> 2011-06-28 02:48:24 CDT ---
Fixed indeed.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 03:29:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 03:29:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10042] -fplugin-arg-dragonegg-enable-gcc-optzns -O3
 -fdefault-integer-8 ICE
In-Reply-To: <bug-10042-206@http.llvm.org/bugs/>
References: <bug-10042-206@http.llvm.org/bugs/>
Message-ID: <20110628082903.7705A2A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #15 from Duncan Sands <baldrick at free.fr> 2011-06-28 03:29:02 CDT ---
This was a GCC bug and has been fixed in GCC.

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

From bugzilla-daemon at llvm.org  Tue Jun 28 05:15:32 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 05:15:32 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10217] New: Confusing error message with deleted
 implicit copy constructors/assignment operators
Message-ID: <bug-10217-206@http.llvm.org/bugs/>

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

           Summary: Confusing error message with deleted implicit copy
                    constructors/assignment operators
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Consider the following code (adapted from libc++):

template <class _T1, class _T2>
struct __compressed_pair
{
    __compressed_pair() {}
    __compressed_pair(__compressed_pair&&) {}
};

typedef __compressed_pair<int, int>    P;

P foo();

int main(int, char**)
{
    P s;
    s = foo();
}


Compiling this with clang r133996 results in:

$ clang -std=c++0x clang.cpp
clang.cpp:15:4: error: overload resolution selected deleted operator '='
        s = foo();
        ~ ^ ~~~~~
clang.cpp:2:8: note: candidate function (the implicit copy assignment operator)
has been explicitly
      deleted
struct __compressed_pair
       ^
1 error generated.


This behaviour is correct as per 12.8p18, however the error message is quite
confusing: How can an *implicit* operator be *explicitely* deleted? I think the
note should end with "... by the explicit move {constructor|assignment
operator}". Also, it should point to this move constructor/operator instead of
to the beginning of the class definition.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 05:53:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 05:53:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10218] New: __compressed_pair<int,
	int> does not compile
Message-ID: <bug-10218-206@http.llvm.org/bugs/>

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

           Summary: __compressed_pair<int, int> does not compile
           Product: libc++
           Version: unspecified
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: All Bugs
        AssignedTo: hhinnant at apple.com
        ReportedBy: jonathan.sauer at gmx.de
                CC: llvmbugs at cs.uiuc.edu


The following applies to a class internal to libc++; I stumbled upon it while
narrowing down Bug 10191. Still, I thought it might be useful to report it:


template <class _T1, class _T2>
class __libcpp_compressed_pair_imp
{
public:
    typedef _T1 _T1_param;
    typedef _T2 _T2_param;

    __libcpp_compressed_pair_imp();
    __libcpp_compressed_pair_imp(_T1_param __t1, int = 0);
    __libcpp_compressed_pair_imp(_T1_param __t1, _T2_param __t2);
};


int main(int, char**)
{
    __libcpp_compressed_pair_imp<int, int>    f;
}


I isolated this code from the __compressed_pair implementation in <memory>.
When compiling with clang r133996, the following error is generated:


clang.cpp:10:2: error: constructor cannot be redeclared
        __libcpp_compressed_pair_imp(_T1_param __t1, _T2_param __t2);
        ^
clang.cpp:16:41: note: in instantiation of template class
'__libcpp_compressed_pair_imp<int, int>'
      requested here
        __libcpp_compressed_pair_imp<int, int>  f;
                                                ^
clang.cpp:9:5: note: previous declaration is here
    __libcpp_compressed_pair_imp(_T1_param __t1, int = 0);
    ^
1 error generated.


This is because <int> is used both as a way to distinguish between the
constructor for <_T1> and <_T2> as well as <_T2> itself, effectively making
lines A and identical.

I think a private type should be used for the dummy parameters instead of <int>
(if the bug is considered relevant, that is).

I'm using libc++ r133667.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 13:22:40 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 13:22:40 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10219] New: UNREACHABLE: unexpected type in nested
 name specifier!
Message-ID: <bug-10219-206@http.llvm.org/bugs/>

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

           Summary: UNREACHABLE: unexpected type in nested name specifier!
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zilla at kayari.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


struct Nosm 
{
    int m_R;
};

namespace dx {

    struct onc
    {
        typedef void(*Cb)();

        onc(Cb cb);
    };

    struct grac
    {
        template<class Derived> static void once();
    };

    template<class Derived>
        struct tonc : onc
        {
            tonc() : onc(&grac::once<Derived>) {}

            static Derived& get();
        };

    template<class Derived> void grac::once()
    {
        tonc<Derived>::get().h();
    }
}

namespace
{
    template<typename T, int = sizeof(&T::m_R)>
        struct has_R { };

    template<typename T>
        inline void
        setR(T* m, has_R<T>* = 0)
        { }

    inline void setR(...) { }
}

template<typename M>
    struct Qmi
    : dx::tonc<Qmi<M> >
    {
        void h()
        {
            setR(&msg);
        }

        M msg;
    };

Qmi<Nosm> x;

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

From bugzilla-daemon at llvm.org  Tue Jun 28 13:27:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 13:27:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10210] Odd behavior with
 llvm::StringMap::GetOrCreateValue when passed const char * vs. std::string.
In-Reply-To: <bug-10210-206@http.llvm.org/bugs/>
References: <bug-10210-206@http.llvm.org/bugs/>
Message-ID: <20110628182704.B86012A6C12D@llvm.org>

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

Chad Rosier <chad.rosier at gmail.com> changed:

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

--- Comment #5 from Chad Rosier <chad.rosier at gmail.com> 2011-06-28 13:27:04 CDT ---
Reinstated in revision 134017.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 13:36:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 13:36:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3472] Cannot compile code with FP inline asm
In-Reply-To: <bug-3472-206@http.llvm.org/bugs/>
References: <bug-3472-206@http.llvm.org/bugs/>
Message-ID: <20110628183650.F26A52A6C130@llvm.org>

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

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

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

--- Comment #10 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-06-28 13:36:49 CDT ---
This is likely fixed by r134018. Please verify.

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

From bugzilla-daemon at llvm.org  Tue Jun 28 13:49:44 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 13:49:44 -0500 (CDT)
Subject: [LLVMbugs] [Bug 879] [X86] No support for fp stack in inline asm
In-Reply-To: <bug-879-206@http.llvm.org/bugs/>
References: <bug-879-206@http.llvm.org/bugs/>
Message-ID: <20110628184944.962BF2A6C12F@llvm.org>

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

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

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

--- Comment #39 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-06-28 13:49:42 CDT ---
Fixed in r134018

Chris' tests now produce:


_floor:                                 ## @floor
## BB#0:                                ## %entry
    pushl    %ebp
    movl    %esp, %ebp
    fldl    8(%ebp)
    ## InlineAsm Start
    frndint
    ## InlineAsm End
    popl    %ebp
    ret

    .globl    _test
    .align    4, 0x90
_test:                                  ## @test
## BB#0:                                ## %entry
    pushl    %ebp
    movl    %esp, %ebp
    fldl    16(%ebp)
    fldl    8(%ebp)
    ## InlineAsm Start
    fucomip %st(1), %st; seta %al
    ## InlineAsm End
    fstp    %st(0)
    movsbl    %al, %eax
    popl    %ebp
    ret

    .globl    _test2
    .align    4, 0x90
_test2:                                 ## @test2
## BB#0:                                ## %entry
    pushl    %ebp
    movl    %esp, %ebp
    fld1
    fldl    8(%ebp)
    fxch
    ## InlineAsm Start
    fscale
    ## InlineAsm End
    fstp    %st(1)
    popl    %ebp
    ret

Roman's ldexp:

_ldexp:                                 ## @ldexp
## BB#0:                                ## %entry
    pushl    %ebp
    movl    %esp, %ebp
    pushl    %eax
    movl    16(%ebp), %eax
    movl    %eax, -4(%ebp)
    fildl    -4(%ebp)
    fldl    8(%ebp)
    ## InlineAsm Start
    fscale 
    ## InlineAsm End
    fstp    %st(1)
    addl    $4, %esp
    popl    %ebp
    ret

Dimitry:

_irint:                                 ## @irint
## BB#0:                                ## %entry
    pushl    %ebp
    movl    %esp, %ebp
    pushl    %eax
    fldl    8(%ebp)
    ## InlineAsm Start
    fistl -4(%ebp)
    ## InlineAsm End
    fstp    %st(0)
    movl    -4(%ebp), %eax
    addl    $4, %esp
    popl    %ebp
    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 Jun 28 18:13:04 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 18:13:04 -0500 (CDT)
Subject: [LLVMbugs] [Bug 2270] [X87 FPStack] Issues with inline asm
In-Reply-To: <bug-2270-206@http.llvm.org/bugs/>
References: <bug-2270-206@http.llvm.org/bugs/>
Message-ID: <20110628231304.8ADC82A6C12D@llvm.org>

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

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

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

--- Comment #18 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-06-28 18:13:03 CDT ---
Fixed in r134018. Please verify, I can no longer read to attached test case.

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

From bugzilla-daemon at llvm.org  Tue Jun 28 18:29:05 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 18:29:05 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8870] False live range after running the coalescer
In-Reply-To: <bug-8870-206@http.llvm.org/bugs/>
References: <bug-8870-206@http.llvm.org/bugs/>
Message-ID: <20110628232905.04BC62A6C124@llvm.org>

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

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

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

--- Comment #3 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-06-28 18:29:04 CDT ---
Chris deleted this test case in r133228, but I verified that -verify-coalescing
is happy 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 Jun 28 18:32:59 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 18:32:59 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10125] debug variables incorrectly deleted by LLVM
 in the Live Debug Variables pass
In-Reply-To: <bug-10125-206@http.llvm.org/bugs/>
References: <bug-10125-206@http.llvm.org/bugs/>
Message-ID: <20110628233259.996392A6C12C@llvm.org>

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

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

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

--- Comment #5 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-06-28 18:32:59 CDT ---
I am closing this since no problem can be reproduced with an in-tree target.

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

From bugzilla-daemon at llvm.org  Tue Jun 28 18:50:38 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 18:50:38 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10220] New: Crash in scheduler on x86-64 with very
 wide addition
Message-ID: <bug-10220-206@http.llvm.org/bugs/>

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

           Summary: Crash in scheduler on x86-64 with very wide addition
           Product: new-bugs
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: sharparrow1 at yahoo.com
                CC: llvmbugs at cs.uiuc.edu


Testcase:

define void @f(i256* nocapture %a, i256* nocapture %b, i256* nocapture %cc,
i256* nocapture %dd) nounwind uwtable noinline ssp {
entry:
  %c = load i256* %cc
  %d = load i256* %dd
  %add = add nsw i256 %c, %d
  store i256 %add, i256* %a, align 8
  %or = or i256 %c,
1606938044258990275541962092341162602522202993782792835301376
  %add6 = add nsw i256 %or, %d
  store i256 %add6, i256* %b, align 8
  ret void
}

(The very large constant is 1<<200.)

Crashes with:

Assertion failed: ((getKind() == Data || getKind() == Anti || getKind() ==
Output) && "getReg called on non-register dependence edge!"), function getReg,
file /Users/efriedma/llvm/include/llvm/CodeGen/ScheduleDAG.h, line 204.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 28 22:28:12 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Tue, 28 Jun 2011 22:28:12 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10221] New: Poor register allocation
Message-ID: <bug-10221-206@http.llvm.org/bugs/>

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

           Summary: Poor register allocation
           Product: libraries
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: Register Allocator
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: jmuizelaar at mozilla.com
                CC: llvmbugs at cs.uiuc.edu


This code:

void foo(float x, float y);
int finit(double);
int
nsSVGPathElementCreateSVGPathSegMovetoAbs(float x, float y, void **_retval)
{
    if (!finit((x)+(y))) {
    return 5;
  }

  foo(x, y);
  return 0;
}

Compiles to:

__ at _Z41nsSVGPathElementCreateSVGPathSegMovetoAbsffPPv
    pushq    %rax
    movaps    %xmm1, %xmm2
    movaps    %xmm0, %xmm1
    movaps    %xmm1, %xmm0

We move and then move back?

    movss    %xmm1, 4(%rsp)          ## 4-byte Spill
    addss    %xmm2, %xmm0
    movss    %xmm2, (%rsp)           ## 4-byte Spill

We also shouldn't need to use xmm2 here above

    cvtss2sd    %xmm0, %xmm0
    callq    __Z5finitd
    movl    %eax, %ecx
    movl    $5, %eax
    testl    %ecx, %ecx
    je    LBB0_2
    movss    4(%rsp), %xmm0          ## 4-byte Reload
    movss    (%rsp), %xmm1           ## 4-byte Reload
    callq    __Z3fooff
    xorl    %eax, %eax
    addq    $8, %rsp
    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  Wed Jun 29 04:10:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 04:10:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10222] New: llc -O0 crash somehow due to debug info
Message-ID: <bug-10222-206@http.llvm.org/bugs/>

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

           Summary: llc -O0 crash somehow due to debug info
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: baldrick at free.fr
                CC: llvmbugs at cs.uiuc.edu


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

$ llc -O0 921206-1.ll
...
3  llc       0x0000000000cc8394
__gnu_cxx::new_allocator<llvm::MachineBasicBlock*>::construct(llvm::MachineBasicBlock**,
llvm::MachineBasicBlock* const&) + 52
4  llc       0x0000000000cc79de std::vector<llvm::MachineBasicBlock*,
std::allocator<llvm::MachineBasicBlock*> >::push_back(llvm::MachineBasicBlock*
const&) + 64
5  llc       0x0000000001103b18
llvm::MachineBasicBlock::addSuccessor(llvm::MachineBasicBlock*, unsigned int) +
194

Here llc runs out of memory because it is trying to push an infinite number
of basic block successors into the vector.

I don't see how debug info could be causing this, but if you strip debug info
then the problem goes 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  Wed Jun 29 06:31:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 06:31:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10223] New: Segmentation fault with inline assembly
Message-ID: <bug-10223-206@http.llvm.org/bugs/>

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

           Summary: Segmentation fault with inline assembly
           Product: clang
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: sas at cd80.net
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6799)
 --> (http://llvm.org/bugs/attachment.cgi?id=6799)
Stack trace of clang

The following C source makes clang segfault where it should just display an
error message and quit. Note that the second operand of the `mov` instruction
is %o instead of %0.

int main(void)
{
  void *esp;
  __asm__ volatile ("mov %%esp, %o" : "=r"(esp) : : );
  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 Jun 29 07:49:54 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 07:49:54 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10224] New: iostream broken in clang++
Message-ID: <bug-10224-206@http.llvm.org/bugs/>

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

           Summary: iostream broken in clang++
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


The simple iostream example code...

// basic file operations
#include <iostream>
#include <fstream>
using namespace std;

int main () {
  ofstream myfile;
  myfile.open ("example.txt");
  myfile << "Writing this to a file.\n";
  myfile.close();
  return 0;
}

is miscompiled by clang++ svn r134030 at all optimization levels. The default
optimization fails as...

[MacPro:~] howarth% /sw/opt/llvm-3.0/bin/clang++ test.cc
Stack dump:
0.    Program arguments: /sw/opt/llvm-3.0/bin/clang-3.0 -cc1 -triple
x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name test.cc -pic-level 1 -mdisable-fp-elim
-masm-verbose -munwind-tables -target-cpu core2 -resource-dir
/sw/opt/llvm-3.0/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 177 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/cc-47ABTv.o -x c++ test.cc 
1.    <eof> parser at end of file
2.    Code generation
3.    Running pass 'Function Pass Manager' on module 'test.cc'.
4.    Running pass 'X86 DAG->DAG Instruction Selection' on function
'@__cxx_global_var_init'
clang-3: error: unable to execute command: Segmentation fault: 11
clang-3: error: clang frontend command failed due to signal 2 (use -v to see
invocation)

which backtraces as...


[MacPro:~] howarth% gdb /sw/opt/llvm-3.0/bin/clang-3.0
GNU gdb 6.3.50-20050815 (Apple version gdb-1657) (Tue May 17 04:19:06 UTC 2011)
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 "x86_64-apple-darwin"...Reading symbols for shared
libraries ... done

(gdb) r  -cc1 -triple x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all
-disable-free -disable-llvm-verifier -main-file-name test.cc -pic-level 1
-mdisable-fp-elim -masm-verbose -munwind-tables -target-cpu core2 -resource-dir
/sw/opt/llvm-3.0/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 177 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/cc-47ABTv.o -x c++ test.cc 
Starting program: /sw/opt/llvm-3.0/bin/clang-3.0 -cc1 -triple
x86_64-apple-macosx10.7.0 -emit-obj -mrelax-all -disable-free
-disable-llvm-verifier -main-file-name test.cc -pic-level 1 -mdisable-fp-elim
-masm-verbose -munwind-tables -target-cpu core2 -resource-dir
/sw/opt/llvm-3.0/bin/../lib/clang/3.0 -fdeprecated-macro -ferror-limit 19
-fmessage-length 177 -stack-protector 1 -fblocks -fcxx-exceptions -fexceptions
-fdiagnostics-show-option -fcolor-diagnostics -o
/var/folders/1l/n78sywl52lz6kkys6nv7mnph0000gp/T/cc-47ABTv.o -x c++ test.cc
Reading symbols for shared libraries ++......................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: KERN_INVALID_ADDRESS at address: 0x00000039010f0090
0x0000000100a95497 in llvm::MachineInstr::MachineInstr ()
(gdb) bt
#0  0x0000000100a95497 in llvm::MachineInstr::MachineInstr ()
#1  0x0000000100a8f79e in llvm::MachineFunction::CreateMachineInstr ()
#2  0x000000010079fb61 in (anonymous namespace)::X86FastISel::DoSelectCall ()
#3  0x0000000100794624 in (anonymous
namespace)::X86FastISel::TargetSelectInstruction ()
#4  0x0000000100918925 in llvm::FastISel::SelectInstruction ()
#5  0x00000001009fca59 in llvm::SelectionDAGISel::SelectAllBasicBlocks ()
#6  0x00000001009fbc19 in llvm::SelectionDAGISel::runOnMachineFunction ()
#7  0x0000000100a9339e in llvm::MachineFunctionPass::runOnFunction ()
#8  0x0000000100d88061 in llvm::FPPassManager::runOnFunction ()
#9  0x0000000100d882fb in llvm::FPPassManager::runOnModule ()
#10 0x0000000100d88496 in llvm::MPPassManager::runOnModule ()
#11 0x0000000100d88a38 in llvm::PassManagerImpl::run ()
#12 0x0000000100d88f4d in llvm::PassManager::run ()
#13 0x0000000100117786 in clang::EmitBackendOutput ()
#14 0x00000001001fd335 in clang::BackendConsumer::HandleTranslationUnit ()
#15 0x00000001002dd913 in clang::ParseAST ()
#16 0x00000001001fc555 in clang::CodeGenAction::ExecuteAction ()
#17 0x0000000100279c9a in clang::CompilerInstance::ExecuteAction ()
#18 0x00000001002aee38 in clang::ExecuteCompilerInvocation ()
#19 0x0000000100005b77 in cc1_main ()
#20 0x0000000100001526 in main ()
(gdb) 

At -O1 and higher, the compiler doesn't ICE but the resulting executable
crashes with a segmentation fault...


[MacPro:~] howarth% /sw/opt/llvm-3.0/bin/clang++ -O1 -g  test.cc
[MacPro:~] howarth% gdb ./a.out
GNU gdb 6.3.50-20050815 (Apple version gdb-1657) (Tue May 17 04:19:06 UTC 2011)
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 "x86_64-apple-darwin"...Reading symbols for shared
libraries ... done

(gdb) r
Starting program: /Users/howarth/a.out 
Reading symbols for shared libraries ++......................... done

Program received signal EXC_BAD_ACCESS, Could not access memory.
Reason: 13 at address: 0x0000000000000000
0x00007fff8f06d6cd in misaligned_stack_error_entering_dyld_stub_binder ()
(gdb) bt
#0  0x00007fff8f06d6cd in misaligned_stack_error_entering_dyld_stub_binder ()
#1  0x00000001000010b0 in pvars ()
#2  0x0000000100001030 in pvars ()
#3  0x00007fff5fc0fd1a in
__dyld__ZN16ImageLoaderMachO18doModInitFunctionsERKN11ImageLoader11LinkContextE
()
#4  0x00007fff5fc0fa66 in
__dyld__ZN16ImageLoaderMachO16doInitializationERKN11ImageLoader11LinkContextE
()
#5  0x00007fff5fc0d258 in
__dyld__ZN11ImageLoader23recursiveInitializationERKNS_11LinkContextEjRNS_21InitializerTimingListE
()
#6  0x00007fff5fc0e02b in
__dyld__ZN11ImageLoader15runInitializersERKNS_11LinkContextERNS_21InitializerTimingListE
()
#7  0x00007fff5fc034ad in __dyld__ZN4dyld24initializeMainExecutableEv ()
#8  0x00007fff5fc07580 in __dyld__ZN4dyld5_mainEPK12macho_headermiPPKcS5_S5_ ()
#9  0x00007fff5fc01059 in __dyld__dyld_start ()
(gdb)

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 29 08:17:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 08:17:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10224] iostream broken in clang++
In-Reply-To: <bug-10224-206@http.llvm.org/bugs/>
References: <bug-10224-206@http.llvm.org/bugs/>
Message-ID: <20110629131751.F35772A6C12E@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #3 from Duncan Sands <baldrick at free.fr> 2011-06-29 08:17:51 CDT ---
According to the reporter this works at 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  Wed Jun 29 11:19:03 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 11:19:03 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10225] New: Mysterious llvm-ld error "Global
 metadata operand cannot be function local"
Message-ID: <bug-10225-206@http.llvm.org/bugs/>

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

           Summary: Mysterious llvm-ld error "Global metadata operand
                    cannot be function local"
           Product: new-bugs
           Version: 2.9
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: new bugs
        AssignedTo: unassignedbugs at nondot.org
        ReportedBy: srk31 at srcf.ucam.org
                CC: llvmbugs at cs.uiuc.edu


I'm getting the following error on a run of llvm-ld. This is from the 2.9
release, built Release+Debug+Asserts for x86_64 on a FC13 machine.

$ llvm-ld -lpthread -Lout/host/linux-x86/pr/sim/obj/lib/llvm
-Lout/host/linux-x86/pr/sim/obj/lib/llvm -L\$ORIGIN/../lib/llvm
-Lout/host/linux-x86/pr/sim/obj/lib/llvm
out/host/linux-x86/pr/sim/obj/EXECUTABLES/audioloop_intermediates/SineSource.o.bc
out/host/linux-x86/pr/sim/obj/EXECUTABLES/audioloop_intermediates/audioloop.o.bc
-l=stagefright -l=log -l=utils -l=binder -o
out/host/linux-x86/pr/sim/obj/EXECUTABLES/audioloop_intermediates/LINKED/audioloop.bc
Global metadata operand cannot be function local!
metadata !34477
metadata !{null}
Broken module found, compilation aborted!
0  llvm-ld         0x00000000008708cf
1  llvm-ld         0x0000000000872b1a
2  libpthread.so.0 0x0000003b7f60f4a0
3  libc.so.6       0x0000003b7ea328f5 gsignal + 53
4  libc.so.6       0x0000003b7ea340d5 abort + 373
5  llvm-ld         0x000000000082c8e8
6  llvm-ld         0x000000000080852d
llvm::FPPassManager::runOnFunction(llvm::Function&) + 557
7  llvm-ld         0x000000000080862b
llvm::FPPassManager::runOnModule(llvm::Module&) + 75
8  llvm-ld         0x00000000008080b7
llvm::MPPassManager::runOnModule(llvm::Module&) + 503
9  llvm-ld         0x0000000000808237 llvm::PassManagerImpl::run(llvm::Module&)
+ 167
10 llvm-ld         0x00000000004a7d9f llvm::Optimize(llvm::Module*) + 495
11 llvm-ld         0x00000000004ac5f6 main + 1510
12 libc.so.6       0x0000003b7ea1ec5d __libc_start_main + 253
13 llvm-ld         0x00000000004a75f9
Stack dump:
0.      Program arguments: llvm-ld -lpthread
-Lout/host/linux-x86/pr/sim/obj/lib/llvm
-Lout/host/linux-x86/pr/sim/obj/lib/llvm -L$ORIGIN/../lib/llvm
-Lout/host/linux-x86/pr/sim/obj/lib/llvm
out/host/linux-x86/pr/sim/obj/EXECUTABLES/audioloop_intermediates/SineSource.o.bc
out/host/linux-x86/pr/sim/obj/EXECUTABLES/audioloop_intermediates/audioloop.o.bc
-l=stagefright -l=log -l=utils -l=binder -o
out/host/linux-x86/pr/sim/obj/EXECUTABLES/audioloop_intermediates/LINKED/audioloop.bc 
1.      Running pass 'Function Pass Manager' on module
'out/host/linux-x86/pr/sim/obj/EXECUTABLES/audioloop_intermediates/LINKED/audioloop.bc'.
2.      Running pass 'Module Verifier' on function
'@_GLOBAL__I__ZN7android10DataSource9getUInt16ExPt'

This is using a Release+Debug+Asserts build of the LLVM 2.9 release.

The input files have all been built in (I think) the standard way. To reproduce
the bug, I guess you have to try it on this input yourself. Here's a tarball
that should have what you need (apologies for the additional chaff):
<http://www.cs.ox.ac.uk/people/stephen.kell/private/llvm-bug-20110629.tar.gz>

Background: I'm trying to build a large source tree (namely Android) as LLVM
bitcode. I'm doing so based on a vanilla build ("lunch sim-eng" in Android
build-speak) that uses gcc/binutils to output native binaries. I've hacked the
build system to generate bitcode alongside these. 

In case there's something fishy about how I'm building the bitcode objects,
here's the make -n log, hopefully including mostly (only) relevant stuff.
<http://www.cs.ox.ac.uk/people/stephen.kell/private/llvm-bug-20110629-build-log.txt>

Thanks for any suggestions!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 29 13:16:30 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 13:16:30 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8363] [inline asm] Assertion `PartVT.isInteger() &&
 ValueVT.isInteger() && "Unknown mismatch!"' failed
In-Reply-To: <bug-8363-206@http.llvm.org/bugs/>
References: <bug-8363-206@http.llvm.org/bugs/>
Message-ID: <20110629181630.C6C552A6C124@llvm.org>

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

Eric Christopher <echristo at gmail.com> changed:

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

--- Comment #3 from Eric Christopher <echristo at gmail.com> 2011-06-29 13:16:29 CDT ---
This appears to be fixed from the front end side of things.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 29 13:49:51 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 13:49:51 -0500 (CDT)
Subject: [LLVMbugs] [Bug 5776] "use of undeclared identifier" error should
 scan namespaces
In-Reply-To: <bug-5776-206@http.llvm.org/bugs/>
References: <bug-5776-206@http.llvm.org/bugs/>
Message-ID: <20110629184951.89EC92A6C12E@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-29 13:49:50 CDT ---
Implemented by Kaelyn Uhrain in a series of patches leading up to r134039.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 29 15:01:43 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 15:01:43 -0500 (CDT)
Subject: [LLVMbugs] [Bug 7330] miscompile of SPEC CPU2006's 450.soplex
In-Reply-To: <bug-7330-206@http.llvm.org/bugs/>
References: <bug-7330-206@http.llvm.org/bugs/>
Message-ID: <20110629200143.BD0822A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #5 from Duncan Sands <baldrick at free.fr> 2011-06-29 15:01:42 CDT ---
I think this was fixed a while ago, but the reporter did not confirm.

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

From bugzilla-daemon at llvm.org  Wed Jun 29 16:22:31 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 16:22:31 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10013] Scope of extern declarations extend past
	enclosing block
In-Reply-To: <bug-10013-206@http.llvm.org/bugs/>
References: <bug-10013-206@http.llvm.org/bugs/>
Message-ID: <20110629212231.D1B292A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #3 from Douglas Gregor <dgregor at apple.com> 2011-06-29 16:22:31 CDT ---
I've committed Jordy's patch in Clang r134097. Thanks, Jordy!

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 29 19:59:06 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 19:59:06 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10226] New: -O1 produces binary that valgrind
	complains about
Message-ID: <bug-10226-206@http.llvm.org/bugs/>

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

           Summary: -O1 produces binary that valgrind complains about
           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: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu


I noticed that valgrind would complain about a clang compiled clang, but not a
gcc compiled clang. I reduced it to _ZNK5clang4Expr21refersToVectorElementEv
being "miscompiled" (at least producing code that valgrind doesn't like.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 29 23:17:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 23:17:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3105] TwoAddressInstructionPass fails to correctly
 handle instruction with multiple results and constraints
In-Reply-To: <bug-3105-206@http.llvm.org/bugs/>
References: <bug-3105-206@http.llvm.org/bugs/>
Message-ID: <20110630041750.D541D2A6C12D@llvm.org>

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

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> 2011-06-29 23:17:49 CDT ---
I think this was fixed a while back. Inline assembly can do the same an any
target.

llc < t.ll  -march=xcore -mcpu=xs1b-generic
    .file    "<stdin>"
    .text
    .globl    test
    .align    2
    .type    test, at function
    .cc_top test.function,test      # @test
test:
# BB#0:                                 # %entry
    mov r2, r1
    ldc r1, 0
    mov r3, r1
    maccs r1, r3, r0, r2
    mov r0, r3
    retsp 0
    .cc_bottom test.function
.Ltmp0:
    .size    test, .Ltmp0-test

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

From bugzilla-daemon at llvm.org  Wed Jun 29 23:34:17 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Wed, 29 Jun 2011 23:34:17 -0500 (CDT)
Subject: [LLVMbugs] [Bug 3315] Error on the attached file
In-Reply-To: <bug-3315-206@http.llvm.org/bugs/>
References: <bug-3315-206@http.llvm.org/bugs/>
Message-ID: <20110630043418.471C62A6C12C@llvm.org>

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

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

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

--- Comment #3 from Jakob Stoklund Olesen <stoklund at 2pi.dk> 2011-06-29 23:34:17 CDT ---
Seems to be working now.

$ clang -g -c t.c
$ dwarfdump t.o
----------------------------------------------------------------------
 File: t.o (x86_64)
----------------------------------------------------------------------
.debug_info contents:

0x00000000: Compile Unit: length = 0x00000080  version = 0x0002  abbr_offset =
0x00000000  addr_size = 0x08  (next CU at 0x00000084)

0x0000000b: TAG_compile_unit [1] *
             AT_producer( "clang version 3.0 (trunk 134120)" )
             AT_language( DW_LANG_C99 )
             AT_name( "t.c" )
             AT_entry_pc( 0x0000000000000000 )
             AT_stmt_list( 0x00000000 )
             AT_comp_dir( "/Volumes/Krask/b" )

0x00000050:     TAG_subprogram [2] *
                 AT_sibling( {0x0000007c} )
                 AT_name( "f" )
                 AT_decl_file( "/Volumes/Krask/b/t.c" )
                 AT_decl_line( 2 )
                 AT_prototyped( 0x01 )
                 AT_external( 0x01 )
                 AT_low_pc( 0x0000000000000000 )
                 AT_high_pc( 0x0000000000000042 )
                 AT_frame_base( rbp )

0x0000006d:         TAG_formal_parameter [3]  
                     AT_name( "len" )
                     AT_decl_file( "/Volumes/Krask/b/t.c" )
                     AT_decl_line( 1 )
                     AT_type( {0x0000007c} ( int ) )
                     AT_location( fbreg -12 )

0x0000007b:         NULL

0x0000007c:     TAG_base_type [4]  
                 AT_encoding( DW_ATE_signed )
                 AT_name( "int" )
                 AT_byte_size( 0x04 )

0x00000083:     NULL

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 07:29:37 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 07:29:37 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10227] New: Add OS.h for OpenBSD
Message-ID: <bug-10227-206@http.llvm.org/bugs/>

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

           Summary: Add OS.h for OpenBSD
           Product: dragonegg
           Version: trunk
          Platform: Other
        OS/Version: OpenBSD
            Status: NEW
          Severity: normal
          Priority: P
         Component: New Bugs
        AssignedTo: baldrick at free.fr
        ReportedBy: jsg at openbsd.org
                CC: llvmbugs at cs.uiuc.edu


Created an attachment (id=6806)
 --> (http://llvm.org/bugs/attachment.cgi?id=6806)
OpenBSD OS.h for dragonegg

The following is a s/FreeBSD/OpenBSD/ of the FreeBSD OS.h header.  dragonegg
seems to work fine here in basic testing with dragonegg svn and gcc 4.6.1
(+patches to make gcc build) on OpenBSD/amd64 -current.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 07:33:45 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 07:33:45 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10227] Add OS.h for OpenBSD
In-Reply-To: <bug-10227-206@http.llvm.org/bugs/>
References: <bug-10227-206@http.llvm.org/bugs/>
Message-ID: <20110630123345.1652C2A6C124@llvm.org>

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

Duncan Sands <baldrick at free.fr> changed:

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

--- Comment #1 from Duncan Sands <baldrick at free.fr> 2011-06-30 07:33:44 CDT ---
Thanks for the patch - applied here:
http://lists.cs.uiuc.edu/pipermail/llvm-commits/Week-of-Mon-20110627/123212.html

Note that dragonegg with gcc-4.6 is not completely stable yet compared with
gcc-4.5 - there are some problems with C++.

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

From bugzilla-daemon at llvm.org  Thu Jun 30 09:28:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 09:28:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10228] New: Crash on -dealloc in category with ARC
	enabled
Message-ID: <bug-10228-206@http.llvm.org/bugs/>

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

           Summary: Crash on -dealloc in category with ARC enabled
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: LLVM Codegen
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: csdavec at swan.ac.uk
                CC: llvmbugs at cs.uiuc.edu


Compiling this file crashes clang:

@interface NSObject
{
    Class isa;
}
@end
@interface Foo : NSObject @end

@implementation Foo (Private)
- (void) dealloc {}
@end

This works when I target the NeXT runtime, but not when I target the GNU
runtime, but the crash appears to be in runtime-agnostic code, which is
confusing me.  This is the back trace:

#0  0x00007ffff45eb415 in raise (sig=<value optimized out>)
    at ../nptl/sysdeps/unix/sysv/linux/raise.c:64
#1  0x00007ffff45ee690 in abort () at abort.c:92
#2  0x00007ffff45e45c1 in __assert_fail (
    assertion=0x177e600 "isa<X>(Val) && \"cast<Ty>() argument of incompatible
type!\"", file=<value optimized out>, line=194, 
    function=0x177edc0 "typename llvm::cast_retty<To, From>::ret_type
llvm::cast(const Y&) [with X = clang::ObjCImplementationDecl, Y = const
clang::DeclContext*, typename llvm::cast_retty<To, From>::ret_type = const
clang::"...)
    at assert.c:81
#3  0x0000000000d8da16 in llvm::cast<clang::ObjCImplementationDecl,
clang::DeclContext const*> (Val=@0x7fffffffb848)
    at /build/theraven/llvm/include/llvm/Support/Casting.h:194
#4  0x0000000000d807fd in (anonymous namespace)::FinishARCDealloc::Emit (
    this=0x7fffffffb970, CGF=..., isForEH=false) at CGObjC.cpp:224
#5  0x0000000000d092d4 in EmitCleanup (CGF=..., Fn=0x7fffffffb970, 
    ForEH=false, ActiveFlag=0x0) at CGCleanup.cpp:459
#6  0x0000000000d09e92 in clang::CodeGen::CodeGenFunction::PopCleanupBlock (
    this=0x7fffffffbd60, FallthroughIsBranchThrough=false) at CGCleanup.cpp:665
#7  0x0000000000d08e70 in clang::CodeGen::CodeGenFunction::PopCleanupBlocks (
    this=0x7fffffffbd60, Old=...) at CGCleanup.cpp:374
#8  0x0000000000e001e1 in clang::CodeGen::CodeGenFunction::FinishFunction (
    this=0x7fffffffbd60, EndLoc=...) at CodeGenFunction.cpp:150
#9  0x0000000000d812c9 in clang::CodeGen::CodeGenFunction::GenerateObjCMethod (
    this=0x7fffffffbd60, OMD=0x1fb48b0) at CGObjC.cpp:324
#10 0x0000000000cbd16c in clang::CodeGen::CodeGenModule::EmitTopLevelDecl (
    this=0x1fa60f0, D=0x1fb48b0) at CodeGenModule.cpp:2161
#11 0x0000000000cb1a83 in (anonymous
namespace)::CodeGeneratorImpl::HandleTopLevelDecl (this=0x1f862b0, DG=...) at
ModuleBuilder.cpp:65
#12 0x0000000000cb0eaa in clang::BackendConsumer::HandleTopLevelDecl (
    this=0x1f86120, D=...) at CodeGenAction.cpp:86
#13 0x0000000000e20b0f in clang::ParseAST (S=..., PrintStats=false)
    at ParseAST.cpp:85
#14 0x0000000000b7330d in clang::ASTFrontendAction::ExecuteAction (
    this=0x1f730d0) at FrontendAction.cpp:379
#15 0x0000000000cb051c in clang::CodeGenAction::ExecuteAction (this=0x1f730d0)
    at CodeGenAction.cpp:341
#16 0x0000000000b72f69 in clang::FrontendAction::Execute (this=0x1f730d0)
    at FrontendAction.cpp:299
#17 0x0000000000b58cd9 in clang::CompilerInstance::ExecuteAction (
    this=0x1f713a0, Act=...) at CompilerInstance.cpp:601
#18 0x0000000000aff3f3 in clang::ExecuteCompilerInvocation (Clang=0x1f713a0)
    at ExecuteCompilerInvocation.cpp:166
#19 0x0000000000af07d6 in cc1_main (ArgBegin=0x7fffffffce30, 
    ArgEnd=0x7fffffffcf68, 
    Argv0=0x1f65338 "/build/theraven/llvm/Debug+Asserts/bin/clang", 

The problem is in frame #3 - it is trying to cast the -dealloc method's context
to a class implementation context, when it is actually a category
implementation context.  I'm not sure why this would work with the Mac
runtime...

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 12:24:49 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 12:24:49 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10230] New: UNREACHABLE: non-canonical or dependent
 type in IR-generation
Message-ID: <bug-10230-206@http.llvm.org/bugs/>

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

           Summary: UNREACHABLE: non-canonical or dependent type in
                    IR-generation
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++0x
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: zilla at kayari.org
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


template<bool, typename T = void> struct enable_if { };
template<typename T> struct enable_if<true, T> { typedef T type; };

template<typename... E> struct tuple { explicit tuple(E...) { } };

template<typename... Elements>
    struct make_tuple
    {
        template<typename... Args>
            static typename
            enable_if<sizeof...(Args)==sizeof...(Elements),
                      tuple<Elements...>>::type
            make(Args&&... args)
            {
                return tuple<Elements...>{ Elements(args)... };
            }
    };

int main()
{
    make_tuple<short, int, short>::make(1, '2', 3.0);
}

$ clang++ -v
clang version 3.0 (trunk 134169)
Target: x86_64-unknown-linux-gnu
Thread model: posix
$
$ clang++ -std=c++0x make_tuple2.cc
non-canonical or dependent type in IR-generation
UNREACHABLE executed at
/home/wakelj/src/llvm/llvm/tools/clang/lib/CodeGen/CodeGenFunction.cpp:64!
...

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

From bugzilla-daemon at llvm.org  Thu Jun 30 15:16:24 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 15:16:24 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10231] New: no error on inline function with static
	variable
Message-ID: <bug-10231-206@http.llvm.org/bugs/>

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

           Summary: no error on inline function with static variable
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


C99 6.7.4 paragraph 3 reads:

"An inline definition of a function with external linkage shall not contain a
definition of a modifiable object with static storage duration, and shall not
contain a reference to an identifier with internal linkage."

which does not appear to be implemented by clang:

nlewycky at ducttape:~$ cat x.c
inline int* foo() {
  static int x;
  return &x;
}
nlewycky at ducttape:~$ clang x.c -std=c99 -Wall -pedantic -fsyntax-only
nlewycky at ducttape:~$ 

GCC notices this and offers a warning:

nlewycky at ducttape:~$ gcc x.c -std=c99 -fsyntax-only
x.c: In function ?foo?:
x.c:2: warning: ?x? is static but declared in inline function ?foo? which is
not static

but I really think that warning should be an error (downgrading it to a warning
is fine as an extension so long as you go ahead and detect bad uses of it, such
as taking its address).

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 15:21:39 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 15:21:39 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10223] Segmentation fault with inline assembly
In-Reply-To: <bug-10223-206@http.llvm.org/bugs/>
References: <bug-10223-206@http.llvm.org/bugs/>
Message-ID: <20110630202139.5667E2A6C124@llvm.org>

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

Hans Wennborg <hans at chromium.org> changed:

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

--- Comment #3 from Hans Wennborg <hans at chromium.org> 2011-06-30 15:21:39 CDT ---
Fixed in r134183.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 16:33:09 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 16:33:09 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10232] New: Assertion failed: (isa<X>(Val) &&
 "cast<Ty>() argument of incompatible type!"), function cast,
 file llvm/include/llvm/Support/Casting.h, line 194
Message-ID: <bug-10232-206@http.llvm.org/bugs/>

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

           Summary: Assertion failed: (isa<X>(Val) && "cast<Ty>() argument
                    of incompatible type!"), function cast, file
                    llvm/include/llvm/Support/Casting.h, line 194
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: etlverified at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


I am trying to compile a project that I am working on using clang. I've got the
latest trunk from svn:

clang version 3.0 (trunk 134187)
Target: x86_64-apple-darwin10.7.4
Thread model: posix

I am encountering the error pasted below. Please let me know if I can provide
any other information that can be useful:

Assertion failed: (isa<X>(Val) && "cast<Ty>() argument of incompatible type!"),
function cast, file llvm/include/llvm/Support/Casting.h, line 194.
0  clang             0x00000001019146f2
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
754
1  clang             0x0000000101915543
llvm::SmallVectorTemplateBase<llvm_regmatch_t, false>::grow(unsigned long) +
4419
2  libSystem.B.dylib 0x00007fff801cc66a _sigtramp + 26
3  libSystem.B.dylib 0x000000010281d600 _sigtramp + 2187661232
4  clang             0x000000010001a732
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 4146
5  clang             0x00000001004a479d llvm::cast_retty<clang::Decl,
clang::DeclContext*>::ret_type llvm::cast_or_null<clang::Decl,
clang::DeclContext>(clang::DeclContext*) + 147805
6  clang             0x00000001004a49c7 llvm::cast_retty<clang::Decl,
clang::DeclContext*>::ret_type llvm::cast_or_null<clang::Decl,
clang::DeclContext>(clang::DeclContext*) + 148359
7  clang             0x000000010037d5ab
clang::PragmaOpenCLExtensionHandler::~PragmaOpenCLExtensionHandler() + 18411
8  clang             0x000000010037e219
clang::PragmaOpenCLExtensionHandler::~PragmaOpenCLExtensionHandler() + 21593
9  clang             0x000000010037e6b0
clang::PragmaOpenCLExtensionHandler::~PragmaOpenCLExtensionHandler() + 22768
10 clang             0x0000000100329852
llvm::CrashRecoveryContextDeleteCleanup<clang::Sema>::~CrashRecoveryContextDeleteCleanup()
+ 2498
11 clang             0x0000000100329238
llvm::CrashRecoveryContextDeleteCleanup<clang::Sema>::~CrashRecoveryContextDeleteCleanup()
+ 936
12 clang             0x000000010034d937
clang::Parser::DeclaratorScopeObj::EnterDeclaratorScope() + 44231
13 clang             0x000000010034f4ba
clang::Parser::DeclaratorScopeObj::EnterDeclaratorScope() + 51274
14 clang             0x00000001003386cc clang::Parser::ConsumeAnyToken() +
50604
15 clang             0x00000001003866e6
clang::Sema::NameClassification::getType() const + 19446
16 clang             0x0000000100387702
clang::Sema::NameClassification::getType() const + 23570
17 clang             0x0000000100387af1
clang::Sema::NameClassification::getType() const + 24577
18 clang             0x000000010033e069 clang::Parser::ConsumeAnyToken() +
73545
19 clang             0x0000000100397158
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 62344
20 clang             0x0000000100397d7a
llvm::SmallVectorTemplateBase<clang::ParsedTemplateArgument,
false>::grow(unsigned long) + 65450
21 clang             0x0000000100328a5b clang::ABIArgInfo::getCoerceToType()
const + 523
22 clang             0x00000001002f371c llvm::DenseMap<clang::GlobalDecl, long
long, llvm::DenseMapInfo<clang::GlobalDecl>, llvm::DenseMapInfo<long long>
>::grow(unsigned int) + 2188
23 clang             0x0000000100059ad1 llvm::DenseMap<clang::IdentifierInfo
const*, unsigned int, llvm::DenseMapInfo<clang::IdentifierInfo const*>,
llvm::DenseMapInfo<unsigned int> >::grow(unsigned int) + 9073
24 clang             0x0000000100024f27 llvm::raw_ostream::operator<<(char
const*) + 1687
25 clang             0x000000010001ba51
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 9041
26 clang             0x0000000100023d5e std::vector<std::string,
std::allocator<std::string> >::operator=(std::vector<std::string,
std::allocator<std::string> > const&) + 13390
27 clang             0x000000010001ae84
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*>
>::_M_insert_aux(__gnu_cxx::__normal_iterator<llvm::PassRegistrationListener**,
std::vector<llvm::PassRegistrationListener*,
std::allocator<llvm::PassRegistrationListener*> > >,
llvm::PassRegistrationListener* const&) + 6020
Stack dump:
0.    Program arguments: software/clang/bin/clang -cc1 -triple
x86_64-apple-macosx10.6.7 -emit-obj -mrelax-all -disable-free -main-file-name
Partitioner.C -pic-level 1 -mdisable-fp-elim -masm-verbose -munwind-tables
-target-cpu core2 -target-linker-version 123.2 -coverage-file
.libs/Partitioner.o -resource-dir software/clang/bin/../lib/clang/3.0 -D
HAVE_CONFIG_H -D BOOST_REGEX_MATCH_EXTRA -D PIC -I . -I
../../../../src/frontend/Disassemblers -I ../../.. -I ../../../src/roseSupport
-I ../../../src/frontend/SageIII -I ../../../../src -I
../../../../src/frontend/SageIII -I ../../../../src/frontend/SageIII/astFixup
-I ../../../../src/frontend/SageIII/astPostProcessing -I
../../../../src/frontend/SageIII/astMerge -I
../../../../src/frontend/SageIII/astVisualization -I
../../../../src/frontend/SageIII/astFileIO -I
../../../../src/frontend/SageIII/sageInterface -I
../../../../src/frontend/SageIII/virtualCFG -I
../../../../src/frontend/SageIII/astTokenStream -I
../../../../src/frontend/SageIII/astHiddenTypeAndDeclarationLists -I
../../../src/frontend/SageIII/astFileIO -I
../../../../src/frontend/SageIII/astFromString -I
../../../../src/frontend/OpenFortranParser_SAGE_Connection -I
../../../../src/frontend/ECJ_ROSE_Connection -I
../../../../src/frontend/PHPFrontend -I ../../../../src/frontend/PythonFrontend
-I ../../../../src/frontend/BinaryDisassembly -I
../../../../src/frontend/BinaryFormats -I ../../../../src/frontend/BinaryLoader
-I ../../../../src/frontend/Disassemblers -I ../../../../src/backend/unparser
-I ../../../../src/backend/unparser/formatSupport -I
../../../../src/backend/unparser/languageIndependenceSupport -I
../../../../src/backend/unparser/CxxCodeGeneration -I
../../../../src/backend/unparser/JavaCodeGeneration -I
../../../../src/backend/unparser/FortranCodeGeneration -I
../../../../src/backend/unparser/PHPCodeGeneration -I
../../../../src/backend/unparser/PythonCodeGeneration -I
../../../../src/backend/asmUnparser -I ../../../../src/util -I
../../../../src/util/support -I ../../../../src/util/graphs -I
../../../../src/util/stringSupport -I
../../../../src/util/commandlineProcessing -I
../../../../src/midend/abstractHandle -I ../../../../src/midend/astDiagnostics
-I ../../../../src/midend/programTransformation/astInlining -I
../../../../src/midend/programTransformation/astOutlining -I
../../../../src/midend/astProcessing -I ../../../../src/midend/astQuery -I
../../../../src/midend/astRewriteMechanism -I
../../../../src/midend/astUtil/annotation -I
../../../../src/midend/astUtil/astInterface -I
../../../../src/midend/astUtil/astSupport -I
../../../../src/midend/astUtil/symbolicVal -I
../../../../src/midend/binaryAnalyses -I
../../../../src/midend/binaryAnalyses/dataflowanalyses -I
../../../../src/midend/binaryAnalyses/instructionSemantics -I
../../../../src/midend/programTransformation/loopProcessing/computation -I
../../../../src/midend/programTransformation/loopProcessing/depGraph -I
../../../../src/midend/programTransformation/loopProcessing/depInfo -I
../../../../src/midend/programTransformation/loopProcessing/driver -I
../../../../src/midend/programTransformation/loopProcessing/outsideInterface -I
../../../../src/midend/programTransformation/loopProcessing/prepostTransformation
-I ../../../../src/midend/programTransformation/ompLowering -I
../../../../src/midend/programAnalysis -I
../../../../src/midend/programAnalysis/annotationLanguageParser -I
../../../../src/midend/programAnalysis/CFG -I
../../../../src/midend/programAnalysis/CallGraphAnalysis -I
../../../../src/midend/programAnalysis/OAWrap -I
../../../../src/midend/programAnalysis/dataflowAnalysis -I
../../../../src/midend/programAnalysis/defUseAnalysis -I
../../../../src/midend/programAnalysis/distributedMemoryAnalysis -I
../../../../src/midend/programAnalysis/dominanceAnalysis -I
../../../../src/midend/programAnalysis/graphAnalysis -I
../../../../src/midend/programAnalysis/pointerAnal -I
../../../../src/midend/programAnalysis/staticInterproceduralSlicing -I
../../../../src/midend/programAnalysis/valuePropagation -I
../../../../src/midend/programAnalysis/variableRenaming -I
../../../../src/midend/programTransformation/partialRedundancyElimination -I
../../../../src/midend/programTransformation/finiteDifferencing -I
../../../../src/midend/programTransformation/functionCallNormalization -I
../../../../src/midend/programTransformation/constantFolding -I
../../../../src/midend/programTransformation/implicitCodeGeneration -I
../../../../src/roseSupport -I ../../../../src/3rdPartyLibraries/MSTL -I
../../../../src/3rdPartyLibraries/libharu-2.1.0/include -I
../../../src/3rdPartyLibraries/libharu-2.1.0/include -I
../../../../src/3rdPartyLibraries/qrose/Framework -I
../../../../src/3rdPartyLibraries/qrose/Widgets -I ../../../../src/util/graphs
-I ../../../../src/midend/astUtil/astInterface -I ../../../../libltdl -I
macports/include -fdeprecated-macro -ferror-limit 19 -fmessage-length 146
-stack-protector 1 -fblocks -fcxx-exceptions -fexceptions -fno-common
-fdiagnostics-show-option -fcolor-diagnostics -o .libs/Partitioner.o -x c++
../../../../src/frontend/Disassemblers/Partitioner.C 
1.   
../../../../src/midend/binaryAnalyses/instructionSemantics/x86InstructionSemantics.h:2521:24:
current parser token ')'
2.   
../../../../src/midend/binaryAnalyses/instructionSemantics/x86InstructionSemantics.h:30:1:
parsing struct/union/class body 'X86InstructionSemantics'
3.   
../../../../src/midend/binaryAnalyses/instructionSemantics/x86InstructionSemantics.h:716:55:
parsing function try block 'translate'
clang: error: unable to execute command: Illegal instruction
clang: error: clang frontend command failed due to signal 2 (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  Thu Jun 30 17:30:57 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 17:30:57 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10233] New: extern keyword for inline definition
 should trigger function emission
Message-ID: <bug-10233-206@http.llvm.org/bugs/>

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

           Summary: extern keyword for inline definition should trigger
                    function emission
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: Linux
            Status: NEW
          Severity: normal
          Priority: P
         Component: -New Bugs
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nlewycky at google.com
                CC: llvmbugs at cs.uiuc.edu


This file:

  inline double ms2kph(double ms)
  {
    return (ms * 3.6);
  }
  extern double ms2kph(double ms);

when compiled in C99 mode should produce a definition of ms2kph, but it does
not. GCC gets this right:

nlewycky at ducttape:~$ gcc -std=c99 z.c -c -o z.o
nlewycky at ducttape:~$ nm z.o
0000000000000000 T ms2kph
nlewycky at ducttape:~$ clang -std=c99 z.c -c -o z.o
nlewycky at ducttape:~$ nm z.o
nlewycky at ducttape:~$ 

The relevant rule in C99 6.7.4/6 is "If all of the file scope declarations for
a function in a translation unit include the inline function specifier without
extern, then the definition in that translation unit is an inline definition.
An inline definition does not provide an external definition ...".

The example in para 7/8 makes the intended behaviour much more clear.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 18:25:56 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 18:25:56 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10234] New: clang should warn if a class and its
 subclass have a method with the same signature but no "virtual" in base
 class
Message-ID: <bug-10234-206@http.llvm.org/bugs/>

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

           Summary: clang should warn if a class and its subclass have a
                    method with the same signature but no "virtual" in
                    base class
           Product: clang
           Version: trunk
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: nicolasweber at gmx.de
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Consider

class A {
public:
  void f() {}
};

class B : public A {
public:
  void f() {}
};

It is likely that B::m is supposed to be an override of A::m, but "virtual" is
missing. We should add this warning and check how noisy it is. If it's not
noisy, it should be added to the -Wall group.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 19:05:27 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 19:05:27 -0500 (CDT)
Subject: [LLVMbugs] [Bug 8835] Clang crash with dependent
 exception-specification on function pointer
In-Reply-To: <bug-8835-206@http.llvm.org/bugs/>
References: <bug-8835-206@http.llvm.org/bugs/>
Message-ID: <20110701000527.151D02A6C12D@llvm.org>

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

Douglas Gregor <dgregor at apple.com> changed:

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

--- Comment #1 from Douglas Gregor <dgregor at apple.com> 2011-06-30 19:05:26 CDT ---
This is fixed on top-of-tree.

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

From bugzilla-daemon at llvm.org  Thu Jun 30 19:39:46 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 19:39:46 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10235] New: error: unknown machine mode 'V8QI' is
 an unclear warning from clang
Message-ID: <bug-10235-206@http.llvm.org/bugs/>

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

           Summary: error: unknown machine mode 'V8QI' is an unclear
                    warning from clang
           Product: clang
           Version: trunk
          Platform: Macintosh
        OS/Version: MacOS X
            Status: NEW
          Severity: normal
          Priority: P
         Component: Frontend
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: howarth at nitro.med.uc.edu
                CC: llvmbugs at cs.uiuc.edu


When compiling...

    typedef int v8qi __attribute__ ((mode(V8QI)));

in clang, the compilation fails with the cryptic error message...

[MacPro:~] howarth% clang -c unclear_warning.c
unclear_warning.c:1:38: error: unknown machine mode 'V8QI'
    typedef int v8qi __attribute__ ((mode(V8QI)));
                                     ^
1 error generated.

whereas llvm-gcc produces the very helpful warning...

[MacPro:~] howarth% llvm-gcc -c unclear_warning.c
unclear_warning.c:1: warning: specifying vector types with __attribute__
((mode)) is deprecated
unclear_warning.c:1: warning: use __attribute__ ((vector_size)) instead

that properly identifies the origin of the compilation failure in clang. Clang
should be enhanced
to provide similar warnings for fully depreciated attributes like mode.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 20:12:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 20:12:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10096] Early tail dup can cause problems to
	register allocator
In-Reply-To: <bug-10096-206@http.llvm.org/bugs/>
References: <bug-10096-206@http.llvm.org/bugs/>
Message-ID: <20110701011250.5E2472A6C12E@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

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

--- Comment #26 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-06-30 20:12:49 CDT ---
I tried jsinterp.o with 134215 (old) and 134216 (new) with and without taildup
(2). The results:

-rw-r--r--  1 espindola  staff  1619864 30 Jun 20:31 new.o
-rw-r--r--  1 espindola  staff  2074040 30 Jun 20:32 old.o
-rw-r--r--  1 espindola  staff  1448936 30 Jun 21:07 new2.o
-rw-r--r--  1 espindola  staff  1448936 30 Jun 21:06 old2.o

I will declare this fixed by 134216. I can open new PRs if I find more
problems.

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

From bugzilla-daemon at llvm.org  Thu Jun 30 20:15:50 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 20:15:50 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10089] Lots of spills generated
In-Reply-To: <bug-10089-206@http.llvm.org/bugs/>
References: <bug-10089-206@http.llvm.org/bugs/>
Message-ID: <20110701011550.878712A6C12E@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

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

--- Comment #2 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-06-30 20:15:50 CDT ---
Fixed in 134216.

-- 
Configure bugmail: http://llvm.org/bugs/userprefs.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 Jun 30 22:37:11 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 22:37:11 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10236] New: Crash with -g
Message-ID: <bug-10236-206@http.llvm.org/bugs/>

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

           Summary: Crash with -g
           Product: clang
           Version: unspecified
          Platform: PC
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P
         Component: C++
        AssignedTo: unassignedclangbugs at nondot.org
        ReportedBy: rafael.espindola at gmail.com
                CC: llvmbugs at cs.uiuc.edu, dgregor at apple.com


Created an attachment (id=6807)
 --> (http://llvm.org/bugs/attachment.cgi?id=6807)
jsalloc.ii

clang -cc1 -triple x86_64-apple-macosx10.6.8 -emit-llvm -x c++-cpp-output
jsalloc.ii -g -w
Segmentation fault

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

From bugzilla-daemon at llvm.org  Thu Jun 30 22:50:22 2011
From: bugzilla-daemon at llvm.org (bugzilla-daemon at llvm.org)
Date: Thu, 30 Jun 2011 22:50:22 -0500 (CDT)
Subject: [LLVMbugs] [Bug 10236] Crash with -g
In-Reply-To: <bug-10236-206@http.llvm.org/bugs/>
References: <bug-10236-206@http.llvm.org/bugs/>
Message-ID: <20110701035022.DD6552A6C12D@llvm.org>

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

Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> changed:

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

--- Comment #1 from Rafael ?vila de Esp?ndola <rafael.espindola at gmail.com> 2011-06-30 22:50:22 CDT ---
Fixed with a git pull. Sorry for the noise.

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